Aging hardware, IPv6 and the growing route table

I’ve blathered on about BGP forever.  Say what you will about the venerable protocol, it runs the interwebs, is reliable, extendable and well documented.  I’ve also espoused ad nauseam about IPv6, so none of this [admitted] rant should really be a surprise coming from me.

As of 8/12/2014, according to the CIRD report (and many mailing lists), the default free global ipv4 routing table has reached 512k routes.  This is a milestone from many perspectives, but more importantly, it solidifies the fact that there is a great deal of equipment in critical points in the internet that is out of date and cannot perform as intended in its current configuration or function.


This is a problem.  This is a problem for old hardware.  This is a problem for anyone that says their border router is “good enough”, and expects to take a default free table.  It’s a problem for anyone that wants to be multihomed on sub-par hardware.  I don’t think that many engineers would be surprised at how common this really is because network hardware is expensive, especially appropriate hardware that runs at site borders and in internet backbones, and by nature network engineer want to “make things work”.  I assert, however, that this may not be the best idea.

The increased size of the default free zone has been forecasted for years, and with the inclusion of the 16k of ipv6 prefixes (you are running IPv6, right?), resources quickly become exhausted on aging hardware.  This causes a cascading problem.  Forget the odd issues seen by not having enough TCAM to house the entire default free ipv4 table.  That problem is a haymaker swing that was telegraphed long ago and should have been coming; that ship has sailed.

The bigger problem is that in flurrying around to deal with smaller TCAM sizes on gear that should have been replaced years ago, one course of action is to  repartition the TCAM, stripping away space allocated for IPv6 and allocating it to IPv4 in order to remain “default free” v4 tables.  I know because I’ve had to do this.  And it sucked. Personally, I felt a little like a sell out since I was robbing Peter to pay Paul and keep our “beloved” IPv4 running at the expense of the protocol we should have been migrated to years before but could not due to fear, uncertainty, doubt and, frankly, sheer laziness on the part of executives, developers, vendors and engineers. Blech.  I don not even like typing that.  We, I promise you,  in come cases are prolonging the deployment of IPv6 in favor of keeping v4 working due to this limitation.  And it stinks.  Like a skunk. Dipped in sewage. Wrapped in garbage.  Blown through an onion.

It’s a banner day, make no mistake.  512k ipv4 routes in the global default free ipv4 table is a milestone.  However, lets not forget that much of the pain involved in expanding the ability to use more v4 would probably have been better served in expanding ipv6 support.  Be a catalyst for change and start learning and evangelizing IPv6.

I often have a thought when discussing the merits of ipv6 with anyone that is arguing as to why they don’t want or need to deploy it:

Would the internet/their network be a better place if we spent as much time making ipv6 work instead of going well out of our way to work around it?

<end rant> =)




  1. “I would like to say that it will help the adoption of IPv6, because it may bring some attention to the fact that IPv4 addresses are being exhausted, but IPv6 has completely failed to take off,” Cowie said. “If anything, it really shows you that IPv4 has really never been healthier.”
    I’d like to think that this is a true statement, but history has shown that people only try to prolong the inevitable IPv6 deployment. If we worked half as hard at rolling out IPv6 as we did trying to work around it we would have been done years ago. “Never been healthier” is a relative statement, too, I think I could argue that the opposite of “healthy” as a descriptor for IPv4. “In use” yes.

© 2019 The Forwarding Plane. All rights reserved.

Copyright 2016 Nick Buraglio, ForwardingPlane, LLC

%d bloggers like this: