[c-nsp] QOS Configuration Help
Nick Griffin
nick.jon.griffin at gmail.com
Thu Mar 6 15:54:23 EST 2008
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 <MLouis at nwnit.com> 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: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net]
> On Behalf Of Nick Griffin [nick.jon.griffin at gmail.com]
> Sent: Thursday, March 06, 2008 12:11 AM
> To: Dan Letkeman
> Cc: cisco-nsp at 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 <danletkeman at gmail.com>
> 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 <nick.jon.griffin at gmail.com
> >
> > 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 <danletkeman at gmail.com>
> > 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 <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.
> > > > >
> > > > >
> > > > _______________________________________________
> > > > 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.
>
>
More information about the cisco-nsp
mailing list