Re: /25's prefixes announced into global routing table?
Date: Fri, 21 Jun 2013 16:14:07 -0400 From: "Majdi S. Abbas" <msa@latt.net>
On Fri, Jun 21, 2013 at 01:56:02PM -0600, Michael McConnell wrote:
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 http://tools.ietf.org/html/rfc6769 -- Jakob Heitz.
On 06/22/2013 12:27 AM, Jakob Heitz wrote:
Date: Fri, 21 Jun 2013 16:14:07 -0400 From: "Majdi S. Abbas" <msa@latt.net> 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.
There are techniques to fix that. For example, Simple Virtual Aggregation http://tools.ietf.org/html/rfc6769
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
Hai! Extreme supports route compression since several years. I hope other vendors will also start doing this. Thanks, Raymond Dijkxhoorn, Prolocation Op 22 jun. 2013 om 15:11 heeft Daniel Suchy <danny@danysek.cz> het volgende geschreven:
On 06/22/2013 12:27 AM, Jakob Heitz wrote:
Date: Fri, 21 Jun 2013 16:14:07 -0400 From: "Majdi S. Abbas" <msa@latt.net> 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.
There are techniques to fix that. For example, Simple Virtual Aggregation http://tools.ietf.org/html/rfc6769
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
Daniel Suchy wrote:
There are techniques to fix that. For example, Simple Virtual Aggregation http://tools.ietf.org/html/rfc6769
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
Le 22/06/2013 00:27, Jakob Heitz a écrit :
There are techniques to fix that. For example, Simple Virtual Aggregation http://tools.ietf.org/html/rfc6769
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... -- Jérôme Nicolle +33 6 19 31 27 14
participants (5)
-
Daniel Suchy -
Jakob Heitz -
Jérôme Nicolle -
Masataka Ohta -
Raymond Dijkxhoorn