service-policy input doesn't work

Unanswered Question

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


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
ariela Wed, 12/03/2008 - 02:34
User Badges:
  • Silver, 250 points or more

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.

ariela Wed, 12/03/2008 - 05:30
User Badges:
  • Silver, 250 points or more

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


ariela Wed, 12/03/2008 - 06:17
User Badges:
  • Silver, 250 points or more

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

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

ariela Wed, 12/03/2008 - 06:29
User Badges:
  • Silver, 250 points or more

But gig3/1 is a trunk?

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


FiLeinster Thu, 12/18/2008 - 01:39
User Badges:

As you are using a switched environment, you must have the ports to and from the 6509 and to the 3560 set as trusted:


interface x/x

mls qos trust dscp


Have you done that?

Actions

This Discussion