Applies To:

Show Versions Show Versions

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

As described in Chapter 8, Configuring Routes, the BIG-IP® system has two routing tables: the kernel table for routing BIG-IP system management traffic, and a Traffic Management Microkernel (TMM) table for routing application traffic. Normally, the TMM routing table contains static routes that you specify, using the Routes screen of the Configuration utility.
In addition to adding static entries to the TMM routing table, however, you can configure the BIG-IP system to add entries into the kernel and the TMM routing 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.
Border Gateway Protocol (BGP)
A dynamic routing protocol for external networks.
Routing Information Protocol (RIP)
A dynamic routing protocol for internal networks, based on a distance-vector algorithm (number of hops).
Open Shortest Path First (OSPF)
A dynamic routing protocol for internal networks, based on a link-state algorithm. OSPF is generally considered to be more suitable than RIP for large-scale, complex internal networks.
Advertise and redistribute virtual address routes to routers on an internal or external network
Note: To enable the Advanced Routing Modules feature, you may need to purchase an additional license key. For more information, contact F5 Networks.
The dynamic routing subsystem on the BIG-IP system has no inherent information about the active or standby state of a unit of a redundant pair. This means that a unit can potentially advertise routes, while at the same time being unable to use those routes to successfully deliver traffic. Fortunately, you can prevent this problem by following these guidelines:
For protocols that include the router ID attribute, each unit of the redundant system must have a unique router ID.
Prior to using the BGP or RIP modules, you must explicitly configure them. This explicit configuration ensures that both units of the redundant system advertise their shared, floating self IP address as the next hop for BIG-IP system virtual addresses. This, in turn, ensures that traffic destined for virtual addresses always targets the active unit of the redundant system. For more information, see Viewing a BGP configuration for a redundant system and Viewing a RIP configuration for a redundant system.
When using the OSPF module, you do not need to explicitly configure the module for active/standby configuration. Instead, the BIG-IP system, by default, automatically changes the OSPF runtime configuration after failover has occurred. These runtime configuration changes ensure that other routers always treat the active unit as the preferred next hop for routes advertised by both units. The next hop IP address in this case is the static (non-floating) self IP address of the advertising router. Note that you can change the way that the BIG-IP system changes the OSPF runtime configuration. For more information, see Editing the configuration file for OSPF.
When you have configured Route Health Injection (RHI), only the active unit of a redundant system can advertise routes to virtual addresses. For more information on configuring RHI, see Configuring the BIG-IP system to advertise virtual addresses.
Neighbor routers always select the active unit in the redundant system as the next hop, based on routes that they learn from both units.
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:
2.
Next, you must use a configuration tool known as the VTY shell to customize the routing modules configuration. This step includes using the shell to save this configuration data. For more information, see Configuring the advanced routing modules.
3.
Next, if you want to advertise any BIG-IP system virtual addresses, you must configure the bigip.conf file. This step is optional. For more information, see Configuring the BIG-IP system to advertise virtual addresses.
4.
Finally, if you advertise virtual addresses, you can configure the redistribution of the routes to these virtual addresses, using the VTY shell, to configure the selected advanced routing module. For more information, see Redistributing routes to virtual addresses using the advanced routing modules.
Throughout this guide, the text contains references to various ZebOS reference or configuration guides. These guides are available online, through the AskF5sm web site http://tech.f5.com.
1.
2.
ZebOS BGP Command Reference
ZebOS NSM Command Reference
ZebOS OSPF Command Reference
ZebOS RIP Command Reference
ZebOS VTY Command Reference
ZebOS Architecture and Developer Guide
ZebOS Configuration Guide
The advanced routing modules acquire knowledge of routes from other routers and present these routes to the NSM daemon as candidates for insertion into the kernel routing table. The NSM daemon then determines whether or not to insert the route into the kernel table, based on criteria such as the information stored in a modules configuration data and the current state of the kernel routing table.
On the BIG-IP system, dynamically-learned routes must be propagated to the separate TMM routing 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 tmrouted daemon listens for new, modified, or deleted dynamic routes that the NSM daemon has inserted into the kernel routing table. (Dynamic routes are labeled in the kernel routing table with the attribute zebra). When detecting such changes, the tmrouted daemon:
Removes any existing dynamically-learned routes from the TMM routing table that are no longer present in the kernel routing table.
If you have recently licensed the routing modules but have not started them yet, then the first step is to enable the relevant module. When you start a routing module, the BIG-IP system starts the NSM daemon and the specified protocol daemon, and creates a default set of configuration data. This configuration data is stored in a file named /config/ZebOS.conf.
At the BIG-IP system prompt, type the zebos command and specify a routing module, using this syntax:
Warning: Do not attempt to configure an advanced routing module when the corresponding protocol daemon is not actively running on the BIG-IP system. Doing so can cause a loss of configuration data. For more information, see the individual sections on configuring each of the advanced routing modules.
This chapter contains general information on advanced routing module configuration, as well as a description of the configuration tool, the VTY shell.
Following the description of the VTY shell are sections that provide configuration information unique to each routing module, including sample configuration entries.
When you enable the advanced routing modules for the first time, the BIG-IP system creates a default configuration for the enabled module. By customizing this configuration, you can configure the modules to meet your particular networking needs.
If you have an active/standby redundant-system configuration, there are additional issues to consider when you customize the advanced routing modules. For more information, see Important considerations for active/standby configurations.
Note: On a redundant system, each unit stores the advanced routing module configuration. These two sets of configuration data can (and should) be identical, except when each file contains information that is unique to each unit, such as a router ID.
You configure the advanced routing modules using the VTY shell, which is a command-line shell. Using the VTY shell, you can configure every aspect of dynamic routing. The shell provides command completion and in-line help for configuration and management commands.
The VTY shell also allows you to monitor operation of the modules at runtime. You can list the current state of the routing table, display the internal state of individual routing modules, and so on. For more information on the VTY shell, see the ZebOS VTY Shell Command Reference on http://tech.f5.com.
Important: When you configure the advanced routing modules, the BIG-IP system stores this data in a file named ZebOS.conf. It is essential that you always use the VTY shell to customize the configuration data in this file. F5 Networks provides no technical support for configurations created by modifying the ZebOS.conf file directly with a text editor.
The Border Gateway Protocol (BGP) routing module is a dynamic routing protocol for external networks. A good way to understand the configuration of the BGP module for an active/standby system is to examine part of a sample configuration. Figure C.1 shows part of a sample BGP configuration, configured on one unit of an active/standby system. The configuration on the peer unit is identical, except for the router ID.
The configuration example illustrates BGP configuration for two peer routers The example also shows how to use route maps to selectively set the next-hop on advertised routes to the shared self IP addresses.
Note that the line numbers shown in the example are not part of the actual BGP configuration data, but are included in the figure to identify each line for the explanation that follows.
1 interface external
2 !
3 interface internal
4 !
5 interface lo0
6 !
7 interface admin
8 !
9 router bgp 1000
10 bgp router-id 192.168.151.1
11 neighbor ext-routers peer-group
12 neighbor ext-routers remote-as 66
13 neighbor ext-routers route-map external-out out
14 neighbor 192.168.151.253 peer-group ext-routers
15 neighbor 192.168.151.254 peer-group ext-routers
16 !
17 route-map external-out permit 10
18 set ip next-hop 192.168.151.3
Line 12: Configures an ASN of 66 for the remote peers in the peer group ext-routers.
Line 13: Using the route map external-out, filters all routes advertised to the peers in the peer group ext-routers.
Line 14: Assigns the external router 192.168.151.253 to the peer group ext-routers.
Line 15: Assigns the external router 192.168.151.254 to the peer group ext-routers.
Line 18: Configures the route map external-out to set the next-hop address of all routes to be the external floating self IP address of the redundant pair (IP address 192.168.151.3).
Once you have familiarized yourself with the default BGP configuration, you can customize the configuration data. To simplify this task, the BIG-IP system includes the vtysh command. This command starts the VTY command line shell. For information on how to use the VTY shell to customize the BGP configuration, see the ZebOS BGP Command Reference on http://tech.f5.com.
Important: Always use the VTY shell to configure the BGP module. The VTY shell provides error-checking and command completion, two features that help to ensure correct configuration of the module. The shell also saves your customized configuration, to prevent data loss when you restart the module later.
Warning: Do not customize the BGP configuration data until you have verified that the BGP protocol daemon (bgpd) is actively running. Otherwise, the VTY shell might either prevent you from configuring the file, or fail to save your configuration data. For more information, see Displaying the status of advanced routing modules.
For more information about configuring specific BGP functionality, refer to the following information included in the Zebos BGP Command Reference:
Tip: The ZebOS BGP Command Reference is available on http://tech.f5.com.
The Routing Information Protocol (RIP) routing module is a dynamic routing protocol for internal networks, based on a distance-vector algorithm. A good way to understand the configuration of the RIP module is to examine part of a sample configuration. Figure C.2, following, shows part of a sample RIP configuration, configured on one unit of an active/standby system.
The example shows RIP routing configured on a single VLAN. It also shows how the route-map option can be used in this context to set the next-hop address of advertised routes to the shared self IP address.
Important: The sample configuration in Figure C.2 works correctly when RIP is enabled on a single VLAN only. If RIP is enabled on multiple VLANs, the advertised route to each redundant-system unit is the units static (non-floating) self IP address instead of the shared self IP address. This can cause routers to send packets to a unit that is in standby mode, thereby resulting in silently-dropped packets.
Note that the line numbers shown in the example are not part of the actual RIP configuration data, but are included in the figure to identify each line for the explanation that follows.
Figure C.2 shows a typical RIP configuration for an active/standby system. Note that because RIP has no concept of a router ID, the configuration of the RIP module should be identical on both units of the redundant pair.
1 interface external
2 !
3 interface internal
4 !
5 interface lo0
6 !
7 interface admin
8 !
9 router rip
10 network 10.1.1.0/24
11 redistribute connected route-map internal-out out
12 !
13 route-map internal-out permit 10
14 set ip next-hop 10.1.1.3
Line 1: Configures redistribution of routes to the directly-connected network to RIP, with filtering through the route map internal-out.
Line 14: Configures the route map internal-out to set the next-hop address of all routes to be the internal floating self IP address of the redundant pair (IP address 10.1.1.3).
Once you have familiarized yourself with the default RIP configuration, you can customize the configuration data. To simplify this task, the BIG-IP system includes the vtysh command. This command starts the VTY command line shell. For information on how to use the VTY shell to customize the RIP configuration, see the ZebOS RIP Command Reference on http://tech.f5.com.
Important: Always use the VTY shell to configure the RIP module. The VTY shell provides error-checking and command completion, two features that help to ensure correct configuration of the module. The shell also saves your customized configuration, to prevent data loss when you restart the module later.
Warning: Do not customize the RIP configuration until you have verified that the RIP protocol daemon (ripd) is actively running. Otherwise, the VTY shell might either prevent you from configuring the module, or fail to save your configuration data. For more information, see Displaying the status of advanced routing modules.
For more information about configuring specific RIP functionality, refer to the following information in the ZebOS RIP Command Reference:
Tip: The ZebOS RIP Command Reference is available on http://tech.f5.com.
The Open Shortest Path First (OSPF) routing module is a dynamic routing protocol for internal networks, based on a link-state algorithm. To guarantee correct operation in redundant active/standby configurations, the BIG-IP changes the runtime OSPF configuration after failover.
The goal of the runtime configuration change is to modify advertised link state information in way that makes the standby unit the least preferred next-hop router. You can change the way that the system changes the runtime configuration by configuring some bigdb database keys.
More specifically, when a unit of a redundant system transitions from an active to a standby state, or from a standby to an active state, the BIG-IP system, by default, changes the OSPF runtime configuration.
When transitioning from an active to a standby state, the system adds the following statement to the configuration of all interfaces on which OSPF is enabled:
This statement makes all non-local link state advertisements (LSAs) that the unit generates the least preferred, due to having a cost larger than any other available link.
This statement makes the unit immediately time out the advertisements of all external LSAs (for example, the redistribution of kernel, BGP, and other routes).
Note: You can view these runtime configuration statements by opening the VTY shell and typing the show running command. After you type the write file command, you can see these statements in the OSPF configuration.
The BIG-IP system removes these statements when failback occurs, that is, after the unit transitions from a standby to an active state again.
In some cases, the default statements that the BIG-IP system adds to the OSPF runtime configuration might interfere with your configuration goals. To resolve this conflict, you can modify the values of these statements. You do this by using the bigpipe db command and specifying one of the variables listed in Table C.1.
The commands specified with the ZebOS.ospf.interfaces.GoActiveCmd and ZebOS.ospf.router.GoActiveCmd configuration keys are run after transition from standby to active mode. The commands specified with the ZebOS.ospf.interfaces.GoStandbyCmd and ZebOS.ospf.router.GoStandbyCmd keys are run after transition from active to standby mode.
Note: These configuration keys modify the runtime configuration only. However, if you use the VTY shell write file command on the standby unit, the system saves a temporary configuration change to a file. This poses no problem because the GoActive and GoStandby commands are run whenever the operational mode of the unit changes, including the selection of the initial mode after the system boots. The only situation in which the presence of the statements added in active/standby transition (in the start-up configuration) might cause problems is when the advanced routing modules are stopped on a unit in standby mode and restarted after the unit becomes active (or the reverse). This should never occur under normal operational conditions.
You can customize the bigdb configuration keys to accommodate specific configuration items that might be overridden by the automatic runtime configuration change (for example, a non-default OSPF cost on interfaces). Commands specified in bigdb configuration keys with names that include ZebOS.ospf.interfaces are run in the interface configuration mode on every interface on which OSPF is enabled. Commands specified in bigdb configuration keys with names that include ZebOS.ospf.router are run in router configuration mode for every configured OSPF instance.
Units of a BIG-IP redundant system are poor candidates to be elected as OSPF designated routers (DR) or backup designated routers (BDR). To prevent OSPF instances configured on the units of a redundant system from becoming a DR or a BDR, we recommend that you configure an OSPF priority of 0 on every interface on which OSPF routing is enabled.
6.
Type exit.
This exits the interface configuration mode.
8.
Type exit.
This exits the configuration mode.
9.
Type the write file command.
This saves the running configuration to a file.
10.
Type exit.
This exits the VTY shell.
Once you have familiarized yourself with the default OSPF configuration data, you can customize the configuration data. To simplify this task, the BIG-IP system includes the vtysh command. This command starts the VTY command line shell. For information on how to use the VTY shell to customize the OSPF configuration, see the ZebOS OSPF Command Reference on http://tech.f5.com.
Important: Always use the VTY shell to configure the OSPF module instead of editing the file directly. The VTY shell provides error-checking and command completion, two features that help to ensure correct configuration of the module. The shell also saves your customized configuration, to prevent data loss when you restart the module later.
Warning: Do not customize the OSPF configuration data until you have verified that the OSPF protocol daemon (ospfd) is actively running. Otherwise, the VTY shell might either prevent you from configuring the file, or fail to save your configuration data. For more information, see Displaying the status of advanced routing modules.
For more information about configuring specific OSPF functionality, see the following information in the ZebOS Configuration Guide on http://tech.f5.com:
In addition to dynamically adding learned routes to the TMM routing table, the advanced routing modules can redistribute routes to any virtual addresses that you have defined on the BIG-IP system. However, before the modules can redistribute routes to virtual addresses, you must advertise the routes to those addresses to the BIG-IP systems kernel routing table. This process of advertising virtual address routes to the kernel routing table is known as Route Health Injection.
When you configure the BIG-IP system to insert a route for a virtual address into the kernel routing table, the NSM daemon can later redistribute that address to other routers on the network.
To advertise the route for a virtual address, you use the Configuration utility to add an entry for the IP address into the bigip.conf file on the BIG-IP system. For example, the following entry in the bigip.conf file advertises the route for virtual address 10.10.10.1.
Figure C.3 Sample bigip.conf entry for advertising a route
In the Configuration utility, when you enable the Route Advertisement setting on the Virtual Address screen, the Advertise Routes setting causes the BIG-IP system to insert a route for the associated virtual address into the BIG-IP system kernel routing table. This allows the advanced routing modules to redistribute that route to other routers on the network.
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.
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.
For the Route Advertisement setting, check the box.
This enables route advertisement for this virtual address.
5.
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.
6.
Click Update.
Note: If the advertised IP address becomes unavailable or failover occurs, the advertised route disappears from the kernel routing table.
Once you have advertised a virtual address, you can then configure the advanced routing modules to redistribute that address to other routers. However, prior to configuring an advanced routing module, you must start the module. For information on starting an advanced routing module, see Enabling an advanced routing module. For information on redistributing routes to virtual addresses, see Redistributing routes to virtual addresses using the advanced routing modules, following.
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 kernel route.
Figure C.4 shows a sample entry in the OSPF configuration. When you add this statement to the OSPF configuration, using the VTY shell, the BIG-IP system redistributes the route to the virtual address that was previously advertised in Figure C.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 C.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. The ZebOS Configuration Guide provides examples of using route maps with all supported dynamic routing protocols. Both of these guides are available on http://tech.f5.com.
As previously mentioned, routes to BIG-IP virtual addresses are redistributed using the kernel route information source in the redistribution statement of the configuration (that is, kernel, which refers to the kernel routing table). The kernel route table, however might contain other routes (for example, TMM and management static routes) along with routes to virtual addresses that the BIG-IP system inserted using RHI. To prevent redistribution of unwanted routes using the advanced routing modules, you can specify a route map in the redistribution statement.
Continuing with the example in Figure C.2, Figure C.6 shows an OSPF configuration that uses a route map to limit the redistribution of kernel 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: Configure redistribution of kernel 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.
One of the requirements of dynamic routing configuration for a BIG-IP redundant system is to guarantee that traffic is always directed to the active unit in the redundant system. An easy way to achieve this goal is to ensure that advertised routes specify a shared, floating self IP address as the next-hop. For routes redistributed by a dynamic routing protocol, you can achieve this by applying a route map to the redistribution.
Continuing with the previous example, you can add a statement to the route map, setting the next-hop IP address to 192.168.254.3 (which is assumed to be a shared self IP address on the VLAN on which OSPF routing is enabled). Figure C.7 shows an example of the set ip next-hop route map statement in the OSPF configuration.
1 router ospf
2 network 192.168.254.0/24 area 0
3 redistribute kernel route-map virtual-addresses-external
4
5 route-map virtual-addresses-external permit 10
6 set ip next-hop 192.168.254.3
Line 5: Defines an entry with the serial number 10 of route map virtual-addresses-external. The entry accepts all routes.
Line 6: Sets the next-hop IP address of every accepted route to 192.168.254.3. (Note: In the context of OSPF, the specified address is advertised as the forwarding address in the corresponding type 5 link state advertisement.)
Note: Using a route map for modifying the next-hop address of redistributed routes is applicable only if the routing protocol is enabled on a single VLAN only. This is because the system applies the route map regardless of the VLAN on which the resulting advertisement is transmitted. If the specified next-hop address does not belong to any directly-connected network on the VLAN, the address is ignored and a static self IP address is used instead.
Once you have enabled at least one advanced routing module, you can use the bigstart utility to start, stop, restart, and query the status of the advanced routing modules. For information on enabling a routing module, see Enabling an advanced routing module.
Once you have enabled one or more modules, the BIG-IP system automatically starts the enabled module whenever you perform a reboot. Note that all required module daemons start automatically at boot time if the the ZebOS.conf file exists on the system.
If you need to manually start or stop the daemons, you can type the following command at the BIG-IP system command-line prompt:
This command stops all advanced routing daemons and, as a result, causes the system to remove all dynamically-learned routes from the TMM and kernel routing tables.
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 dynamically-learned routes to disappear (at least temporarily) both from the TMM and kernel routing tables.
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 zebosd. The <time> variable is the time since the modules have been started.
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 format shown in Figure C.8.
Figure C.8 Sample output from the zebos command
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)