Software Configuration Guide for the Cisco ISR 4400 Series
Configuring High Availability
Downloads: This chapterpdf (PDF - 612.0KB) The complete bookPDF (PDF - 3.81MB) | The complete bookePub (ePub - 413.0KB) | Feedback

Table of Contents

Configuring High Availability

Information About Cisco High Availability

Interchassis High Availability

IPsec Failover

Bidirectional Forwarding Detection

Bidirectional Forwarding Detection Offload

Configuring Cisco High Availability

Configuring Interchassis High Availability

Configuring Bidirectional Forwarding

Verifying Interchassis High Availability

Verifying BFD Offload

Additional References

Related Documents

Configuring High Availability

Cisco High Availability (HA) features enable network-wide protection by providing fast recovery from faults that may occur in any part of the network. With Cisco High Availability, network hardware and software work together and enable rapid recovery from disruptions to ensure fault transparency to users and network applications.

The following sections describe how to configure Cisco High Availability features on your router:

Information About Cisco High Availability

Cisco High Availability (HA) enables network-wide protection by providing fast recovery from faults that may occur in any part of the network. With Cisco High Availability, network hardware and software work together and enable rapid recovery from disruptions to ensure fault transparency to users and network applications.

The unique hardware and software architecture of your router is designed to maximize router uptime during any network event, and thereby provide maximum uptime and resilience within any network scenario.

This chapter covers some aspects of Cisco High Availability that may be used on this router.

Interchassis High Availability

The Interchassis High Availability feature also known as the box-to-box redundancy feature. Interchassis High Availability enables the configuration of pairs of routers to act as backup for each other. This feature can be configured to determine the active router based on a number of failover conditions. When a failover occurs, the standby router seamlessly takes over and starts processing call signaling and performing media forwarding tasks.

Groups of redundant interfaces are known as redundancy groups. Figure 12-1 depicts the active-standby device scenario. It shows how the redundancy group is configured for a pair of routers that have a single outgoing interface.

Figure 12-1 Redundancy Group Configuration

The routers are joined by a configurable control link and data synchronization link. The control link is used to communicate the status of the routers. The data synchronization link is used to transfer stateful information to synchronize the stateful database for the calls and media flows. Each pair of redundant interfaces are configured with the same unique ID number, also known as the RII. For information on configuring Interchassis HA on your router, see Configuring Interchassis High Availability.

IPsec Failover

The IPsec failover feature increases the total uptime (or availability) of your IPsec network. Traditionally, the increased availability of your IPsec network is accomplished by employing a redundant (standby) router in addition to the original (active) router. When the active router becomes unavailable for any reason, the standby router takes over the processing of IKE and IPsec. IPsec failover falls into two categories: stateless failover and stateful failover.

On the router, only the stateless form of IPsec failover is supported. This stateless failover uses protocols such as the Hot Standby Router Protocol (HSRP) to provide primary to secondary cutover and also allows the active and standby VPN gateways to share a common virtual IP address.

Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning is easier, and reconvergence time is consistent and predictable.

BFD is supported for the IP routing protocols. For more information on BFD, see the “Bidirectional Forwarding Detection” section in the IP Routing BFD Configuration Guide, Cisco IOS XE Release 3S .

Bidirectional Forwarding Detection Offload

The Bidirectional Forwarding Detection (BFD) offload feature allows the offload of BFD session management to the forwarding engine for improved failure detection times. BFD offload reduces the overall network convergence time by sending rapid failure detection packets (messages) to the routing protocols for recalculating the routing table. See Configuring BFD Offload.

Configuring Interchassis High Availability

Prerequisites

  • The active device and the standby device must run on the identical version of the Cisco IOS XE software.
  • The active device and the standby device must be connected through an L2 connection for the control path.
  • The Embedded Service Processor must be the same on both the active and standby devices. Route Processors (RPs) must also match and have a similar physical configuration.
  • Network Time Protocol (NTP) must be configured or the clock must be set identical on both devices to allow timestamps and call timers to match.
  • The latency times must be minimal on all control and data links to prevent timeouts.
  • Physically redundant links, such as Gigabit EtherChannel must be used for the control and data path.

Restrictions

  • The failover time for a box-to-box application is higher for a non-box-to-box application.
  • LAN and MESH scenarios are not supported.
  • Virtual router forwarding (VRF) must be defined in the same order on both active and standby routers for an accurate synchronization of the data.
  • When the configuration is replicated to the standby router, it is not committed to the startup configuration; it is in the running configuration. The user must enter the write memory command to commit changes on the standby router that have been synchronized from the active router.

How to Configure Interchassis High Availability

For more information on configuring Interchassis High Availability on the router, see the
IP Addressing: NAT Configuration Guide .

Configuring Bidirectional Forwarding

For information on configuring BFD on your router, see the IP Routing BFD Configuration Guide. For BFD commands see the Cisco IOS IP Routing: Protocol-Independent Command Reference .

Configuring BFD Offload

Restrictions

  • Only BFD version 1 is supported.
  • When configured, only offloaded BFD sessions are supported;, BFD session on RP are not supported.
  • Only Asynchronous mode or no echo mode of BFD is supported.
  • 511 asynchronous BFD sessions are supported.
  • BFD hardware offload is supported for IPv4 sessions with non-echo mode only.
  • BFD offload is supported only on port-channel interfaces.
  • BFD offload is supported only for the Ethernet interface.
  • BFD offload is not supported for IPv6 BFD sessions.
  • BFD offload is not supported for BFD with TE/FRR.

How to Configure BFD Offload

BFD offload functionality is enabled by default. You can configure BFD hardware offload on the route processor. For more information, see Configuring BFD and IP Routing BFD Configuration Guide.

Verifying Interchassis High Availability

Use the following show commands to verify the Interchassis High Availability.

Prerequisites and links to additional documentation configuring Interchassis High Availability are shown in the “Configuring Interchassis High Availability” section.

  • show redundancy application group [group-id | all]
  • show redundancy application transport {client | group [group-id]}
  • show redundancy application control-interface group [group-id]
  • show redundancy application faults group [group-id]
  • show redundancy application protocol {protocol-id | group [group-id]}
  • show redundancy application if-mgr group [group-id]
  • show redundancy application data-interface group [group-id]

The following example shows the redundancy application groups configured on the router:

Router# show redundancy application group

Group ID Group Name State

-------- ---------- -----

1 Generic-Redundancy-1 STANDBY

2 Generic-Redundancy2 ACTIVE

 

The following example shows the details of redundancy application group 1:

Router# show redundancy application group 1

Group ID:1

Group Name:Generic-Redundancy-1

 

Administrative State: No Shutdown

Aggregate operational state : Up

My Role: STANDBY

Peer Role: ACTIVE

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

 

RF Domain: btob-one

RF state: STANDBY HOT

Peer RF state: ACTIVE

 

The following example shows the details of redundancy application group 2:

Router# show redundancy application group 2

Group ID:2

Group Name:Generic-Redundancy2

 

Administrative State: No Shutdown

Aggregate operational state : Up

My Role: ACTIVE

Peer Role: STANDBY

Peer Presence: Yes

Peer Comm: Yes

Peer Progression Started: Yes

 

RF Domain: btob-two

RF state: ACTIVE

Peer RF state: STANDBY HOT

 

 

 

The following example shows details of the redundancy application transport client:

Router# show redundancy application transport client

Client Conn# Priority Interface L3 L4

( 0)RF 0 1 CTRL IPV4 SCTP

 

( 1)MCP_HA 1 1 DATA IPV4 UDP_REL

 

( 4)AR 0 1 ASYM IPV4 UDP

 

( 5)CF 0 1 DATA IPV4 SCTP

The following example shows configuration details for the redundancy application transport group:

Router# show redundancy application transport group

Transport Information for RG (1)

Client = RF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

0 0 1.1.1.1 59000 1.1.1.2 59000 CTRL IPV4 SCTP

Client = MCP_HA

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

1 1 9.9.9.2 53000 9.9.9.1 53000 DATA IPV4 UDP_REL

Client = AR

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

2 0 0.0.0.0 0 0.0.0.0 0 NONE_IN NONE_L3 NONE_L4

Client = CF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

3 0 9.9.9.2 59001 9.9.9.1 59001 DATA IPV4 SCTP

Transport Information for RG (2)

Client = RF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

8 0 1.1.1.1 59004 1.1.1.2 59004 CTRL IPV4 SCTP

Client = MCP_HA

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

9 1 9.9.9.2 53002 9.9.9.1 53002 DATA IPV4 UDP_REL

Client = AR

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

10 0 0.0.0.0 0 0.0.0.0 0 NONE_IN NONE_L3 NONE_L4

Client = CF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

11 0 9.9.9.2 59005 9.9.9.1 59005 DATA IPV4 SCTP

 

The following example shows the configuration details of redundancy application transport group 1:

Router# show redundancy application transport group 1

Transport Information for RG (1)

Client = RF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

0 0 1.1.1.1 59000 1.1.1.2 59000 CTRL IPV4 SCTP

Client = MCP_HA

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

1 1 9.9.9.2 53000 9.9.9.1 53000 DATA IPV4 UDP_REL

Client = AR

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

2 0 0.0.0.0 0 0.0.0.0 0 NONE_IN NONE_L3 NONE_L4

Client = CF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

3 0 9.9.9.2 59001 9.9.9.1 59001 DATA IPV4 SCTP

 

The following example shows configuration details of redundancy application transport group 2:

Router# show redundancy application transport group 2

Transport Information for RG (2)

Client = RF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

8 0 1.1.1.1 59004 1.1.1.2 59004 CTRL IPV4 SCTP

Client = MCP_HA

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

9 1 9.9.9.2 53002 9.9.9.1 53002 DATA IPV4 UDP_REL

Client = AR

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

10 0 0.0.0.0 0 0.0.0.0 0 NONE_IN NONE_L3 NONE_L4

Client = CF

TI conn_id my_ip my_port peer_ip peer_por intf L3 L4

11 0 9.9.9.2 59005 9.9.9.1 59005 DATA IPV4 SCTP

The following example shows configuration details of the redundancy application control-interface group:

Router# show redundancy application control-interface group

The control interface for rg[1] is GigabitEthernet0/0/0

Interface is Control interface associated with the following protocols: 2 1

BFD Enabled

Interface Neighbors:

Peer: 1.1.1.2 Active RGs: 1 Standby RGs: 2 BFD handle: 0

 

The control interface for rg[2] is GigabitEthernet0/0/0

Interface is Control interface associated with the following protocols: 2 1

BFD Enabled

Interface Neighbors:

Peer: 1.1.1.2 Active RGs: 1 Standby RGs: 2 BFD handle: 0

 

 

The following example shows configuration details of the redundancy application
control-interface group 1:

Router# show redundancy application control-interface group 1

The control interface for rg[1] is GigabitEthernet0/0/0

Interface is Control interface associated with the following protocols: 2 1

BFD Enabled

Interface Neighbors:

Peer: 1.1.1.2 Active RGs: 1 Standby RGs: 2 BFD handle: 0

 

 

 

The following example shows configuration details of the redundancy application
control-interface group 2:

Router# show redundancy application control-interface group 2

The control interface for rg[2] is GigabitEthernet0/0/0

Interface is Control interface associated with the following protocols: 2 1

BFD Enabled

Interface Neighbors:

Peer: 1.1.1.2 Active RGs: 1 Standby RGs: 2 BFD handle: 0

 

 

The following example shows configuration details of the redundancy application faults group:

Router# show redundancy application faults group

Faults states Group 1 info:

Runtime priority: [50]

RG Faults RG State: Up.

Total # of switchovers due to faults: 0

Total # of down/up state changes due to faults: 2

Faults states Group 2 info:

Runtime priority: [135]

RG Faults RG State: Up.

Total # of switchovers due to faults: 0

Total # of down/up state changes due to faults: 2

The following example shows configuration details specific to redundancy application faults group 1:

Router# show redundancy application faults group 1

Faults states Group 1 info:

Runtime priority: [50]

RG Faults RG State: Up.

Total # of switchovers due to faults: 0

Total # of down/up state changes due to faults: 2

The following example shows configuration details specific to redundancy application faults group 2:

Router# show redundancy application faults group 2

Faults states Group 2 info:

Runtime priority: [135]

RG Faults RG State: Up.

Total # of switchovers due to faults: 0

Total # of down/up state changes due to faults: 2

The following example shows configuration details for the redundancy application protocol group:

Router# show redundancy application protocol group

RG Protocol RG 1

------------------

Role: Standby

Negotiation: Enabled

Priority: 50

Protocol state: Standby-hot

Ctrl Intf(s) state: Up

Active Peer: address 1.1.1.2, priority 150, intf Gi0/0/0

Standby Peer: Local

Log counters:

role change to active: 0

role change to standby: 1

disable events: rg down state 1, rg shut 0

ctrl intf events: up 2, down 1, admin_down 1

reload events: local request 0, peer request 0

 

RG Media Context for RG 1

--------------------------

Ctx State: Standby

Protocol ID: 1

Media type: Default

Control Interface: GigabitEthernet0/0/0

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 117, Bytes 7254, HA Seq 0, Seq Number 117, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 0

Active Peer: Present. Hold Timer: 10000

Pkts 115, Bytes 3910, HA Seq 0, Seq Number 1453975, Pkt Loss 0

 

 

 

RG Protocol RG 2

------------------

Role: Active

Negotiation: Enabled

Priority: 135

Protocol state: Active

Ctrl Intf(s) state: Up

Active Peer: Local

Standby Peer: address 1.1.1.2, priority 130, intf Gi0/0/0

Log counters:

role change to active: 1

role change to standby: 1

disable events: rg down state 1, rg shut 0

ctrl intf events: up 2, down 1, admin_down 1

reload events: local request 0, peer request 0

 

RG Media Context for RG 2

--------------------------

Ctx State: Active

Protocol ID: 2

Media type: Default

Control Interface: GigabitEthernet0/0/0

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 118, Bytes 7316, HA Seq 0, Seq Number 118, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 1

Standby Peer: Present. Hold Timer: 10000

Pkts 102, Bytes 3468, HA Seq 0, Seq Number 1453977, Pkt Loss 0

The following example shows configuration details for the redundancy application protocol group 1:

Router# show redundancy application protocol group 1

RG Protocol RG 1

------------------

Role: Standby

Negotiation: Enabled

Priority: 50

Protocol state: Standby-hot

Ctrl Intf(s) state: Up

Active Peer: address 1.1.1.2, priority 150, intf Gi0/0/0

Standby Peer: Local

Log counters:

role change to active: 0

role change to standby: 1

disable events: rg down state 1, rg shut 0

ctrl intf events: up 2, down 1, admin_down 1

reload events: local request 0, peer request 0

 

RG Media Context for RG 1

--------------------------

Ctx State: Standby

Protocol ID: 1

Media type: Default

Control Interface: GigabitEthernet0/0/0

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 120, Bytes 7440, HA Seq 0, Seq Number 120, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 0

Active Peer: Present. Hold Timer: 10000

Pkts 118, Bytes 4012, HA Seq 0, Seq Number 1453978, Pkt Loss 0

The following example shows configuration details for the redundancy application protocol group 2:

Router# show redundancy application protocol group 2

RG Protocol RG 2

------------------

Role: Active

Negotiation: Enabled

Priority: 135

Protocol state: Active

Ctrl Intf(s) state: Up

Active Peer: Local

Standby Peer: address 1.1.1.2, priority 130, intf Gi0/0/0

Log counters:

role change to active: 1

role change to standby: 1

disable events: rg down state 1, rg shut 0

ctrl intf events: up 2, down 1, admin_down 1

reload events: local request 0, peer request 0

 

RG Media Context for RG 2

--------------------------

Ctx State: Active

Protocol ID: 2

Media type: Default

Control Interface: GigabitEthernet0/0/0

Current Hello timer: 3000

Configured Hello timer: 3000, Hold timer: 10000

Peer Hello timer: 3000, Peer Hold timer: 10000

Stats:

Pkts 123, Bytes 7626, HA Seq 0, Seq Number 123, Pkt Loss 0

Authentication not configured

Authentication Failure: 0

Reload Peer: TX 0, RX 0

Resign: TX 0, RX 1

Standby Peer: Present. Hold Timer: 10000

Pkts 107, Bytes 3638, HA Seq 0, Seq Number 1453982, Pkt Loss 0

The following example shows configuration details for the redundancy application protocol 1

Router# show redundancy application protocol 1

Protocol id: 1, name: rg-protocol-1

BFD: ENABLE

Hello timer in msecs: 3000

Hold timer in msecs: 10000

OVLD-1#show redundancy application protocol 2

Protocol id: 2, name: rg-protocol-2

BFD: ENABLE

Hello timer in msecs: 3000

Hold timer in msecs: 10000

 

 

 

The following example shows configuration details for redundancy application interface manager group:

Router# show redundancy application if-mgr group

RG ID: 1

==========

 

interface GigabitEthernet0/0/3.152

---------------------------------------

VMAC 0007.b421.4e21

VIP 55.1.1.255

Shut shut

Decrement 10

 

interface GigabitEthernet0/0/2.152

---------------------------------------

VMAC 0007.b421.5209

VIP 45.1.1.255

Shut shut

Decrement 10

 

 

RG ID: 2

==========

 

interface GigabitEthernet0/0/3.166

---------------------------------------

VMAC 0007.b422.14d6

VIP 4.1.255.254

Shut no shut

Decrement 10

 

interface GigabitEthernet0/0/2.166

---------------------------------------

VMAC 0007.b422.0d06

VIP 3.1.255.254

Shut no shut

Decrement 10

The following examples shows configuration details for redundancy application interface manager group 1 and group 2:

Router# show redundancy application if-mgr group 1

 

RG ID: 1

==========

 

interface GigabitEthernet0/0/3.152

---------------------------------------

VMAC 0007.b421.4e21

VIP 55.1.1.255

Shut shut

Decrement 10

 

interface GigabitEthernet0/0/2.152

---------------------------------------

VMAC 0007.b421.5209

VIP 45.1.1.255

Shut shut

Decrement 10

 

Router# show redundancy application if-mgr group 2

RG ID: 2

==========

 

interface GigabitEthernet0/0/3.166

---------------------------------------

VMAC 0007.b422.14d6

VIP 4.1.255.254

Shut no shut

Decrement 10

 

interface GigabitEthernet0/0/2.166

---------------------------------------

VMAC 0007.b422.0d06

VIP 3.1.255.254

Shut no shut

Decrement 10

The following example shows configuration details for redundancy application data-interface group:

Router# show redundancy application data-interface group

The data interface for rg[1] is GigabitEthernet0/0/1

The data interface for rg[2] is GigabitEthernet0/0/1

The following examples show configuration details specific to redundancy application data-interface group 1 and group 2:

Router# show redundancy application data-interface group 1

The data interface for rg[1] is GigabitEthernet0/0/1

 

Router # show redundancy application data-interface group 2

The data interface for rg[2] is GigabitEthernet0/0/1

Verifying BFD Offload

Use the following commands to verify and monitor BFD offload feature on your router. Configuration of BFD Offload is described in the “Configuring Bidirectional Forwarding” section.

  • show bfd neighbors [details]
  • debug bfd [packet | event]
  • debug bfd event

The show bfd neighbors command displays the BFD adjacency database:

 
Router# show bfd neighbor

 

IPv4 Sessions

NeighAddr LD/RD RH/RS State Int

192.10.1.1 362/1277 Up Up Gi0/0/1.2

192.10.2.1 445/1278 Up Up Gi0/0/1.3

192.10.3.1 1093/961 Up Up Gi0/0/1.4

192.10.4.1 1244/946 Up Up Gi0/0/1.5

192.10.5.1 1094/937 Up Up Gi0/0/1.6

192.10.6.1 1097/1260 Up Up Gi0/0/1.7

192.10.7.1 1098/929 Up Up Gi0/0/1.8

192.10.8.1 1111/928 Up Up Gi0/0/1.9

192.10.9.1 1100/1254 Up Up Gi0/0/1.10

The debug bfd neighbor detail command displays the debugging information related to BFD packets.

Router# show bfd neighbor detail

 

IPv4 Sessions

NeighAddr LD/RD RH/RS State Int

192.10.1.1 362/1277 Up Up Gi0/0/1.2

Session state is UP and not using echo function.

Session Host: Hardware

OurAddr: 192.10.1.2

Handle: 33

Local Diag: 0, Demand mode: 0, Poll bit: 0

MinTxInt: 50000, MinRxInt: 50000, Multiplier: 3

Received MinRxInt: 50000, Received Multiplier: 3

Holddown (hits): 0(0), Hello (hits): 50(0)

Rx Count: 3465, Rx Interval (ms) min/max/avg: 42/51/46

Tx Count: 3466, Tx Interval (ms) min/max/avg: 39/52/46

Elapsed time watermarks: 0 0 (last: 0)

Registered protocols: CEF EIGRP

Uptime: 00:02:50

Last packet: Version: 1 - Diagnostic: 0

State bit: Up - Demand bit: 0

Poll bit: 0 - Final bit: 0

C bit: 1

Multiplier: 3 - Length: 24

My Discr.: 1277 - Your Discr.: 362

Min tx interval: 50000 - Min rx interval: 50000

Min Echo interval: 0

The show bfd summary command displays the BFD summary

Router# show bfd summary

 

Session Up Down

 

Total 400 400 0

 

The show bfd drops command displays the number of packets dropped in BFD.

Router# show bfd drops

BFD Drop Statistics

IPV4 IPV6 IPV4-M IPV6-M MPLS_PW MPLS_TP_LSP

Invalid TTL 0 0 0 0 0 0

BFD Not Configured 0 0 0 0 0 0

No BFD Adjacency 33 0 0 0 0 0

Invalid Header Bits 0 0 0 0 0 0

Invalid Discriminator 1 0 0 0 0 0

Session AdminDown 94 0 0 0 0 0

Authen invalid BFD ver 0 0 0 0 0 0

Authen invalid len 0 0 0 0 0 0

Authen invalid seq 0 0 0 0 0 0

Authen failed 0 0 0 0 0 0

 

 

The debug bfd packet command displays debugging information about BFD control packets.

Router# debug bfd packet

*Nov 12 23:08:27.982: BFD-DEBUG Packet: Rx IP:192.11.22.1 ld/rd:1941/0 diag:0(No Diagnostic) Down C cnt:4 ttl:254 (0)

*Nov 12 23:08:27.982: BFD-DEBUG Packet: Tx IP:192.11.22.1 ld/rd:983/1941 diag:3(Neighbor Signaled Session Down) Init C cnt:44 (0)

*Nov 12 23:08:28.007: BFD-DEBUG Packet: Rx IP:192.11.22.1 ld/rd:1941/983 diag:0(No Diagnostic) Up PC cnt:4 ttl:254 (0)

*Nov 12 23:08:28.007: BFD-DEBUG Packet: Tx IP:192.11.22.1 ld/rd:983/1941 diag:0(No Diagnostic) Up F C cnt:0 (0)

*Nov 12 23:08:28.311: BFD-DEBUG Packet: Rx IP:192.11.22.1 ld/rd:1941/983 diag:0(No Diagnostic) Up FC cnt:0 ttl:254 (0)

*Nov 12 23:08:28.311: BFD-DEBUG Packet: Tx IP:192.11.22.1 ld/rd:983/1941 diag:0(No Diagnostic) Up C cnt:0 (0)

*Nov 12 23:08:28.311: BFD-DEBUG Packet: Rx IP:192.11.90.1 ld/rd:1907/0 diag:0(No Diagnostic) Down C cnt:3 ttl:254 (0)

*Nov 12 23:08:28.311: BFD-DEBUG Packet: Tx IP:192.11.90.1 ld/rd:993/1907 diag:3(Neighbor Signaled Session Down) Init C cnt:43 (0)

*Nov 12 23:08:28.311: BFD-DEBUG Packet: Rx IP:192.11.22.1 ld/rd:1941/983 diag:0(No Diagnostic) Up C cnt:0 ttl:254 (0)

*Nov 12 23:08:28.626: BFD-DEBUG Packet: Rx IP:192.11.90.1 ld/rd:1907/993 diag:0(No Diagnostic) Up PC cnt:3 ttl:254 (0)

*Nov 12 23:08:28.626: BFD-DEBUG Packet: Tx IP:192.11.90.1 ld/rd:993/1907 diag:0(No Diagnostic) Up F C cnt:0 (0)

*Nov 12 23:08:28.645: BFD-DEBUG Packet: Rx IP:192.11.90.1 ld/rd:1907/993 diag:0(No Diagnostic) Up C cnt:0 ttl:254 (0)

*Nov 12 23:08:28.700: BFD-DEBUG Packet: Rx IP:192.11.90.1 ld/rd:1907/993 diag:0(No Diagnostic) Up FC cnt:0 ttl:254 (0)

*Nov 12 23:08:28.700: BFD-DEBUG Packet: Tx IP:192.11.90.1 ld/rd:993/1907 diag:0(No Diagnostic) Up C cnt:0 (0)

*Nov 12 23:08:28.993: BFD-DEBUG Packet: Rx IP:192.11.90.1 ld/rd:1907/993 diag:0(No Diagnostic) Up C cnt:0 ttl:254 (0)

 

 

 

The debug bfd event displays debugging information about BFD state transitions.

Router# deb bfd event

 

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.16.1, ld:1401, handle:77, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(CEF) IP:192.10.16.1, ld:1401, handle:77, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.153.1, ld:1400, handle:39, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(CEF) IP:192.10.153.1, ld:1400, handle:39, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(EIGRP) IP:192.168.0.1, ld:1399, handle:25, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(CEF) IP:192.168.0.1, ld:1399, handle:25, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.30.1, ld:1403, handle:173, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(CEF) IP:192.10.30.1, ld:1403, handle:173, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.36.1, ld:1402, handle:95, event:DOWN adminDown, (0)

*Nov 12 23:11:29.503: BFD-DEBUG Event: notify client(CEF) IP:192.10.36.1, ld:1402, handle:95, event:DOWN adminDown, (0)

*Nov 12 23:11:30.639: BFD-HW-API: Handle 1404: Timers: Tx timer 1000000 Detect timer 0

*Nov 12 23:11:30.639: BFD-HW-API: Handle 1404: Flags: Poll 0 Final 0

*Nov 12 23:11:30.639: BFD-HW-API: Handle 1404: Buffer: 0x23480318 0x0000057C 0x00000000 0x000F4240 0x000F4240 0x00000000 size 24

*Nov 12 23:11:30.641: BFD-HW-API: Handle 1405: Timers: Tx timer 1000000 Detect timer 0

*Nov 12 23:11:30.641: BFD-HW-API: Handle 1405: Flags: Poll 0 Final 0

*Nov 12 23:11:30.641: BFD-HW-API: Handle 1405: Buffer: 0x23480318 0x0000057D 0x00000000 0x000F4240 0x000F4240 0x00000000 size 24

*Nov 12 23:11:30.649: BFD-DEBUG Packet: Rx IP:192.10.33.1 ld/rd:1601/1404 diag:7(Administratively Down) AdminDown C cnt:0 ttl:254 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: V1 FSM ld:1404 handle:207 event:RX ADMINDOWN state:UP (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: resetting timestamps ld:1404 handle:207 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(CEF) IP:192.10.33.1, ld:1404, handle:207, event:DOWN adminDown, (0)

*Nov 12 23:11:30.650: BFD-DEBUG Packet: Tx IP:192.10.33.1 ld/rd:1404/0 diag:3(Neighbor Signaled Session Down) Down C cnt:0 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Packet: Rx IP:192.10.85.1 ld/rd:1620/1405 diag:7(Administratively Down) AdminDown C cnt:0 ttl:254 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: V1 FSM ld:1405 handle:209 event:RX ADMINDOWN state:UP (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: resetting timestamps ld:1405 handle:209 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(CEF) IP:192.10.85.1, ld:1405, handle:209, event:DOWN adminDown, (0)

*Nov 12 23:11:30.650: BFD-DEBUG Packet: Tx IP:192.10.85.1 ld/rd:1405/0 diag:3(Neighbor Signaled Session Down) Down C cnt:0 (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.33.1, ld:1404, handle:207, event:DOWN adminDown, (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(CEF) IP:192.10.33.1, ld:1404, handle:207, event:DOWN adminDown, (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(EIGRP) IP:192.10.85.1, ld:1405, handle:209, event:DOWN adminDown, (0)

*Nov 12 23:11:30.650: BFD-DEBUG Event: notify client(CEF) IP:192.10.85.1, ld:1405, handle:209, event:DOWN adminDown, (0)

*Nov 12 23:11:31.035: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.10.191.1

...

Additional References

The following documents provide information related to the BFD feature.

Related Documents

 

Related Topic
Document Title

Configuring Stateful Interchassis Configuration.

Security Configuration Guide: Zone-Based Policy Firewall, Cisco IOS XE Release 3S .

IP Routing Protocol-Independent Commands.

Cisco IOS IP Routing: Protocol-Independent Command Reference.