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: https://archive.nanog.org/mailinglist/mailarchives/old_archive/1996-01/msg00... 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