> On Sep 22, 2020, at 4:46 AM, Andy Davidson <a...@nosignal.org> wrote:
>
> Hi,
>
> Douglas Fisher wrote:
>> B) There is any other alternative to that?
>
> Don't connect to IXPs with very very large and complicated topologies.
> Connect to local IXPs where the design makes a forwarding plane failure that
> causes the problem you describe less likely.
Or don’t use a route server except to bootstrap. I regularly see issues
related to them. I get it’s not easy to peer at an IXP, but IXP peering isn’t
for everyone as some people might make it sound. This is why back in the day
there was a push to require 24x7 staffing of the remote side to ensure it was
being monitored/supported.
That may no longer apply to many people, but without active monitoring, you
won’t know what the state is of the remote side.
- Jared
