Applies To:

Show Versions Show Versions

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

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.
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.
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 Ask F5SM Knowledge Base (http://support.f5.com).
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.
1.
Log on to the Ask F5SM web site, http://support.f5.com.
2.
In the Search by Keywords box, type a ZebOS guide title.
3.
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:
The VIPRION® platform
If you have a VIPRION system, it is helpful to understand how the cluster environment affects the dynamic routing functionality.
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.
Track communication between a module and the peer routers, or wait for transition to MASTER or STANDBY mode
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.
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.
Figure 5.3 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 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:
Table 5.4 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 5.5 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 5.1 about syntax usage.
Figure 5.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 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 5.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 5.3 shows a sample entry in the bigip.conf file. This entry advertises a route to address 10.1.1.1/32.
Tip: You can view the above configurations using the bigpipe virtual address list command.
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 10.1.1.1:80, the BIG-IP system automatically creates the virtual address 10.1.1.1, with a netmask of 255.255.255.255.
For a virtual server with a destination address of 10.2.0.0:any and a netmask of 255.255.0.0, the BIG-IP system automatically creates the virtual address 10.2.0.0, with a netmask of 255.255.0.0.
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.
Note: A virtual server is considered to be available when it is in the UP (green) or UNCHECKED (blue) state.
1.
On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers.
The Virtual Servers screen opens.
2.
On the menu bar, click Virtual Address List.
This displays the list of virtual addresses.
3.
In the Address column, click the IP address that you want to advertise.
This opens the Virtual Addresses screen.
4.
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.
5.
For the Route Advertisement setting, check the box.
This enables route advertisement for this virtual address.
6.
Click Update.
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.
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 5.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 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.)
1 router ospf
2 redistribute kernel route-map virtual-addresses-out
4 access-list virtual-addresses permit 10.10.10.0/24
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 10.10.10.0/24 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 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.
Table of Contents   |   << Previous Chapter

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)