One use case for configuring service routes at the virtual
system level is when a large customer (such as an ISP) needs to
support multiple individual tenants on a single Palo Alto Networks
firewall. The ISP has configured virtual systems on the firewall, and
wants to have separate service routes for each virtual system, rather
than services routes configured at the global level. Each tenant
requires service route capabilities so that it can customize service
route parameters for DNS, email, Kerberos, LDAP, NetFlow, RADIUS,
SNMP trap, syslog, TACACS+, User-ID Agent, and VM Monitor.
Another use case is an IT organization that wants to provide
full autonomy to groups that set servers for services. Each group
can have a virtual system and define its own service routes.
If Multi Virtual System Capability is enabled, any virtual system
that does not have specific service routes configured inherits the
global service and service route settings for the firewall.
An organization can have multiple virtual systems, but use a
global service route for a service rather than different service
routes for each virtual system. For example, the firewall can use
a shared email server to originate email alerts to its virtual systems.
A firewall with multiple virtual systems must have interfaces
and subinterfaces with non-overlapping IP addresses.
A per-virtual system service route for SNMP traps or for Kerberos
is for IPv4 only.
You can select a virtual router for a service route in a virtual
system; you cannot select the egress interface. After you select
the virtual router and the firewall sends the packet from the virtual
router, the firewall selects the egress interface based on the destination
IP address. Therefore:
If a virtual system has multiple virtual routers, packets
to all of the servers for a service must egress out of only one
A packet with an interface source address may egress a different
interface, but the return traffic would be on the interface that
has the source IP address, creating asymmetric traffic.