F5 Networking: Egress VLAN, Route and IP selection

Exam Topics

• F5CAB2
  • F5CAB2.01
    • Identify, based on traffic, which VLAN/route/egress IP would be used
  • F5CAB2.03
    • Determine the egress source IP based on configuration

Introduction

In the Listener Processing Order course, we saw how the F5 BIG-IP handles incoming client connections and determines which listener will process the traffic, such as a Virtual Server, NAT, or SNAT object. We also examined what happens when multiple objects could match the same traffic and how the system decides which one takes precedence.

In the opposite direction, when the F5 BIG-IP generates traffic toward other devices such as backend servers, Active Directory, syslog servers, or any external service, it must determine which interface, VLAN, and source IP address to use. Understanding this decision process is essential when troubleshooting connectivity or routing issues.

Why Egress VLAN, Route, and IP Selection Matters

An F5 BIG-IP system typically hosts multiple interfaces.
For example, in a dual-armed deployment, the device commonly has an external interface facing clients and an internal interface connected to backend servers. In addition, the BIG-IP also includes a management interface used for administrative access.

Each interface can host multiple Self IP addresses. These addresses can be configured as floating or non-floating.

Floating Self IP addresses move between devices in a High Availability (HA) pair and are always owned by the active device. In contrast, non-floating Self IP addresses remain tied to the specific device on which they are configured and do not move during a failover.

Now imagine the following scenario: a client connects to a virtual server exposed on the external interface, and the session must then be forwarded to a backend server located on the internal network.

At that point, several questions arise:

• Which source IP address will the F5 BIG-IP use when initiating the connection to the backend server?

• Through which VLAN or interface will the traffic leave the device?

• Which route from the routing table will be selected?

The same questions also apply to health monitoring. To verify the availability of backend servers, the BIG-IP regularly sends health checks. These monitoring requests must also choose a source IP address, VLAN, and route before being sent to the server.

Understanding how the BIG-IP makes these decisions is essential when designing architectures or troubleshooting connectivity issues.

Egress Traffic Principle

When the F5 BIG-IP generates traffic to a remote host, it follows a simple decision process:

• It first checks the routing table and selects the most specific destination route using the longest prefix match.

• The selected route determines the outgoing VLAN used to reach the destination.

• Based on that VLAN, the F5 BIG-IP selects the appropriate Self IP or IP address as the source IP address.

This process ensures that the traffic exits through the correct network while using the correct source IP address.

Routing Table Check

The routing table lookup on the F5 BIG-IP works the same way as on a traditional router. When traffic needs to be sent to a destination, the system searches the routing table and selects the most specific matching entry using the longest prefix match.

This lookup determines the next-hop IP address to reach the destination.

The next hop can be:

• A directly connected network. In this case, the BIG-IP already knows which VLAN is associated with that subnet and will use that VLAN as the egress interface.

• A remote network reachable through a gateway. In this case, the BIG-IP performs a recursive route lookup to determine how to reach the gateway, which ultimately identifies the correct outgoing VLAN.

In this example, the longest prefix match is the 172.16.10.0/24 route, which dictates that the traffic will exit through the External VLAN. Although the packet also matches the 172.16.0.0/16 route, which uses the Internal VLAN, this route is less specific and is therefore not selected.

Once the outgoing VLAN has been determined by the routing table, the BIG-IP must still decide which source IP address to use. Because a VLAN can contain multiple Self IP addresses (like floating and non-floating Self-IP), the system selects the source IP based on the type of traffic being generated.

Source IP Selection

The third step, after consulting the routing table to determine the egress VLAN, is selecting the appropriate source IP address for the outgoing packet.

The source IP selection depends on the type of traffic being generated. It may come from a statically configured object, such as when a specific source IP is defined for certain features, from the Self IP used for health monitors, or from the SNAT Auto Map mechanism when source translation is required.

NAT, SNAT and Virtual Servers Without SNAT

For statically configured objects such as NAT, SNAT, or a Virtual Server without SNAT, the source IP address used by the BIG-IP is explicitly defined by the configuration.

For example:

• A Virtual Server configured with no SNAT preserves the original client source IP address when forwarding traffic to the backend server.

• A SNAT or NAT object uses the translated source address configured in the object.

In this example, a SNAT object is configured, so the source IP address used for the outgoing traffic is defined by the statically configured Address Translation field. In this case, regardless of the destination or egress VLAN, the source IP address of the packet will always be 192.168.10.1.

Health Monitors

Health monitors are executed by each device in an HA cluster independently. This means every unit must be able to perform its own health checks toward the backend servers.

For this reason, the most appropriate source address for monitoring traffic is typically the non-floating Self IP of the egress VLAN, since it is tied to a specific device rather than shared between HA members.

This approach allows each unit to monitor the servers independently. If the active unit encounters an issue while the passive unit does not, the health checks, being performed independently on each device, may lead to a failover, allowing the passive unit to take over service.

SNAT Automap

When configuring a Virtual Server, you can enable SNAT Automap as the address translation method. This feature allows the BIG-IP to automatically select a suitable Self IP address to use as the source address instead of requiring the administrator to manually configure one.

SNAT is commonly used to prevent asymmetric routing, ensuring that return traffic from the backend server flows back through the BIG-IP.

When SNAT Automap is enabled, the BIG-IP selects a source address using the following priority order:

1. Floating Self IP addresses on the egress VLAN

2. Floating Self IP addresses on other VLANs

3. Non-floating Self IP addresses on the egress VLAN

4. Non-floating Self IP addresses on other VLANs

If a floating Self IP exists on the egress VLAN, it will be selected first. However, if no floating Self IP is available on that VLAN, the system will attempt to use a floating Self IP from another VLAN before falling back to a non-floating address on the correct VLAN.

This behavior prioritizes floating addresses over non-floating ones. Floating Self IPs are preferred in an HA pair because they move with the active device during failover, ensuring continuity of service. In contrast, non-floating Self IPs remain tied to a specific device.

In this example, the administrator has configured only a non-floating Self IP on the Datacenter VLAN, which is the egress interface used to reach the servers. However, a floating Self IP is configured on the External VLAN.

In this scenario, because floating Self IP addresses are preferred by the SNAT Automap feature, the system selects the External VLAN floating Self IP (172.16.0.1) as the source IP when contacting the servers.

As a result, traffic to the servers uses 172.16.0.1, rather than the more intuitive choice of the non-floating Self IP associated with the outgoing Datacenter VLAN (192.168.1.1).

However, depending on the network design, selecting a floating Self IP from another VLAN may lead to routing issues or unexpected traffic paths, so administrators should validate the routing behavior when relying on SNAT Automap.

Management

Until now, we have reviewed how routing, VLAN, and source IP selection is handled on the production interfaces tied to the TMM context (data plane).

However, the management interface behaves differently and deserves its own discussion. It is possible to generate traffic that uses the management interface instead of a TMM interface. This is often useful for service-related traffic, such as Syslog, NTP, SNMP, or other management communications. In these cases, it can be preferable for the traffic to use the management interface rather than a production data interface, ensuring that operational or monitoring traffic remains isolated from application traffic.

In these cases, specific routes must be configured as management routes to ensure that the traffic is correctly sent through the management interface, bypassing the production TMM interfaces.

TMM and Management routing system

On an F5 BIG-IP system, there is a single routing table, but routes can originate from two different contexts: the TMM data plane (production interfaces) and the management plane, which uses the dedicated management interface.

If you want traffic to exit through the management interface, you must configure a management route instead of a standard TMM route. Management routes can only be created using tmsh.

When management routes are inserted into the routing table, they are automatically assigned a higher metric than routes created in the TMM context. Because of this, when two routes have the same prefix length, the BIG-IP prefers the TMM route, and traffic exits through the production interface rather than the management interface.

However, the longest prefix match rule still applies. If a management route has a more specific prefix than a TMM route, the management route will be selected despite its higher metric.

For example, if the routing table contains a TMM route for 10.10.10.0/24 and a management route for 10.10.10.10/32, traffic destined for 10.10.10.10 will follow the management route, because /32 is more specific than /24.

Similarly, if a default route (0.0.0.0/0) is configured for both the TMM and the management interface, the TMM default route will be preferred because both prefixes are equal and the TMM route has a lower metric. On the other hand, if only a management default route exists and no TMM route matches the destination, the traffic will exit through the management interface.

In summary, when prefix lengths are equal, TMM routes take precedence over management routes.

Verifying the Routing and Source IP Selection

Now that we have reviewed how the routing table is used and how the outgoing VLAN and source IP address are selected, let’s look at some practical ways to review and validate the configuration.

Checking the routing table

From the command line, you can display the full routing table (including both TMM and management routes) using the following commands in bash:

route

or

netstat -rn

Here is an example output :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
8.8.4.4         192.168.150.1   255.255.255.255 UG    4096    0        0 mgmt
8.8.0.0         192.168.10.10   255.255.0.0     UGH   0       0        0 Internal
8.8.0.0         192.168.150.1   255.255.0.0     U     0       0        0 mgmt

When examining the output, you will notice that TMM routes use a metric of 0, while management routes use a metric of 4096.

As with any router, the longest prefix match rule applies first. The route with the most specific prefix is selected. If multiple routes share the same prefix length, the route with the lowest metric is preferred. Because TMM routes have a lower metric than management routes, they are selected when the prefix length is equal.

In the following example:

• Traffic destined for 8.8.4.4 uses the management interface, because the management route has the most specific prefix.

• Traffic destined for 8.8.8.8 matches two routes with the same prefix length, so the route with the lower metric (0) is selected, meaning the traffic exits through the TMM interface.

From the routing table, you can determine which interface will be used.

Checking the configured routes

You can review the TMM routes configured on the system from the Configuration Utility by navigating to Network > Routes.

From the command line, you can also display these routes in tmsh using list net route command:

root@(mybigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net route
net route LargeRoute {
    gw 192.168.10.10
    network 172.16.0.0/16
}
net route smallRoute {
    gw 192.168.20.10
    network 172.16.10.0/24
}
net route testroute {
    gw 192.168.10.10
    network 8.8.8.8/32
}

To display the management routes, which are associated with the management interface, use the list sys management-route command :

root@(mybigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys management-route
sys management-route default {
    description configured-statically
    gateway 192.168.150.1
    mtu 1500
    network default
}

Checking Self-IP

To verify Self IP selection, you can display the configured Self IP addresses using the list net self tmsh command:

root@(mybigip)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net self
net self external {
    address 192.168.20.1/24
    traffic-group traffic-group-local-only
    vlan External
}
net self Internal_loc {
    address 192.168.10.1/24
    traffic-group traffic-group-local-only
    vlan Internal
}

This command shows all Self IP addresses, their VLAN association, and whether they are floating or non-floating.

Once the egress VLAN has been identified through the routing lookup, you can determine which Self IP will be used by applying the selection rules based on the type of traffic. For example:

• SNAT Auto Map follows the floating/non-floating selection order.

• Health monitors typically use the non-floating Self IP on the egress VLAN.

By combining the routing table lookup and the Self IP selection rules, you can determine exactly which VLAN, route, and source IP address the BIG-IP will use when generating traffic.

Conclusion

To determine which interface and source IP a packet generated by an F5 BIG-IP will use, follow three main steps:

1. Routing table lookup: The system checks TMM (production) and management routes. The longest prefix match always applies. If prefixes are equal, the TMM route takes precedence.

2. Traffic type identification: Determines the source IP selection process based on traffic type.

3. Source IP selection: Based on traffic type, the source IP is chosen from a statically configured object, a health monitor, or SNAT Auto Map.

Understanding these steps ensures you can predict the egress interface and source IP for any locally generated traffic.