cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2830
Views
0
Helpful
15
Replies

service-policy input doesn't work

mats.brynolf
Level 1
Level 1

I have a question about port-based QoS on a layer 3 interface.

I can't seem to get this working correctly so any suggestions would be helpful.

We wan't to mark all incoming traffic on our 6504/sup720 (g3/1) and then trust the traffic going through our core. For some reason it dosen't seem to work when we use the service-policy input command on the incoming interface. However, when we apply the service-policy command on the egress interface and user service-policy output it works.

This is how the configuration looks like;

interface GigabitEthernet3/1

ip address x.x.x.x x.x.x.x

ip access-group 135 in

ip pim bsr-border

ip pim sparse-mode

ip multicast boundary 50

wrr-queue bandwidth percent 65 20 15

wrr-queue queue-limit 40 30 10

wrr-queue random-detect min-threshold 1 75 90 95 95 95 95 100 100

wrr-queue random-detect min-threshold 2 80 85 90 95 95 95 95 95

wrr-queue random-detect min-threshold 3 100 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 1 95 95 98 99 99 99 100 100

wrr-queue random-detect max-threshold 2 95 97 98 99 99 99 100 100

wrr-queue cos-map 1 7 1

wrr-queue cos-map 1 8 4

wrr-queue cos-map 2 2 2

wrr-queue cos-map 3 1 6

wrr-queue cos-map 3 2 7

wrr-queue cos-map 3 8 3

flowcontrol send off

service-policy input iptv-qos-map

!

policy-map iptv-qos-map

class iptv-class

set dscp 32

!

class-map match-any iptv-class

match access-group name iptv-acl

!

ip access-list extended iptv-acl

permit ip any any

IPTV

|

Cisco 6504

|

Cisco 6509

|

Cisco 3560 <- This is where check if we get the right DSCP value from IPTV

15 Replies 15

ariela
Level 4
Level 4

Hi,

I didn't understand what is your goal. Maybe the command "mls qos map cos-dscp" does the trick. Please check before that link, could be helpful:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd803e5269.html

Let me know

Regards

Andrea

Question: the 'mls qos' is enabled?

Andrea

ps: another good link is:

http://www.gossamer-threads.com/lists/cisco/nsp/80620

As you can see, you have some options, one of them is simplify your policy with something like that:

policy-map set-dscp-32

class class-default

set dscp 32

Another good idea is to move the trusted boundary, mark on access-layer (Cos 4 or DSCP 32) and then on your 6500 trust that value.

Thanks Andrea for the great links.

Our goal is to rewrite all incoming traffic on gig3/1 to dscp 32

Yes mls qos is enabled globally

I don't see how this is more simplyfied than what we have now?

policy-map set-dscp-32

class class-default

set dscp 32

I've also tried to set mls qos trust on gig3/1 and it still won't rewrite to 32.

I need more details about your IPTV infrastructure. Have you got the multicast source directly connected to gig3/1, or to another access layer?

Please let me know

Andrea

ps: in my opinion, in terms of commands and syntax, using the class-default to mark all traffic IP is more simplyfied that creating a specific class, and a generic access list. Simple is better, isn't it? ;)

The multicast source addresses are several route hops away connected on gig3/1.

I don't think its just a problem with multicast. I tested on another gig3/2 layer3 interface where Internet traffic flows and I can't rewrite the traffic there either. I also tried on a vlan interface mls qos vlan-based and with service-policy input and it works ok.

We are running on module type WS-X6724-SFP.

I'm also adding the global configuration we are using:

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos map ip-prec-dscp 0 8 16 24 32 46 48 56

mls qos

I was talking about topology, and not strictly for multicast.

The first idea is: you could mark with CoS 4 or DSCP 32 in an upstream switch or router, then trust that value on gig3/1

The first idea is: you could mark with CoS 4 or DSCP 32 in an upstream switch or router, then trust that value on gig3/1

Unfortunately this is not possible because those routers are not managed by us.

This is how the mls qos vlan-based configuration looks like

interface Vlan607

ip address x.x.x.x x.x.x.x

ip access-group 103 in

no ip redirects

no ip proxy-arp

service-policy input internet-qos-map

end

interface GigabitEthernet3/22

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 607

switchport mode trunk

no ip address

wrr-queue bandwidth percent 65 20 15

wrr-queue queue-limit 40 30 10

wrr-queue random-detect min-threshold 1 75 90 95 95 95 95 100 100

wrr-queue random-detect min-threshold 2 80 85 90 95 95 95 95 95

wrr-queue random-detect min-threshold 3 99 99 99 99 99 99 99 100

wrr-queue random-detect max-threshold 1 95 95 98 99 99 99 100 100

wrr-queue random-detect max-threshold 2 95 97 98 99 99 99 100 100

wrr-queue cos-map 1 7 1

wrr-queue cos-map 1 8 4

wrr-queue cos-map 2 2 2

wrr-queue cos-map 3 1 6

wrr-queue cos-map 3 2 7

wrr-queue cos-map 3 8 3

mls qos vlan-based

flowcontrol send off

end

class-map match-all internet-class

match access-group name internet-acl

!

policy-map internet-qos-map

class internet-class

set dscp 8

!

ip access-list extended internet-acl

permit ip any any

But gig3/1 is a trunk?

gig3/1 is not a trunk interface. gig3/22 is a trunk interface and its on this interface we got the rewriting to work.

for a non trunk interfaces a good idea is to use the 'mls qos cos' command, to set a default cos for all traffic in ingress on this specific interface. CoS 4 will be DSCP 32.

Have you already tryed that way?

Andrea

edit: use the keyword 'override', as

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m2.html#wp1011989

I have not tried that yet. I won't be able to test this until next week. Thanks Andrea for the tip.

'mls qos cos 4' did the trick for this case, but I also have another interface on the same switch where I need to seperate different types of traffic ie. Internet, VoIP etc. into seperate queues. The only way I can do that is by using MQC.

So 'mls qos cos' won't help me in that case.

I discovered the reason why the IPTV/UDP packets did not get marked. The reason seem to be that you can't change the existing multicast stream with MQC. The only way to see the change was to shutdown the interface (g3/1) and bring it up again. Then we could see the right DSCP value 32. Stopping and starting the multicast stream from its source did not help.

So there is nothing wrong with my initial configuration

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: