I've experienced and tried this only on the supV's. I would assume, however never tested to see the same results on the 4948 since they are pretty much identical from a os/platform standpoint. A good hint is if the 4948 will actually even LET you place "qos" commands on the port channel itself. If it will, I would apply them there too. Unless someone can tell this would actually hurt something. The 3560/750 won't let ya do it.
HTH, Nick Griffin On Wed, Mar 5, 2008 at 11:42 PM, Mike Louis <[EMAIL PROTECTED]> wrote: > Is the stripping particular to the 4500 chassis? Have you experience > similar results with the 4948 series as well? > > What supervisors did you experience this with on the 4500? > ________________________________________ > From: [EMAIL PROTECTED] [EMAIL PROTECTED] > On Behalf Of Nick Griffin [EMAIL PROTECTED] > Sent: Thursday, March 06, 2008 12:11 AM > To: Dan Letkeman > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] QOS Configuration Help > > Some other things to watch out for are your trunk links and port channels. > For example, on a 3750/3560 you would configure trust dscp on the physical > member interfaces not the port channel. If for example you have channels > on > a 4500 you should put the trust commands on both the port channel as well > as > the physical member interfaces. This has specifically caused me issues > with > removing markings in the past, the 4500 will strip it if you don't have it > on the port channel too. > > On Wed, Mar 5, 2008 at 6:20 PM, Dan Letkeman <[EMAIL PROTECTED]> > wrote: > > > 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: cisco-nsp@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 < > [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 cisco-nsp@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@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. > > > > > > > > > > > > > > _______________________________________________ > > > > cisco-nsp mailing list cisco-nsp@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@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. > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/