[c-nsp] service-policy on virtual interface
Randy McAnally
rsm at fast-serv.com
Wed Sep 9 08:17:37 EDT 2009
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 <td_miles at yahoo.com>
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>
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 <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/
------- End of Original Message -------
More information about the cisco-nsp
mailing list