[c-nsp] service-policy on virtual interface

[Ian MacKinnon]

I <think> it is required, not 100% sure.

Our policers are just using the default class, but I think by default it will then use different queues on the actual hardware.

In my understanding the policing and queuing is completely separate.

Ian

-----Original Message-----
From: Randy McAnally [mailto:rsm at fast-serv.com]
Sent: 08 September 2009 12:13
To: Ian MacKinnon; cisco-nsp at puck.nether.net
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 -------
>
> 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 -------


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.