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:
http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/mplsqos.html#pgfId-1405948
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
purposes.
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.