As described in the TMOS® Management Guide for BIG-IP® Systems
, 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.
An optional feature of the BIG-IP system, the advanced routing modules
support several protocols. Table 5.1
lists the protocols included in the advanced routing modules, as well as related information.
Throughout this guide, the text contains references to various ZebOS®
Intelligent Network Software reference or configuration guides. These guides are available online, through the Ask F5SM
web site, http://support.f5.com
| |In the Search by Keywords
box, type a ZebOS guide title.
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:
On a VIPRION system, configuration and operation of the dynamic routing
subsystem behaves as if the cluster was a single router. This means that a cluster always appears as a single router to any peer routers regardless of the dynamic routing protocol being used.
From a management perspective, the VIPRION system is designed to
appear as if you are configuring and managing the routing configuration on a single appliance. When you use the cluster IP address to configure the advanced routing modules, you transparently configure the primary blade in the cluster. The cluster synchronization process ensures that those configuration changes are automatically propagated to the other blades in the cluster.
The dynamic routing subsystem takes advantage of the redundancy provided
by the cluster environment of VIPRION chassis, for the purpose of providing redundancy for the dynamic routing control plane.Two key aspects of dynamic routing control plane redundancy are the operational modes of the enabled advanced routing modules, and the clusters appearance to the routing modules as a single router.
Enabled advanced routing modules run on every blade in a cluster in one of
following operational modes: MASTER, STANDBY, or SLAVE. Table 5.2
shows the operational modes for primary and secondary blades, on both the active cluster and the standby cluster.
As described in Table 5.2
, the advanced routing modules operate in the MASTER mode on the primary blade of the active cluster, in STANDBY mode on the primary blade of the standby cluster, and in SLAVE mode on all secondary blades.
In MASTER and STANDBY modes, the advanced routing modules actively
participate in dynamic routing protocol communication with peer routers and maintain TMM and host route tables on all blades in the cluster. All routes learned by way of dynamic routing protocols on the primary blade are (in real-time) propagated to all secondary blades. The difference between MASTER and STANDBY mode is in the parameters of advertised routes, with the goal to always make the active unit the preferred next hop for all advertised routes.
In SLAVE mode, advanced routing modules do not transmit any dynamic
routing protocol traffic. Depending on dynamic routing protocol, modules either track dynamic routing protocol communication between the advanced routing module operating in MASTER mode and peer routers, or simply wait for transition to MASTER or STANDBY mode.
Transition from SLAVE to MASTER or STANDBY mode takes advantage
of standard dynamic routing protocol graceful restart functionality. For more information, see Graceful restart considerations
The graceful restart
function allows the dynamic routing protocol control plane to move from one blade to another without disruption to traffic. Graceful restart is enabled for most supported protocols and address families by default. (See the following note.)
To operate successfully, the graceful restart function must be supported and
enabled on all peer routers with which the VIPRION system exchanges routing information. If one or more peer routers does not support graceful restart for one or more enabled dynamic routing protocols, a change in the primary blade causes full dynamic routing reconvergence and probably traffic disruption. The traffic disruption is caused primarily by peer routers discarding routes advertised by the VIPRION system.
Complete forwarding information (TMM and host route tables) is always
preserved on VIPRION systems during primary blade changes, regardless of support for graceful restart on peer routers.
Startup configuration (in the /config/ZebOS.conf
file) is automatically copied to all secondary blades, and the new configuration is loaded when the running configuration is saved on the primary blade. You can display the running configuration on both primary and secondary blades.
The runtime state (displayed using the IMI shell show
commands) can be used on both the primary and secondary blades; however, some information displayed on secondary blades might differ from the information on the primary blade. Information displayed on the primary blade should be used for troubleshooting purposes, because only the primary blade both actively participates in dynamic routing communication and controls route tables on all blades.
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.
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.
describes the changes that the BIG-IP system makes to the runtime state.
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 http://support.f5.com
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:
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:
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.
shows the tasks to perform, along with the relevant configuration tool. Also included are references to additional information.
Note that typing the zebos
command with no arguments produces the message in Figure 5.1
about syntax usage.
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
). Daemons supporting enabled modules are automatically started when the system starts up.
At the BIG-IP system prompt, type the zebos
command and specify a routing module, using this syntax:
, or ripng
, 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
Once you have enabled one or more modules, the BIG-IP system
automatically starts the enabled module whenever you perform a reboot.
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.
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.
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)
shows a sample entry in the bigip.conf
file. This entry advertises a route to address 10.1.1.1/32
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.
| || |Always
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.
| |For the Route Advertisement
setting, check the box.
This enables route advertisement for this virtual address.
You can also advertise a virtual address using the bigpipe virtual address
command 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.
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 5.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 5.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 Ask F5 Knowledge Base web site http://support.f5.com
On the BIG-IP system, you typically use route maps to filter redistributed
host routes. Figure 5.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 10.10.10.0/24
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.)
redistribute kernel route-map virtual-addresses-out
access-list virtual-addresses permit 10.10.10.0/24
route-map virtual-addresses-out permit 10
match ip address virtual-addresses
| || |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 10.10.10.1/32
matches the access list, and the route with the destination 10.10.0.0/16
does not match the access list.