F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP TMOS: Routing Administration
  3. Dynamic Routing
Manual Chapter : Dynamic Routing

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP APM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP Analytics

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP Link Controller

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP LTM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP PEM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP AFM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP DNS

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP ASM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Manual Chapter

Dynamic Routing

Dynamic routing on the BIG-IP system

By enabling and configuring any of the BIG-IP® advanced routing modules, you can configure dynamic routing on the BIG-IP system. You enable one or more advanced routing modules, as well as the Bidirectional Forwarding Detection (BFD) protocol, on a per-route-domain basis. Advanced routing module configuration on the BIG-IP system provides these functions:
  • Dynamically adds routes to the Traffic Management Microkernel (TMM) and host route tables.
  • Advertises and redistributes routes for BIG-IP virtual addresses to other routers.
  • When BFD is enabled, detects failing links more quickly than would normally be possible using the dynamic routing protocols' own detection mechanisms.
On the BIG-IP system, directly-connected and static routes take precedence over dynamically-learned routes.

Supported protocols for dynamic routing

The BIG-IP® advanced routing modules support these protocols.
Supported protocols
Protocol Name
Description
Daemon
IP version supported
BFD
Bidirectional Forwarding Detection
 is a network protocol that detects faults between two forwarding engines connected by a link. On the BIG-IP system, you can enable the BFD protocol for the OSPFv2, BGP4, and IS-IS dynamic routing protocols specifically. Note that BFD is not a dynamic routing protocol.
oamd
IPv4 and IPv6
BGP4
Border Gateway Protocol (BGP)
 with multi-protocol extension is a dynamic routing protocol for external networks that supports the IPv4 and IPv6 addressing formats.
bgpd
IPv4 and IPv6
IS-IS
Intermediate System-to-Intermediate System (IS-IS)
 is a dynamic routing protocol for internal networks, based on a link-state algorithm.
isisd
IPv4 and IPv6
OSPFv2
The
Open Shortest Path First (OSPF)
 protocol is a dynamic routing protocol for internal networks, based on a link-state algorithm.
ospfd
IPv4
OSPFv3
The
OSPFv3
 protocol is an enhanced version of OSPFv2.
ospf6d
IPv6
PIM
The
Protocol Independent Multicast (PIM)
 protocol is a dynamic routing protocol for multicast packets from a server to all interested clients.
pimd
IPv4 and IPv6
RIPv1/RIPv2
Routing Information Protocol (RIP)
 is a dynamic routing protocol for internal networks, based on a distance-vector algorithm (number of hops).
ripd
IPv4
RIPng
The
RIPng
 protocol is an enhanced version of RIPv2.
ripngd
IPv6

About the Bidirectional Forwarding Detection protocol

Bidirectional Forwarding Detection (BFD)
 is an industry-standard network protocol on the BIG-IP® system that provides a common service to the dynamic routing protocols BGPv4, OSPFv2, and IS-IS. Enabled on a per-route domain basis, BFD identifies changes to the connectivity between two forwarding engines, or endpoints, by transmitting periodic BFD control packets on each path between the two endpoints. When either endpoint fails to receive these control packets for a specific duration of time, the connectivity between the endpoints is considered lost, and BFD notifies the associated dynamic routing protocols. In general, BFD detects connectivity changes more rapidly than the endpoints' standard Hello mechanisms, leading to quicker network convergence, which is highly desirable to data center applications.
BFD operates by establishing a session between two endpoints, sending BFD control packets over the link. If more than one link exists between two endpoints, BFD can establish multiple sessions to monitor each link.
A BFD session can operate in one of two modes, either asynchronous mode or demand mode:
  • You configure BFD to operate in
    asynchronous mode
     when you want both endpoints to verify connectivity by periodically sending Hello packets to each other. This is the most commonly-used mode.
  • You configure BFD to operate in
    demand mode
     when you want the endpoints to use another way to verify connectivity to each other instead of sending Hello packets. For example, the endpoints might verify connectivity at the underlying physical layer. Note, however, that in demand mode, either host can send Hello packets if needed.
BFD failure detection between two BIG-IP systems does not trigger failover.

Configuration overview for the BFD protocol

The first step in configuring the Bidirectional Forwarding Detection (BFD) protocol on the BIG-IP system is to use the IMI Shell within
tmsh
 to configure the protocol for the relevant advanced routing modules (BGP4, OSPFv2, and IS-IS):
  • Because BFD does not include a discovery mechanism, you must explicitly configure BFD sessions between endpoints.
  • The BFD protocol requires you to commit a nominal amount of additional system resources, in the form of timers, interface bandwidth, and system memory.
After configuring BFD protocol behavior, you enable the protocol on one or more specific route domains.
You can find detailed documentation on BFD commands in the AskF5 knowledge base at
https://support.f5.com
.

Enabling the BFD protocol for a route domain

Before you perform this task, verify that you have configured the
Port Lockdown
 setting on all self IP addresses with which routers must communicate. Specifically, you must configure self IP addresses to allow TCP connections on the relevant service port.
You must enable the Bidirectional Forwarding Detection (BFD) network protocol on a per-route domain basis. Use this task to enable BFD on an existing route domain.
  1. On the Main tab, click
    Network
    Route Domains
    .
    The Route Domains list screen opens.
  2. In the Name column, click the name of the relevant route domain.
  3. For the
    Dynamic Routing Protocols
     setting, from the
    Available
     list, select
    BFD
     and move it to the
    Enabled
     list.
    When you enable BFD, the BIG-IP system starts one BFD session for the route domain, and this session supports the BGP4, IS-IS, and OSPFv2 protocols.
  4. Click
    Update
    .
    The system displays the list of route domains on the BIG-IP system.
After you perform this task, the BIG-IP system starts the daemon
oamd
. Once enabled, the BFD protocol automatically restarts whenever the BIG-IP system is restarted.

Common commands for BFD base configuration

There are two common BFD commands that you can use to perform BFD base configuration. To use these commands, you use the IMI Shell within
tmsh
.
Sample command line sequence
Result
bigip (config-if)#
bfd interval
100
 minrx
200
 multiplier
4
Sets desired Min Tx, required Min Rx, and detect Multiplier.
bigip (config)#
bfd slow-timer
2000
Sets BFD slow timer to two seconds.

Common commands for BFD routing configuration

There are a number of common BFD commands that you can use to perform BFD routing configuration. To use these commands, you use the IMI Shell within
tmsh
.
Protocol
Sample command line sequence
Result
BGP4
bigip (config-if)#
neighbor
1.1.1.1
 fallover bfd multihop
Enables multi-hop bidirectional forwarding detection to BGP neighbor
1.1.1.1
.
OSPFv2
bigip (config)#
bfd all-interfaces
Enables single-hop bidirectional forwarding detection for all OSPF neighbors.
OSPFv2
bigip (config)#
area
1
 virtual-link
3.3.3.3
 fallover bfd
Enables multi-hop bidirectional forwarding detection to OSPF router
3.3.3.3
.
IS-IS
bigip (config-if)#
bfd all-interfaces
Enables bidirectional forwarding detection for all IS-IS neighbors.

About the Protocol Independent Multicast protocol

The
Protocol Independent Multicast (PIM)
 protocol (which is available with licensed ZebOS® dynamic routing on the BIG-IP® system) comprises a group of carrier-class multicast routing protocols for the distribution of data. Within this group, the BIG-IP system supports the
PIM Dense Mode (PIM-DM)
 and
PIM Sparse Mode (PIM-SM)
 protocols, which provide dense mode, sparse mode, and sparse-dense mode multicast routing. Sparse-dense mode only applies to IPv4 and is proprietary to Cisco®.

About using PIM sparse mode

You can configure a BIG-IP® system non-default route domain to use the Protocol Independent Multicast (PIM) protocol sparse mode (SM), which is available with a Multicast Routing Bundle license in addition to licensed ZebOS® dynamic routing. This configuration provides an effective multicast solution for Wide Area Networks (WANs) with sparsely distributed groups.
Interested listeners located downstream from a PIM router join a PIM sparse mode tree through a join message, which is then sent from the listener's designated router toward a rendezvous point. All routers in a PIM domain must map to a rendezvous point router, which acts as an information exchange point for the routers.
F5 does not yet support BIG-IP system in the role of a Rendezvous point for PIM sparse mode.

About using PIM dense mode

You can configure a BIG-IP® system non-default route domain to use the Protocol Independent Multicast (PIM) protocol dense mode (DM), which is available with a Multicast Routing Bundle license in addition to licensed ZebOS® dynamic routing. This configuration provides an effective multicast solution for Local Area Networks (LANs) that are configured with listeners at most locations.
For example, in a PIM-DM configuration, you can configure the Local Traffic Manager (LTM) to use a wildcard forwarding virtual server to flood IPv4 or IPv6 multicast traffic throughout the domain. Interested listeners, located downstream from a PIM router, use the Internet Group Management Protocol (IGMPv3) protocol for IPv4 traffic or Multicast Listener Discovery (MLDv2) protocol for IPv6 traffic to join the multicast group. When the LTM receives traffic, it sends that traffic to all active PIM routers, which then forward the packets toward the interested listeners. PIM routers without interested listeners prune themselves from the multicast group. When a listener leaves the multicast group, the upstream router sends a PIM prune message to the LTM, which removes that router from the group's forwarding list, thus enabling the LTM to send group traffic only to active PIM routers, and use the shortest-path trees.
Additionally, a PIM-DM configuration applies reverse path forwarding functionality, using the unicast routing information base (RIB), to provide loop-free forwarding of multicast traffic.

About using PIM sparse-dense mode

The IPv4 Protocol Independent Multicast (PIM) Sparse-Dense protocol is a Cisco proprietary protocol. Combining PIM dense mode (DM) and sparse mode (SM) into a single process offers simplicity, maintainability, and better performance. Certain groups can be explicitly configured for DM, while leaving the rest operating in SM.

About reverse path forwarding functionality

The Protocol Independent Multicast (PIM) protocol dense mode (DM) configuration applies
reverse path forwarding (RPF)
 functionality, which uses a unicast routing information base (RIB) to provide loop-free forwarding of multicast traffic.
For example, an RPF router is located on an interface that sends unicast packets to the source. When a multicast packet arrives on an RPF router, the router forwards the packet to the interfaces specified by the unicast RIB. If a multicast packet arrives on a non-RPF interface, the packet is discarded, thus preventing a loop condition.

About Maximum Multicast Rate functionality

Maximum Multicast Rate functionality provides a packets-per-second rate limit intended for non-broadcast multicast functionality. You can disable this functionality to optimize performance and throughput for multicast functionality. Click
System
Configuration
Local Traffic
General
, and then clear the
Maximum Multicast Rate
 check box.

Configuration overview for the PIM protocol

The first step in configuring Protocol Independent Multicast (PIM) protocol on the BIG-IP system is to use the IMI Shell within
tmsh
 to configure the protocol for the relevant advanced routing module (PIM).
After configuring PIM protocol behavior, you enable the protocol on one or more specific route domains.
You can find detailed documentation on PIM commands in the AskF5 knowledge base at
http://support.f5.com
.

Enabling a PIM protocol for a route domain

Before you configure a BIG-IP system route domain to use Protocol Independent Multicast (PIM) network protocol functionality, you need to license and configure ZebOS multicast functionality.
You must enable the PIM network protocol on a per-route domain basis. Use this task to enable PIM on an existing route domain.
  1. On the Main tab, click
    System
    Configuration
    Local Traffic
    General
    .
    The Local Traffic General settings screen opens.
  2. Clear the
    Maximum Multicast Rate
     check box.
  3. Click
    Update
     to apply the changes.
  4. On the Main tab, click
    Network
    Route Domains
    .
    The Route Domains list screen opens.
  5. In the Name column, click the name of the relevant route domain.
  6. For the
    Dynamic Routing Protocols
     setting, from the
    Available
     list, select
    PIM
     and move it to the
    Enabled
     list.
    When you enable PIM, the BIG-IP system starts one PIM session for the route domain, and this session supports the IGMPv3 for IPv4 and MLDv2 for IPv6 protocols.
  7. Click
    Update
    .
    The system displays the list of route domains on the BIG-IP system.
After you perform this task, the BIG-IP system starts the daemons
mribd
 and
pimd
. Once enabled, the PIM protocol automatically restarts whenever the BIG-IP system is restarted.

Common commands for enabling multicast routing

There are several commands that you can use to enable multicast routing. To use these commands, you access the IMI Shell within
tmsh
.
Sample command line sequence
Result
bigip (config-if)>en
Enables multicast functionality.
bigip (config-if)#conf t
Enables configuration functionality.
bigip (config-if)#ip pim dense-mode
Enables IPv4 PIM dense-mode functionality.
bigip (config-if)#ipv6 pim dense-mode
Enables IPv6 PIM dense-mode functionality.
bigip (config-if)#ip pim sparse-mode
Enables IPv4 PIM sparse-mode functionality.
bigip (config-if)#ipv6 pim sparse-mode
Enables IPv6 PIM sparse-mode functionality.
bigip (config-if)#ip pim sparse-dense-mode
Enables IPv4 PIM sparse-dense-mode functionality.
bigip (config-if)#ipv6 pim sparse-dense-mode
Enables IPv6 PIM sparse-dense-mode functionality.

Common commands for configuring PIM interfaces

There are a number of common PIM commands that you can use to perform PIM routing configuration. To use these commands, you access the IMI Shell within
tmsh
.
Sample command line sequence
Result
bigip (config-if)#interface external
Specifies configuration of external port.
bigip (config-if)#ip pim dense-mode
Configures PIM dense mode for external port.
bigip (config)#ip pim dense-group
Configures a particular multicast group to function in dense-mode while all other groups function in sparse mode.

Common tmsh commands for PIM interfaces

There are a number of common
tmsh
 commands that you can use to assess Protocol Independent Multicast (PIM) interfaces.
Sample commands
Results
bigip (config-if)#
tmsh show net mroute
Lists multicast sources, groups, incoming interfaces, and outgoing interfaces.
bigip (config-if)#
tmsh show sys ip-stat | grep Multicast
Summarizes multicast statistics.

PIM protocol supported tunnel types

Protocol Independent Multicast (PIM) protocol functionality, available with licensed ZebOS dynamic routing, supports several types of tunnels.
  • etherip
  • fec
  • gre
  • ip4ip4
  • ip4ip6
  • ip6ip4
  • ip6ip6
  • ipip
  • ppp
  • vxlan

About ECMP routing

Some of the advanced routing modules on the BIG-IP system include support for Equal Cost Multipath (ECMP) routing.
ECMP
 is a forwarding mechanism for routing a traffic flow along multiple paths of equal cost, with the goal of achieving equally-distributed link load sharing. By load balancing traffic over multiple paths, ECMP offers potential increases in bandwidth, as well as some level of fault tolerance when a path on the network becomes unavailable.

Advanced routing modules that support ECMP

The BIG-IP® system deploys Equal Cost Multipath (ECMP) routing with these advanced routing modules:
  • BGP4
  • IS-IS
  • OSPFv2
  • OSPFv3
  • PIM
  • RIPv1
  • RIPv2
The ECMP protocol is enabled by default for all of these advanced routing modules except BGP4. For BGP4, you must explicitly enable the ECMP forwarding mechanism.

Enabling the ECMP protocol for BGP4

You can enable the Equal Cost Multipath (ECMP) forwarding mechanism for the BGP4 advanced routing module, using the Traffic Management Shell (
tmsh
) command line interface. When you enable ECMP for BGP4, the BIG-IP system provides multiple paths for a traffic flow to choose from, in order to reach the destination.
For all other advanced routing modules, the ECMP protocol is enabled by default.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP system.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. Type this command:
    run /util imish
    -r
    ID
    .
    The
    ID
     variable represents the route domain ID.
    This command invokes the IMI shell.
  5. Type
    enable
    .
  6. Type
    configure terminal
    .
  7. Type
    router bgp
    as-number
    .
  8. Type this command:
    bgp max-paths (
    ebgp
    |
    ibgp
    |)
    2-64
After you perform this task, the ECMP forwarding mechanism is enabled for the BGP4 advanced routing module.

Viewing routes that use ECMP

You can perform this task to view the dynamic routes on the system that are using the Equal Cost Multipath (ECMP) forwarding mechanism.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP system.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh show net route
    .
The system displays all dynamic routes and indicates the routes that are using ECMP.

Location of startup configuration for advanced routing modules

When you enable advanced routing modules for a route domain, the BIG-IP system creates a dynamic routing startup configuration. Each route domain has its own dynamic routing configuration, located in the folder
/config/zebos/rd
n
, where
n
 is the numeric route domain ID.
F5 Networks strongly discourages manual modifications to the startup configuration (such as by using a text editor). Doing so might lead to unexpected results.

Accessing the IMI Shell

Perform this task when you want to use IMI Shell (
imish
) to configure any of the dynamic routing protocols. Note that if you are using the route domains feature, you must specify the route domain pertaining to the dynamic routing protocol that you want to configure.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. Type this command:
    run /util imish
    -r
    ID
    .
    If the route domain for the protocol you want to configure is the default route domain for the current partition, you do not need to use the
    -r
     option to specify the route domain ID.
    This command invokes the IMI shell.
You can now use any of the IMI shell commands.

Relationship of advanced routing modules and BFD to route domains

For each route domain on the BIG-IP system (including route domain
0
), you can enable one or more dynamic routing protocols, as well as the network protocol Bidirectional Forwarding Detection (BFD). For example, you can enable BGP4 and OSPFv3 on a specific route domain. Use of dynamic routing protocols for a route domain is optional.
When you enable dynamic routing on a specific route domain, the BIG-IP system creates a dynamic routing instance. This dynamic routing instance is made up of the core dynamic routing daemons (
imi
 and
nsm
), as well each relevant dynamic routing protocol daemon. If you enable BFD, the BFD instance is made up of the
oamd
 protocol daemon. Thus, each dynamic routing instance for a route domain has a separate configuration. You manage a dynamic routing configuration using the IMI shell (
imish
) within the BIG-IP Traffic Management Shell (
tmsh
).

Enabling a protocol for a route domain

Before you perform this task, verify that you have configured the
Port Lockdown
 setting on all self IP addresses with which routers must communicate. Specifically, you must configure self IP addresses to allow TCP connections on the relevant service port. For example, for BGP4, you must configure self IP addresses to allow TCP connections for port
179
, the well-known port for BGP4.
The first step in configuring dynamic routing protocols on the BIG-IP system is to enable one or more routing protocols, as well as the optional the Bidirectional Forwarding Detection (BFD) network protocol. A protocol is enabled when at least one instance of the protocol is enabled on a route domain.
The BIG-IP system does not synchronize enabled protocols at runtime during configuration synchronization in a redundant system configuration. This can adversely affect the OSPFv2 and OSPFv3 protocols. To prevent these effects, always enable the protocol on an active device. Then synchronize the configuration to a standby device.
  1. On the Main tab, click
    Network
    Route Domains
    .
    The Route Domains list screen opens.
  2. In the Name column, click the name of the relevant route domain.
  3. For the
    Dynamic Routing Protocols
     setting, from the
    Available
     list, select a protocol name and move it to the
    Enabled
     list.
    You can enable any number of listed protocols for this route domain.
    When you enable BFD, the BIG-IP system starts one BFD session for the route domain, and this session supports the BGP4, IS-IS, and OSPFv2 protocols only.
  4. Click
    Update
    .
    The system displays the list of route domains on the BIG-IP system.
After performing this task, the BIG-IP system starts an instance of the specified protocol daemon for the specified route domain, and starts the core daemons
nsm
 and
imi
. If BFD is enabled, the system also starts the daemon
oamd
. Once enabled, a protocol automatically restarts whenever the BIG-IP system is restarted.

Disabling a protocol for a route domain

Perform this task to disable an instance of a routing or network protocol that is currently associated with a route domain other than route domain
0
.
The BIG-IP system does not synchronize disabled protocols at runtime during configuration synchronization in a device service clustering (redundant) configuration. This can adversely affect the OSPFv2 and OSPFv3 protocols. To prevent these effects, always disable the protocol on a standby device. Then synchronize the configuration to an active device.
  1. On the Main tab, click
    Network
    Route Domains
    .
    The Route Domains list screen opens.
  2. In the Name column, click the name of the relevant route domain.
  3. For the
    Dynamic Routing Protocols
     setting, from the
    Enabled
     list, select a protocol name and move it to the
    Available
     list.
    You can disable any number of listed protocols for this route domain.
  4. Click
    Update
    .
    The system displays the list of route domains on the BIG-IP system.
After disabling a dynamic routing protocol for a route domain, the BIG-IP system stops the daemon of the specified protocol, resulting in these effects:
  • If the specified protocol was the only protocol enabled on the system, the system stops the common daemons
    nsm
     and
    imi
    , and possibly the
    oamd
     daemon. You will no longer see these daemons running on the system.
  • The relevant configuration is removed from the runtime configuration, but the configuration is stored on the system until you explicitly save the running configuration.
  • If restarted later, the BIG-IP system does not automatically re-enable the protocol. In this case, you must explicitly re-enable the protocol after the system restarts.

Displaying the status of enabled protocols

Perform this task to display the status of instances of any dynamic routing protocols (including the Bidirectional Forwarding Detection (BFD) protocol) that are enabled for a specific route domain.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. Type
    run util zebos check
    This displays the status and process IDs of any enabled dynamic routing protocols or BFD protocol for the specified route domain.
After performing this task, you can see the status and process IDs of any enabled protocols. The following shows sample output: 

        bgpd    is running [22320]

About Route Health Injection

Route Health Injection (RHI)
 is the system process of advertising the availability of virtual addresses to other routers on the network. You can configure two aspects of RHI: route advertisement and route redistribution.

About route advertisement of virtual addresses

Route advertisement
 is the function that the BIG-IP® system performs when advertising a route for a virtual address to the Traffic Management Microkernel (TMM) routing table. You must configure route advertisement to ensure that the dynamic routing protocols propagate this route to other routers on the network.
The settings related to route advertisement that you can configure on a virtual address are:
Property
Description
Default Value
Availability Calculation
A setting that tells the BIG-IP system when to consider the virtual address available for advertisement to an advanced routing module. This setting only applies when the
Route Advertisement
 setting is set to anything other than
Disabled
. Possible values are:
  • When any virtual server is available
  • When all virtual server(s) are available
  • Always
When any virtual server is available
ICMP Echo
A setting that enables, selectively enables, or disables responses to ICMP echo requests on a per-virtual address basis. When this setting is disabled, the BIG-IP system drops any ICMP echo request packets sent to virtual addresses, including standard statistics and logging. Note that the resulting behavior is affected by the value you configure for the
Availability Calculation
 setting.
Enabled
Route Advertisement
A setting that inserts a route to this virtual address into the kernel routing table so that an advanced routing module can redistribute that route to other routers on the network. Possible values are:
Disabled
Does not advertise the route for the virtual address, regardless of the availability status
Enabled
Advertises the route for the available virtual address, based on the calculation method selected in the Availability Calculation list.
Always
Always advertises the route for the virtual address, regardless of availability status. This requires an enabled virtual address.
Selective
You can also selectively enable ICMP echo responses, which causes the BIG-IP system to internally enable or disable responses based on virtual server state: any virtual server, all virtual servers, or always, regardless of the state of any virtual server.
Any
Advertises the route for the virtual address when any virtual server is available.
All
Advertises the route for the virtual address when all virtual servers are available.
Disabled
After you configure the desired behavior of the system with respect to route advertisement, the
tmrouted
 daemon attempts to comply. The daemon only succeeds in advertising the route for the virtual address when the relevant virtual servers, pool, and pool members collectively report their status in specific combinations.
When you configure RHI in a device group configuration, only devices with active traffic groups attempt to advertise routes to virtual addresses.

Determination of UP state for a virtual address

The
tmrouted
 daemon within the BIG-IP® system considers a virtual IP address to be in an UP state when any one of the following conditions are true:
  • The BIG-IP Configuration utility shows blue, green, or yellow status for the virtual address.
  • The virtual address is a member of an active traffic group.
  • The virtual address is enabled and is currently being advertised.

Conditions for route advertisement of virtual addresses

This table shows the ways that Local Traffic Manager (LTM) object status affects whether the BIG-IP system advertises a route to a virtual address. In the table, the colors represent object status shown on the Local Traffic screens within the BIG-IP Configuration utility. The table also summarizes the collective LTM object status that determines route advertisement.
Route advertisement for virtual addresses based on LTM object status
​
LTM object status
​
Route advertised?
Pool member
Pool
Virtual server
Virtual address
Status summary
Yes
green circle status icon
green circle status icon
green circle status icon
green circle status icon
Pool members are monitored and
UP
. The virtual address is
UP
.
Yes
blue square status icon
blue square status icon
blue square status icon
blue square status icon
Pool or pool members are not monitored. The virtual address is enabled.
Yes
black circle status icon black diamond status icon
green circle status icon
green circle status icon
green circle status icon
Pool members are disabled. Other objects are enabled.
Yes
black circle status icon black diamond status icon
green circle status icon
black circle status icon black diamond status icon
green circle status icon
Virtual server is disabled. Virtual address is enabled.
Yes
N/A
yellow triangle status icon
yellow triangle status icon
yellow triangle status icon
The pool has no members. The virtual address is enabled.
Yes
N/A
N/A
blue square status icon
blue square status icon
Virtual server has no pool assigned.
No
red diamond status icon
red diamond status icon
red diamond status icon
red diamond status icon
Pool members are monitored and
DOWN
.
No
black circle status icon black diamond status icon
green circle status icon
black circle status icon black diamond status icon
black circle status icon black diamond status icon
Virtual server and virtual address are disabled.
No
green circle status icon
green circle status icon
gray circle status icon gray square status icon gray triangle status icon
black circle status icon black diamond status icon
Virtual address is disabled. Other objects are enabled.

LTM object status indicators

The BIG-IP Configuration utility displays various colored icons to report the status of virtual servers, virtual addresses, pools, and pool members.
Green circle green circle status icon
The object is available in some capacity. The BIG-IP system services traffic destined for this object.
Blue square blue square status icon
The availability of the object is unknown. Sample causes of this status are when the object is not configured for service checking, the IP address of the object is misconfigured, or the object is disconnected from the network.
Yellow triangle yellow triangle status icon
The object is not currently available but might become available later with no user intervention. For example, an object that has reached its configured connection limit might show yellow status but later switch to green when the number of connections falls below the configured limit.
Red diamond red diamond status icon
The object is not available. The BIG-IP system cannot service traffic destined for this object. A sample cause of this status is when a node fails service checking because it has become unavailable. This status requires user intervention to restore the object status to green.
Black circle black circle status icon
A user has actively disabled an available object.
Black diamond black diamond status icon
A user has actively disabled an unavailable object.
Gray icons gray circle status icon gray square status icon gray triangle status icon
A parent object disabled the object, or the object is enabled but unavailable because of another disabled object.

Configuring route advertisement on virtual addresses

Before performing this task, verify that you have created the relevant virtual server on the BIG-IP system. Also, the virtual address that you want to advertise must have a status of Up, Unavailable, or Unknown.
Perform this task to specify the criterion that the BIG-IP system uses to advertise routes for virtual addresses. You must perform this task if you want the dynamic routing protocols to propagate this route to other routers on the network.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    Virtual Address List
    .
  2. Click the virtual address you want to configure.
    If the virtual address does not appear in the list, you must first create the associated virtual server.
  3. To specify when the virtual address is considered available for route advertisement, select an option from the
    Availability Calculation
     list:
    • When any virtual server is available
    • When all virtual server(s) are available
    • Always
    When the virtual address is available and the
    Route Advertisement
     setting is set to
    Enabled
    , the BIG-IP system advertises the route for the virtual address.
  4. From the
    Route Advertisement
     list, select an option:
    Option
    Description
    Disabled
    Does not advertise the route for the virtual address, regardless of the availability status.
    Enabled
    Advertises the route for the available virtual address, based on the calculation method selected in the
    Availability Calculation
     list.
    Always
    Always advertises the route for the virtual address, regardless of availability status. This requires an enabled virtual address.
    Selective
    Selectively enables ICMP echo responses, which causes the BIG-IP system to internally enable or disable responses based on virtual server state: any virtual server, all virtual servers, or always, regardless of the state of any virtual server.
    Any
    Advertises the route for the virtual address when any virtual server is available.
    All
    Advertises the route for the virtual address when all virtual servers are available.
After you perform this task, properly-configured dynamic routing protocols can redistribute the advertised route to other routers on the network.

Displaying advertised routes for virtual addresses

Before you perform this task, depending on the dynamic routing protocol, you might need to configure the protocol's router definition to redistribute the kernel.
Perform this task when you want to display routes for virtual addresses that the BIG-IP system has advertised to other routers on the network.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. Type
    run /util imish
    -r
    ID
    The variable
    ID
     is the ID of the relevant route domain. This ID must be an integer.
    This opens the IMI shell.
  5. At the prompt, type
    show ip route kernel
    .
After performing this task, you should see the advertised routes for virtual addresses. For example, advertised routes for virtual addresses
10.1.51.80/32
 and
10.2.51.81/32
 appear as follows:

             K       10.1.51.80/32 is directly connected, tmm0
             K       10.1.51.81/32 is directly connected, tmm0
The
/32
 netmask indicates that the IP addresses pertain to individual hosts, and the
tmm0
 indicator shows that protocols on other routers have learned these routes from the Traffic Management Microkernel (TMM).

Delaying the withdrawal of RHI routes

Perform this task to delay the withdrawal of RHI routes when operation status changes. Delaying route withdrawal prevents short route flaps that might occur due to both the short period during failover when both devices are in a standby state, and the periodic housekeeping processes in routing protocol daemons (specifically
bgpd
).
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. Set the
    bigdb
     variable to the needed delay by typing this command:
    modify /sys db tmrouted.rhifailoverdelay value
    delay_in_seconds
The BIG-IP system now delays the withdrawal of RHI routes by the number of seconds that you specified.

Redistribution of routes for BIG-IP virtual addresses

You can explicitly configure each dynamic routing protocol to redistribute routes for advertised virtual addresses, to ensure that other routers on the network learn these routes. For purposes of redistribution, the dynamic routing protocols consider any route generated through Route Health Injection (RHI) to be a host route.
For all dynamic routing protocols, you must configure route redistribution for IPv4 addresses separately from that of IPv6 addresses.
This example shows an entry in the OSPF configuration. When you add this statement to the OSPF configuration, the BIG-IP system redistributes the route for the virtual address.
router ospf
   redistribute kernel
You can optionally specify a
route-map
 reference that specifies the route map to use for filtering routes prior to redistribution. For example:
redistribute kernel route-map external-out
Route maps provide an extremely flexible mechanism for fine-tuning redistribution of routes using the dynamic routing protocols.

Advertisement of next-hop addresses

The BIG-IP system advertises all self IP addresses, including floating self IP addresses, to the dynamic routing protocols. The protocols store floating addresses so that the protocols can prefer a floating address as the advertised next hop. This applies only to protocols that allow explicit next-hop advertisement.

IPv6 next-hop address selection (BGP4 only)

When you are using BGP4 and IPv6 addressing, you can advertise one or two next-hop addresses for each route. The BIG-IP system selects the addresses to advertise based on several factors.

Parameter combinations for next-hop address selection

For BGP-4 only, you can choose from several combinations of configuration parameters to control the selection of next-hop IPv6 addresses.
P = Peering, X = Configured
Link-local autoconf. (LL-A)
Link-local (LL)
Link-local floating (LL-F)
Global (G)
Global floating (G-F)
EBGP multihop
Advertised nexthop addresses
P
LL-A
X
P
LL
X
P
X
LL-F
X
P
X
G, LL
X
P
G, LL-A
X
X
X
P
X
G
X
X
X
P
LL-F
X
P
X
G-F
X
P
X
X
GF, LL
X
X
P
X
GF
X
P
X
X
X
LL-F
X
X
X
P
X
GF-F

Visibility of static routes

The dynamic routing protocols view Traffic Management Microkernel (TMM) static routes as kernel routes. (
TMM static routes
 are routes that you configure using
tmsh
 or the BIG-IP Configuration utility.) Because TMM static routes are viewed as kernel routes, a TMM static route has a higher precedence than a dynamic route (with an identical destination).
Management routes and addresses are not visible to the dynamic routing protocols and cannot be advertised. Routes to the networks reachable through the management interface can be learned by dynamic routing protocols if they are reachable through a VLAN, VLAN group, or tunnel.

About dynamic routing for redundant system configurations

If the BIG-IP system that you are configuring for dynamic routing is part of a redundant system configuration, you should consider these factors:
  • You must configure the dynamic routing protocols on each member of the device group.
  • For protocols that include the router ID attribute, you should verify that each member of the device group has a unique router ID.
  • When you configure Route Health Injection (RHI), only active device group members advertise routes to virtual addresses.

Special considerations for BGP4, RIP, and IS-IS

For the BGP, RIP, RIPng, and IS-IS protocols, you no longer need to specifically configure these protocols to function in active-standby configurations. Each member of the device group automatically advertises the first floating self IP address of the same IP subnet as the next hop for all advertised routes. This applies to both IPv4 and IPv6 addresses.
Advertising a next-hop address that is always serviced by an active device guarantees that all traffic that follows routes advertised by any device in the redundant pair is forwarded based on the active LTM configuration.

Special considerations for OSPF

For OSPF protocols, the BIG-IP system ensures that standby device group members are the least preferred next-hop routers. The system does this by automatically changing the runtime state as follows:
Dynamic routing protocols
Protocol Name
Runtime state change
OSPFv2
The OSPF interface cost is increased on all interfaces to the maximum value (65535) when the status of the device is Standby. Also, all external type 2 Link State Advertisements (LSAs) are aged out.
OSPFv3
The OSPF interface cost is increased on all interfaces to the maximum value.

Displaying OSPF interface status

When you display OSPF interface status, you can see the effect of runtime state changes.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
  4. Type this command:
    run /util imish
    -r
    ID
    .
  5. Type
    sh ip ospf interface
    .
    The variable
    id
     is the ID of the relevant route domain.

Listing the OSPF link state database

When you list the contents of the OSPF link state database, you can see the effect of runtime state changes.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
  4. Type this command:
    run /util imish
    -r
    ID
  5. Type
    sh ip ospf database external self-originate
    .
    The variable
    id
     is the ID of the relevant route domain.

Dynamic routing on a VIPRION system

If you have a VIPRION® system, it is helpful to understand how the cluster environment affects the dynamic routing functionality.

VIPRION appearance as a single router

On a VIPRION® system, the dynamic routing system behaves as if the cluster were 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 dynamic routing protocols, 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.

Redundancy for the dynamic routing control plane

The dynamic routing system takes advantage of the redundancy provided by the cluster environment of a 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 VIPRION cluster’s appearance to the routing modules as a single router, and the operational modes of the enabled dynamic routing protocols.

Operational modes for primary and secondary blades

Enabled dynamic routing protocols run on every blade in a cluster in one of these operational modes: MASTER, STANDBY, or SLAVE.
This table shows the operational modes for primary and secondary blades, on both the active cluster and the standby cluster.
Operational modes for dynamic routing protocols per blade type
Blade Type
Active Cluster
Standby Cluster
Notes
Primary
MASTER mode
STANDBY mode
The dynamic routing protocols:
  • Actively participate in dynamic routing protocol communication with peer routers.
  • Maintain TMM and host route tables on all blades in the cluster.
Secondary
SLAVE mode
SLAVE mode
The dynamic routing protocols:
  • Do not transmit any dynamic routing protocol traffic.
  • Track communication between a module and the peer routers, or wait for transition to MASTER or STANDBY mode.
In MASTER and STANDBY modes, 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.
The transition from SLAVE to MASTER or STANDBY mode takes advantage of standard dynamic routing protocol graceful restart functionality.

Viewing the current operational mode

Perform this task to display the current operational mode (MASTER, STANDBY, or SLAVE) of a blade.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
  4. Type
    run /util imish
    -r
    ID
    .
    If the route domain for the protocol you want to configure is the default route domain for the current partition, you do not need to use the
    -r
     option to specify the route domain ID.
    This command invokes the IMI shell.
  5. Type
    show state
    .
The BIG-IP system displays a message such as
Current operational state: MASTER
.

About graceful restart on the VIPRION system

With the
graceful restart
 function, the dynamic routing protocol control plane moves from one blade to another without disruption to traffic. Graceful restart is enabled for most supported protocols and address families by default.
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.
The BIG-IP system always preserves complete forwarding information (TMM and host route tables) on VIPRION systems during primary blade changes, regardless of support for graceful restart on peer routers.

Runtime monitoring of individual blades

The BIG-IP system automatically copies the startup configuration to all secondary blades and loads the new configuration when the running configuration is saved on the primary blade.
You can display information about the runtime state of both the primary and secondary blades. However, some information displayed on secondary blades might differ from the information on the primary blade. For troubleshooting, you should use the information displayed on the primary blade only, because only the primary blade both actively participates in dynamic routing communication and controls route tables on all blades.

Troubleshooting information for dynamic routing

Dynamic route propagation depends on a BIG-IP® system daemon named
tmrouted
. The BIG-IP system starts the
tmrouted
 daemon when you enable the first dynamic routing protocol. and restarts the daemon whenever the BIG-IP system restarts.
In the rare case when you need to manage the
tmrouted
 daemon due to a system issue, you can perform a number of different tasks to troubleshoot and solve the problem.

Checking the status of the tmrouted daemon

Use this procedure to verify that the
tmrouted
 daemon is running. This daemon must be running for the enabled dynamic routing protocols to propagate routes.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Type your user credentials to log in to the system.
  3. If the system has granted you access to the BASH shell prompt, type
    tmsh
    . Otherwise, skip this step.
  4. Type
    show /sys service tmrouted
    .
The BIG-IP system displays information about
tmrouted
 such as:
tmrouted run (pid 5113) 1 days

Stopping the tmrouted daemon

Before you can stop an instance of the
tmrouted
 daemon, the associated protocol instance must be enabled on the BIG-IP system. Also, the BIG-IP system
mcpd
 and
tmm
 daemons must be running on the system.
You perform this task to stop an instance of the
tmrouted
 daemon.
Manage the
tmrouted
 daemon using the
tmsh
 utility only. Attempting to manage
tmrouted
 using a Linux command or with invalid parameters might cause the daemon to fail.
  1. Open a console window, or an SSH session using the management port, on the BIG-IP device.
  2. Type your user credentials to log in to the system.
  3. If the system has granted you access to the BASH shell prompt, type
    tmsh
    . Otherwise, skip this step.
  4. At the
    tmsh
     shell prompt, type
    stop /sys service tmrouted
    .
This command stops any instances of
tmrouted
 that are running on the system, causing the associated protocol instance to stop propagating routes.

Restarting the tmrouted daemon

Before restarting an instance of the
tmrouted
 daemon, verify that the associated protocol instance is enabled on the BIG-IP system. Also, verify that the BIG-IP system
mcpd
 and
tmm
 daemons are running on the system.
You perform this task to restart an instance of the
tmrouted
 daemon. Whenever the BIG-IP system reboots for any reason, the BIG-IP system automatically starts an instance of
tmrouted
 for each instance of an enabled dynamic routing protocol.
Manage the
tmrouted
 daemon using the
tmsh
 utility only. Attempting to manage
tmrouted
 using a Linux command or with invalid parameters might cause the daemon to fail.
  1. Open a console window, or an SSH session using the management port, on the BIG-IP system.
  2. Type your user credentials to log in to the system.
  3. If the system has granted you access to the BASH shell prompt, type
    tmsh
    . Otherwise, skip this step.
  4. At the
    tmsh
     shell prompt, type
    restart /sys service tmrouted
    .
This command restarts any instances of
tmrouted
 that are currently stopped. The daemon also communicates with the
nsm
 daemon to propagate dynamically-learned routes to other BIG-IP system processes that need to direct application traffic.

Configuring tmrouted recovery actions

Use this task to configure recovery actions when the
tmrouted
 daemon restarts.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
  4. Type
    modify /sys daemon-ha tmrouted running [enabled|disabled]
    • If you want to enable the
      running-timeout
       and
      non-running-action
       options, type
      enabled
      .
    • If you want to disable the
      running-timeout
       and
      non-running-action
       options, type
      disabled
      .
    Typing this command with the
    enabled
     option causes the active BIG-IP device to fail over to another device in the device group whenever the
    tmrouted
     daemon restarts.
  5. Type
    modify /sys daemon-ha tmrouted heartbeat [enabled|disabled]
    • If you want to enable monitoring for the
      tmrouted
       heartbeat, type
      enabled
      .
    • If you want to disable monitoring for the
      tmrouted
       heartbeat, type
      disabled
      .
    When you type this command with the
    enabled
     option and the
    tmrouted
     heartbeat is subsequently lost, the system behaves according to the action specified by the
    heartbeat-action
     option.

Location and content of log files

For each dynamic routing protocol, the BIG-IP system logs messages to a file that pertains to the route domain in which the protocol is running. An example of the path name to a dynamic routing log file is
/var/log/zebos/rd
1
/zebos.log
 file, where
rd1
 is the route domain of the protocol instance.
The system logs additional messages to the files
/var/log/daemon.log
 and
/var/log/ltm
. The system logs protocol daemon information for protocol-specific issues, and logs
nsm
 and
imi
 daemon information for core daemon-related issues.
If a core dynamic routing daemon exits, the system logs an error message similar to the following to the
/var/log/daemon.log
 file:
Mar  5 22:43:01 mybigip LOGIN: Re-starting tmrouted
In addition, the BIG-IP system logs error messages similar to the following to the
/var/log/ltm
 file:
mcpd[5157]: 01070410:5: Removed subscription with subscriber id bgpd
mcpd[5157]: 01070533:3: evWrite finished with no byte sent to connection 0xa56f9d0 (user Unknown) - connection deleted

Creating a debug log file

Perform this task to create a log file for debugging. With a debug log file, you can more effectively troubleshoot any issues with a dynamic routing protocol.
  1. Open a console window, or an SSH session using the management port, on a BIG-IP device.
  2. Use your user credentials to log in to the system.
  3. At the command prompt, type
    tmsh
    .
    This opens the
    tmsh
     shell.
  4. At the
    tmsh
     prompt, type this command:
    run /util imish
    -r
    ID
    .
    If the route domain for the protocol you want to configure is the default route domain for the current partition, you do not need to specify the route domain ID.
    This command invokes the IMI shell.
  5. Type the command
    log file /var/log/zebos/rd
    n
    /zebos.log
    .
    The variable
    n
     represents the relevant route domain ID. This ID must be an integer.
    The system creates a debug log file.
  6. Type
    write
    .
    This action saves the log file.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information