Catalyst 6500/7600 MPLS Exp bits

AC and there is no command to see packet hit counters per queue to see how many packets are matching into each queue (the equivilent of “show policy-map interface x/x” on a device using HQF).


The best commands I found where:


show mls qos ip Gi2/17

show mls qos queuing int Gi2/17

show mls qos queuing interface Gi2/17 | b dropped show counters interface Gi2/17 remote command switch show qm port 2 17 show interfaces | i Ethernet|output drop


like below (on 7606-S)

 class-map match-all PLATINUM
  match mpls experimental topmost 5
 class-map match-all GOLD
  match mpls experimental topmost 3
 class-map match-all SILVER
  match mpls experimental topmost 1
 policy-map EXPMAP
  class PLATINUM
  class GOLD
  class SILVER
  class class-default
 interface vlan 1700
  service-policy output EXPMAP

To recap:

Traffic comes in via transit provider attached to 7600-PE1, label is

pushed, traffic is label switched over to 7600-PE2, PE2 PoPs label and

sends IP traffic to customer.

Packets are coming from the transit provider with a DSCP making and

being sent over to the customer with a DSCP marking. I’m was trying to

set the incoming packets to DSCP 0 on PE1 first, with a policy-map

with “set DSCP 0” which didn’t work. Then without a policy map the

port is by default in a state of un-trust as mls qos is enabled

gobally. Still this didn’t work.

By default the 7600/PFC is operating in short pipe mode:

Switching to uniform mode work, using the global config command “mls

mpls qos input uniform-mode”.

Now PE1 will set DSCP 0 on the incoming transit packets however, even

in short pipe mode, if the port is untrusted I would have expected the

DSCP to be set to 0. It seems in short pipe mode no actions can be

made against the DSCP/ToS value at ingress only egress.


It shouldn’t be necessary in your situation, but I’m curious if adding
“platform ip features sequential” on the ingress interfaces where
marking is occurring would help. This should only be necessary if you
are marking on ingress and then taking action on the new marking in
the same box. It should have zero bearing on if the packet is actually
re-marked on egress, but it might be worth a shot for troubleshooting

Interesting, I didn’t know that command so I’m reading about it now.

TAC have asked if I can add a policy with “set mpls experimental
imposition 0”, I guess there logic is something like:

Traffic comes in via transit provider attached to 7600-PE1, label is
pushed, label switched over to 7600-PE2. PE1 has pushed the label
before setting DSCP so the DSCP isn’t being removed (maybe the DSCP
removal actually happens on egrees of the incomming line card into the
crossbar or something like that, not as soon as the packet comes into
the port ASIC, but since this packet gets a label pushed maybe that
also happens before the packet egresses the line card into the
crossbar so the DSCP isn’t removed when the packet leaves the line
card becasue it’s now a labelled packet).

However they haven’t explained why I should do this, so I’ve thrown it
back at them to explain.


TAC have confirmed this is more or less a bug with the platform and

there is an internal bag case CSCuw80912 which the developers have

looked at. There is no intention to fix this though as it seems to be

some sort of limitation of the way the PFC hardware works.

It seems “mls mpls qos input uniform-mode” toggles uniform mode and

also performs some additional steps internally so that the PFC can set

re-write DSCP on ingress, to work around the issue.