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

Wed Oct 12 00:33:30 UTC 2022

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

> On Tue, Oct 11, 2022 at 1:15 PM Matthew Petach <mpetach at netflight.com>
> wrote:
> > 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?
> >
> > What makes /24 boundaries magically "OK" to filter on,
>
> Hi Matthew,
>
> /24 is the consensus filtering level for Internet-wide routes and it
> has been for decades. It became the consensus as a holdover from
> "class C" and remains the consensus because too many people would have
> to cooperate to change it. Indeed, a little over a decade ago some
> folks tried to change it to /19 and then /20 for prefixes outside "the
> swamp" and, well, they failed. Likewise, more than a few folks
> announce /26's to their immediate transit providers and they simply
> don't move very deep into the system -- nobody has any expectation
> that they will.
>

Yes, I know.  I was there when smd was pointing out the arbitrary lines
being drawn in the sand, and decided to draw his own line.  The first salvo
was fired in 1996, with a customer complaining their /24 wasn't being
accepted by everyone, leading to a *very* long chorus of people chiming
in with different thoughts on where the line could and should be drawn:
https://archive.nanog.org/mailinglist/mailarchives/old_archive/1996-01/msg00306.html

My point is that it's not a feature of BGP, it's a purely human convention,
arrived at through the intersection of pain and laziness.
There's nothing inherently "right" or "wrong" about where the line was
drawn, so for networks to decide that /24 is causing too much pain,
and moving the line to /23 is no more "right" or "wong" than drawing
the line at /24.  A network that *counts* on its non-connected sites
being reachable because they're over a mythical /24 limit is no more
right than a customer upset that their /25 announcements aren't being
listened to.

> > 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.
>
> Got any better reasons besides disliking the consensus?
>

Absolutely.

Let BGP work as it's supposed to work.

If there's a covering prefix being announced, according to BGP, it's a
valid pathway to reach
all the prefixes contained within it.  If that's not how your network is
constructed, don't
send out your announcements that way.  Only announce prefixes for which you
*do* have
actual reachability.

Consensus isn't a guarantee.

"SHOULD" in an RFC is still just a recommendation, and not following
it isn't an error.

If you're worried about memory in your routers, and you decide to move the
line from /24 to /23 or /22, that's not an error, that's not breaking BGP,
that's
just moving an arbitrary line that was set by stressed and busy network
engineers nearly 3 decades ago.

If a network engineer feels the need to filter out longer prefixes to deal
with
a memory shortage in their devices, that's their decision; my anecdote was
to point out you'll likely run into people who don't understand BGP very
well,
and mistakenly think there's some magical guarantee that /24 or shorter
prefixes will always work, while longer prefixes won't.  And that's just
not
at all true.  BGP simply looks for the longest match in the available table,
whatever that might be, and uses whatever the "most specific" match is,
no matter how long or short it might be.  Networks should always keep
that in mind when announcing prefixes; don't announce a prefix you aren't
prepared to handle the traffic for, no matter what traffic engineering
tweaks
you might be attempting to steer traffic away.  You should always assume
that for whatever reason, if you announce a prefix, there's a good chance
that other networks will see that as the best match and make use of it.
If you don't want it used for traffic, don't announce it.

Thanks!

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