Got it. I’ll dig into the pros and cons of using Palo Alto's Advanced Routing engine versus the classic virtual router in PAN-OS 11.2.8, particularly when managed through Panorama. I’ll also check whether Palo Alto plans to deprecate or sunset support for the legacy virtual router, and if any timelines have been announced.I’ll let you know once I’ve pulled everything together.
Advanced Routing Engine vs Legacy Virtual Router in PAN-OS 11.2.8
Overview
Palo Alto Networks introduced the Advanced Routing Engine (ARE) in PAN-OS 10.2 as a modern replacement for the traditional Virtual Router routing engine. In PAN-OS 11.2.8, both routing engines are available: the legacy Virtual Router (VR) and the newer Advanced Routing Engine. Advanced Routing must be explicitly enabled (via a checkbox in Device > Setup > Management) and requires a reboot to switch the firewall over to the new enginedocs.paloaltonetworks.com. When enabled, a built-in migration script can convert existing virtual router configurations into the new advanced routing (logical router) formatdocs.paloaltonetworks.com. Below, we compare feature differences, performance implications, Panorama management considerations, and migration concerns between the two, followed by a list of pros and cons of moving to Advanced Routing. We also discuss any known plans for deprecating the legacy Virtual Router.
Feature and Configuration Differences
Logical Routers vs Virtual Routers: In the Advanced Routing Engine, virtual routers are replaced by logical routers, which serve the same purpose in routing but are managed differentlydocs.paloaltonetworks.comdocs.paloaltonetworks.com. Unlike the legacy engine, the advanced engine does not automatically create a default router instance – an admin must create logical routers as needed after enabling advanced routingdocs.paloaltonetworks.com. The number of logical routers supported is the same as the number of virtual routers supported on a given firewall modeldocs.paloaltonetworks.com.Routing Profiles and Policies: The legacy VR configuration allowed certain shortcuts (for example, defining route filters or export rules without attaching them to any peer/neighbor), and each VR maintained its own separate set of profiles/policies. In contrast, the advanced engine uses a more standards-based configuration with reusable profiles and explicit attachments. Routing profiles (prefix-lists, route maps, etc.) in Advanced Routing are defined globally per virtual system and can be reused across multiple logical routers, instead of being siloed per VR as in the legacy enginedocs.paloaltonetworks.com. This means you can create a prefix-list or route-map once and apply it to multiple peers or protocols across different logical routers, improving configuration consistency and reducing duplicationdocs.paloaltonetworks.com. (In the legacy engine, profiles with the same name under different VRs could conflict during migration, since the advanced engine treats them as shared objectsdocs.paloaltonetworks.com.) Additionally, the advanced engine does not allow “orphaned” routing policy rules or filters (unattached to any neighbor or protocol) – any such unused objects in the legacy config will be skipped by the migrationdocs.paloaltonetworks.com.Dynamic Routing Protocol Features: Both engines support common dynamic routing protocols (BGP, OSPFv2/v3, RIPv2, static routes, etc.), but the Advanced Routing Engine introduces enhanced capabilities and a configuration style similar to traditional routers. For example, BGP configuration on the advanced engine supports modern features like multiple address families (IPv4/IPv6) over a single BGP peering – meaning one BGP session can carry both IPv4 and IPv6 routes if both sides support itdocs.paloaltonetworks.com. (Legacy VR required separate BGP instances or sessions for IPv4 vs IPv6 peering.) The advanced engine also introduced support for multicast routing enhancements (e.g. Multicast Source Discovery Protocol, MSDP) which were added for the advanced stack in PAN-OS 11.0docs.paloaltonetworks.com. Overall, Palo Alto has achieved near feature parity between the advanced engine and the legacy engine for unicast routing by PAN-OS 10.2.4 and later, and in many cases advanced routing offers more flexibility. For instance, route filtering and redistribution are more granular in the advanced engine – you can create profile-based filters (access lists, prefix lists, AS-path filters, route maps with conditions, etc.) and apply them to control route import/export and even which routes get installed in the RIB (Routing Information Base)docs.paloaltonetworks.com. The legacy VR did support route redistribution and filtering via import/export rules, but the advanced engine’s use of standard route-map logic provides finer control (including the ability to filter routes before they enter the RIB)docs.paloaltonetworks.com. Advanced Routing also provides many tunable protocol parameters via profiles – for example, BGP timers, authentication, route dampening, and BFD – which can be applied per neighbor or peer group easilydocs.paloaltonetworks.com. Essentially, the Advanced Routing Engine “aligns with widespread configuration methodologies in the networking industry,” making it more familiar to engineers used to Cisco/Juniper style routing configurationsdocs.paloaltonetworks.com. The GUI and CLI for advanced routing reflect this; for example, route map and prefix-list objects are first defined and then applied to protocols, rather than the more monolithic style of the legacy VR.One minor difference to note is how route tags are represented: the legacy engine used a dotted decimal format for route tags (e.g. 10.1.7.1), whereas the advanced engine uses a simple 32-bit integer format (decimal) for tags (e.g. 1234567). During migration, any existing route tags are automatically converted to the new format with no loss of informationdocs.paloaltonetworks.com.Feature Gaps: As of PAN-OS 11.2, there are no significant feature gaps in unicast routing – the advanced engine supports all major protocols that the legacy VR did, and more. (Earlier in PAN-OS 10.2, the advanced engine was marked “preview” until it matured, but by 10.2.4 it had full support for BGP, OSPFv2/v3, RIP, etc., and even additional features.) For multicast, advanced routing now supports PIM-SM and related features, matching legacy capabilities and extending them (with MSDP, as noted). In short, Advanced Routing can do everything the Virtual Router could do, using a more flexible and modular configuration approach, plus offers new capabilities (like richer route filtering and combined IPv4/IPv6 BGP peering) not available in the old VRdocs.paloaltonetworks.com.
Performance and Architecture Implications
Under the hood, the Advanced Routing Engine has a different architecture designed for scalability and reliability. In legacy PAN-OS, all dynamic routing protocols ran under a single routed process (one process handling BGP, OSPF, RIP, etc. for all VRs). By contrast, the Advanced Routing Engine isolates each logical router and protocol into separate processes and Linux network namespacesa.storyblok.com. This means, for example, that each logical router (LR) runs its own RIB management daemon, and each routing protocol (BGP, OSPF, etc.) enabled on that LR runs in its own process context. If a particular protocol is not enabled, its daemon isn’t running at all on that LR, conserving resourcesa.storyblok.com. This process isolation improves reliability – a crash or issue in one protocol instance would only affect that protocol in one logical router, not the entire routing enginea.storyblok.com. It also can improve performance on multi-core management planes, as different protocol processes can potentially execute in parallel (whereas the legacy single routed process was single-threaded). Each logical router’s dedicated network namespace provides improved security and separation as well, preventing any unintended interaction between routes of different VR/LR instancesa.storyblok.com.From a performance standpoint, route convergence and handling of large routing tables should be at least as good as (and likely better than) the legacy engine. The Advanced Routing Engine is effectively running a more modern routing software stack (internally, it is similar to industry-standard routing daemons), so it benefits from more optimized algorithms for things like BGP best path selection and OSPF calculations. Palo Alto has indicated that the advanced engine brings improved reliability and flexibility without changing forwarding behavior (the data-plane forwarding of traffic remains the same)a.storyblok.com. In practice, many of the performance implications are positive: better stability under load and the ability to handle complex routing policies more gracefully.One consideration is that the advanced engine might use slightly more memory/CPU overhead on the management plane, since separate processes and additional data structures are in play. On higher-end hardware this is negligible, but very low-end models have hardware limitations – in fact, some smaller firewall models do not support the advanced engine at all (more on this below). For supported devices, Palo Alto’s tests have shown the advanced engine to be stable. (During the early adoption phase, some users encountered bugs – e.g. issues with static route conversion in PAN-OS 10.2.4 – but these have been addressed in later maintenance releaseswww.reddit.comlive.paloaltonetworks.com.) By PAN-OS 11.2.8, the Advanced Routing Engine is considered mature and fully supported. There is no inherent data-plane throughput penalty for using Advanced Routing; the differences are in the control-plane. Administrators should plan a maintenance window for the one-time reboot to switch engines, but after that, routing should operate normally, with potential improvements in how the firewall handles routing updates (especially in complex BGP environments).
Panorama Management and Migration Considerations
Managing Advanced Routing via Panorama introduces some important planning steps. Panorama (as of version 10.2 and later) is capable of pushing advanced routing configurations to managed firewalls, but all devices in a given template stack should use the same routing engine mode (either all using legacy VR or all using advanced LRs)docs.paloaltonetworks.com. Palo Alto Networks explicitly advises creating separate device groups/templates for firewalls with Advanced Routing enabled vs. those using the legacy enginedocs.paloaltonetworks.com. This is because Panorama will not push an advanced routing configuration to a firewall that doesn’t support it or hasn’t been enabled for it – if it detects a lower-end model or a device in legacy mode, it will skip the advanced config and only push legacy VR config (if present)docs.paloaltonetworks.com.Migration Process via Panorama: If you have an existing deployment with legacy Virtual Routers managed by Panorama, moving to Advanced Routing is a multi-step process. Palo Alto’s recommended procedure is:
- Enable Advanced Routing on Panorama (in the template’s General Settings) and commit+push the config to the firewalls. This converts the Panorama-stored network configuration for that template to the new advanced routing format (logical routers, profiles, etc.).
- On each managed firewall, enable Advanced Routing locally but do not commit yet. (In other words, toggle the Advanced Routing setting on the firewall itself to initiate the on-box migration for that device’s local config.)
- Commit on the firewall to run the local migration script and then reboot the firewall to complete the engine switchdocs.paloaltonetworks.com.
- The firewall will come up with Advanced Routing enabled and both the Panorama-pushed config and local (formerly VR) config migrated to logical routers. At this point, all routing configuration should be under the advanced engine on both Panorama and the firewall.
This two-phase approach ensures that both Panorama’s template config and the firewall’s local config (including any device-specific static routes or interface/VR assignments) are migrated. The built-in migration script runs on the firewall when you enable Advanced Routing, converting each Virtual Router and its contents into a Logical Router configdocs.paloaltonetworks.com. Panorama itself will also perform a conversion of its template definitions when you flip the switch in Panorama. Palo Alto provides a color-coded migration status output to highlight any issues (for example, if certain settings don’t directly translate to the new engine). A green status means everything converted with no issues; yellow/orange indicates some differences that were adjusted or features that use different parameters in the new engine (requiring review), and red indicates a migration failure that needs manual attentiondocs.paloaltonetworks.comdocs.paloaltonetworks.com. In most cases, migrations come out green or yellow. Common adjustments might include renaming duplicate profiles or alerting if an old feature is unsupported. (For instance, any “orphaned” policy rules in a VR that were not applied to a neighbor are not migrateddocs.paloaltonetworks.com, since the advanced engine requires policies to be attached to something. These would show as a warning to be re-created if needed in the new structure.)It’s worth noting that a reboot is required after enabling/disabling Advanced Routing on a devicedocs.paloaltonetworks.com. This means that pushing the Panorama template change to enable advanced routing will trigger a reboot of each firewall (after commit) to actually activate the new engine. Administrators should schedule downtime accordingly when migrating. The firewalls should be backed up before migration (Panorama will have the current config, but best practice is to export a backup)docs.paloaltonetworks.com. Palo Alto’s migration process preserves the original VR configuration so that you can revert if necessary. In fact, if something goes wrong or you choose to roll back, you can disable Advanced Routing on the firewall and reboot, and the firewall will return to using the legacy VR configuration (the original config is retained separately). It’s still prudent to have manual backups, but the system is designed to allow a rollback to the pre-migration state if needed.Panorama Version Compatibility: Ensure Panorama itself is running a version that supports Advanced Routing (Panorama 10.2 or 11.x for managing PAN-OS 11.2 devices). Panorama 11.x can manage both legacy and advanced routing configurations, but again, it cannot mix them within the same configuration context for a given firewall. Some Panorama-managed deployments have reported commit errors if the configurations are inconsistent (for example, an “
advance-routing unexpected here” error can occur if Panorama tries to push advanced routing config to a device not in advanced mode or vice-versa, indicating a mismatch in config mode). These issues are avoided by following the recommended migration steps and separating device groups by routing engine. After migration, day-to-day management via Panorama is fully supported – you’ll manage Logical Routers (and their routing profiles) under the Panorama templates’ Network tab instead of Virtual Routers. The look and feel in Panorama for editing an advanced Logical Router is slightly different (reflecting the new profiles and options), but it is intuitive once familiar.
Pros of Moving to Advanced Routing Engine
Moving from the legacy Virtual Router to the Advanced Routing Engine offers several advantages:
- Greater Feature Set and Flexibility: Advanced Routing unlocks newer capabilities like route-map based filtering and conditional route control, prefix-lists/AS-path filters, and support for both IPv4 and IPv6 address families in a single BGP sessiondocs.paloaltonetworks.com. These features enable more sophisticated routing policies than were possible with the legacy VR. The advanced engine also supports all major routing protocols (BGP, OSPFv2/v3, RIP, PIM) with feature parity and additional enhancements (e.g. MSDP for multicast) that the legacy engine either lacked or handled less flexiblydocs.paloaltonetworks.comdocs.paloaltonetworks.com.
- Standards-Based Configuration (Easier Management): The configuration model in the Advanced Routing Engine is aligned with industry-standard router CLI/logic, which can shorten the learning curvedocs.paloaltonetworks.com. Concepts like logical routers, reusable route policy profiles, and BGP peer groups with inheritance make it easier for network engineers to manage complex configs. For example, you can define a prefix-list once and use it across multiple neighbors or protocols, instead of duplicating it in each VRdocs.paloaltonetworks.com. This not only reduces errors but also simplifies managing large configurations via Panorama or automation.
- Improved Reliability and Stability: Because each protocol runs in its own process and each logical router is isolated, the routing engine becomes more robusta.storyblok.com. A fault in one routing protocol (say an OSPF process crash or a BGP issue) will not bring down all routing on the box, as could theoretically happen with the single-process legacy engine. This isolation also means changes or flaps in one VR (logical router) have less performance impact on others. The advanced engine’s design of “protocols on demand” (only running what is needed) can lead to a leaner runtime profile and avoid any one process getting overloadeda.storyblok.com.
- Potential Performance Benefits: The Advanced Routing Engine is designed to scale on modern hardware. With multiple processes, it can utilize multi-core CPUs better than the single-threaded legacy
routedprocess. This is beneficial in route-heavy environments (e.g. multiple full BGP tables or many OSPF areas). Routing convergence might be faster or more deterministic under the advanced engine due to optimized code. Additionally, the option to filter routes before inserting into the RIB can save precious TCAM/FIB space on smaller firewalls by only installing necessary routesdocs.paloaltonetworks.com – something not possible with legacy VR – which indirectly helps performance on constrained devices. - Future-Proofing (Longevity of Support): Palo Alto Networks has made it clear that new routing features will be developed for the Advanced Routing Engine moving forward, not for the legacy VR. By migrating now, you position your network to take advantage of future improvements. It also means your configuration is aligned with what PANW considers the strategic path. (As noted below, the legacy engine will eventually be phased out, so moving to the advanced engine is a forward-looking choice.)
- Panorama and GUI Support: The advanced engine is fully supported in the GUI and Panorama, so you retain centralized management and visibility. The GUI actually provides a more convenient experience for some advanced routing features – for instance, defining BGP peer groups and applying profile objects is straightforward. All the familiar show commands have equivalents (e.g.
show routing routeis replaced withshow advanced-routing routein CLI for logical routers), and there are new troubleshooting commands specific to the advanced engine. In short, management workflows are well-supported, and many users find the new routing UI more user-friendly once they get used to it, due to organized profiles and color-coded status indicators for logical routers. - Commit Safety Checks: The migration process includes validation (color-coded results) and won’t cut over until issues (if any) are resolveddocs.paloaltonetworks.com. This reduces the risk of accidental misconfiguration during the transition. You also have the ability to revert to the legacy VR with your original config if something doesn’t work out, providing a safety net during migration.
Cons and Considerations (Potential Drawbacks)
Despite the benefits, there are some considerations or downsides to moving to Advanced Routing that you should weigh:
- Migration Effort and Downtime: Switching to the Advanced Routing Engine requires a reboot of each firewalldocs.paloaltonetworks.com, causing downtime. The migration process, while assisted by scripts, still requires careful planning, backup, and verification. In a Panorama-managed environment, the process is multi-step (Panorama template conversion, then device-by-device conversion) and may be labor-intensive for large deployments. During the transition, there’s a period of potential disruption as routes are migrated and the engine is swapped. If your network is stable and relatively simple under the legacy VR, the motto “if it isn’t broken, don’t fix it” could argue for deferring this change until necessary.
- Learning Curve and New CLI: Administrators familiar with the legacy PAN-OS routing interface will need to learn the new configuration syntax and CLI commands for advanced routing. While it is more industry-standard, it is a change – for example, scripts or automation tools that interacted with the old
routedCLI or XML API may need updates (because commands likeset network virtual-routerare replaced withset network logical-router, and certain CLI outputs likeshow routing routeare deprecated in favor of new commands). There may be a period of adjustment and potential for misconfiguration if one is not yet comfortable with the new structure. - Stability of New Codebase (Initial Bugs): The Advanced Routing Engine was a major architectural change, and earlier releases (PAN-OS 10.2.x) revealed some bugs or behavioral differences. By PAN-OS 11.2.8 most of these issues have been ironed out, but it’s inherently less “battle-tested” than the legacy VR which has been stable for many years. Some administrators have reported needing to tweak configurations post-migration – for example, certain static route behaviors or OSPF default metric settings had minor differences that required attention (these were highlighted during migration with warnings). There is a slight risk that in complex routing scenarios, you might encounter a software issue that wouldn’t have existed in the legacy engine. Palo Alto has been actively fixing such issues in maintenance releases, but this risk is something to consider (especially if your environment pushes the limits of routing features).
- Compatibility with Lower-End Models: A significant limitation is that not all PA firewall models support the Advanced Routing Engine. Small branch models like the PA-220, PA-220R, and the older PA-800 series (PA-820, PA-850) are currently not supported for advanced routinga.storyblok.com. These devices lack the hardware resources (CPU/RAM) required to run the new routing daemons. If your deployment includes such models, you cannot enable Advanced Routing on them – they must continue using the legacy Virtual Router. This can complicate management if you have a mix of supported and unsupported devices. You would need to either upgrade those smaller devices or maintain separate configuration sets. (Panorama will automatically stick to legacy VR config for those unitsdocs.paloaltonetworks.com, but that means you’d be managing two different routing configurations in parallel.) This is a major consideration for organizations with distributed sites on smaller PA boxes.
- Panorama Template Segmentation: As mentioned, Panorama cannot push a single config to both engine types simultaneously. You may need to refactor your Panorama templates and device groups. For example, if you previously had one template with a VR config applied to all firewalls, and now half will use advanced routing, you must split those into different templates. This adds to management overhead, at least until all firewalls are migrated. It’s a one-time reorganization, but it is effort nonetheless.
- No Immediate Benefit for Simple Routing: If your firewall’s routing needs are very simple (e.g. just a handful of static routes or a small OSPF deployment), the Advanced Routing Engine might not provide a tangible benefit to justify the change. The legacy VR is fully capable of basic routing, and if you don’t need the new features, you might not see an operational improvement after migration. In such cases, the main reason to move would be future-proofing rather than solving a current problem. Some teams choose to wait until they require a feature exclusive to the advanced engine (or until Palo Alto announces an end-of-support date for the legacy engine) before undertaking the migration.
- Potential Resource Usage: While not usually an issue on medium-to-large platforms, the advanced engine’s multiple processes and profiles do consume a bit more memory and CPU on the management plane. On devices with many logical routers and neighbors, you’ll want to monitor the management CPU/RAM after enabling advanced routing. The difference is not huge, but on the flip side, the legacy single-process engine was quite lightweight. If a firewall is already under heavy management-plane load (for example, with thousands of routes, SNMP polling, etc.), you should ensure it has headroom before switching. Palo Alto’s documentation does not call out any specific scaling downgrade with Advanced Routing – in fact, all documented maximums (like max BGP peers, routes, etc.) are equal or higher with the new engine – but it’s wise to be mindful of system resources during the transition.
Future Support and Deprecation Plans
Palo Alto Networks has indicated that the legacy Virtual Router (legacy routing engine) will eventually be phased out in favor of the Advanced Routing Engine. Already, as of PAN-OS 11.x, new routing features are developed only for the Advanced engine, and the legacy engine is in a maintenance mode. The writing on the wall is that at some future PAN-OS release, the option to use the legacy VR may be removed entirely. In a Palo Alto Networks presentation to users, the company explicitly noted “Legacy Routing Engine to be phased out” and emphasized that all future enhancements will be on the advanced engine. While an exact PAN-OS version for deprecation hasn’t been officially announced (publicly) as of early 2025, it’s expected that once a vast majority of customers have migrated and the advanced engine has proven itself over a couple of major releases, Palo Alto will drop support for the old VR. This could potentially happen in an upcoming PAN-OS 12.x timeframe or beyond, but again, no firm date has been stated in official documentation yet.Administrators should keep an eye on PAN-OS release notes and support advisories. Already, PAN-OS 10.1 (which has only the legacy engine) is a mature release and newer hardware platforms encourage using PAN-OS 10.2+ (with advanced routing available). It would not be surprising if within a year or two, Palo Alto makes Advanced Routing the default (and only) option for new releases, especially since feature parity has been achieved and the advanced engine is stable. The presence of an in-place migration tool shows Palo Alto’s intent to facilitate this transition.In summary, there is no immediate forced requirement to switch – PAN-OS 11.2.8 fully supports the legacy VR for now – but the trend and guidance from Palo Alto clearly favor moving to the Advanced Routing Engine sooner rather than later. Organizations planning long-term should consider migrating in a planned way, rather than waiting until an end-of-life announcement creates urgency. By migrating, you also ensure access to the latest routing capabilities and avoid falling behind as the legacy engine becomes “frozen” in terms of features.