[c-nsp] service-policy on virtual interface
Tony
td_miles at yahoo.com
Tue Sep 8 20:02:51 EDT 2009
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 <rsm at fast-serv.com> wrote:
> From: Randy McAnally <rsm at fast-serv.com>
> Subject: Re: [c-nsp] service-policy on virtual interface
> To: "Randy McAnally" <rsm at fast-serv.com>, "Ian MacKinnon" <Ian.Mackinnon at lumison.net>, "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> 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" <rsm at fast-serv.com>
> To: Ian MacKinnon <Ian.Mackinnon at lumison.net>,
> "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> 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 <Ian.Mackinnon at lumison.net>
> > To: Randy McAnally <rsm at fast-serv.com>,
> "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > 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:rsm at fast-serv.com]
> > > Sent: 08 September 2009 11:54
> > > To: Ian MacKinnon; cisco-nsp at puck.nether.net
> > > 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 <Ian.Mackinnon at lumison.net>
> > > To: Randy McAnally <rsm at fast-serv.com>,
> "cisco-nsp at puck.nether.net"
> > > <cisco-nsp at puck.nether.net>
> > > 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: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-
> > > > bounces at puck.nether..net]
> On Behalf Of Randy McAnally Sent: 08
> > > > September 2009 11:40 To: cisco-nsp at puck.nether.net
> 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 cisco-nsp at puck.nether.net
> > > > 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/
More information about the cisco-nsp
mailing list