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

Matthew Petach mpetach at netflight.com
Tue Oct 11 20:16:17 UTC 2022


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

> On Mon, Oct 10, 2022 at 3:37 PM Matthew Petach <mpetach at netflight.com>
> wrote:
> > They became even more huffy, insisting that we were breaking the
> internet by not
> > following the correct routing for the more-specific /24s which were no
> longer present
> > in our tables.  No amount of trying to explain to them that they should
> not advertise
> > an aggregate route if no connectivity to the more specific constituents
> existed seemed
> > to get the point across.  In their eyes, advertising the /24s meant that
> everyone should
> > follow the more specific route to the final destination directly.
>
> Hi Matthew,
>
> They were correct. If the /24 was reaching your network, traffic
> should not have been following the /20. In your version, they would
> have to disaggregate the /20 into 16 /24s just because you didn't want
> to honor most-specific path routing. That's not what anybody wants.
> Least of all you.
>

I disagree.

To illustrate why, let's take your case a step further, shall we?

Wouldn't that same argument mean that every ISP that isn't honoring
my /26 announcement, but is instead following the covering /24, or /20,
or whatever sized prefix is equally in the wrong?  And what about Fred's
/27 announcement?  Gosh, and now Cindy wants to announce a dozen
/30's--is it everyone else's error for not listening to those announcements?

What makes /24 boundaries magically "OK" to filter on, such that if
you announce something smaller than a /24 that gets filtered, and
traffic goes to the covering aggregate, everyone says "well, that's
just how the Internet works, and of course traffic would be expected
to flow towards the covering announcement", but if I set the boundary
at a different, but still arbitrarily-sized point, like /23, suddenly the
announcing party is right, and I'm wrong?

If the stance is "it doesn't matter if there's a covering prefix, that
announcement doesn't mean you can reach all the prefixes
contained within it, you *must* listen to all the smaller announcements
in order to have reachability", then A) you're redefining how BGP works
in a fundamental way, and B) we should all buy stock in router memory
manufacturers, because they're going to be the next oil companies.

BGP 101 says that if I announce a covering prefix, I'm making a statement
into the BGP routing table that says "you can reach everything contained
within this covering route via me", and that's how the forwarding tables
treat it; any time there's nothing more specific in the table, even due to
a brief transient change on the Internet, traffic for those prefixes will be
forwarded to the router announcing the covering prefix announcement.

If I announce 0/1 into the DFZ and drop any traffic destined for it on the
floor, I'm not going to get much sympathy by saying "well, it's your fault,
you should have been listening to all the more specifics and not trusting
the covering route to actually have reachability to the prefixes contained
within it."  (though that does make me think that if you're a content-heavy
shop looking to balance your traffic flows, it might be a interesting way
to make the point in a very real way to everyone on the Internet...)

To wrap up--I disagree with your assertion because it depends entirely
on a 'magic' /24 boundary that makes it OK to filter more specifics smaller
than it, but not OK to filter larger than that and depend instead on
covering
prefixes, without actually being based on anything concrete in BGP or
published standards.

"But that's how we've always done it" is not the same as "but that's how
the protocol works."   ^_^;

Regards,

Bill Herrin


Thank you for the discussion!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221011/4eba6fa6/attachment.html>


More information about the NANOG mailing list