Applies To:

Show Versions Show Versions

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

As described in Chapter 10, Configuring Routes and Route Domains, 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 11.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 AskF5SM Knowledge Base (
Throughout this guide, the text contains references to various ZebOS® Intelligent Network Software guides. These guides are available online, through the AskF5SM web site,
Log on to the AskF5SM 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 unit of the redundant system configuration must have a unique router ID.
When using BGP, RIP, or IS-IS, both units 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 unit advertises routes to virtual addresses. For more information on configuring RHI, see Configuring 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 unit the least preferred next-hop router. The next hop IP address in this case is the self IP address of the advertising router.
Table 11.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 unit is in standby mode.
The BIG-IP system reverses the runtime state changes after the unit transitions to active mode. You can see the effect of these changes by displaying OSPF interface status and listing the OSPF link state database.
For information on how to use the IMI shell to configure an OSPF routing module, see the ZebOS OSPF Command Reference guide on
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 11.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 facts:
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.
Table 11.4 shows the tasks to perform, along with the relevant configuration tool. Also included are references to additional information.
zebos command
Start, stop, and restart the modules,
Display status of the modules
bigstart and zebos commands
Note that typing the zebos command with no arguments produces the message in Figure 11.1 about syntax usage.
Figure 11.1 Syntax for the zebos command
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 unit 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 unit, and then synchronizing the configuration to the standby unit.
At the BIG-IP system prompt, type the zebos command and specify a routing module, using this syntax:
where <protocol> represents bgp, isis, ospf, ospf6, rip, or ripng.
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 unit 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 unit, and then synchronizing the configuration to the active unit.
where <protocol> represents bgp, isis, ospf, ospf6, rip, or ripng.
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.
If you need to manually start the daemons, you can type the following command at the BIG-IP system command-line prompt:
To temporarily stop all dynamic routing protocols and remove all dynamic routes from the system, you can use this command:
This command is useful for reloading a configuration from the ZebOS.conf file. The command 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.
To display the current status of the advanced routing modules, type the following command at the BIG-IP system command-line prompt:
The <number> variable is the process identification number (PID) of the supervisory daemon tmrouted. The <time> variable is the time since the modules have been started. The <n> variable can be used if tmrouted was restarted since the last reboot.
In this case, the <time> variable represents the time since the modules were stopped, or since the system booted.
If the modules have been enabled and started, this command lists every currently-running routing daemon, in the format shown in Figure 11.2.
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).
Figure 11.3 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.
On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers.
The Virtual Servers screen opens.
On the menu bar, click Virtual Address List.
This displays the list of virtual addresses.
In the Address column, click the IP address that you want to advertise.
This opens the Virtual Addresses screen.
From the Advertise Routes list, select a value or retain the default value.
For more information on this setting, see Specifying conditions for advertising routes to virtual addresses, preceding.
For the Route Advertisement setting, check the box.
This enables route advertisement for this virtual address.
Click Update.
You can also advertise a virtual address using the command bigpipe virtual address in the bigpipe utility. For more information, see the Bigpipe Utility Reference Guide.
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 11.4 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 11.3.
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 11.5 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 AskF5SM Knowledge Base web site
On the BIG-IP system, you typically use route maps to filter redistributed host routes. Figure 11.6 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)