BFD for routes learned trough Route-servers in IXPs

Wed Sep 16 02:01:17 UTC 2020

> "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?"

Install a route optimizer that constantly pings next hops, when the drop threshold is met, remove the routes. No one is going to open BFD to whole subnets, especially those they don't have peering agreements with, making this pointless.
> - ARP Resolution issues (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a bombastic recipe)
CoPP is always important, and it's not just Mikrotik's with default low ARP timeouts.
Linux - 1 minute
Brocade - 10 minutes
Cumulus - 18 minutes
BSD distros - 20 minutes
Extreme - 20 minutes
HP - 25 minutes

> - MAC-Address Learning limitations on the transport link of the participants can be a pain in the a..rm.
As you said, this issue doesn't seem important enough to warrant significant action. For transport, colo a switch that can handles BGP announcements, routes, and ARPs, then transport that across with only 2 MACs and internal point-to-point IP assignments.
Ryan
On Sep 15 2020, at 5:55 pm, Douglas Fischer <fischerdouglas at gmail.com> wrote:
> 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/80d6d05a/attachment.html>