Applies To:

Show Versions Show Versions

Manual Chapter: Advanced Routing Modules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

As described in Chapter 16, Routes, the BIG-IP® system has two route tables: a Traffic Management Microkernel (TMM) table for routing application traffic, and a host table for routing BIG-IP system management traffic. At a minimum, the TMM route table contains static routes that you specify, using the Routes screen of the Configuration utility.
In addition to adding static entries to the TMM route table, however, you can configure the BIG-IP system to add entries into the TMM and host route tables dynamically, that is, without user intervention. You can do this by licensing the optional set of advanced routing modules and then configuring them on the BIG-IP system. The advanced routing modules consist of industry-standard dynamic routing protocols that enable the BIG-IP system to establish relationships with other routers on a network for the purpose of sharing route information on a regular basis.
Important: If you have a VIPRION® system, do not use this chapter. Instead, see the Configuration Guide for the VIPRION® System for information on configuring the advanced routing modules.
An optional feature of the BIG-IP system, the advanced routing modules support several protocols. Table 24.1 lists the protocols included in the advanced routing modules, as well as related information.
Protocol name and version
IP version supported
Border Gateway Protocol (BGP) 4 with multi-protocol extension is a dynamic routing protocol for external networks that supports the IPv4 and IPv6 addressing formats.
Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol for internal networks, based on a link-state algorithm.
The Open Shortest Path First (OSPF) protocol is a dynamic routing protocol for internal networks, based on a link-state algorithm. OSPF is an alternative to the RIP protocol. OSPFv2 supports the IPv4 addressing format.
Routing Information Protocol (RIP) is a dynamic routing protocol for internal networks, based on a distance-vector algorithm (number of hops). RIPv1 and RIPv2 support the IPv4 addressing format.
Advertise and redistribute virtual address routes to other routers
Note: To enable the Advanced Routing Modules feature, you might need to purchase an additional license key. For more information, contact F5 Networks®.
For background information on configuring the advanced routing modules, see the AskF5TM Knowledge Base (
Throughout this guide, the text contains references to various ZebOS® Intelligent Network Software guides. These guides are available online, through the AskF5TM web site,
Log on to the AskF5TM web site,
In the Search by Keywords box, type a ZebOS guide title.
Press Enter.
Before configuring the advanced routing modules on the BIG-IP system, it is helpful to understand how the modules behave with respect to few key areas. They are:
When deploying the advanced routing modules in a redundant system configuration, there are some general topics to consider, as well as considerations for systems using OSPF.
For protocols that include the router ID attribute, each device of the redundant system configuration must have a unique router ID.
When using BGP, RIP, or IS-IS, both devices of the redundant system automatically advertise their shared, floating self IP address as the next hop for all advertised routes. This ensures that peer routers use the shared self IP address as the next hop for all routes advertised by the BIG-IP system.
When you have configured Route Health Injection (RHI), only the active device advertises routes to virtual addresses. For more information about RHI, see Route Health Injection.
To guarantee correct operation in redundant active/standby configurations, the BIG-IP system automatically changes the runtime state of the OSPF subsystem. The purpose of a runtime state change is to modify advertised link state information in way that makes the standby device the least preferred next-hop router. The next hop IP address in this case is the self IP address of the advertising router.
Table 24.2 describes the changes that the BIG-IP system makes to the runtime state.
The OSPF interface cost is increased on all interfaces to the maximum value when the status of the device is Standby.
The BIG-IP system reverses the runtime state changes after the device transitions to Active status. You can see the effect of these changes by displaying OSPF interface status and listing the OSPF link state database.
For IPv6 addressing, the BGP module allows you to advertise one or two next-hop addresses for each route. Selection of addresses that are advertised to a peer depends on the following:
Table 24.3 shows several practical combinations of configuration parameters for selecting next-hop addresses, and shows the resulting set of advertised addresses.
If you are using the route domains feature, you can implement dynamic routing, but only for route domain 0. Route domain 0 is the default route domain on the BIG-IP system and the only route domain of which the advanced routing modules have knowledge. For this reason, you should consider the following:
You can implement non-default route domains and simultaneously use dynamic routing in the default route domain. However, the advanced routing modules can use and advertise only those objects (routes, self IP addresses, and virtual addresses) that pertain to the default route domain.
The advanced routing modules acquire knowledge of routes from other routers and present these routes to the nsm daemon. The nsm daemon then determines whether or not to communicate these routes to other BIG-IP system processes, based on criteria such as the information stored in a modules configuration data.
On the BIG-IP system, dynamically-learned routes must be propagated to the separate TMM route table in order for the system to use them for directing application traffic. To accomplish this, the BIG-IP system includes a daemon named tmrouted. The nsm daemon communicates with the tmrouted daemon about any new, modified, or deleted dynamic routes. When learning of such changes, the tmrouted daemon communicates with the mcpd daemon, and the mcpd daemon updates the TMM and host route tables.
Regardless of the specific advanced routing module you want to configure, the procedure for configuring an advanced routing module on a BIG-IP system is similar. In general, you must complete a few basic tasks.
If you have recently licensed the routing modules but have not started them yet, the first step is to enable the relevant module. When you enable a module, the system starts the corresponding protocol daemon. If this is the first enabled module, it also starts the required common daemons (nsm and imi). Daemons supporting enabled modules are automatically started when the system starts up.
Note: The system does not propagate enabled modules at runtime to the peer device in a redundant configuration. For the OSPFv2 and OSPFv3 modules, this could have adverse effects. You can prevent these effects by always enabling or disabling a module on the active device, and then synchronizing the configuration to the standby device.
The relevant daemon is stopped immediately (and will not start with the next reboot). If this module is the last enabled module, the common daemons (nsm and imi) are also stopped.
After a module is disabled, the relevant configuration is removed from the runtime configuration (as displayed by the IMI shell command show running), but it remains in the configuration file (/config/ZebOS.conf) until you save the running configuration (using the command write file).
Note: The system does not propagate disabled modules at runtime to the peer device in a redundant configuration. For the OSPFv2 and OSPFv3 modules, this could have adverse effects. You can prevent these effects by always disabling a module on the standby device, and then synchronizing the configuration to the active device.
You configure the advanced routing modules using the IMI shell, which is a command-line shell. Using the IMI shell, you can configure every aspect of dynamic routing. The IMI shell provides command completion and in-line help for configuration and management commands.
Note: If you are accustomed to using the vtysh command to configure the advanced routing modules, you can continue to do so. The IMI shell is backward-compatible with the VTY Shell.
The IMI shell also allows you to monitor operation of the modules at runtime. You can list the current state of the route table, display the internal state of individual routing modules, and so on.
Important: Always use the IMI shell to configure an advanced routing module, rather than directly updating the ZebOS.conf file with a text editor. The IMI shell provides error-checking and command completion, two features that help to ensure correct configuration of the module. Note that a runtime configuration created with the IMI shell is lost when routing modules restart, unless it is saved to the configuration file using the IMI shell write file command. Note, too, that F5 Networks provides no technical support for configurations created by modifying the ZebOS.conf file directly.
Once you have enabled one or more modules, the BIG-IP system automatically starts the enabled module whenever you perform a reboot.
To temporarily stop all dynamic routing protocols and remove all dynamic routes from the system, you can use this command:
You can restart a module in order to reload a configuration from the ZebOS.conf file. Restarting a module basically performs the bigstart stop and bigstart start actions in sequence. As a result, the command causes all dynamic routes to temporarily disappear from the system.
For modules that have been enabled and started, you can list every currently-running routing daemon and its status, in the format shown in Figure 24.1.
In addition to dynamically adding learned routes to the TMM route table, the advanced routing modules can redistribute routes to any virtual addresses that you have defined on the BIG-IP system. Advertising routes to virtual addresses based on the status of attached virtual servers is known as Route Health Injection (RHI).
Is considered to have a status of: up, unavailable (due to the connection limit reached), or unknown. This is based on the status of virtual servers using the IP address.
Figure 24.2 shows a sample entry in the bigip.conf file. This entry advertises a route to address
Note that virtual address objects are created automatically, based on configured virtual server objects. For example:
For a virtual server with a destination address of, the BIG-IP system automatically creates the virtual address, with a netmask of
For a virtual server with a destination address of and a netmask of, the BIG-IP system automatically creates the virtual address, with a netmask of
Advertisement of virtual addresses can depend on the status of virtual servers using the address as their destination (that is, virtual servers that are attached to that address). A virtual address can be advertised as follows:
When any virtual server is available
When set to this value, the BIG-IP system advertises the virtual address when any one of the virtual servers associated with the virtual address is available. This is the default value.
When all virtual servers are available
When set to this value, the BIG-IP system advertises the virtual address only when all of the virtual servers associated with the virtual address are available.
When set to this value, the BIG-IP system always advertises the virtual address, regardless of the availability of virtual servers associated with the virtual address.
Note: A virtual server is considered to be available when it is in the UP (green) or UNCHECKED (blue) state.
Once you have advertised a virtual address, you can then configure the advanced routing modules to redistribute that address to other routers.
If you have enabled the Route Health Injection (RHI) feature, you can redistribute routes for virtual addresses to other devices on the network, using any supported advanced routing modules.
You must explicitly configure each advanced routing module to redistribute routes for advertised virtual addresses, to ensure that other routers on the network learn these routes. Also, for purposes of redistribution, the advanced routing modules consider any route generated through RHI to be a host route.
Note: You must configure route redistribution for IPv4 addresses separately from that of IPv6 addresses. This is true for all advanced routing modules, including those that pertain to both IPv4 and IPv6 formats such as BGP.
Figure 24.3 shows a sample entry in the OSPF configuration. When you add this statement to the OSPF configuration, using the IMI shell, the BIG-IP system redistributes the route to the virtual address that was previously advertised in Figure 24.2.
When adding this entry into the configuration data, you can optionally specify a route-map reference that specifies the route map to use for filtering routes prior to redistribution. Figure 24.4 shows a sample entry for route filtering in the advanced routing module configuration.
Route maps provide an extremely flexible mechanism for fine-tuning redistribution of routes using the advanced routing modules. For a full description of all available route map commands, see the ZebOS NSM Command Reference guide. The ZebOS Core Configuration Guide provides examples of using route maps with all supported dynamic routing protocols. Both of these guides are available on the AskF5TM Knowledge Base web site
On the BIG-IP system, you typically use route maps to filter redistributed host routes. Figure 24.5 shows an OSPF configuration that uses a route map to limit the redistribution of host routes to only those routes with a destination in the subnet. (Note that the line numbers shown in the example are not part of the actual configuration, but are included in the figure to identify each line for the explanation that follows.)
1 router ospf
2 redistribute kernel route-map virtual-addresses-out
4 access-list virtual-addresses permit
6 route-map virtual-addresses-out permit 10
7 match ip address virtual-addresses
Line 1 and 2: Configures redistribution of host routes using the OSPF module with the route map virtual-addresses-out applied.
Line 4: Defines the access list virtual-addresses, which permits all addresses in the subnet.
Line 6: Defines an entry with the serial number 10 of the route map virtual-addresses-out. The entry causes the module to accept all route-matching-specified criteria (due to the permit directive in the definition.
Line 7: Configures matching criteria for the route map entry. The entry matches all routes whose destination prefix is accepted by the access list virtual-addresses. An access list accepts a prefix if the prefix is equal to, or fully contained in, the prefix specified in the access list. For example, a route with the destination matches the access list, and the route with the destination does not match the access list.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Additional Comments (optional)