|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Route table growth and hardware limits...talk to the filter
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
|