[c-nsp] 6500 SUP720 High Latency and Jitter issues

[Gert Doering]

Hi,

On Wed, May 25, 2005 at 06:39:44PM -0400, Jared Mauch wrote:
> On Wed, May 25, 2005 at 11:26:54PM +0200, Gert Doering wrote:
> > On Wed, May 25, 2005 at 12:27:26PM -0700, Tim Stevenson wrote:
> > > Ah - you can't use the same IP (same loopback) for all your tunnels, you 
> > > have to use unqiue IPs to terminate the tunnels.
> > 
> > I would find it enormously useful if IOS issued a warning if you
> > configure something that will be "perfectly fine" on other platforms,
> > but will drop the box to software switching on the Sup720...
> 
> 	I actually disagree with this, this is part of knowing your
> platform.  

Oh well.  I understand about "knowing my platform", but things like 
*this* are just too surprising to be aware of - and it's quite hard to 
keep up-to-date which features on what platform (using which IOS) have 
"interesting strings" attached - like "not being CEF switched" or 
"only being central-CEF switched".

> The '76k' (i've renamed it since it's confusing to have the
> 7600/6500 name, i encourage everyone to call it by this name :) is a software
> based platform, with 'mls' hardware assist for some features.  If
> you add a distributed linecard, they will be handled in the linecard
> (in most cases) that can be seen by doing a 'sh cef line' to know what
> slots are likely to be hardware switched.

"sh cef line" will tell you what slots have the potential to do hardware
forwarding, but not if you have enabled a feature that happens to break
MLS for a specific interface (or specific packets *on* that interface)
on the line card.

Even regarding this, the 76k has "more levels" of interesting switching
paths - distributed, hardware assisted on the Sup720, software CEF, and
pure process switched (if I understand that right).

> 	This is similar to the 7500, where if you had a VIP linecard,
> packets would (if configured for dcef) be handled in a distributed
> fashion, but with older linecards, it would be handled on the RP.

Sure, no objection here.

> > Or, as people have already asked for, a way to figure out "*why* is this
> > packet being process switched" - the current output isn't fine-grained
> > enough to really know what a box with lots of different features 
> > enabled is really doing to *what* packets.
> 
> 	This is a seperate argument.  Knowing why a platform is doing something
> is in part knowing the equipment that you own/operate.  I can understand
> some of a learning curve if you acquired someone or got stuck with
> some hardware, or make some major changes to your network, but this
> is part of the cost of not knowing your hardware.

I don't buy this.  Judging from this list alone, there's hardly anyone
running *any* IOS platform that really knows why the platform is doing
all the things the way it does (as a simple example I could mention
various generations of counter bugs - some of which could be nicely
explained by switching paths, others just didn't follow any logic).

> 	Perhaps if vendors are not properly documenting this,
> a forum can be created that provides accurate matrix of features
> instead of the 'marketing' data that is always touted.. 

I agree, this would also be useful - having a full list of available
features in IOS with a documentation on which combinations of Supervisor
and line card it will be switched in what path.  And what circumstances
(like "only one tunnel per local IP") will make it fall to another path.

Sounds a bit unpractical to me, though.  The feature list in IOS is LONG
(and constantly growing), and the hardware support is changing over time 
- due to new hardware coming out, or new IOS versions supporting different 
things.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de