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: [email protected] [mailto:cisco-nsp- > [email protected]] On Behalf Of Jeff Bacon > Sent: Thursday, June 11, 2009 2:01 PM > To: [email protected] > 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 <[email protected]> > > To: Jo Rhett <[email protected]> > > Cc: [email protected] > > Subject: Re: [c-nsp] full routing table / provider-class chassis > > Message-ID: <[email protected]> > > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
