Route table growth and hardware limits...talk to the filter

Fri Sep 21 20:18:14 UTC 2007

I think one of the points here is that we've gotten beyond the space 
where two uplinks was "good enough" for virtually all cases and that 
either uplink was "good enough" provided it is up. And "up" was a binary 
state rather than an array of binary states with associated keys defined 
by destinations.

More explicitly, I think those using MSFC2s to take full routes are 
largely saying "hey, we know what we are doing and why." and "Cisco 
should have redesigned their boards to support more routes earlier"-- so 
items like the SUP32 would have a 3BXL option and the like.

 From the folks on here who are saying using a default or aggressive 
route filtering isn't sufficient are also implying they have more than 2 
views of the Internet... in many cases many more than 2 transit views, 
and possibly peers as well.

Certain snobbery aside ("Anyone who needs a M7i doesn't need a full 
routing table") seems uncalled for. I am not going to comment on J's 
line up, but a M7i should be able to route 3-4Gb/s to a full table 
without sweating too hard over a handful of interfaces. How many people 
are routing 3-4 Gb/s to the Internet and don't have at least several 
uplinks and LOTS of customers that would get *exceptionally* pissed off 
at less than ideal routing or routing holes (in this case defined as a 
default to a provider that has a hole)?

The Cisco 6500/7600 line is amazingly stable and supports a ridiculously 
high number of 1GE ethernet and 10GE ethernet L3 ports mated to a 
Cisco<tm> BGP talker. Yes, in the majority, the ports have small 
interface buffers. Therefore, these are best suited at interfaces 
between other networks over low-latency intra-building or metro-area 
cross-connects rather than large-latency international circuits. I 
suspect that is where the majority are being operated.

If you need a router to talk to your >40ms interfaces, its not for you. 
If you like to mix and match a lot of media in your router, its not for 
you. If you have gotten rid of most of that SONET-speed craziness (OC3, 
OC12, OC48) in your core --even if that just means upgrading to Nx10GE 
everywhere, and everything has started looking like ethernet, they are 
exceptionally tasty.

As an operator of such a successful series of equipment that has had a 
surprisingly long set of legs, I think I would be more impressed if 
Cisco had a board that had dramatically greater routing capabilities 
(not just speed, but table size) than the 3BXL. Or if Cisco demonstrated 
that it understands where these boxes are being used and they all aren't 
deployed in super-high-density PoE applications or on high-latency 
overseas interfaces.

But that is neither here nor there. The idea of how to filter has been 
brought up, in fact, someone posted an actively worked-on filter for 
US-centric providers that provide some immediate relief. The idea of a 
code improvement that gives MSFC2s a more graceful fail pattern has been 
brought up by Lincoln c/o Cisco.

So far, nobody has spoken of a Cisco plan to provide a SUP32-3BXL or 
similar board for immediate relief of the problem -- so either the NDA 
has no leaks or its not going to happen in the next few months of 
operational planning.

Speculation about the alternative platforms (from C or J) is fair game. 
I suspect J is trying to upsell lots of people from 6500s and 7600s and 
is realizing that lots of 6500/7600 users don't see the point of paying 
$7,000 per GigE interface no matter how many bells and whistles one can 
turn on at the same time. C isn't worried about many defections, nor 
should it be -- no one has a competing box with the same kind of 
reputation for ethernet density/stability at the price point. I suspect 
whoever owns the product line at C is going to get a big bonus this year 
while he/she struggles to justify why they need to keep increasing the 
routing capabilities beyond the Sup720-3BXL, at least for the 6500.

This is longer than I had intended. Hopefully something in it is 
operational.

Deepak Jain
AiNET