any dangers of filtering every /24 on full internet table to preserve FIB space ?

Sun Oct 16 08:02:03 UTC 2022

On Tue, Oct 11, 2022 at 7:03 PM William Herrin <bill at herrin.us> wrote:

> On Tue, Oct 11, 2022 at 5:32 PM Matthew Petach <mpetach at netflight.com>
> wrote:
> [...]
> All TCP/IP routing is more-specific route first. That is the expected
> behavior. I honestly don't fathom your view that BGP is or should be
> different from that norm. If the origin of a covering route has no
> problem sinking the traffic when the more-specific is offline, I don't
> see the problem. You shouldn't be taking them offline with route
> filtering.
>

*facepalm*

Right.  That's the entire point I started off the subthread with.

The problem lay with an organization that *did* have a problem
sinking the traffic when the more-specific was not available.
They had chunked up their allocation into smaller pieces
which were distributed to different island locations with no
internal network connectivity to the island sites.

They were announcing a covering prefix for all the more
specifics, where the covering less specific announcement
had no reachability to the more specifics; so when a network
filtered out the more specifics, the traffic fell on the floor, because
it was sent to a location that was announcing the supernet that
had no reachability to the correct destination.

Their assumption that *everyone* would hear the more specifics,
and thus the traffic would flow to the right island location was the
"failure to understand BGP" that I was commenting on, and noting
that while it is entirely correct to decide if you want to filter prefixes
of an arbitrary length from entering your network, you may discover
in the process that other networks that do not understand BGP and
routing in general may complain that you have Broken The Internet(tm)
by doing so.

Assuming that your announcement of more specifics will always pull
traffic away from a less-specific announcement is overly-optimistic.
While it may *often* work, you should still be prepared to deal with
traffic arriving at your least-specific announcement as well.

This turned out to be something that not every network on the
Internet fully grasps, and my original message was warning that
filtering on /24s would potentially bring complaints from networks
like those.

It took a roundabout path, but I'm glad we eventually both ended
up at the same place.   :)

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221016/8dec9798/attachment.html>