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: [email protected] [mailto:[email protected]] On Behalf Of Mikael Abrahamsson Sent: Friday, November 04, 2011 12:37 AM To: Geert Nijs Cc: [email protected] 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: [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
