/25's prefixes announced into global routing table?

Mailman List Mirror (Read Only)
1

Date: Fri, 21 Jun 2013 16:14:07 -0400
From: "Majdi S. Abbas" <msa@latt.net>

As the IPv4 space get smaller and smaller, does anyone think we'll
see a time when /25's will be accepted for global BGP prefix
announcement. The current smallest size is a /24 and generally ok
for most people, but the crunch gets tighter, routers continue to
have more and more ram will it always be /24 the smallest size?

  RAM != FIB.

  The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.

  You couldn't even consider such a thing until after that pain
point.

  --msa

There are techniques to fix that. For example, Simple Virtual Aggregation

2

I'm not sure, if hardware vendors will implement something like this. I
expect they'll sell you router with larger hardware FIB instead.

- Daniel

3

Hai!

Extreme supports route compression since several years. I hope other vendors will also start doing this.

Thanks,
Raymond Dijkxhoorn, Prolocation

4

Daniel Suchy wrote:

There are techniques to fix that. For example, Simple Virtual Aggregation
RFC 6769 - Simple Virtual Aggregation (S-VA)

I'm not sure, if hardware vendors will implement something like this. I
expect they'll sell you router with larger hardware FIB instead.

As the RFC says:

   Some routers in an Autonomous System (AS) announce an aggregate (the
   VA prefix) in addition to the routes they already announce.

it assumes some routers in the AS have unaggregated routing table
entries.

Thus, even within the AS, the RFC is not very effective.

The RFC, either, does not help to reduce the number of routing
table entries exchanged between adjacent ASes.

            Masataka Ohta

5

Le 22/06/2013 00:27, Jakob Heitz a �crit :

There are techniques to fix that. For example, Simple Virtual Aggregation
RFC 6769 - Simple Virtual Aggregation (S-VA)

The principle behind this RFC is that RAM (RIB) is cheap, CAM (FIB) is
not. But it's mostly intended for SDN developpments.

You need a full RIB on every (current - non SDN) BGP speakers in only
one scenario : beeing a transit provider. If you're not, there's no
point in keeping (and least to install) all routes.

But let's say you have enough RAM to store a very large de-aggregated
RIB, and a smaller TCAM. The best path selection takes place in RIB, and
selected best path can be installed as long as you have free space in CAM.

Let's compress (agregate) the table prior to installation, by creating
agregates over adjacent prefixes having only the same next-hop and
origin AS, and you may fit a virtual-full-view, perfectly matching your
routing policy, with far less physical routes to install.

This will probably not be backported to "obsolete" routers, but it would
be natural to operate in such manners for an SDN control plane.

It *could* be deployed on older hardware using some customized BGP
speakers : use a software BGP speaker as a route-server /
route-reflector, get all your eBGP peers to hook to this speaker instead
of your ASBRs, and have the controller apply dynamic compression to the
route table (dynamic meaning it has to be a localy optimized agregate
different for every routers in your network) and feed it to your ASBRs
through iBGP.

There would be different levels of agregation : destructive or not,
matching the exact policy or cutting some slack to fit in smaller TCAMs.

For instance, having AS paths in the local RIB in your ASBRs is required
for netflow/ipfix AS agregates. You may not care about AS beeing too far
from your network, thus generating agregates over multiple adjacent
prefixes originating form different AS is not an issue : if you agregate
every prefixes matching the same 3-4 (deduplicated) AS in the path,
let's use the last as origin, and agregate all the adjacent blocks in a
signle prefix, as long as your best-path selection concluded in using
the same next-hop for all of them.

If you want a more agressive compression, then you may decide not to
fully respect the routing policy, and agregate over a minor block (let's
say a few /24 have a different next hop than their common less-specific
/12), discard the specificity and enjoy shooting /24s off your CAM.

If such a software existed (it's not yet available AFAIK, I wrote some
code to try the concept but it's still far from beeing usable), you may
actually run a real network with less than 30k route entries in your CAM...