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

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

Sounds good to me. Especially , if you are prioritizing ipv6 routes in your fib

What is your use case ? Selling transit bgp might be tricky since you will be not sending specifics to your downstreams.

If you are edge network like me, taking a default from your upstream solves all problems and you can filter and TE as you wish.

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.

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.

If you have a default route that works and you don't have any
downstream customers which expect a full routing table, this is fine.
You just won't get as good results with the /24s. Beware that MOST
Internet /24 routes are NOT covered by a shorter prefix so unless you
specifically cover them they will be lost. This will severely impact
your Internet connectivity.

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

Regards,
Bill Herrin

a message of 10 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.

I even find an example on my employer's network :slight_smile:

192.93.0.0/24

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.

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?

Not great for passing downstream, but should fill a need internally.

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.

Are you multi-homed? If not you can simply take a default.

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.

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

Mark.

we're thinking to deny all /24s to save the memory

i recommend this to all my competitors

randy

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.

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

My assumption is that it’s not a one-and-done scenario - that the middleware continually adjusts.

There are most definitely a number of organizations that have /24s that are not part of a larger aggregate.

If you don’t have a default route to some router that takes the full table on your behalf, then you will loose connectivity to/from those entities.

Owen

I like that idea.

This is called "FIB aggregation." It exists and works but is not widely adopted.

Regards,
Bill Herrin

You’ll need to be very selective about the IP ranges you apply that filter to, or more likely, just do it and make sure have one or more default routes to devices/providers that carry full tables.

As for alternate devices, have you looked at Arista 7280, particularly the Jericho >1 versions.

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; Volta Networks had an implementation of full BGP table compression to about 370K routes with no connectivity loss and reasonably fast reaction of topology changes/disaggregation needed(it even won some Intel price for innovation), not sure what happened to it (Volta had been acquired by IBM some time ago). To my memory - IOS-XR allows off box custom best path logic and re-injection of routes into BGP RIB

Cheers,
Jeff