[c-nsp] BFD on port channel

[Mack McBride]

The layer 2 version of BFD is UDLD.
UDLD should be used for port channels to detect up/down/impaired on the individual links.

If you are using two links my suggestion would be to make both links routed.
In the scenario you have provided that doesn't really make sense.

You could use sub-interfaces on R2 but I am not sure that is going to work with BFD.

Your design provides a bottle-neck at SW1.
You have two single points of failure. The port channel doesn't buy you much and
complicates detection of problems.  If there is an alternate path then ditch the
port channel.  It is adding complexity and introducing a detection problem while
not providing much added benefit.  If there isn't an alternate path then doing detection
isn't going to help much.

LR Mack McBride
Network Architect

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mikael Abrahamsson
Sent: Friday, November 04, 2011 12:37 AM
To: Geert Nijs
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BFD on port channel

On Thu, 3 Nov 2011, Geert Nijs wrote:

> so no, forget BFD and portchannels :-)

I hope this is not the reason that we do not have BFD on portchannels. 
There are other perfectly valid use-cases where what you describe is not a 
problem:

R1 - (2x1GE PC) - SW1 - (1GE) - R2

Now, is we want to understand if R2 is still alive running BFD for our 
routing protocol session between R1 and R2 is perfectly valid. It might 
not protect all fault scenarios, but it protects some, and that's still 
enough that I would like to run it.

On platforms where BFD is handled on the RP I set it to 3x1s which is 
still enormously much better than 30+ seconds that most routing protocols 
have as default dead timers or what you can safely achieve by lowering the 
dead timers.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/