BFD for routes learned trough Route-servers in IXPs

Wed Sep 16 00:55:25 UTC 2020

Time-to-time, in some IXP in the world some issue on the forwarding plane
occurs.
When it occurs, this topic comes back.

The failures are not big enough to drop the BGP sessions between IXP
participants and route-servers.

But are enough to prejudice traffic between participants.

And then the problem comes:
"How can I check if my communication against the NextHop of the routes that
I learn from the route-servers are OK?
If it is not OK, how can I remove it from my FIB?"

Some other possible causes of this feeling are:
- ARP Resolution issues
(CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a
bombastic recipe)
- MAC-Address Learning limitations on the transport link of the
participants can be a pain in the a..rm.

So, I was searching on how to solve that and I found a draft (8th release)
with the intention to solve that...
https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08

If understood correctly, the effective implementation of it will depend on
new code on any BGP engine that will want to do that check.
It is kind of frustrating... At least 10 years after the release of RFC
until the refresh os every router involved in IXPs in the world.

Some questions come:
A) There is anything that we can do to rush this?
B) There is any other alternative to that?

P.S.1: I gave up of inventing crazy BGP filter polices to test reachability
of NextHop. The effectiveness of it can't even be compared to BFD, and
almost kill de processing capacity of my router.

P.S.2: IMHO, the biggest downside of those problems is the evasion of
route-servers from some participants when issues described  above occurs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200915/6b07f2e4/attachment.html>