bfd-like mechanism for LANPHY connections between providers

Jensen Tyler JTyler at
Wed Mar 16 13:33:51 CDT 2011

We are going to turn up BFD with Level3 this Saturday. They require that you run a Juniper(per SE). Its sounds like it is fairly new as there was no paperwork to request the service, had to put it in the notes.

We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure.

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz at] 
Sent: Wednesday, March 16, 2011 1:26 PM
To: nanog at
Subject: Re: bfd-like mechanism for LANPHY connections between providers

Richard A Steenbergen wrote on 16/03/2011 19:03:
> On Wed, Mar 16, 2011 at 06:56:28PM +0200, Tassos Chatzithomaoglou wrote:
>> Are there any transit providers out there that accept using the BFD (or
>> any other similar) mechanism for eBGP peerings?
>> If no, how do you solve the issue with the physical interface state when
>> LANPHY connections are used?
>> Anyone messing with the BGP timers? If yes, what about multiple LAN
>> connections with a single BGP peering?
> Well first off LAN PHY has a perfectly useful link state. That's pretty
> much the ONLY thing it has in the way of native OAM, but it does have
> that, and that's normally good enough to bring down your EBGP session
> quickly. Personally I find the risk of false positives when speaking to
> other people's random bad BGP implementations to be too great if you go
> much below 30 sec hold timers (and sadly, even 30 secs is too low for
> some people). We (nLayer) are still waiting for our first customer to
> request BFD, we'd be happy to offer it (with reasonable timer values of
> course). :)

Link state is good for the local connection. If there are multiple 
intermediate optical points (not managed by either party), or a lan 
switch (IX environment), you won't get any link notification for 
everything not connected locally to your interface, unless there is a 
mechanism to signal that to you.


More information about the NANOG mailing list