Wednesday, August 10, 2011

Bidirectional Forwarding Detection

Hi Guys

So right now I am doing a Cisco Nexus 1000,5000,7000 Training course and during this course I came across for the first time a protocol you may or may not have heard of called Bidirectional Forwarding Detection that can be _VERY_ Useful to all you BGP guys out there, heck to anyone running a routing protocol.

When I first started looking into this protocol, it appeared it was something juniper had actually developed, I was like finally a protocol Juniper developed! But Alas, Junipers own slides refer to the fact it's a joint effort between Juniper and Cisco (Source: http://meetings.ripe.net/ripe-48/presentations/ripe48-eof-bfd.pdf Last Page) But it is great to see them working together to help us network engineers get even better protocols and products!

So, what is Bidirectional Forwarding Detection and why should I care?

So let's say you have dual homed internet connections, via BGP for example, or maybe you have two connections via OSPF for your internal network, whatever the case may be, you might have run into this problem:

Time it takes to detect a dead peer is painfully long!

Sure sure, you can tweak the timers for OSPF and to a certain extent BGP, but wouldn't it be nice if there was a way to easily add this capability without having to affect BGP/OSPF

Enter BFD, BFD provides _VERY_ fast dead peer detection, and can then feed this information into your routing protocol which can then know the peer is dead very quickly and converge

It is super easy to configure, works on all all media types, encapsulations, topologies, and routing protocols.

Let's get onto some configuration!


Here I have two routers connected via a single gigabit link running BGP and OSPF, nothing special so far:

R1#show run | sect router
router ospf 1
network 192.168.1.0 0.0.0.3 area 0
router bgp 65400
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 65400

R2#show run | sect router
router ospf 1
network 192.168.1.0 0.0.0.3 area 0
router bgp 65400
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 65400




They are neighbors:

R2#show ip bgp sum
BGP router identifier 192.168.1.1, local AS number 65400
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.2 4 65400 52 52 1 0 0 00:43:22 0

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 1 FULL/DR 00:00:33 192.168.1.2 GigabitEthernet1/0


so far so good, next let's configure BFD

So currently the only supported BFD mode is Asynchronous mode, this means that BOTH ends must be configured to support it, so if your ISP on your BGP won't provide it at the moment your shit out of luck. But I believe there is a mode of BFD called demand mode that might address this.

So, to configure it, first we go to the interface that has our peering relationship and enter:

bfd interval <50-999> min_rx <1-999> multiplier <3-50>

So the BFD interval is how often we send BFD's, the min_rx is how often we except to receive the BFD's (it can be more frequently though that is fine, but we are basically saying if we dont receive one within this time frame consider it a timeout) and then finally we have a multiplier which is how many we can miss before we consider the interface down

Now unfortunately, and I would love to see if someone can correct me, but doing this alone is not enough to turn on BFD and actually see if the other end has it turned on, what you need to do is:

router ospf 1
bfd all-interface
!

This turns on BFD for any interface that has a BFD interval configured.

If the peer goes down, you will see a message like this:


*Aug 10 18:24:59.323: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on GigabitEthernet1/0 from FULL to DOWN, Neighbor Down: BFD node down

Pretty cool hey? And I tell you when I was testing it, it went down in absolute microseconds when I did this, so very funky little feature to help with convergence times.

Let's see how to configure it with BGP (which is probably more relevant because let's face it, OSPF convergence times can be tuned and are not that bad, BGP has the bad convergence times)

so with BGP, same again with the BFD interval:



interface GigabitEthernet1/0
ip address 192.168.1.2 255.255.255.252
negotiation auto
bfd interval 100 min_rx 100 multiplier 3
!

Then you go ahead and enable it on your BGP Peer:

router bgp 65400
neighbor 192.168.1.1 remote-as 65400
neighbor 192.168.1.1 fall-over bfd
!

Easy as that! Super easy to turn on as you can see, you can verify with:



R2#show ip bgp neighbor
BGP neighbor is 192.168.1.1, remote AS 65400, internal link
Fall over configured for session
BFD is configured.

To verify BFD itself is working, you have:

R1#show bfd neighbors


NeighAddr LD/RD RH/RS State Int
192.168.1.2 1/1 Up Up Gi1/0

Pretty cool hey!



Here are some references on how to configure it both for Juniper and Cisco

Cisco:
http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005.html

Juniper:
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-bfd-protocol_3.html

5 comments:

  1. a handy tool and something that will no doubt be further developed on the NXOS platform. I like the blog, bring on the Nexus and UCS discussions :)

    ReplyDelete
  2. What NX-OS version were you running? In 6.x you don't have the "bfd all-interface" command available under the ospf process. Instead, you only enter "bfd" and then go to each OSPF enabled interface and say "ip ospf bfd" in there.

    ReplyDelete
  3. @ alfonso: it's a new command, just like that of normal eigrp, allows you tie bfd to ospf instance per interface rather than all interface which is often unneeded

    ReplyDelete