Smaller than a /24 for BGP?
Lars Prehn
lprehn at mpi-inf.mpg.de
Wed Jan 25 05:08:37 UTC 2023
We performed some high-level analyses on these hyper-specific prefixes
about a year ago and pushed some insights into a blog post [1] and a
paper [2].
While not many ASes redistribute these prefixes, some accept and use
them for their internal routing (e.g., NTT's IPv4 filtering policy [3]).
Rob already pointed out that this is often sufficient for many traffic
engineering tasks. In the remaining scenarios, announcing a covering /24
and hyper-specific prefixes may result in some traffic engineering, even
if the predictability of the routing impact is closer to path prepending
than usual more-specific announcements. In contrast to John's claim,
some transit ASes explicitly enabled redistributions of up to /28s for
their customers upon request (at least, they told us so during interviews).
Accepting and globally redistributing all hyper-specifics increases the
routing table size by >100K routes (according to what route collectors
see). There are also about 2-4 de-aggregation events every year in which
some origin (accidentally) leaks some large number of hyper-specifics to
its neighbours for a short time.
Best regards,
Lars
[1]
https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/
[2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
[3] https://www.gin.ntt.net/support-center/policies-procedures/routing/
On 25.01.23 05:12, Forrest Christian (List Account) wrote:
> I have two thoughts in relation to this:
>
> 1) It's amazing how many threads end up ending in the (correct)
> summary that making an even minor global change to the way the
> internet works and/or is configured to enable some potentially useful
> feature isn't likely to happen.
>
> 2) I'd really like to be able to tag a BGP announcement with "only use
> this announcement as an absolute last resort" so I don't have to break
> my prefixes in half in those cases where I have a backup path that
> needs to only be used as a last resort. (Today each prefix I have to
> do this with results in 3 prefixes in the table where one would do).
>
> And yes. I know #2 is precluded from actually ever happening because
> of #1. The irony is not lost on me.
>
>
> On Tue, Jan 24, 2023, 7:54 PM John Levine <johnl at iecc.com> wrote:
>
> It appears that Chris J. Ruschmann <chris at scsalaska.net> said:
> >-=-=-=-=-=-
> >How do you plan on getting rid of all the filters that don’t
> accept anything less than a /24?
> >
> >In all seriousness If I have these, I’d imagine everyone else
> does too.
>
> Right. Since the Internet has no settlements, there is no way to
> persuade a network of whom you are not a customer to accept your
> announcements if they don't want to, and even for the largest
> networks, that is 99% of the other networks in the world. So no,
> they're not going to accept your /25 no matter how deeply you believe
> that they should.
>
> I'm kind of surprised that we haven't seen pushback against sloppily
> disaggregated announcements. It is my impression that the route table
> would be appreciably smaller if a few networks combined adjacent a
> bunch of /24's into larger blocks.
>
> R's,
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230125/cb83568c/attachment.html>
More information about the NANOG
mailing list