What is bfd cisco

The latter approach is referred to as BFD asymmetry. For single-hop situations, RFC applies:. The source port MUST be in the range through Here are my thoughts about BFD best practices:. Do use interface event dampening. The default timers look pretty good. It is a good idea when attempting fast convergence to also be doing significant amounts of route summarization. The fewer routes, the faster all routing related scans and calculations can be performed.

I was just revisiting the docs. A number of the google hits were unclear as to what "bfd slow-timers" does. It is in milliseconds. If you are doing BFD echo, you can use the "bfd slow-timers" command to slow down how often the demand control connection packets get sent, e.

If you are not doing BFD echo e. If you do that, you are limited as to how much BFD the device can handle. Interesting question. BFD is much lighter weight so can run as frequently as every 50 msec. BFD also just logically brings the interface down, with routing then reacting appropriately — so the interaction with routing is a bit simpler, no special configuration required there either.

Please explain. Let me make more clarification. AndrewX: I agree! Any idea if this is applicable for control as well as echo packets. Different purposes. Set carrier delay low or to 0 for instant response to link down. BFD deals with the situation where you have a failure but some intermediate device keeps Ethernet link status up.

No idea, seems likely. Optional Displays all received routes both accepted and rejected from the specified neighbor. Optional Displays all routes that are received and accepted.

The output displayed when this keyword is entered is a subset of the output displayed by the received-routes keyword. Optional Displays the policies applied to this neighbor per address family. Optional Displays detailed policy information such as route maps, prefix lists, community lists, access control lists ACLs and AS-path filter lists. The output was modified to display the no-prepend configuration option and this command was integrated into Cisco IOS Release The received and prefix-filter keywords were added, and this command was integrated into Cisco IOS Release Support for the BGP graceful restart capability was integrated into the output.

Support for the Cisco series routers Engine 0 and Engine 2 was also added. The policy and detail keywords were added. For BGP, this includes detailed neighbor attribute, capability, path, and prefix information. Prefix activity is displayed based on the number of prefixes that are advertised and withdrawn. Policy denials display the number of routes that were advertised but then ignored based the function or attribute that is displayed in the output.

When BGP neighbors use multiple levels of peer templates it can be difficult to determine which policies are applied to the neighbor. Inherited policies are policies that the neighbor inherits from a peer-group or a peer-policy template. Example output is different for the various keywords available for the show ip bgp neighbors command. To view the appropriate output, choose one of the following sections:. The following example shows output for the BGP neighbor at This neighbor supports the route refresh and graceful restart capabilities.

Table 5 describes the significant fields shown in the display. Fields that are preceded by the asterisk character are displayed only when the counter has a nonzero value. Verifies that the local autonomous system number is not prepended to received external routes.

This output supports the hiding of the local autonomous systems when migrating autonomous systems. Time, in seconds, that BGP will maintain the session with this neighbor without receiving a messages.

Time, interval in seconds, that keepalive messages are transmitted to this neighbor. BGP capabilities advertised and received from this neighbor. Internal version number of the table. This is the primary routing table with which the neighbor has been updated. The number increments when the table changes. Number used by the software to track prefixes that have been sent and those that need to be sent.

Number of soft resets performed with a neighbor that supports soft reconfiguration. This field is displayed only if the counter has a nonzero value. Number of invalid paths. Prefixes denied due to local policy configuration.

Counters are updated for inbound and outbound policy denials. The fields under this heading are displayed only if the counter has a nonzero value. Displays inbound denials because the neighbor or link is in a dampening state. Time since this peering session was last reset. The reason for the reset is displayed on this line. The maximum number hops that can separate the local and remote peer is displayed on this line. TCP event timers.

Counters are provided for starts and wakeups expired timers. Delayed receive window—data the local host has read from the connection, but has not yet subtracted from the receive window the host has advertised to the remote host.

The value in this field gradually increases until it is larger than a full-sized packet, at which point it is applied to the rcvwnd field. New round-trip timeout using the Karn algorithm. This field separately tracks the round-trip time of packets that have been re-sent.

Time the local host will delay an acknowledgment to carry piggyback additional data. A duplicate acknowledgement is retransmitted for an out of order segment before the retransmission timer expires.

Number of retransmissions for partial acknowledgements transmissions before or without subsequent acknowledgements. The following example displays routes advertised for only the Table 6 describes the significant fields shown in the display. Table 6 show ip bgp neighbors advertised-routes Field Descriptions. Status of the table entry. The status is displayed at the beginning of each line in the table. It can be one of the following values:. Origin of the entry.

The origin code is placed at the end of each line in the table. IP address of the next system used to forward a packet to the destination network. An entry of 0. If shown, this is the value of the inter-autonomous system metric. This field is not used frequently. Local preference value as set with the set local-preference route-map configuration command. The default value is Autonomous system paths to the destination network.

There can be one entry in this field for each autonomous system in the path. The following is example output from the show ip bgp neighbors command entered with the paths keyword:.

Table 7 describes the significant fields shown in the display. Autonomous system path for that route, followed by the origin code for that route.

The following example shows that a prefix-list the filters all routes in the Table 8 describes the significant fields shown in the display. Table 8 show ip bgp neighbors received prefix-filter Field Descriptions. The following sample output shows the policies applied to the neighbor at The output displays both inherited policies and policies configured on the neighbor device. Inherited polices are policies that the neighbor inherits from a peer-group or a peer-policy template.

The following is sample output from the show ip bgp neighbors command that verifies that BFD is being used to detect fast fallover for the BGP neighbor that is a BFD peer.

The detail keyword was added. Support was added for the Cisco series Internet router. Support for the BFD feature was added. If an interface is specified, only that interface is displayed. If an autonomous system is specified, only the routing process for the specified autonomous system is displayed. The following is sample output from the show ip eigrp interfaces command:.

The following is sample output from the show ip eigrp interfaces command to verify that the BFD feature has been enabled on the EIGRP interfaces for process Table 9 describes the significant fields shown in the display. Pacing time in seconds used to determine when EIGRP packets should be sent out the interface unreliable and reliable packets. Optional Process ID. If this argument is included, only information for the specified routing process is included.

This command was modified to show packet pacing timers in the displayed output. The output of this command was expanded to display LSA throttling timers and the limit on redistributed routes. Table 10 describes the significant fields shown in the display. Table 11 describes the significant fields shown in the display. Minimum time interval in seconds between link-state advertisements, and maximum arrival time in milliseconds of link-state advertisements,.

The following is sample output from the show ip ospf command. In this example, the user had configured the redistribution maximum-prefix command to set a limit of redistributed routes. Table 12 describes the significant fields shown in the display. Value set in the redistribution maximum-prefix command to set a limit on the number of redistributed routes.

Percentage set in the redistribution maximum-prefix command for the threshold number of redistributed routes needed to cause a warning message. The default is 75 percent of the maximum limit. Configured with the timers throttle spf command. In this example, the user had configured LSA throttling, and those lines of output are displayed in bold. The following is sample show ip ospf command. SPF throttling was configured with the timers throttle spf command.

Table 13 describes the significant fields shown in the display. To get a list of components that support event tracing in this release, use the monitor event-trace? Displays all event trace messages currently in memory for the specified component.

Specifies how far back from the current time you want to view messages. For example, you can gather messages from the last 30 minutes. The time argument is specified in hours and minutes format hh:mm. Displays event trace messages starting from a specific clock time in hours and minutes format hh:mm.

Displays event trace messages starting from a specified number of seconds after booting uptime. To view the uptime, in seconds, enter the show monitor event-trace component from-boot?

Displays only the event trace messages since the last show monitor event-trace command was entered. Displays the trace parameters.

The only parameter displayed is the size number of trace messages of the trace file. The bfd keyword was added as a possible entry for the component argument to display trace messages relating to the Bidirectional Forwarding Detection BFD feature.

The cfd keyword was added as a possible entry for the component argument to display trace messages relating to crypto fault detection. Use the show monitor event-trace command to display trace message information. The trace function is not locked while information is being displayed to the console, which means that new trace messages can accumulate in memory. If entries accumulate faster than they can be displayed, some messages can be lost. If this happens, the show monitor event-trace command will generate a message indicating that some messages might be lost; however, messages will continue to display on the console.

If the number of lost messages is excessive, the show monitor event-trace command will stop displaying messages. Use the bfd keyword for the component argument to display trace messages relating to the Bidirectional Forwarding Detection BFD feature.

Use the cfd keyword for the component argument to display trace messages relating to the crypto fault detection feature. This keyword displays the contents of the error trace buffers in an encryption data path. The following is sample output from the show monitor event-trace component command for the IPC component.

Notice that each trace message is numbered and is followed by a timestamp derived from the device uptime. Following the time stamp is the component-specific message data. Use the show monitor event-trace bfd all command to display logged messages for important BFD events in the recent past. The following trace messages show BFD session state changes:.

To view trace information for all components configured for event tracing on the networking device, enter the show monitor event-trace all-traces command. In this example, separate output is provided for each event, and message numbers are interleaved between the events. The following is sample output from the show monitor event-trace component latest command for the spa component:.

If you select Cisco Express Forwarding as the component for which to display event messages, you can use the following additional arguments and keywords: show monitor event-trace cef [ events interface ipv6 ipv4 ][ all ]. Each trace message is numbered and is followed by a time stamp derived from the device uptime. In the following example, all event trace messages for the Cisco Express Forwarding component are displayed:.

Each trace message is numbered and is followed by a the time stamp derived from the device uptime. In the following example, all event trace message for the Cisco Express Forwarding component are displayed:.

To troubleshoot errors in an encryption datapath, enter the show monitor event-trace cfd all command. In this example, events are shown separately, each beginning with a timestamp, followed by data from the error trace buffer.

Cisco TAC engineers can use this information to diagnose the cause of the errors. Note If no packets have been dropped, this command does not display any output. Controls event trace functions for a specified Cisco IOS software subsystem component.

Configures event tracing for a specified Cisco IOS software subsystem component. Saves trace messages for all event traces currently enabled on the networking device. Optional Displays information for groups that are learned or do not have the standby ip command configured. The output was enhanced to display information about Message Digest 5 MD5 authentication. The output for this command was enhanced to display information about HSRP master and client groups.

The output for this command was enhanced to display information about HSRP group shutdown configuration. The following is sample output from the show standby command:. The following is sample output from the show standby command when HSRP version 2 is configured:. The following is sample output from the show standby command with the brief keyword specified:.

The following is sample output from the show standby command when HSRP group shutdown is configured:. Table 14 describes the significant fields shown in the displays. HSRP groups configured on other routers on the network that are learned via snooping are displayed as being in the Init state. Locally configured groups with an interface that is down or groups without a specified interface IP address appear in the Init state.

For these cases, the Active addr and Standby addr fields will show "unknown. All secondary virtual IP addresses are listed on separate lines.

If one of the virtual IP addresses is a duplicate of an address configured for another device, it will be marked as "duplicate.

Virtual MAC address that would be used if this router became the active router. The origin of this address displayed in parentheses can be "default," "bia," burned-in address or "confgd" configured. The hello time is the time between hello packets in seconds based on the command.

The holdtime is the time in seconds before other routers declare the active or standby router to be down, based on the standby timers command. All routers in an HSRP group use the hello and hold- time values of the current active router.

If the locally configured values are different, the variance appears in parentheses after the hello time and hold-time values. Time in which the Cisco IOS software will send the next hello packet in hours:minutes:seconds. Authentication type configured based on the standby authentication command. Duration in seconds that HSRP will accept message digests based on both the old and new keys.

Indicates whether preemption is enabled. If enabled, the minimum delay is the time a higher-priority nonactive router will wait before preempting the lower-priority active router. The sync delay is the maximum time a group will wait to synchronize with the IP redundancy clients.

Value can be "local," "unknown," or an IP address. Address and the expiration date of the address of the current active Hot Standby router. Address and the expiration date of the address of the "standby" router the router that is next in line to be the Hot Standby router. Time in hours:minutes:seconds in which the standby router will no longer be the standby router if the local router receives no hello packets from it. List of interfaces that are being tracked and their corresponding states.

Based on the standby track command. Configures the time between hello messages and the time before other routers declare the active Hot Standby or standby router to be down.

Configures an interface so that the Hot Standby priority changes based on the availability of other interfaces. Use this command to display information about HSRP peer neighbors. This command displays the HSRP groups for which each neighbor is acting as the active and standby router and whether Bidirectional Forwarding Detection BFD peering is enabled for each neighbor. Neighbor Table 15 describes the significant fields shown in the displays. Previously, group member monitoring relied exclusively on HSRP multicast messages, which are relatively large and consume CPU memory to produce and check.

In architectures where a single interface hosts a large number of groups, there is a need for a protocol with low CPU memory consumption and processing overhead. BFD addresses this issue and offers subsecond health monitoring failure detection in milliseconds with a relatively low CPU impact. This command is enabled by default. Table 16 lists the release history for this feature. Not all commands may be available in your Cisco IOS software release.

For release information about a specific command, see the command reference documentation. Use Cisco Feature Navigator to find information about platform support and software image support. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature. In Release A detection protocol designed to provide fast failure detection times for all media types, encapsulations, topologies, and routing protocols. Note See Internetworking Terms and Acronyms for terms not included in this glossary.

Download this chapter. Bidirectional Forwarding Detection. Command or Action. RouterA show bfd neighbors details. Session state is UP and not using echo function. Last packet: Version: 0 - Diagnostic: 0. Min tx interval: - Min rx interval: Session state is UP and using echo function with 50 ms interval. Last packet: Version: 1 - Diagnostic: 0. RouterB show bfd neighbors details. Minimum hold time between two consecutive SPFs msecs.

Maximum wait time between two consecutive SPFs msecs. Number of areas in this router is 1. Number of interfaces in this area is 2 1 loopback. Number of opaque link LSA 0. Checksum Sum 0x Checksum Sum 0x0. Designated Router ID Backup Designated router ID Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5. Adjacent with neighbor RouterA show ip bgp neighbors.

BGP neighbor is RouterB show ip bgp neighbors. Note For the most accurate platform and hardware restrictions, see the Cisco IOS software release notes for your software version. Before you configure BFD, you should become familiar with the information in the following sections:. BFD provides a low-overhead, short-duration method of detecting failures in the forwarding path between two adjacent routers, including the interfaces, data links, and forwarding planes. BFD is a detection protocol that you enable at the interface and routing protocol levels.

Cisco supports the BFD asynchronous mode, which depends on the sending of BFD control packets between two systems to activate and maintain BFD neighbor sessions between routers. By sending rapid failure detection notices to the routing protocols in the local router to initiate the routing table recalculation process, BFD contributes to greatly reduced overall network convergence time. Figure 2 shows what happens when a failure occurs in the network 1.

If an alternative path is available the routers will immediately start converging on it. Once a BFD session has been established and timer negations are complete, BFD peers send BFD control packets that act in the same manner as an IGP hello protocol to detect liveliness, except at a more accelerated rate. The following information should be noted:.

BFD detects a failure, but the routing protocol must take action to bypass a failed peer. Cisco IOS Release BFD LC sessions will have no knowledge of sessions being added or deleted by the clients. This database will contain only the minimum required information. It will also update transmit and receive counters. BFD control packets are received and processed, as well as sent, from the LC itself. When you deploy any feature, it is important to consider all the alternatives and be aware of any trade-offs being made.

There are several advantages to implementing BFD over reduced timer mechanisms for routing protocols:. When the BFD process is started, no entries are created in the adjacency database, in other words, no BFD control packets are sent or received.

The adjacency creation takes places once you have configured BFD support for the applicable routing protocols. This section contains the following procedures:. The steps in this procedure show how to configure BFD on the interface by setting the baseline BFD session parameters on an interface.

You can enable BFD support for routing protocols at the router level to enable BFD support globally for all interfaces or you can configure BFD on a per-interface basis at the interface level.

Note In order to display the full output of the show bfd neighbors details command on a Cisco series router, you must enter the command on the line card. Enter the attach slot-number command to establish a CLI session with a line card. The registered protocols are not shown in the output of the show bfd neighbors details command when it is entered on a line card. If you want to configure BFD support for another routing protocol, see the following sections:. Configures the router to send a system logging syslog message when an EIGRP neighbor goes up or down.

Note In order to see the full output of the show bfd neighbors details command on a Cisco series router, you must enter the command on the line card. You can then disable BFD for one or more of those interfaces using the isis bfd disable command in interface configuration mode. Optional Returns the router to global configuration mode.

Enter this command only if you want to follow Step 6 and Step 7 to disable BFD for one or more interfaces. Note You should use the disable keyword only if you enabled BFD on all of the interfaces that IS-IS is associated with using the bfd all-interfaces command in router configuration mode.

Displays information that can be used to verify if the BFD neighbor is active and displays the routing protocols that BFD has registered. Displays information that can help verify if the BFD neighbor is active and displays the routing protocols that BFD has registered. If you want to configure BFD support for another routing protocol, see one of the following sections:.

You can disable BFD support on individual interfaces using the ip ospf bfd [ disable ] command in interface configuration mode. Enter this command only if you want to perform Step 7 to disable BFD for one or more interfaces. Optional Enters interface configuration mode. Note You should use the disable keyword only if you enabled BFD on all of the interfaces that OSPF is associated with using the bfd all-interfaces command in router configuration mode. If HSRP support for BFD has been manually disabled, you can reenable it at the router level to enable BFD support globally for all interfaces or on a per-interface basis at the interface level.

BFD echo mode is enabled by default, but you can disable it such that it can run independently in each direction. Before you configure echo mode you should be familiar with the following concepts:. Echo packets are sent by the forwarding engine and forwarded back along the same path in order to perform detection—the BFD session at the other end does not participate in the actual forwarding of the echo packets.

The echo function and the forwarding engine are responsible for the detection process, therefore the number of BFD control packets that are sent out between two BFD neighbors is reduced. And since the forwarding engine is testing the forwarding path on the remote neighbor system without involving the remote system, there is an opportunity to improve the interpacket delay variance, thereby achieving quicker failure detection times than when using BFD Version 0 with BFD control packets for the BFD session.

Echo mode is described as without asymmetry when it is running on both sides both BFD neighbors are running echo mode. The steps in this procedure show how to change the value of the BFD slow timer.