[c-nsp] cisco-nsp Digest, Vol 79, Issue 37

[Matthew Huff]

input and output drops on the interface are the key (depending on
direction). Microbursting is a problem with the short term sustained rate
overflows the input or output hardware buffer. If the system can't dequeue
the packets faster enough the you will get tail drops. With a 6500/720-3BXL
the problem with microbursting is going to be in the linecard.

With a 67xx series linecard you shouldn't receive microbursting unless you
have a very congested fabric or are saturating the interface
With a 65xx series linecard it will depend on the rate. On an otherwise
normal utilization microbursting shouldn't be a big problem
With a 61xx,62xx, 63xx the buffers are pretty shallow, hence their
positioning as access linecards for end users

All this depends on hardware switching. If something is causing the packets
to be punted to the CPU, then microbursting drops can occur on any linecard.


----
Matthew Huff       | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139



> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jeff Bacon
> Sent: Thursday, June 11, 2009 2:01 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] cisco-nsp Digest, Vol 79, Issue 37
> 
> >
> > Message: 4
> > Date: Thu, 11 Jun 2009 15:41:24 +0200
> > From: Gert Doering <gert at greenie.muc.de>
> > To: Jo Rhett <jrhett at netconsonance.com>
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] full routing table / provider-class chassis
> > Message-ID: <20090611134124.GO290 at greenie.muc.de>
> > Content-Type: text/plain; charset="us-ascii"
> >
> >
> > (Yes, caveats apply.  With LAN hardware, you always have issues with
> > microbursts and buffering.  But ES/CRS - or Juniper - hardware is
> LOTS
> > of extra money.)
> >
> > gert
> >
> 
> So is there a good way to watch/track microbursts? I don't care if it
> buffers, but in our environment (lot of market data) we suffer from
> a) regular microbursts (micro meaning in the 1s or less timeframe)
> b) no really good way to measure or capture them short of putting
> packet
> sniffers on lines and sorting through packet dumps ex-post-facto.
> 
> We're using 6500/720-3BXL hardware but could buy other hardware (though
> I imagine that's not the problem). Traffic comes in over gig fiber or
> various metro-e, NYC metro area.
> 
> Our general answer is "throw more bandwidth at the problem" - which is
> fine; the problem is knowing _when_ we need to, short of finding out
> from end-users.
> 
> -bacon
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4229 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090611/0f636d9e/attachment-0001.bin>