BGP Labs: Reduce FIB Size on Access Routers
Here’s another BGP lab challenge to start your weekend: use RIB-to-FIB filters to reduce the forwarding table size on access routers in a large Service Provider network.
Here’s another BGP lab challenge to start your weekend: use RIB-to-FIB filters to reduce the forwarding table size on access routers in a large Service Provider network.
I used this technique on a Sup720 on the Cat 6500 platform. The FIB could only hold 239k prefixes. After that it would process switch, which was death on that platform.
We had a full Internet table in the BGP database. The RAM was not the problem, it held the entire Internet. But the FIB was the limit.
With the table-map command we could selectively load only certain routes into the RIB, which would then load into the FIB.
The syntax was non-intuitive. Table-map was designed to adjust the prefixes before loading them into the RIB, not eliminate them entirely! I tried to set the admin distance of the undesired routes to 255 (unreachable) but the CLI didn't take it. I got it to work by setting the metric to 4294967295. I only knew that was the largest number by using the "?" in the CLI.
That did it! Something with metric 4294967295 was unreachable, so it didn't load into the RIB/FIB.
Wow. Cool trick! I never managed to get it to work on Cisco IOS.
Would you be interested in labbing up my eBGP based SP design, Ivan? It particularly solves or rather prevents the need of flooding full tables into the network devices beyond the edge (border) routers, small, medium and big networks.
For instance, if I had a DIA/Transit customer, they do not peer with my PE router, my PE router will transport that customer's L2 over a pseudowire back to my real edge, whereby there, they directly peer with my full table-capable router (and should they choose, which I recommend, get a full table export from my side to their side as well).
P/PEs would only have a few entries of each other's loopbacks for LDP/BGP signalled VPLS etc. Not more than a few tens or hundreds routes tops.
Sure, I have two scenarios in mind:
It will take me a while to get there though ;)
> Run EBGP with the PE router to get the local prefixes and multihop EBGP with a core router to get the transit prefixes.
IMO: I personally dislike this model as both a customer of a transit provider (had terrible nightmares with a carrier that did this) and as the transit service provider myself (if I'm the one who designed the network). It just leads to configuration pollution for no good reason (on both sides), other than laziness, to create (hopefully it's automated in the backend) a Pseudowire from PE to the real edge router for a clean hand-off.
> Pull the circuit to a core router (although I'll use VXLAN instead of VPLS).
What's your reasoning behind VXLAN though? For an SP network? Curious :)
> IMO: I personally dislike this model as both a customer of a transit provider (had terrible nightmares with a carrier that did this) and as the transit service provider myself (if I'm the one who designed the network).
It depends on how much customer traffic would have to go through the network core anyway. That depends on the traffic profile, the size of the network, where the first router with the full routing table is... What's optimal for an access network might not be best for a large SP with lots of regional traffic.
Anyway, the idea of the labs is to let people explore how to do things in a controlled environment.
> What's your reasoning behind VXLAN though? For an SP network? Curious :)
If you're already running MPLS, the I guess adding a new LSP is not such a big deal (particularly in the EVPN days). Things are different if you have a pure IP network (see for example https://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html).
A lot of IXPs are using VXLAN instead of VLPS these days, and there are large WAN networks using it: https://blog.ipspace.net/2017/06/packet-fabric-on-software-gone-wild.html
I've heard of/seen Packet Fabric before. But I'm not sure “a lot of IXPs” are using VXLAN. Arguably, the largest global “commercial” IXP is using MPLS + EVPN: https://www.de-cix.net/en/about-de-cix/news/peering-lans-2-0-evpn-rollout-on-the-de-cix-apollon-platform
The largest IXP in India (a country that's larger than many nations globally by land-mass) is also using MPLS still (with EVPN mostly likely, haven't spoken to them in a long time).