Thank Tony. I knew I was going to have to dig into QoS further and you helped me a lot. My line cards are all 6724 units at the current time.
I have a spare 3750 laying around, assuming it has similar QoS features I'll plug away at it for a bit with some load generators. Cheers -- Randy www.FastServ.com ---------- Original Message ----------- From: Tony <[email protected]> To: Randy McAnally <[email protected]>, Ian MacKinnon <[email protected]>, "[email protected]" <[email protected]> Sent: Tue, 8 Sep 2009 17:02:51 -0700 (PDT) Subject: Re: [c-nsp] service-policy on virtual interface > Hi Randy, > > I remember the previous topic because I was the one who suggested > that you disable QOS globally (if you didn't need it) when you were > seeing throughput issues. I stand by this as the easiest solution at > the time, but now that you need to use QOS for something else, > you'll have to look at the queueing and work out what is happening > and how to fix it. > > If you don't classify any of your traffic the it will all be in the > default class (ie. DSCP & COS = 0) and go into the queue for this class. > > What happens depends on what hardware you have. As an example, if > you have a 6516-GE-TX card then the following happens you enable > QOS. If you run the command "show queueing int gigx/y" you will see > something like this: > > Default COS is 0 > Queueing Mode In Tx direction: mode-cos > Transmit queues [type = 1p2q2t]: > Queue Id Scheduling Num of thresholds > ----------------------------------------- > 1 WRR low 2 > 2 WRR high 2 > 3 Priority 1 > > WRR bandwidth ratios: 100[queue 1] 255[queue 2] > queue-limit ratios: 70[queue 1] 15[queue 2] 15[Pri > Queue]*same as Q2 > > queue random-detect-min-thresholds > ---------------------------------- > 1 40[1] 70[2] > 2 40[1] 70[2] > > queue random-detect-max-thresholds > ---------------------------------- > 1 70[1] 100[2] > 2 70[1] 100[2] > > queue thresh cos-map > --------------------------------------- > 1 1 0 1 > 1 2 2 3 > 2 1 4 6 > 2 2 7 > 3 1 5 > > From this we can see: > > Number of queues = 3 (2 normal/configurable + 1 priority) > Number of thresholds per queue = 2 thresholds (except PQ, which has > just 1) > > You can see from the COS-MAP (or maybe you can't) that COS 0 & 1 are > assigned to queue 1, threshold 1. The real problem is the random- > detect thresholds on the queue. What this means is that once the > queue gets full above the min-threshold the box will start random > throwing out packets (based on queue weightings and number of > packets in queues). When the queue gets above max-threshold then all > packets for this queue with the COS value will be dropped. This is > done to ensure there is some space in the queues for higher priority > packets. > > From the card above you can see that unclassified traffic (COS 0) > will start getting discarded at 40% and as the queue gets fuller it > will progressively discard more. If the queue gets to 70% then ALL > COS0 traffic will be discarded. In queue 1 this 30% at the top of > the queue is for COS 2 & 3 packets in threshold 2. > > This theoretically means that the maximum throughput you would see > on the above card with just enabling QOS and not configuring > anything is around 700Mbps (70% of 1Gbps). in reality it would > probably be a bit less, but that would be absolute maximum > > You can change this behaviour with the commands: > > wrr-queue random-detect min-threshold > wrr-queue random-detect max-threshold > > (you'll have to read the syntax for the commands, you need to put > queue and thresholds on them) > > I'm using this card as an example because I have one in a box I can > play with, you'll need to adjust it for your particular situation. > All of the above is for TX queues, you may also have to adjust the > RX queues. > > Now you can see why I previously said the easier option was just to > disable QOS ;) > > regards, > Tony. > > --- On Tue, 8/9/09, Randy McAnally <[email protected]> wrote: > > > From: Randy McAnally <[email protected]> > > Subject: Re: [c-nsp] service-policy on virtual interface > > To: "Randy McAnally" <[email protected]>, "Ian MacKinnon" <[email protected]>, "[email protected]" <[email protected]> > > Received: Tuesday, 8 September, 2009, 9:29 PM > > Thanks, I don't want to enable global > > QOS (queuing) which 'mls qos' will > > enable. The default queues cause all kinds of trouble > > with our traffic (you > > can see details in another topic I created couple months > > back). > > > > -- > > Randy > > www.FastServ.com > > > > ---------- Original Message ----------- > > From: "Randy McAnally" <[email protected]> > > To: Ian MacKinnon <[email protected]>, > > "[email protected]" > > <[email protected]> > > Sent: Tue, 8 Sep 2009 07:13:24 -0400 > > Subject: Re: [c-nsp] service-policy on virtual interface > > > > > By 'not classify' I meant all of our traffic is in the > > same default > > > class. Could you verify that 'mls qos' is not needed > > globally before > > > you can do 'mls qos vlan-based' on an interface? > > > > > > Cheers > > > > > > -- > > > Randy > > > > > > ---------- Original Message ----------- > > > From: Ian MacKinnon <[email protected]> > > > To: Randy McAnally <[email protected]>, > > "[email protected]" > > > <[email protected]> > > > Sent: Tue, 8 Sep 2009 16:05:57 +0100 > > > Subject: RE: [c-nsp] service-policy on virtual > > interface > > > > > > > Not seen problems turning on mls qos.. > > > > We have on the physicals :- > > > > Int gi1/1 > > > > mls qos vlan-based > > > > mls qos trust dscp > > > > and a typical service policy looks like :- > > > > policy-map 10MegPolice > > > > class class-default > > > > police 10000000 26000 32000 > > conform-action transmit > > exceed- > > > > action transmit > > violate-action drop > > > > > > > > what do you mean you don't classify? > > > > > > > > Ian > > > > > > > > -----Original Message----- > > > > From: Randy McAnally [mailto:[email protected]] > > > > Sent: 08 September 2009 11:54 > > > > To: Ian MacKinnon; [email protected] > > > > Subject: RE: [c-nsp] service-policy on virtual > > interface > > > > > > > > 6500 platform. > > > > > > > > Last time we had 'mls qos' enabled we had massive > > speed/packet loss issues > > > > with interfaces over 40% utilization since we > > don't classify traffic. > > > > > > > > Is there any possible issues you might see? > > > > > > > > -- > > > > Randy > > > > > > > > ---------- Original Message ----------- > > > > From: Ian MacKinnon <[email protected]> > > > > To: Randy McAnally <[email protected]>, > > "[email protected]" > > > > <[email protected]> > > > > Sent: Tue, 8 Sep 2009 15:44:57 +0100 > > > > Subject: RE: [c-nsp] service-policy on virtual > > interface > > > > > > > > > Hi Randy, > > > > > What platform? > > > > > On 6500/7600 the answer is yes, you need mls > > qos vlan-based on the > > > > > physical interfaces and then you can police > > on the SVI. > > > > > > > > > > Ian > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] > > [mailto:cisco-nsp- > > > > > [email protected]] > > On Behalf Of Randy McAnally Sent: 08 > > > > > September 2009 11:40 To: [email protected] > > Subject: [c-nsp] > > > > > service-policy on virtual interface > > > > > > > > > > Do the same commands work e.g. > > 'service-policy input/output > > > > > FooPolicy' at the virtual interface level > > the same as they do on a > > > > > physical port, both in and out? > > > > > > > > > > I'm trying to set up rate limiting 'further > > up the line' rather than > > > > > at the network edge, so we can pool customer > > bandwidth and keep > > > > > inbound floods of traffic from being passed > > beyond the distribution layer. > > > > > > > > > > -- > > > > > Randy > > > > > > > _______________________________________________ > > > > > cisco-nsp mailing list [email protected] > > > > > https://puck..nether.net/mailman/listinfo/cisco-nsp > > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > > > No virus found in this incoming message. > > > > > Checked by AVG - www.avg.com > > > > > > > > > > Version: 8.5.409 / Virus Database: > > 270.13.81/2350 - Release Date: > > > > > 09/07/09 18:03:00 > > > > > > > > > > -- > > > > > > > > > > This email and any files transmitted with it > > are confidential and intended > > > > > solely for the use of the individual or > > entity to whom they are addressed. > > > > > If you have received this email in error > > please notify the sender. > > > > > Any offers or quotation of service are > > subject to formal specification. > > > > > Errors and omissions excepted. Please > > note that any views or > > > > > opinions presented in this email are solely > > those of the author and > > > > > do not necessarily represent those of > > Lumison. Finally, the > > > > > recipient should check this email and any > > attachments for the > > > > > presence of viruses. Lumison accept no > > liability for any damage > > > > > caused by any virus transmitted by this > > email. > > > > ------- End of Original Message ------- > > __________________________________________________________________________________ > Get more done like never before with Yahoo!7 Mail. > Learn more: http://au.overview.mail.yahoo.com/ ------- End of Original Message ------- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
