[c-nsp] QOS Configuration Help
Dan Letkeman
danletkeman at gmail.com
Wed Mar 5 22:10:06 EST 2008
Mike,
Makes perfect sense....and actually seems more simple than what I was
trying to do!
Thanks for the detailed explanation.
Dan.
On Wed, Mar 5, 2008 at 6:26 PM, Mike Louis <MLouis at nwnit.com> wrote:
> You don't need to use the service policy input unless you are trying to remark the traffic on the host side. The codec is probably marking DSCP correctly, remove the service policy and go with the mls qos trust dscp command on the port
>
> Use the mls qos map statements indicated previously for cos-dscp and cos-ipprec
> Others are related to queues and buffer sizes and thresholds for wred
>
> Then launch the video session and do show mls qos interface x/x statistics command on the interface with the codec. If you see counters in fields other than the first row, indicating no dcsp marking, for instance if you see incrementing fields in the 32 or 41 ranges then you are good. This means that DSCP of 41 (natural for most video conferencing) is working. You might see DSCP 32 (IP PREC 4) as well if the codec only supports first 3 bits of the TOS field.
>
> With this information in hand you should be able to tell if you trusting is setup correctly on the port. The port srr-queue configurations will not affect this. The maps will specify what values to map dscp-ipprec or cos-ipprec or cos-dscp in the packet and thus what queue that field will correspond to. You can see what queue your DSCP values are mapping to with the show mls qos maps dscp-cos or dscp-xxx commands. These will show you the corresponding queue that the markings are mapping to. Important for setting up queue weights, etc.
>
> Next you can move on to the trunk link. If the packet is being received with the correct value on the access port the switch will use that value to map it to the corresponding queue on the output interface of the switch (which is most likely a trunk). If that packet is being placed on a vlan on the trunk other than the native vlan the DSCP field in the packet will determine what COS value is marked in the User field of the 802.1q header. Thus determining what the receiving switch will receive and should trust.
>
> So moving on from there you can see that you are placing the packet on the output interface and transmitting it to the upstream switch without a 802.1q header so you need not worry about trusting the COS. You will want the upstream switch to trust the DSCP value of the incoming packet on the native vlan since you marked it on the outbound queue when you sent it from the downstream switch along the trunk. If the trust statement is not present on the upstream receiving switch, and that interface is a trunk, the command mls qos trust cos will force the DSCP value in the packet to be ignored. This is where you can use a service policy to trust or deny the dscp value if you are using the mls qos trust cos command to trust or rewrite the dscp value in packets received but in that case you just would be better off trusting the DSCP value or rewriting it and ignoring the trust cos command entirely. This is a common scenario, mls qos trust dscp on trunk ports and then use dscp-mutation or service policies to modify the value. 2960/3560/3750 switches forward internally based on DSCP values not COS values anyways. So its better to stick with DSCP value when possible. COS are trusted and mapped to DSCP tables for outbound queue determination where maps, if a trunk, can also rewrite the COS value if necessary.
>
> Anyways, once you successfully sent the packet upstream you will have an accurate DSCP marked in the packet, trusted at the inbound switch, and then placed into the appropriate queue based on the DSCP of the trusted packet. The reverse is true for return traffic.
>
> So trust DSCP all around, remove service policies unless you need them to remark traffic, and make sure you queue and maps are setup properly on the interface and globally to ensure the packets are placed in the correct queue with the correct amount of queue weight and you are good.
>
> Remember, as long as you have plenty of bandwidth, your video traffic will respond very well. You are going to have to introduce congestion into the links before you will see whether your QOS is working or not. This can be difficult in 100mbps circuits but can certainly be done.
>
> Hope that long winded explanation was somewhat helpful and not too confusing
>
> mike
>
>
>
> -----Original Message-----
> From: Dan Letkeman [mailto:danletkeman at gmail.com]
> Sent: Wednesday, March 05, 2008 6:21 PM
> To: Mike Louis; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] QOS Configuration Help
>
> Ok, that would explain some of my problems. But my main question is
> why won't the 2960 get a match on the ACL? I even changed the ACL to
> "permit ip any any" and it still didn't get a match. Without that acl
> getting a match nothing will work.
>
>
> On Wed, Mar 5, 2008 at 4:59 PM, Mike Louis <MLouis at nwnit.com> wrote:
> > Also, native vlan will not have a cos value on the trunk link. You will have to trust DSCP on that link to have it match the dscp setting from the downstream switch since native is passed w/o dot1q header
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick Griffin
> > Sent: Wednesday, March 05, 2008 5:46 PM
> > To: Dan Letkeman
> >
> >
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] QOS Configuration Help
> >
> > I'm pretty certain you will not get output on this information based on the
> > qos works on these devices, specifically the 3560/3750. The best way to
> > check this stuff out from what I've seen on the CLI is "show mls qos
> > interface x/y statistics". This will give you an idea of the DSCP values
> > coming into and leaving the particular interface. Make sure your dscp/cos to
> > queue mappings are configured the way you want, ie what dscp value maps to
> > which queue. Priority queue on the 3560 is by default 1 on the 3560, not
> > sure on the 2960.
> >
> > On Wed, Mar 5, 2008 at 4:32 PM, Dan Letkeman <danletkeman at gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I am in the process of configuring QOS for our video system.
> > > Currently I'm having trouble configuring our 2960's with srr queuing.
> > > I have not yet tackled the 3560's.
> > >
> > > Here is the config I'm working with, there are more 3560's and 2960's,
> > > but this should give an idea on how I have configured them:
> > >
> > > 3560:
> > >
> > > class-map match-any VIDEO
> > > match access-group name POLYCOM
> > > !
> > > policy-map in
> > > class VIDEO
> > > set dscp af41
> > > !
> > > interface FastEthernet0/24
> > > description test trunk to 2960
> > > switchport trunk encapsulation dot1q
> > > switchport trunk native vlan 500
> > > switchport trunk allowed vlan 500
> > > switchport mode trunk
> > > srr-queue bandwidth share 10 10 60 20
> > > srr-queue bandwidth shape 10 0 0 0
> > > srr-queue bandwidth limit 20
> > > priority-queue out
> > > mls qos trust cos
> > > spanning-tree portfast
> > > !
> > > ip access-list extended POLYCOM
> > > permit ip host 192.168.50.12 any
> > >
> > >
> > > 2960:
> > >
> > > class-map match-any VIDEO
> > > match access-group name POLYCOM
> > > !
> > > policy-map in
> > > class VIDEO
> > > set precedence 4
> > > !
> > > interface FastEthernet0/1
> > > description - Codec plugged in here
> > > switchport access vlan 500
> > > switchport mode access
> > > ip access-group POLYCOM in
> > > srr-queue bandwidth share 10 10 60 20
> > > srr-queue bandwidth shape 10 0 0 0
> > > auto qos voip trust
> > > spanning-tree portfast trunk
> > > service-policy input in
> > >
> > > interface FastEthernet0/24
> > > description - trunk to 3560
> > > switchport trunk native vlan 500
> > > switchport trunk allowed vlan 500
> > > switchport mode trunk
> > > srr-queue bandwidth share 10 10 60 20
> > > srr-queue bandwidth shape 10 0 0 0
> > > srr-queue bandwidth limit 35
> > > priority-queue out
> > > auto qos voip trust
> > > spanning-tree portfast trunk
> > >
> > > ip access-list extended POLYCOM
> > > permit ip host 192.168.50.12 any
> > >
> > > I'm not exactly sure what is happening, but i'm not getting any hits
> > > on the acl's. The Codec is 192.168.50.12, the trunk's are all
> > > working, and the network is working fine.
> > >
> > > Is there something i'm missing?
> > >
> > > Thanks,
> > > Dan.
> > > _______________________________________________
> > > 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/
> > >
> > _______________________________________________
> > 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/
> >
> >
> >
> >
> > Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately.
> >
> >
>
>
> Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately.
>
>
More information about the cisco-nsp
mailing list