Thanks Nick. That does make sense. I have a polycom vsx 6000 that is marking the packets already. So what you are saying is I shouldn't need to have an acl to match the traffic if the port is setup properly because the device is tagging the traffic with the correct values. I will try wireshark and see what It comes up with.
Dan. On Wed, Mar 5, 2008 at 5:46 PM, Nick Griffin <[EMAIL PROTECTED]> wrote: > Well that depends, if your doing the trust dscp on the port facing the video > server, as well as your interconnects and your video application is tagging > dscp values appropriately, then you don't need an acl for classification as > it's already classified by the application itself. It's not that the ACL is > NOT working, it's that the CLI output will not show it because of the way > these switches devices perform qos. You won't get the output you would > expect from a router. The best thing to do to get your head around it is to > grab some test equipment and a packet sniffer and capture some packets, > change some things and see how it works. Also, have a gander at End to End > QoS network design. > > HTH, > > Nick Griffin > > > > On Wed, Mar 5, 2008 at 5:20 PM, Dan Letkeman <[EMAIL PROTECTED]> wrote: > > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nick Griffin > > > Sent: Wednesday, March 05, 2008 5:46 PM > > > To: Dan Letkeman > > > > > > > > > Cc: [email protected] > > > 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 <[EMAIL PROTECTED]> > 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 [email protected] > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > _______________________________________________ > > > cisco-nsp mailing list [email protected] > > > 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. > > > > > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
