The Internet IPv4 forwarding table continues to grow unabated. Is anyone surprised? Earlier thinking by industry pundits believed that as networks migrated to the new promised land of IPv6, the need for additional IPv4 address space would diminish; leading to a flattening of growth for IPv4 addresses. On top of that, it was expected that as IANA becomes more stringent on IPv4 address space allocation (due to the imminent inevitability of running out of IPv4 address space), this must surely result in a dimished appetite for IPv4 addresses – and both of these would lead to a flattening of the growth trend for the global IPv4 Internet table.
However, the expected flat lining of the IPv4 growth trend line is not occurring. The below diagram clearly depicts this.
While the address allocations have flat lined, other factors such as prefix length distribution and unique prefix advertisements are driving the growth trend. In other words; de-aggregation of the IPv4 address space is driving this. In a nutshell, the IPv4 address space in the Internet routing table is becoming more fragmented. This is due to the lack of available large address block allocations; which leads to more unique and specific prefix lengths being advertised. This directly contributes to the continuing growth of the IPv4 table.
Now, back to the question of what’s so special about the 512k threshold? The simple answer is there are tons of routers deployed today that can only store 512k routes in their forwarding planes (ie., TCAM, FIB, etc). Some of these routers have been deployed many, many years ago. Some of these routers have been deployed more recently; however, they have been deployed or re-deployed into BGP peering roles without the necessary foresight regarding the growth of the Internet routing table. As the IPv4 table breaches this 512k threshold, these legacy routers can no longer add any additional prefixes and the result is a black-hole routing effect. In fact, some vendor gear handles this in a more disastrous manner – by crashing. Of course, I’m not talking about Brocade gear here! There have already been reports of such crashes occurring in the Internet.
Now the good news!
Brocade has been shipping line cards that support 1M IPv4 entries for many years now. Here is a data sheet of the industry’s first 2-port 100GbE module on the MLXe Internet scale routing platform that has been shipping for over 3 years. If the router is not intended to be involved with full BGP peering, hence there is no need for a module that can carry 1M IPv4 route entries, there are modules available that store 512k route entries. Customers must be sure that these modules will not be deployed in a scenario now or in the future where full BGP routing is required. A good example of this is in the data center as a core router. The standard data center architecture does not put the burden of full BGP routing (ie., Internet peering) on the data center core routers. The common practice is to deploy an Internet border router for this peering role, such as a Brocade MLXe with modules that support the 1M route entry capacity or a Brocade CER platform (that happens to support 1.5M IPv4 entries). The morale of that story is that the intended application of a router must be well planned and defined before any deployments. An operator should not assume that any router can be deployed into an Internet BGP peering role.
Now the better news!
Brocade is now shipping advanced Internet scale modules for the MLXe platform. We have doubled the IPv4 route table size to 2M IPv4 entries and practically quadrupled the IPv6 capacity to 800k entries. These modules are the 20x10GbE and 2x100GbE line cards and both are half-slot, line-rate modules with full feature support; including data plane programmability which is so important with the emerging SDN architecture.
With the capacity for 2M IPv4 route entries these modules will scale well into the future and continue to provide the investment protection you’ve come to expect from Brocade. The 800k IPv6 route table capacity also provides unparalleled investment protection, as the IPv6 route table also continues to grow. But more on IPv6 in a future blog …
I hope this clears up the question with the IPv4 route table growth trend and provides you with a clear path towards which products to deploy in critical BGP peering roles. As usual, please provide any comments or questions to this blog!