SYSTEM ADMINISTRATOR GUIDE     17/1543-CRA 119 1170/1-V1 Uen A

Configuring BFD

Copyright

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

Contents

1   Overview

This document provides an overview of Bidirectional Forwarding Detection (BFD) and describes the tasks and commands used to configure, monitor, troubleshoot, and administer BFD features through the SmartEdge® router.

Bidirectional Forwarding Detection (BFD) is a simple Hello protocol that, in many respects, is similar to the detection components of some routing protocols. A pair of routers periodically transmit BFD packets over each path between the two routers, and if a system stops receiving BFD packets after a predefined time interval, some component in that particular bidirectional path to the neighboring router is assumed to have failed.

A path is only declared to be operational when two-way communication has been established between systems.

Note:  

Currently, only Ethernet or Gigabit Ethernet (GE) ports support BFD communication. For BFD to work properly, the BFD neighbor must be reachable over an Ethernet link. All Ethernet line cards (PPA1, PPA2, and PPA3) support BFD communication.

BFD provides low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data links, and to the extent possible, the forwarding engines themselves.

The legacy Hello mechanism run by routing protocols does not offer detections of less than one second, and for some applications, more than one second is too long and represents a large amount of data loss at gigabit rates. BFD provides the ability to detect communication failures in less than one second.

2   Configuration and Operations Tasks

Note:  

In this section, the command syntax in the task tables displays only the root command.

To configure BFD, perform the tasks in the sections that follow.

2.1   Configuring a BFD Neighbor

A BFD session is established for each BFD neighbor configured. More than one BFD neighbor can be configured.

To configure a BFD neighbor, perform the tasks described in Table 1. Enter all commands in BFD neighbor configuration mode, unless otherwise noted.

2.2   Configuring BFD on an Interface

Configuring BFD on an interface establishes a separate BFD session for each neighbor on the interface. Neighbors are learned by the client routing protocol (such as Open Shortest Path First [OSPF]) that has BFD detection enabled.

Note:  

BFD clients are routing protocols that use BFD to detect communication failures in less than one second. Currently, BFD supports static routes, RSVP links, external Border Gateway Protocol (eBGP), Intermediate System-to-Intermediate System (IS-IS), and OSPF.

To configure BFD on an interface, perform the tasks described in Table 2. Enter all commands in BFD interface configuration mode, unless otherwise noted.

2.3   Disabling BFD for an IS-IS or OSPF Interface

By default, when BFD is enabled for the same interface on which IS-IS or OSPF has been enabled, BFD is automatically enabled for each neighbor on the interface; however, you can disable BFD for the interface. To disable BFD for an IS-IS or OSPF interface, perform either of the tasks described in Table 3.

2.4   Enabling BFD for a Static Route

By default, BFD is disabled for all static routes, but you can enable BFD for a particular static route. When BFD detects a communication failure to the next hop specified for a static route (that has BFD enabled), the static route is withdrawn.

To enable BFD for a static route, perform the task described in Table 4.

2.5   Enabling FRR Triggered by BFD to the IP Next Hop

By default, BFD detection is disabled on RSVP links. You must enable BFD at both the router RSVP level and for any individual neighbor that requires fast reroute (FRR).

Note:  

FRR for RSVP supports single-hop IP BFD only. The SmartEdge router does not support Multiprotocol Label Switching (MPLS) BFD.

Consider the following rules and restrictions when enabling FRR triggered by BFD to the IP next hop:

• BFD is supported on one next hop for each interface only and runs outside the RSVP tunnel.
• LDP-over-RSVP LSPs do not support BFD.
• If a port-down event occurs simultaneously with a BFD event, the port-down event takes precedence over the BFD event.
• If protected LSPs traverse a LAG for which BFD is enabled and the number of remaining active links falls below the minimum number of links required for the LAG to be active, BFD triggers FRR.
• If a protected link in a LAG fails and the number of remaining active links is greater than or equal to the minimum number of links required for the LAG to be active, traffic that was traversing the failed link is redistributed to the remaining links in less than 50 ms after the failed link is detected.

Note:  

Traffic redistribution is supported only when an LSP is protected.

To enable FRR triggered by BFD to the IP next hop, perform the task described in Table 5.

2.6   Enabling BFD for an eBGP Neighbor

By default, BFD is disabled for all eBGP neighbors, but you can enable BFD for a particular eBGP neighbor. When BFD detects a communication failure to the eBGP neighbor, the neighbor is reset.

To enable BFD for an eBGP neighbor, perform the task described in Table 6.

2.7   BFD Operations

To manage BFD functions, perform the appropriate tasks described in Table 7. Enter the show command in any mode; enter the debug commands in exec mode.

3   Configuration Examples

The sections that follow provide BFD configuration examples.

3.1   BFD Neighbor

A BFD session is established for each BFD neighbor configured. More than one BFD neighbor can be configured. The following example configures the BFD neighbor, 192.168.0.24, sets the minimum desired transmit interval to 30 ms, sets the minimum receive interval to 30 ms, and the sets detection multiplier to 4:

[local]Redback#configure

[local]Redback(config)#context local

[local]Redback(config-ctx)#router bfd

[local]Redback(config-bfd)#neighbor 192.168.0.24

[local]Redback(config-bfd-nbr)#minimum receive-interval 30

[local]Redback(config-bfd-nbr)#minimum transmit-interval 30

[local]Redback(config-bfd-nbr)#detection-multiplier 4

[local]Redback(config-bfd-nbr)#end

3.2   BFD Interface

Configuring BFD on an interface establishes a separate BFD session for each neighbor on the interface. Neighbors are learned by the client routing protocol (such as OSPF) that has BFD detection enabled. The following example configures BFD on the interface, foo, sets the minimum desired transmit interval to 25 ms, sets the minimum receive interval to 40 ms, and the sets detection multiplier to 2:

[local]Redback#configure

[local]Redback(config)#context local

[local]Redback(config-ctx)#router bfd

[local]Redback(config-bfd)#interface foo

[local]Redback(config-bfd-if)#minimum receive-interval 25

[local]Redback(config-bfd-if)#minimum transmit-interval 40

[local]Redback(config-bfd-if)#detection-multiplier 2

[local]Redback(config-bfd-if)#end

3.3   BFD for IS-IS

By default, when BFD is enabled for the same interface on which IS-IS has been enabled, BFD is automatically enabled for each neighbor on the interface; however, you can disable BFD for the interface. The following example disables BFD for the IS-IS interface, isis-foo:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface isis-foo

[local]Redback(config-isis-if)#disable-bfd

[local]Redback(config-isis-if)#end

3.4   BFD for OSPF

By default, when BFD is enabled for the same interface on which OSPF has been enabled, BFD is automatically enabled for each neighbor on the interface; however, you can disable BFD for the interface. The following example disables BFD for the OSPF interface, ospf-foo:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router ospf 15

[local]Redback(config-ospf)#interface ospf-foo

[local]Redback(config-ospf-if)#disable-bfd

[local]Redback(config-ospf-if)#end

3.5   BFD for Static Routes

By default, BFD is disabled for all static routes, but you can enable BFD for a particular static route. The following example enables BFD for the static route to 1.1.1.1/24 with the next hop, 2.2.2.2:

[local]Redback(config)#context local

[local]Redback(config-ctx)#ip route 1.1.1.1/24 2.2.2.2 bfd

[local]Redback(config-ctx)#end

3.6   FRR Triggered by BFD to the IP Next Hop

By default, BFD is disabled for all RSVP LSPs, but you can enable BFD at both the router RSVP level and for any individual neighbor that requires FRR. The following example shows how to enable FRR triggered by BFD to the IP next hop. In this example, BFD is enabled on the RSVP client and for the next hop on the RSVP interface called rsvp1:

First, enable BFD on the RSVP client. All IP interfaces configured on that RSVP client have BFD enabled:

local]Redback#configure

[local]Redback(config)#context local

[local]Redback(config-ctx)#router rsvp

[local]Redback(config-rsvp)#bfd

Next, enable BFD for a specific next hop neighbor:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router bfd

[local]Redback(config-bfd)#interface rsvp1

3.7   BFD for eBGP

By default, BFD is disabled for all eBGP neighbors, but you can enable BFD for a particular eBGP neighbor. The following example enables BFD for the eBGP neighbor, 8.8.8.2:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router bgp 100

[local]Redback(config-bgp)#neighbor 8.8.8.2 external

[local]Redback(config-ospf-bgp-neighbor)#bfd

[local]Redback(config-ospf-bgp-neighbor)#end