Applies To:

Show Versions Show Versions

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

As described in the BIG-IP® Network and System Management Guide, 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. At a minimum, 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.
An optional feature of the BIG-IP system, the advanced routing modules support several protocols. Table 6.1 lists the protocols included in the advanced routing modules, as well as related information.
Protocol name and version
IP version supported
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 IP addressing format.
This protocol is similar to OSPFv2 except that it supports the IPv6 IP addressing format instead of the IPv4 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 IP addressing format.
This protocol is similar to RIPv1 and RIPv2 except that it supports the IPv6 IP addressing format instead of the IPv4 format.
Advertise and redistribute virtual address routes to routers on an internal or external network
Note: On the BIG-IP system, some advanced routing modules support both IPv4 and IPv6 addressing formats. Other modules support either IPv4 or IPv6.
If you have a VIPRION system, it is helpful to understand how the cluster environment affects the dynamic routing functionality. The key aspects of dynamic routing on VIPRION systems are:
Cluster behavior as a single router
On a VIPRION system, configuration and operation of the dynamic routing subsystem behaves as if the cluster was a single router. This causes the following:
Appearance as single router to peer routers
A cluster always appears as a single router to any peer routers regardless of the dynamic routing protocol being used.
Single configuration of the advanced routing modules
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.
Active/standby configuration
A cluster (that is, a VIRPRION chassis) represents one unit of a redundant pair in active/standby configuration. For detailed information on active/standby configuration for a VIPRION system, see Chapter 4, Configuring Clusters for Redundancy.
As mentioned in the previous section, a single VIPRION chassis acts as a single router. Dynamic routing must always be configured on the primary blade using the IMI shell (invoked with the imish command).
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.
Important: The configuration cannot be modified and saved on secondary blades. F5 does not support direct modifications of the ZebOS.conf file.
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 routing tables on all blades.
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.
Enabled dynamic routing modules execute on every blade in a cluster in one of following operational modes: MASTER, STANDBY, or SLAVE. You can display the current operational mode from within the IMI shell (imish) using command show state. Dynamic 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 the MASTER and STANDBY modes, dynamic routing modules actively participate in dynamic routing protocol communication with peer routers and maintain TMM and Linux dynamic routing 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, dynamic routing modules do not transmit any dynamic routing protocol traffic. Depending on dynamic routing protocol, modules either track dynamic routing protocol communication between the dynamic 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.
Table 6.2 lists the supported IETF documents for individual protocols, as well as the extent to which each protocol supports the graceful restart function on the VIPRION system:
IPv4 -- Yes
IPv6 -- No
RIP (all versions)
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 in all supported protocols and for all supported address families by default. For details on protocols and graceful restart options in the BIG-IP system, see the BIG-IP system release notes.
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 Linux route tables) is always preserved on VIPRION systems during primary blade changes, regardless of support for graceful restart on peer 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 (https://support.f5.com).
When deploying the advanced routing modules in a redundant system configuration, you should consider the following:
For protocols that include the router ID attribute, each unit of the redundant system configuration must have a unique router ID.
When using either BGP or RIP (or both), both units of the redundant system automatically advertise their shared, floating self IP address as the next hop for BIG-IP system virtual addresses. This ensures that traffic destined for virtual addresses always targets the active unit of the redundant system. For more information, see Configuring BGP for a redundant system, Configuring RIP for a redundant system, and Configuring RIPng 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 Configuring OSPF for a redundant system.
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.
All required module daemons start automatically when you install a user configuration set (UCS) that contains a properly-configured ZebOS.conf file.
If you have an active/standby redundant system configuration, there are additional issues to consider when you configure the advanced routing modules. For more information, see Important considerations for active/standby configurations. If your redundant system configuration consists of VIPRION systems, see also Understanding dynamic routing on a VIPRION system.
Note: In a redundant system configuration, 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.
Important: If you have a VIPRION system, always configure the advanced routing modules on the primary blade, using the cluster IP address, rather than on a secondary blade directly. This ensures that the primary blade synchronizes the advanced module configuration to all blades in the cluster.
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 routing 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. Also, always use the IMI shell to actively save your customized configuration; this prevents data loss when you restart the module later. Note that F5 Networks provides no technical support for configurations created by modifying the ZebOS.conf file directly.
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 IMI shell (formerly the VTY Shell) to configure the routing module. This step includes using the shell to save this configuration data. For more information, see Using the IMI shell.
Note: If you are accustomed to using the vtysh command to configure the advanced routing modules, you can continue to do so. The vtysh command is symbolically linked to the imish command.
3.
Next, if you want to advertise any BIG-IP system virtual addresses, you must do this using either the Configuration utility or the bigpipe shell. 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, You do this using the IMI shell to configure the pertinent advanced routing module. For more information, see Redistributing routes to virtual addresses.
Throughout this guide, the text contains references to various ZebOS reference or configuration guides. These guides are available online, through the AskF5SM web site, https://support.f5.com.
1.
Log on to the AskF5SM web site, https://support.f5.com.
2.
In the Search by Keywords box, type a ZebOS guide title.
ZebOS BGP Command Reference
ZebOS NSM Command Reference
ZebOS OSPF Command Reference
ZebOS RIP Command Reference
ZebOS Core Configuration Guide
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 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 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 routing table and the Linux 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.
At the BIG-IP system prompt, type the zebos command and specify a routing module, using this syntax:
The Border Gateway Protocol (BGP) routing module is a dynamic routing protocol for external networks. On the BIG-IP system, the corresponding bgpd daemon supports both IPv4 and IPv6 addressing formats.
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 6.1 on this page 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. Note that you do not need to explicitly configure any route maps to selectively set the next-hop on advertised routes to the shared self IP address. The BIG-IP system automatically sets the next-hop to the shared IP address.
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 192.168.151.253 peer-group ext-routers
14 neighbor 192.168.151.254 peer-group ext-routers
15 !
Line 12: Configures an ASN of 66 for the remote peers in the peer group ext-routers.
Line 13: Assigns the external router 192.168.151.253 to the peer group ext-routers.
Line 14: Assigns the external router 192.168.151.254 to the peer group ext-routers.
Once you have familiarized yourself with the sample BGP configuration, you can configure the BGP routing module on your system. To simplify this task for you, the BIG-IP system includes the imish command. This command starts the IMI command line shell. For information on how to use the IMI shell to customize the BGP configuration, see the ZebOS guide BGP Command Reference on https://support.f5.com.
Routing Information Protocol (RIP) is an industry-standard dynamic routing protocol for internal networks, based on a distance-vector algorithm.The Advanced Routing Modules feature of the BIG-IP system contains two versions of the RIP protocol: RIPv1 and RIPv2. The RIP module has a corresponding daemon, ripd.
On the BIG-IP system, the ripd daemon supports the IPv4 addressing format only. This daemon can advertise floating IP addresses as next-hop addresses. With this daemon, a route map can override next-hop addresses.
A good way to understand the configuration of a RIP module is to examine part of a sample configuration. Figure 6.2, following, shows part of a sample RIPv1/v2 configuration, configured on one unit of an active/standby system.
Important: You do not need to explicitly configure a route map to selectively advertise a shared IP address as the next hop on advertised routes. The BIG-IP system automatically advertises a shared IP address as the next hop. By default, the IP address that the BIG-IP system advertises is the first shared IP address on each VLAN. Note that you can override this default behavior using a route map.
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 6.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 system configuration.
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 !
Once you have familiarized yourself with the sample RIP configuration, you can configure the RIP routing module. To simplify this task for you, the BIG-IP system includes the imish command. This command starts the IMI command line shell. For information on how to use the IMI shell to customize the RIP configuration, see the ZebOS RIP Command Reference guide on https://support.f5.com.
RIPng is an industry-standard dynamic routing protocol for internal networks, based on a distance-vector algorithm.The RIPng module has a corresponding daemon, ripngd.
The ripngd daemon supports the IPv6 addressing format only. Like the ripd daemon, the ripngd daemon can advertise floating IP addresses as next-hop addresses. Unlike with the ripd daemon, however, a route map cannot override next-hop addresses.
Important: You do not need to explicitly configure a route map to selectively advertise a shared IP address as the next hop on advertised routes. The BIG-IP system automatically advertises a shared IP address as the next hop. By default, the IP address that the BIG-IP system advertises is the first shared IP address on each VLAN. Note that you can override this default behavior using a route map.
A good way to understand the configuration of a RIPng module is to examine part of a sample configuration. Figure 6.3 shows part of a sample RIPng configuration, configured on one unit of an active/standby system.
The example shows RIPng routing configured on a single VLAN. Note that you do not need to explicitly configure any route maps to selectively set the next-hop on advertised routes to the shared self IP address. The BIG-IP system automatically sets the next-hop to the shared IP address.
Note that because RIPng has no concept of a router ID, the configuration of the RIPng module should be identical on both units of the redundant system configuration.
Also note that the line numbers shown in the example are not part of the actual RIPng 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 rip-ng
10 network 10.1.1.0/24
11 !
Once you have familiarized yourself with the sample RIPng configuration, you can configure the RIPng routing module. To simplify this task for you, the BIG-IP system includes the imish command. This command starts the IMI command line shell. For information on how to use the IMI shell to customize the RIPng configuration, see the ZebOS RIP Command Reference guide on https://support.f5.com.
The Open Shortest Path First (OSPF) routing module is a dynamic routing protocol for internal networks, based on a link-state algorithm. The Advanced Routing Modules feature of the BIG-IP system contains two OSPF routing modules: OSPFv2 and OSPFv3. Each module has a corresponding daemon, ospfd and ospf6d, respectively.
On the BIG-IP system, the ospfd daemon supports the IPv4 addressing format. The ospf6d daemon supports the IPv6 addressing format.
To guarantee correct operation in redundant active/standby configurations, the BIG-IP system automatically changes the runtime state after failover. 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. Figure 6.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 https://support.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 6.4 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.
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.
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, 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.
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 6.5 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 6.4.
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 6.6 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 Core Configuration Guide provides examples of using route maps with all supported dynamic routing protocols. Both of these guides are available on https://support.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.
Figure 6.7 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: Configures 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 6.8 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.
Note: The RIPng routing module does not support the ability to set the next-hop address. If you configure RIPng to set a next-hop address, the module ignores the request.
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:
To stop all advanced routing modules, you must disable each module individually, using the zebos command. For example:
This command stops the named routing daemon, and as a result, causes the system to remove dynamically-learned routes from the 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) from both 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 tmrouted. 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 6.9.
Figure 6.9 Sample output from the zebos command
Table of Contents   |   << Previous Chapter   |   Next 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)