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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

There are several commands that you can use to enable multicast routing. To use these commands, you access the IMI Shell within tmsh.

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.

There are a number of common tmsh commands that you can use to assess Protocol Independent Multicast (PIM) interfaces.

Protocol Independent Multicast (PIM) protocol functionality, available with licensed ZebOS^® dynamic routing, supports several types of tunnels.

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.

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

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.

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.

   Important: 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.

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.

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.

        bgpd    is running [22320]          
        

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:

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.

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.

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.

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.

For BGP-4 only, you can choose from several combinations of configuration parameters to control the selection of next-hop IPv6 addresses.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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/rd1/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
                  

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/rdn/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.