On Tue, Oct 11, 2022 at 1:59 PM William Herrin <
bill@herrin.us> wrote:
On Tue, Oct 11, 2022 at 1:15 PM Matthew Petach <mpetach@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:
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