Virtual aggregation: a quick fix for FIB/TCAM overflow
During the Big Hot and Heavy Switches podcast, Dan Hughes complained that the Nexus 7000 switch cannot take the full BGP table. The reason is simple: it’s TCAM (FIB) has only 56.000 entries and the BGP table has almost 350.000 routes.
Nexus 7000 is a Data Center switch, so the TCAM size is not really a limitation (it would usually have a default route toward the WAN core), but the same problem is experienced by Service Providers all over the world – the TCAM/FIB size of their high-speed routers is limited.
It’s usually easy (and comparatively cheap) to upgrade router’s main memory which holds the BGP table and the IP routing table. Upgrading SRAM or TCAM that holds the FIB is either expensive or mission-impossible (the difference between IP routing table (RIB) and IP forwarding table (FIB) is explained in my RIB/FIB blog post), resulting in premature forced retirement of the high-speed gear.
Faced with this problem, some very smart researchers proposed virtual aggregation (and named it ViAggre), a technique that allows you to reduce FIB/TCAM requirements while still having the full BGP table in your router. For an overview of virtual aggregation, read my SearchTelecom article, for more details, read their paper.
The next problem are the BGP customers - they want full feed (maybe they bought too much RAM and/or care about Elbonia) and you either have full BGP table on the access router or use multihop EBGP into your core (in which case you have support problems with some customers)