Jump to content
Morais

Implementing and Operating Cisco Service Provider Network Core Technologies (SPCOR) v1.0

Recommended Posts

Hi Folks,

 

I am looking for this course: Implementing and Operating Cisco Service Provider Network Core Technologies (SPCOR) v1.0

 

Thanks in advance.

Morais

  • Like 1
  • Thanks 1
  • Confused 1

Share this post


Link to post
Share on other sites

8.3 Implementing High Availability in Networking

Bidirectional Forwarding Detection Support 


The detection of failures is typically accomplished via hardware detection mechanisms. However, the signals from these mechanisms are not always conveyed directly to the upper protocol layers, such as routing protocols. When the hardware mechanisms do not exist (for example, Ethernet) or when the signaling does not reach the upper protocol layers, the protocols must rely on their much slower strategies to detect failures. The detection times in existing protocols are typically equal to or greater than one second, and sometimes much longer. For some applications, this is too long to be useful.

Drivers for Bidirectional Forwarding Detection:

  • Data link layer detection can miss some types of outages

    1. Control Plane failure

  • Control Plane failure detection is slow

    1. Order of tens of seconds

  • Data link layer failure detection is not consistent across media types

    1. Very quick to quick for some media (SONET, Ethernet)

    2. Slow on other WAN links

  • Provides failure detection consistency across routing protocols

    1. Built in routing failure detection mechanisms are not fast enough for SP world

Packet over SONET (POS) tends to have the best failure detection time among the different media choices. It can typically detect and react to media or protocol failures in ~50 milliseconds. This has become the benchmark against which other protocols are measured.

Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) provides low-overhead, short-duration detection of failures in the path between adjacent forwarding engines. BFD allows a single mechanism to be used for failure detection over any media and at any protocol layer, with a wide range of detection times and overhead. The fast detection of failures provides immediate reaction to failure in the event of a failed link or neighbor.

A secondary benefit of BFD, in addition to fast failure detection, is that it provides network administrators with a consistent method of detecting failures. Thus, one availability methodology could be used, irrespective of the Interior Gateway Protocol (IGP) or the topology of the target network. This eases network profiling and planning, because re-convergence time should be consistent and predictable. BFD function is defined in RFC 5880. It is UDP-based and is being put into all of the hardware (e.g. Cisco CRS, Cisco Nexus 9000, and Cisco NCS 6000). It actually resides in the port ASIC.

The Fundamental difference between the BFD Hellos and the Protocol Hellos (OSPF, RSVP and so on) is that BFD adjacencies do not go down on Control-Plane restarts (e.g. RSP failover) since the goal of BFD is to detect only the forwarding plane failures.

BFD has two operating modes that may be selected and an extra function that can be used with the two modes. The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.

The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously.

An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode).

Cisco IOS XR software only supports asynchronous mode and has echo enabled by default.

Asynchronous Modes

Asynchronous mode without echo will engage various pieces of packet switching paths on local and remote systems. However, asynchronous mode with echo is usually known to provide slightly wider test coverage as echo packets are self-destined packets which traverse same packet switching paths as normal traffic on the remote system.

Cisco IOS XR software supports the asynchronous mode of operation only (i.e. no Demand mode), with or without using echo packets (echo is enabled by default).

When BFD is running asynchronously without echo packets, the following occurs:

  • Each system periodically sends BFD control packets to one another. Packets sent by BFD router "Peer A" to BFD router "Peer B" have a source address from Peer A and a destination address for Peer B.

  • Control packet streams are independent of each other and do not work in a request/response model.

  • If a number of packets in a row are not received by the other system, the session is declared down.

Hidden Content

    Give reaction to this post to see the hidden content.

When BFD is running asynchronously with echo packets, the following occurs:

  • BFD echo packets are looped back through th e forwarding path only of the BFD peer and are not processed by any protocol stack. So, packets sent by BFD router "Peer A" can be sent with both the source and destination address of Peer A.

  • BFD echo packets are sent in addition to BFD control packets.

Hidden Content

    Give reaction to this post to see the hidden content.

Hidden Content

    Give reaction to this post to see the hidden content.

Configuring BFD

In IOS-XR an application must terminate the BDF session. Unlike IOS, direct peering without any application using the session is not allowed.

Adding bfd fast-detect suffix to the normal static route will enable BFD feature. To fine tune BFD behavior, use minimum-interval and multiplier optional parameters inside same command.

BFD on a Static Routes (simplest application):

router static
address-family ipv4 unicast
   172.16.1.1/32 10.1.1.1 bfd fast-detect minimum-interval 5000 multiplier 3
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.1.1.2 255.255.255.0

Provided examples for OSPF and IS-IS routing protocols demonstrate that same BFD commands are used for all protocols.

BFD with IGP Peers (OSPF example):

router ospf 1
area 0
!
interface GigabitEthernet0/2/0/1
  bfd minimum-interval 100
  bfd multiplier 3
  bfd fast-detect ipv4

BFD with IGP Peers (ISIS example):

router isis lab
net 49.0111.0111.0111.0111.00
address-family ipv4 unicast
  redistribute connected
!
interface GigabitEthernet0/2/0/1
  bfd minimum-interval 500
  bfd multiplier 3
  bfd fast-detect ipv4

The show bfd session command allows review of configuration details and in addition provides current state for all sessions between the router and neighbors.

The show bfd counters packet provides info for received and transmitted Control and Echo BFD packets (if enabled).

RP/0/RSP0/CPU0:ASR9K-1# show bfd session
Interface       Dest Addr           Local det time(int*mult)      State    
                                Echo             Async          
--------------- --------------- ---------------- ---------------- ----------
Gi0/2/0/1       10.0.9.1        1500ms(500ms*3)  6s(2s*3)         UP

RP/0/RSP0/CPU0:WEST-PE-ASR9K-1# show bfd counters packet                  
GigabitEthernet0/2/0/1 Recv       Xmit                 Recv       Xmit
      Async:          44048     44182       Echo:    175384     175384
  • Like 16
  • Thanks 5
  • Sad 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...