marking DSCP on ingress ports

I have been playing with QOS lately but I am not sure how the mls qos cos-dscp map works. and how to mark ingress packes with DSCP.

I was playing with the Ethernet switch in GNS3 which is basically a 3725router with a 16 FE module.

when I go to configure QOS on the incoming port I only seem to be able to trust/set COS, So I can set COS markings here and then use a policy map to classify the data and set DSCP values on the out going interface.

But where does the cos-DSCP mapping come in?

I thought if I apply the

#mls qos trust cos

to a port then it will apply also the COS_DSCP mapping and tag packets with a DSCP value based on there COS marking?

but if I have

#mls qos trust cos
#mls qos cos 3

I thought that would mean the COS value would be set to 3 and the DSCP value would be what ever is in the mapping? But when try applying a policy map to the outgoing upstream interface with a class map that captures DSCP 26 (as per my map) it does not see any traffic? I can get what I expect using classmaps to capture based on COS and then set the DSCP manually, but I expected the maps to do this all for me.

Find more posts tagged with

Comments

RouteMyPacket

Where is your service-policy? That is what should be configured on the interface. Service policy should reference your Policy Map thereby taking action on the configured interface

Attach a running-config snippit as well, Voice peeps live and breath QoS but i'm decent with it.

networker050184

What does a 'show mls qos interface x/x' show for the interface in question? Are these tagged packets coming in? Do they already have a CoS set? I'm assuming you changed your default map? I think you are hitting some kind of order of operations here, but it's been a while since I've dug into this.

DevilWAH

networker050184 wrote: »

What does a 'show mls qos interface x/x' show for the interface in question? Are these tagged packets coming in? Do they already have a CoS set? I'm assuming you changed your default map? I think you are hitting some kind of order of operations here, but it's been a while since I've dug into this.

This is just in a GNS 3 lab so packets are arriving a interface unmarked, I know this is not hing like a real world situation but I often find trying something of the normaly track teaches you mroe about something than setting it up by the book.

Switch_1#sh mls qos interface f1/15
FastEthernet1/15
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 6
pass-through: none

Cos-dscp map:
cos: 0 1 2 3 4 5 6 7

dscp: 0 10 18 26 34 46 48 56

and I have Switch1(really router with 16 port FE) ---->router1

host is connected to port f1/15 and uplink to router is port f0/0

So what I did is have the running config on f1/15 as

switchport priority default 6 mls qos cos 6
 mls qos trust cos
end

and on int f0/0


interface FastEthernet0/0
 ip address 10.30.30.2 255.255.255.0
 speed 100
 full-duplex
 auto discovery qos
 service-policy output Mark


 Policy Map Mark
    Class COS6
    Class All
      set dscp af41

Class Map match-all COS6 (id 3)
   Match   dscp cs6 (4[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif[/IMG]

A bit messy I know but the idea was that f1/15 would tag all incoming packets as COS6 the map would translate this and DSCP filed would become 48. and then the out going policy would be able to classify them.

I cant use a class map that matches on COS on the routed interface as its not a dot1q port. So I am curious at what point in the process is the DSCP marking mapped from the COS. IE can I mark the traffic explicitly on the layer 2 interface as it comes in to the switch, and get it to write the DSCP field also with out a policy-map?

networker050184

Have you tried turning trust off?

DevilWAH

yep

tried a few variations.

networker050184

I'd guess this is something with the NM because I think this would work with a 3560 for example though I am a bit rusty on my L2 QoS. Only other thing I'd say to try is enabling override.

DevilWAH

Coming back to this, does any one run Policy based QOS on the 6500?

I have set up a policy to match classes based on AL's

Policy Map QOS-Markings
Class Lync-ef
set dscp ef
Class Lync-af41
set dscp af41

each class simple matches a single ACL for IP/port ranges

And I have applied this outgoing to a vlan interface

conf t
int vlan 1001
service-policy outgoing QOS-Markings

But when I #show policy-map int vlan 1001

all i see is

Service-policy output: QOS-Markings

    class-map: Lync-ef (match-all)
      Match: access-group name Lync-Voice
      set dscp 46:
      Earl in switch 1, slot 5 :
        596 bytes
        5 minute offered rate 16 bps
        aggregate-forwarded 596 bytes
      Earl in switch 2, slot 5 :
        0 bytes
        5 minute offered rate 0 bps
        aggregate-forwarded 0 bytes


    class-map: Lync-af41 (match-all)
      Match: access-group name Lync-Video
      set dscp 34:
      Earl in switch 1, slot 5 :
        0 bytes
        5 minute offered rate 0 bps
        aggregate-forwarded 0 bytes
      Earl in switch 2, slot 5 :
        0 bytes
        5 minute offered rate 0 bps
        aggregate-forwarded 0 bytes


    Class-map: class-default (match-any)
      55 packets, 5427 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
        55 packets, 5427 bytes
        5 minute rate 0 bps

But I know this interface is the uplink to the external router so has tons of traffic, even if the main classes where incorrectly configured I would expect to see the class default showing traffic. (this was after about 10 min)

What's going on, why is traffic not hitting the policy map? I assume its to do with hardware switching, but all the documentation i read just says create the policy as you normaly would and apply to interface?

Dieg0M

What are your class-map's matching? If it's an ACL, are you getting hits on this ACL?

deth1k

you should really mark traffic inbound, also 6500 being hardware platform counters aren't "real" time.

DevilWAH

Dieg0M wrote: »

What are your class-map's matching? If it's an ACL, are you getting hits on this ACL?

nope no real matches, I know these should be hit as doing an capture on the interface I can see traffic in these ranges. Also I don't see why the class defualt would not be seeing traffic.

as you can see the packet rate on the interface is quite high.

5 minute input rate 30253000 bits/sec, 3807 packets/sec
5 minute output rate 21952000 bits/sec, 3235 packets/sec

Extended IP access list Lync-Video 
    5 deny ip any host 149.1.1.67 (86 matches)
    10 permit udp any 149.1.1.0 0.0.1.255 range 20040 20079
    20 permit tcp any 149.1.1.0 0.0.1.255 range 20040 20079

Extended IP access list Lync-Voice 
    10 deny ip any host 149.1.1.67 (86 matches)
    20 permit tcp any 149.1.1.0 0.0.1.255 range 20000 20039
    30 permit udp any 149.1.1.0 0.0.1.255 range 20000 20039 (32 matches)

DevilWAH

I don't want to mark it inbound, as by marking it at this point at am marking it after it has been router and at a single point so rather than policy on multiply interface that are 1Gb/s and included traffic I am not interested in looking at. by marking outbound on this vlan interface I am only going to be applying the policy to a single 100mb/s link.

Dieg0M

Give us TCP **** or a .pcap and we can tell you why your ACL's are not matching traffic.

DevilWAH

I can assure you the middle octes match the access list, and the capture has about 2000 packets in it. Also these are marked with DSCP values not by the policy but elsewhere in the network as traffic is coming from switches that honour QOS markings. The policy is actualy for areas of the network that have switches that can't mark and have o pass there data through this choke point.

capture.jpg

Dieg0M

In that packet capture, I don't see any packets matching

10 permit udp any 149.1.1.0 0.0.1.255 range 20040 20079
20 permit tcp any 149.1.1.0 0.0.1.255 range 20040 20079
or 20 permit tcp any 149.1.1.0 0.0.1.255 range 20000 20039

You see ACL hit logs for the packets shown in the packet capture.

DevilWAH

sorry if you see the same access list at the other end of the list it has about 50,000 hits and across all statements, the capture output I shows was only a tiny fraction of the traffic.

in the end i work it back to the fact I was mixing legacy interface queuing commands with policy-maps. auto qos seems to have applied the command
"platform qos queuing-only"

Once i removed this and changed all the config to use "policy-map type lan-queuing" for queuing the marking started to work as expected. Seems mixing them can get confusing.

Cheers for the ideas

Dieg0M

Ah yes, AutoQoS will disable DSCP/CoS remarks if the autoqos command is there. For the 6500 the command is different but still does the same. I guess we should of asked for full configs. This still does not explain why ACL's were not getting hits for the Video traffic. Did you figure that one out too?

DevilWAH

Only in a round about way,

I removed the policy-map and tried to reapply it, at which point i got an error telling me I could not until i removed the "platform qos queuing-only" global command.

once I disabled that and reapplied the policy it worked.. So i assume I had applied the marking policy first, then applied QOS and that stopped the marking policy being applied although it still showed under config, but as it was not a suported configuration it was not matching aginst the ACL's.

I now see both matches and queuing working as I would expect.