Heho, Let alone $all the /24 assigned under the RIPE waiting list policy. In the Geoff Huston spirit, I quickly took a look how less specifics for /24s looks in my table: 8 {'no_less_specific': 16, 'has_less_specific': 0, 'sum': 16, 'least_specific_length': {}} 9 {'no_less_specific': 9, 'has_less_specific': 4, 'sum': 13, 'least_specific_length': {'8': 4}} 10 {'no_less_specific': 38, 'has_less_specific': 0, 'sum': 38, 'least_specific_length': {}} 11 {'no_less_specific': 98, 'has_less_specific': 4, 'sum': 102, 'least_specific_length': {'10': 4}} 12 {'no_less_specific': 269, 'has_less_specific': 31, 'sum': 300, 'least_specific_length': {'9': 5, '11': 23, '8': 1, '10': 2}} 13 {'no_less_specific': 490, 'has_less_specific': 98, 'sum': 588, 'least_specific_length': {'11': 46, '8': 2, '12': 48, '10': 2}} 14 {'no_less_specific': 1022, 'has_less_specific': 188, 'sum': 1210, 'least_specific_length': {'13': 99, '8': 4, '12': 44, '11': 33, '10': 8}} 15 {'no_less_specific': 1641, 'has_less_specific': 476, 'sum': 2117, 'least_specific_length': {'14': 210, '13': 95, '12': 87, '11': 37, '8': 21, '9': 3, '10': 23}} 16 {'no_less_specific': 10319, 'has_less_specific': 3286, 'sum': 13605, 'least_specific_length': {'15': 577, '14': 527, '12': 470, '13': 548, '9': 14, '11': 446, '8': 173, '10': 531}} 17 {'no_less_specific': 4474, 'has_less_specific': 3942, 'sum': 8416, 'least_specific_length': {'16': 1816, '14': 536, '12': 276, '13': 343, '8': 44, '15': 324, '9': 4, '10': 181, '11': 418}} 18 {'no_less_specific': 6926, 'has_less_specific': 7179, 'sum': 14105, 'least_specific_length': {'17': 888, '14': 1367, '16': 2394, '15': 776, '12': 289, '13': 487, '9': 15, '11': 514, '8': 108, '10': 341}} 19 {'no_less_specific': 15056, 'has_less_specific': 10151, 'sum': 25207, 'least_specific_length': {'17': 813, '16': 2561, '15': 1113, '13': 758, '14': 1373, '12': 544, '18': 1213, '8': 198, '9': 28, '11': 770, '10': 780}} 20 {'no_less_specific': 19592, 'has_less_specific': 24430, 'sum': 44022, 'least_specific_length': {'17': 1319, '14': 3435, '16': 6868, '12': 1216, '11': 1568, '13': 2221, '15': 1919, '18': 1450, '19': 2465, '9': 45, '8': 374, '10': 1550}} 21 {'no_less_specific': 22889, 'has_less_specific': 30065, 'sum': 52954, 'least_specific_length': {'17': 1886, '16': 5234, '14': 2569, '13': 1346, '19': 5019, '18': 1717, '12': 2011, '9': 78, '20': 3210, '15': 1760, '8': 513, '11': 3001, '10': 1721}} 22 {'no_less_specific': 59137, 'has_less_specific': 51280, 'sum': 110417, 'least_specific_length': {'17': 3787, '16': 10049, '13': 5469, '19': 4100, '14': 3784, '21': 3287, '18': 3128, '11': 2965, '12': 3428, '20': 4152, '15': 3157, '8': 1018, '9': 166, '10': 2790}} 23 {'no_less_specific': 41052, 'has_less_specific': 60043, 'sum': 101095, 'least_specific_length': {'17': 3844, '21': 3382, '14': 3324, '16': 10032, '22': 13207, '19': 5658, '15': 3007, '18': 2973, '11': 2243, '13': 1645, '12': 1752, '9': 277, '20': 4941, '8': 1260, '10': 2498}} 24 {'no_less_specific': 257032, 'has_less_specific': 295714, 'sum': 552746, 'least_specific_length': {'22': 38330, '17': 19319, '16': 51487, '21': 16799, '23': 14813, '13': 10067, '14': 14328, '20': 26634, '18': 19216, '12': 9440, '11': 10001, '15': 14437, '9': 2700, '19': 31119, '10': 7992, '8': 9032}} So it seems like there is a healthy amount (~260k) prefixes which lack a less specific. With best regards, Tobias -----Original Message----- From: NANOG <nanog-bounces+tobias=reads-this-mailinglist.com@nanog.org> On Behalf Of Stephane Bortzmeyer Sent: Monday, 10 October 2022 17:21 To: Edvinas Kairys <edvinas.email@gmail.com> Cc: NANOG Operators' Group <nanog@nanog.org> Subject: Re: any dangers of filtering every /24 on full internet table to preserve FIB space ? On Mon, Oct 10, 2022 at 05:58:45PM +0300, Edvinas Kairys <edvinas.email@gmail.com> wrote a message of 35 lines which said:

But theoretically every filtered /24 could be routed via smaller prefix /23 /22 /21 or etc.

I don't think this is true, even in theory, specially for legacy prefixes. There is probably somewhere a Geoff Huston survey on /24 without a covering route.

The OP can always take the provider's address space plus their customer's routes and use a default route to fill in the blanks. I did this at a provider years ago where the global routing table outgrew the speed they could spend the money on upgrades and it worked out well. I think it was two upstreams and a connection into a TIE with good peering. -richey On Mon, Oct 10, 2022 at 4:11 PM Geoff Huston <gih@apnic.net> wrote:

...

On 11 Oct 2022, at 4:23 am, Tobias Fiebig <tobias@reads-this-mailinglist.com> wrote:

Heho, Let alone $all the /24 assigned under the RIPE waiting list policy.

In the Geoff Huston spirit, I quickly took a look how less specifics for /24s looks in my table:

[…]

...

So it seems like there is a healthy amount (~260k) prefixes which lack a less specific.

I also looked using a slightly different approach - namely looking for /24s where there was no spanning aggregate that matched the /24’s AS Path. In my local table there are 224,580 of them.

Geoff

On 10/10/22 9:20 AM, Stephane Bortzmeyer wrote:

...

But theoretically every filtered /24 could be routed via smaller prefix /23 /22 /21 or etc. I don't think this is true, even in theory, specially for legacy prefixes. There is probably somewhere a Geoff Huston survey on /24 without a covering route.

There's lots of legacy blocks out there that are only /24 in size... Like my primary IPv4 block, for example. I believe you'll also find them referred to as 'portable' blocks. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org

Randy Bush <randy@psg.com> wrote:

it is a tragedy that cidr and an open market has helped us more than ipv6 has.

True. Maybe cidr and an open market for ipv6 addresses would reduce the tragedy? John

On 10/20/22 17:50, Adam Thompson wrote:

Alternately, a valid technique is to have a default route AND a partial BGP feed (a filtered full feed is by definition a partial feed). That helps optimize outbound routing a little bit, you still get the advantage - mostly - of multiple inbound carriers; but you still have to pick one carrier to do the heavy lifting for you. And you are paying them to route for you, so that's not an unfair shifting of the routing burden, unlike relying on covering routes. Note that this approach does NOT provide any redundancy, unlike having full BGP feeds.

As a note, you can get redundancy (but still none of the best-path advantages of having multiple transits) by asking your transits to originate default in their BGP feed and then selectively accepting it. You can either ECMP it or pick priority with localpref. You need multiple full-view transits for this to work, though. -- Brandon Martin

Been doing exactly this for a couple ASNs for a few years now with surprisingly good results (thanks to advice way far back from my good friend Brandon Martin above, coincidentally). One of them is even on an L3 switch with something like 96k max routes. Taking defaults from two upstream providers and ECMPing between them. This particular AS is a pretty predictable network so after running netflow for a while, compiling a list of the top ~1000 outbound ASs we talk to, then creating route filters to allow any prefixes from this AS list into our forwarding table, it now has something like 98% of it's traffic by volume covered by specifics from all our upstreams, and of course ECMP defaults to fall back on for the remaining 2%. Not pretty, but have had surprisingly zero issues or traffic weirdness over a few years now - when customers want to play bgp but refuse to buy actual routers you have to get creative :) On Mon, Oct 24, 2022, 11:47 AM Adam Thompson <athompson@merlin.mb.ca> wrote:

I can't believe that never occurred to me in all the time I was doing that, 'way back when... <facepalm> Thanks for pointing that out! -Adam

Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athompson@merlin.mb.ca

...

-----Original Message----- From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Brandon Martin Sent: October 21, 2022 4:30 PM To: nanog@nanog.org Subject: Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

...

Alternately, a valid technique is to have a default route AND a

On 10/20/22 17:50, Adam Thompson wrote: partial BGP feed (a filtered full feed is by definition a partial feed). That helps optimize outbound routing a little bit, you still get the advantage - mostly - of multiple inbound carriers; but you still have to pick one carrier to do the heavy lifting for you. And you are paying them to route for you, so that's not an unfair shifting of the routing burden, unlike relying on covering routes. Note that this approach does NOT provide any redundancy, unlike having full BGP feeds.

As a note, you can get redundancy (but still none of the best-path advantages of having multiple transits) by asking your transits to originate default in their BGP feed and then selectively accepting it. You can either ECMP it or pick priority with localpref.

You need multiple full-view transits for this to work, though.

-- Brandon Martin

If you filter out /23 or longer you cut the v4 table size about in half. I have done this with some edge and eyeball network clients that had really old or underpowered routing gear and upgrades were just not in the budget, and they could barely spell BGP. I know of a number of ASNs with SUP720 era gear still in production this way in 2022 (the power bill is usually someone else’s budget!). Be sure to take default from a couple upstreams and allow /24s for the peers on your IXP links that matter (CDN, etc) and your traffic is mostly fine. Maybe not always taking the most direct return path, but it gets there. Inbound traffic distribution isn’t affected and that is all most eyeball networks care about. On Mon, Oct 10, 2022 at 11:26 AM Nick Suan via NANOG <nanog@nanog.org> wrote:

There's 69,055 pure /24's allocated or assigned directly from an RIRs. At least c,d,e, and g root servers only have /24s allocated to them. Major services like Cloudflare only advertise the /24 without advertising an aggregate.

Unless you're also getting a default from upstream, it sounds like you're going to end up wasting the money you saved on chasing down subtle brokenness.

On Mon, Oct 10, 2022, at 9:58 AM, Edvinas Kairys wrote:

Hello,

We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it will be not enough - so we're thinking to deny all /24s to save the memory. What do you think about that approach - I know it could provide some misbehavior. But theoretically every filtered /24 could be routed via smaller prefix /23 /22 /21 or etc. But of course it could be a situation when denied /24 will not be covered by any smaller prefix.

What do you think about this approach ?

Also maybe you know - some advices for edge routers that have at least 8x100G interfaces and "good" memory for prefix count ? Thanks

-- Jim Troutman, jamesltroutman@gmail.com Pronouns: he/him/his 207-514-5676 (cell)

On 10/10/22 17:26, William Herrin wrote:

The Internet FIB is around 900k IPv4 routes. You have years before exhausting a 2.2M table.

Depends on what else they may be carrying in their IGP, MPLS domain, SR domain, e.t.c. Mark.

nanog@ics-il.net (Mike Hammett) wrote:

Feasibility of adding some middleware that culls unneeded routes (existing more specific and aggregate routes pointing to the same next hop), when that table starts to fill?

Well... if that covering prefix goes away, let's hope you still have a default. I've (been forced to) cull long prefixes on some memory-starved routers, and given that all of them have defaults, For our (former employers and certainly the current one) I've seen moderate to no traffic shifting, and this approach gave the museum gear another lease on life - they were fine with bandwidth. I've even gone down to strip anything longer than a /20 in v4, and a /40 in v6. If you run a backbone that needs to know the best exit for a prefix in order to throw traffic out locally and not pay good money for sightseeing capacity, you might fare better with beefier routing engines. El Mare.

On Mon, Oct 10, 2022 at 8:37 AM Mike Hammett <nanog@ics-il.net> wrote:

Feasibility of adding some middleware that culls unneeded routes (existing more specific and aggregate routes pointing to the same next hop), when that table starts to fill?

This is called "FIB aggregation." It exists and works but is not widely adopted. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

On Mon, Oct 10, 2022 at 11:18 AM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

There has been a number of efforts to implement FIB (actually BGP RIB) compression. There’s a white paper from MS research; I recall Spotify talking of running off-box BGP compression SW and re-injecting summarized BGP RIB;

Hi Jeff, Actually, I was talking about FIB aggregation/compression where you take a full BGP RIB but optimize the prefixes placed in the local FIB so that you don't need a FIB entry for every RIB entry. Solid FIB compression can give you a 50% savings in FIB entries without altering the next hop selected for any reachable destination IP address. Costs main processor time computing the FIB from the RIB of course, which can be challenging in a large change event (e.g. a link loss). Excepting source aggregation and terminal default routes, RIB compression and reinjection is dangerous on multiple levels from accidental leaks to connectivity loss and (in my opinion) should not be done. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

On Mon, Oct 10, 2022 at 8:44 AM Mark Tinka <mark@tinka.africa> wrote:

On 10/10/22 16:58, Edvinas Kairys wrote:

...

Hello,

We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it will be not enough - so we're thinking to deny all /24s to save the memory. What do you think about that approach - I know it could provide some misbehavior. But theoretically every filtered /24 could be routed via smaller prefix /23 /22 /21 or etc. But of course it could be a situation when denied /24 will not be covered by any smaller prefix.

I wouldn't bank on that.

I am confident I have seen /24's with no covering route, more so for PI space from RIR's that may only be able to allocate a /24 and nothing shorter.

It would be one heck of an experiment, though :-).

Mark.

I may or may not have done something like this at $PREVIOUS_DAY_JOB. We (might have) discovered some interesting brokenness on the Internet in doing so; in one case, a peer was sending a /20 across exchange peering sessions with us, along with some more specific /24s. After filtering out the /24s, traffic rightly flowed to the covering /20. Peer reached out in an outraged huff; the /24s were being advertised from non-backbone-connected remote sites in their network, that suddenly couldn't fetch content from us anymore. Traceroutes from our side followed the /20 back to their "core", and then died. They explained the /24s were being advertised from remote sites without backbone connections to the site advertising the /20, and we needed to stop sending traffic to the /20, and send it directly to the /24 instead. We demurred, and let them know we were correctly following the information in the routing table. 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. So, even seeing a 'covering route' in the table is no guarantee that you won't create subtle and not-so-subtle breakage when filtering out more specifics to save table space. ^_^; Having (possibly) done this once in the past, I'd strongly recommend looking for a different solution--or at least be willing to arm your front-end response team with suitable "No, *you* broke the Internet" asbestos suits before running a git commit to push your changes out to all the affected devices in your network. ;) Matt

On Mon, Oct 10, 2022 at 3:37 PM Matthew Petach <mpetach@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. One of my service providers has multiple disconnected sites. At each site they advertise the Internet's full BGP table to me -except for- the routes to their other sites. They insist they're doing the right thing but they're not. The BGP table they send me is not full, and when I need to talk to many of -their- servers my traffic ends up routing through one of my other service providers. I'm not paying them enough to make a big stink about it but if I was you can bet I'd take them to task. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

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.

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? Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

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

On Tue, Oct 11, 2022 at 7:03 PM William Herrin <bill@herrin.us> wrote:

On Tue, Oct 11, 2022 at 5:32 PM Matthew Petach <mpetach@netflight.com> wrote: [...] All TCP/IP routing is more-specific route first. That is the expected behavior. I honestly don't fathom your view that BGP is or should be different from that norm. If the origin of a covering route has no problem sinking the traffic when the more-specific is offline, I don't see the problem. You shouldn't be taking them offline with route filtering.

*facepalm* Right. That's the entire point I started off the subthread with. The problem lay with an organization that *did* have a problem sinking the traffic when the more-specific was not available. They had chunked up their allocation into smaller pieces which were distributed to different island locations with no internal network connectivity to the island sites. They were announcing a covering prefix for all the more specifics, where the covering less specific announcement had no reachability to the more specifics; so when a network filtered out the more specifics, the traffic fell on the floor, because it was sent to a location that was announcing the supernet that had no reachability to the correct destination. Their assumption that *everyone* would hear the more specifics, and thus the traffic would flow to the right island location was the "failure to understand BGP" that I was commenting on, and noting that while it is entirely correct to decide if you want to filter prefixes of an arbitrary length from entering your network, you may discover in the process that other networks that do not understand BGP and routing in general may complain that you have Broken The Internet(tm) by doing so. Assuming that your announcement of more specifics will always pull traffic away from a less-specific announcement is overly-optimistic. While it may *often* work, you should still be prepared to deal with traffic arriving at your least-specific announcement as well. This turned out to be something that not every network on the Internet fully grasps, and my original message was warning that filtering on /24s would potentially bring complaints from networks like those. It took a roundabout path, but I'm glad we eventually both ended up at the same place. :) Thanks! Matt

This situation isn’t helped by RIR policies that require you to announce the aggregate in region even if the more specifics are scattered around the world. The whole territorial exclusivity game played by some RIRs may well cause more harm than good at this point. Yes, I realize this is a reversal of my previous views on the subject. I’m becoming more aware of more circumstances in which this idea is fraught and causing problems for legitimate users more than for policy forum shoppers and leasing companies. Owen

On Oct 16, 2022, at 01:01, Matthew Petach <mpetach@netflight.com> wrote:



...

On Tue, Oct 11, 2022 at 7:03 PM William Herrin <bill@herrin.us> wrote: On Tue, Oct 11, 2022 at 5:32 PM Matthew Petach <mpetach@netflight.com> wrote: [...] All TCP/IP routing is more-specific route first. That is the expected behavior. I honestly don't fathom your view that BGP is or should be different from that norm. If the origin of a covering route has no problem sinking the traffic when the more-specific is offline, I don't see the problem. You shouldn't be taking them offline with route filtering.

*facepalm*

Right. That's the entire point I started off the subthread with.

The problem lay with an organization that *did* have a problem sinking the traffic when the more-specific was not available. They had chunked up their allocation into smaller pieces which were distributed to different island locations with no internal network connectivity to the island sites.

They were announcing a covering prefix for all the more specifics, where the covering less specific announcement had no reachability to the more specifics; so when a network filtered out the more specifics, the traffic fell on the floor, because it was sent to a location that was announcing the supernet that had no reachability to the correct destination.

Their assumption that *everyone* would hear the more specifics, and thus the traffic would flow to the right island location was the "failure to understand BGP" that I was commenting on, and noting that while it is entirely correct to decide if you want to filter prefixes of an arbitrary length from entering your network, you may discover in the process that other networks that do not understand BGP and routing in general may complain that you have Broken The Internet(tm) by doing so.

Assuming that your announcement of more specifics will always pull traffic away from a less-specific announcement is overly-optimistic. While it may *often* work, you should still be prepared to deal with traffic arriving at your least-specific announcement as well.

This turned out to be something that not every network on the Internet fully grasps, and my original message was warning that filtering on /24s would potentially bring complaints from networks like those.

It took a roundabout path, but I'm glad we eventually both ended up at the same place. :)

Thanks!

Matt

On Wed, Oct 12, 2022 at 7:54 AM Andrey Kostin <ankost@podolsk.ru> wrote:

IMO this line wasn't arbitrary, it was (and it still is) a smallest possible network size allocated by RIRs. So it's just a common sense to receive everything down to /24 to have the complete data about all Internet participants.

Hi Andrey, Filtering routes longer than /24 route filtering came first and is the cause here while the RIR minimum assignment is an effect. The RIRs stay at /24 because it would be implicitly wasteful to assign addresses in units smaller than can be routed on the public Internet. Of the things that would have to change to make longer prefixes routeable on the Internet, the RIR policies are the easiest. The /24 boundary is simply a holdover from pre-CIDR times when the smallest routing unit was a "class C." Folks wanted to make sure CIDR didn't make their routing woes worse, so they filtered and it stuck. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/

David Conrad писал(а) 2022-10-12 11:39:

Andrey,

There was a period in the mid- to late-90s where some of RIRs allocated longer than /24s, i.e., to match the amount of address space justified by the requester, even if that meant (say) a /29. This didn’t last very long as one of the (at the time) 800 lb gorillas (Sprint) decided to start filtering at /19 (which IIRC was the default prefix length RIPE-NCC chose to allocate to LIRs) to keep their routers from falling over.

I'm looking at it only from a practical side. I worked for different ISPs in RIPE region in 2000-s and never saw anything like that. There was a requirement from RIPE to create an object for any assigned /29 subnet and larger for IP space usage documentation, but from allocated block. Anyways, even is it's true, it doesn't change anything. There are /24 PI blocks and if /24s are filtered, default route must be in use to have functional Internet connectivity. Thanks, Andrey

On Wed, Oct 12, 2022 at 11:51:13AM -0400, Jon Lewis wrote: [snip]

And just for the record, despite having been bitten by it more than once, I'm very much in the camp of "if you advertise a covering aggregate, you're offering to get packets there, regardless of whether or not more specifics exist." You have no business demanding what routes someone else's network receives/accepts. All you can reasonably control is what you advertise and what you accept.

This. People will come up with all sorts of creative topologies, and as long as they are *internal* that's A-OK. The distance outside of one's AS one can expect "interesting" TE to travel is equivalent to the reach of your $s and/or contracts. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling

On 2022-10-10 09:39, Jay Hennigan wrote:

On 10/10/22 07:58, Edvinas Kairys wrote:

...

We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it will be not enough - so we're thinking to deny all /24s to save the memory. What do you think about that approach - I know it could provide some misbehavior. But theoretically every filtered /24 could be routed via smaller prefix /23 /22 /21 or etc. But of course it could be a situation when denied /24 will not be covered by any smaller prefix.

If so, a better approach might be to apply a max AS rule and take full tables plus a default from both (all). Something like "bgp maxas-limit 4" will optimize routing down to /24 but drop routes with long AS paths and punt to default, reducing your table size at the cost of sub-optimal routing to destinations that are going to take a convoluted path anyway.

And run something like netflow to determine high traffic AS paths, and optimize those into your filtering.