[j-nsp] ISIS and BFD

[Mark Tinka]

On Wednesday 30 December 2009 07:22:32 am Richard A 
Steenbergen wrote:

> How would you handle the case where one side decided to
>  unconfigure BFD then?

My assumption doesn't take into account enabling BFD with 
peers not within your AS.

>  The current behavior allows you to
>  configure BFD everywhere, and if the other side doesn't
>  support it they simply don't respond to the packets and
>  the session operates without BFD.

Which is how we operate BFD.

We have a couple of Cisco NPE-G1's that have a nasty BFD-
related bug (I'm sure you've seen me rant about this several 
times on the 'c-nsp' list), so we can't enable BFD on those. 
IS-IS runs fine without it.

All our other Cisco and Juniper routers that have no issues 
running BFD run it and also talk to the other non-BFD-
enabled routers just fine.

> Maybe it would make sense to have a configuration option
>  where you want to enforce that if the other side isn't
>  speaking BFD you don't want to bring the session up at
>  all.

Yes, that's the knob I was asking for, but only if *there 
is* a knob. Having it as a default feature may make sense on 
paper, but is likely very bad for operational reality.

> BFD is one of those features which sounds like it should
>  be a really good thing, but which still has a lot of
>  design flaws and implementation bugs to work out. For
>  example, Cisco doesn't support BFD on 6500/7600 SVIs,

I believe this was a decision they took. The platform 
originally did support it on the SVI's, but for some reason, 
they chose to discontinue it in later code.

If we ever did deploy the 7600 as an edge router, this 
wouldn't be a huge problem since you can run BFD there. 
SVI's would mostly apply to customer terminations, where we 
generally don't run BFD - but that's us :-).

>  and implements it on the same CPU as the control-plane
>  on those platforms, leading to many false positives
>  unless you have very high timeout values.

Trying to work at 50ms interval level for BFD, as 
advertised, is probably not a very good idea. We've been 
happy with 250ms, although I've heard of additional 
happiness with 300ms.

Either way, it's a lot quicker than the IGP, which is good.

>  Juniper
>  doesn't support BFD on IPv6...

Except on JUNOSe, for OSPFv2 and OSPFv3 - but I guess JUNOS 
is what we're really after :-).

Cisco's implementation is also currently limited to "global-
to-global" or "link local-to-link local" source and 
destination addresses. I believe they are also yet to add 
support for more client protocols.

>  (and more to the point,
>  causes a commit error if you try to apply it at the BGP
>  group level and happen to have an IPv6 neighbor in that
>  group), nor a mechanism to disable BFD on a specific
>  neighbor below a group level.

This isn't different from Juniper's lack of v6 support for 
an MPLS control plane. It just means they need to add 
support for it :-).

>  We frequently get
>  complaints from peers about "why are you sending me
>  these packets!" when we enable BFD at a BGP group level,
>  and we lack any mechanism to disable it for just them.

We don't run BFD on anything other than IS-IS (and perhaps, 
some internal static routes where the IGP cannot be 
supported, but I recall we killed the last of those 
problems), but I think what we need there is a knob in 
JUNOS.

As of IOS 12.2(33)SRC5, I can't find any way to have per-
neighbor BFD parametres, either.

>  The MPLS bootstrapping mechanism for BFD using lsping is
>  a complete disaster too, and it doesn't appear to
>  support BFD when doing ECMP over multiple RSVP LSPs
>  either.

Haven't worked with BFD on MPLS. Just IS-IS and static 
routes :-).

> One area I've been meaning to test but haven't had the
>  time is security, i.e. how easy is it to cause an outage
>  by inducing a false positive failure with a BFD flood.
>  There is an inherient TTL security mechanism in BFD
>  (setting ttl to 255 and expecting 254 from your directly
>  connected neighbor), but we all know that Juniper has no
>  native TTL security support anywhere else (shamefully
>  :P), requiring you to manually filter the packets in
>  firewall filters if you want to actually block them. It
>  would be interesting to see what happens when you get a
>  BFD flood and don't apply those manual firewall filters,
>  especially for older platforms or other vendors which
>  don't support TTL matching in filters.

I'm not sure whether BFD Authentication is something that 
would help here. I glanced over it when reading up on JUNOS 
9.6, but for our application, it seems like additional 
overhead for the time being.

> Overall we've had very poor luck getting any significant
>  amount of adoption from remote networks in the places
>  where it is needed most, such as over Internet exchange
>  points (where the lack of link state can cause very
>  significant blackholing periods in the event of an
>  issue, 90-180 secs with default hold timer values).

Obviously such applications are a lot more difficult to co-
ordinate, particularly since BFD is supported only on some 
platforms for some vendors, and only under certain code 
revisions.

My queries were focused more on internal deployments, 
particularly for an IGP.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20091230/21cc9a6d/attachment.bin>