The Internet routing table size has continued to grow steadily. In 2008 we reached 256K routes and now the table has exceed 512K Routes. This is of significance for customers running some of the older PFC3 based Supervisor 720 engines on the 6500 and 7600 switches.
On the Catalyst 6500 and 7600 Series platforms, all of the routing information is stored in special high-speed memory called TCAM. Read More »
I was interviewed recently for an article in Tweakers. It’s a good article, but I think a shade of meaning was lost in translation between Dutch and English. Hence, I’d like to restate the article in my own words.
The nuance of meaning revolves around the words “danger”, “threat”, and “crisis”. Joost opened the interview asking me whether I thought that IPv4 depletion presented a threat, and whether the Internet was in danger. I replied that there was a crisis, but not a threat.
What if your mobile device allowed you the freedom to seamlessly roam across any network in the world, regardless of location or operator and with all the attributes you would expect, security or privacy… With LISPmob, we may have gotten a giant step closer as we open sourced a network stack for network mobility on Linux platforms, an implementation of basic LISP mobile node functionalities.
Imagine how “happy” your eyeballs would become when you realize that your Internet connection failover time was drastically reduced from a full minute to less than half a second, Dan Wing and Andrew Yourtchenko of Cisco developed a methodology to do just that.
The Internet is changing. Network operators and content providers are beginning the widespread global deployment of IPv6, while keeping IPv4 up and running until IPv6 is ready to take over. Dan and Andrew have contributed to the cause of easing the adoption of IPv6 by documenting a methodology that will enable client applications to react more responsively in dual-stack failure scenarios by aggressively rectifying intermittent access issues and therefore preserve the end user experience for dual-stack IPv4 and IPv6 devices. This solution is documented in their IETF draft, cleverly named Happy Eyeballs. It is designed to keep the eyeballs of a computer end user “happy” in the face of problems that may exist when a host is attempting to establish IPv4 or IPv6 connectivity. The IETF draft document describes how client applications should behave when establishing IPv6 and IPv4 connectivity simultaneously, preferring IPv6 if the connectivity is successful, and disconnecting any remaining redundant (IPv4 / TCP) connections. By failing over quickly from IPv6 to IPv4, or from IPv4 to IPv6, the user is not affected by problems that occur in only one of the two IP versions in a dual-stack deployment. This can greatly reduce the connection times in problematic situations -- from minutes to milliseconds, compared to the typical behavior in many implementations today.
In anticipation of World Ipv6 Day, Google Chrome has adopted a similar approach to what Dan and Andrew have documented, under the somewhat less light-hearted name “IPv4-Fallback”. This modification promises to ease potential trouble spots on World IPv6 Day, as well as future browser interactions with dual-stack network configurations. Google’s Internet browser, Chrome 11, uses a “hybrid” variation of Happy Eyeballs that is responsible for establishing, monitoring, and management of simultaneous parallel IP connections. This software enhancement produces significant results by reducing the fallback latency of a problematic IPv6 connection from between 20 and 75 seconds as is often seen today, to as little as 300 milliseconds.
One interesting observation I’ve seen is how something as obtuse and techie as IPv6 has generated so much interest in the main stream press - such as this article at the Wall Street Journal, Web Running Out of Addresses. Even my mother asked me about it on the phone last night “will the internets shut down?” No way mom…we’ve got that covered. The Internet will be Preserved, Prepared, and then Prosper!