Policy-map counters do not increment

[narx]

Hello everyone,

I'm trying to implement QoS on a lab environement for ncs55xx

Due to hardware limitations, i can't match dscp / qos-group for egress  traffic so i decided to match traffic-class. 

This requires me to mark ingress traffic to traffic-class. 

This is my test configuration : 

ipv4 access-list ACL_1
10 permit ipv4 host 192.168.1.3 any
!
ipv4 access-list ACL_2
10 permit ipv4 host 192.168.1.4 any
!
class-map match-any 1-CLASS-IN
match access-group ipv4 ACL_1
end-class-map
!
class-map match-any 2-CLASS-IN
match access-group ipv4 ACL_2
end-class-map
!
policy-map POLICY_MARK_IN
class 1-CLASS
set traffic-class 3
!
class 2-CLASS
set traffic-class 2
!
class-map match-any 1-CLASS-OUT
match traffic-class 3
end-class-map
!
class-map match-any 2-CLASS-OUT
match traffic-class 2
end-class-map
!
policy-map POLICY_OUT
class 1-CLASS-OUT
bandwidth remaining percent 20
!
class 2-CLASS-OUT
bandwidth remaining percent 20
end-policy-map
!
interface Bundle-Ether1
service-policy input POLICY_MARK_IN
service-policy output POLICY_OUT
ipv4 address 192.168.1.2 255.255.255.0
lldp
enable
!
!

From another device, i ping 192.168.1.2, and i see traffic entering & leaving my interface Bundle-Ether1 but my issue is that counter do not increment on my policy-map. Which means packets are not getting marked ? 

What is aslo wierd is that when i replace traffic-class 3 by traffic-class 7, i see POLICY_OUT incrementing even if i do not generate traffic 

Thank you for your help in advance 

[marce1000]

        - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd82088
          Advising to use the latest advisory software version for the platform,

 M.

[narx]

Thank you for your answer, 

My device is under version 7.7.21 so i should be affected by this right ? 

Also another question, is it possible that my device do the marking process but the counters do not increment ? 

[marce1000]

   - @narx    >...My device is under version 7.7.21 so i should not be affected by this right ? 
                             The bug report may not be an exact match; it remains advisable to use the (a)
                                           latest advisory release ,

 M.

[narx]

Thank you for your input, i will upgrade to a more recent release and let you know. 

An other doubt i had is when i use traffic-class 7, i see incrementation on my egress policy

[Tim nathan]

The fact that traffic-class 7 causes increments without real traffic sounds like a default or fallback class. Some platforms treat traffic-class 7 as a ‘catch-all’ or system class, so counters might increment regardless of real matched traffic. It’s worth checking platform documentation or trying a different traffic-class number within the supported range.

[Ramblin Tech]

Not sure I fully understand the QoS policy you are trying to implement...

At ingress (POLICY_MARK_IN), you are matching on any packet sourced from 192.168.1.3 and setting it to traffic-class 3, while any packet sourced from 192.168.1.4 is set to traffic-class 2. All non-matching packets receive default treatment which maps to traffic-class 0. This ingress policy is then applied to be1.

At egress (POLICY_OUT), you are matching on traffic-classes 2 & 3 to implement bandwidth-remaining scheduling policies, but you are also implementing this policy on be1.

In order for a packet sourced from 192.168.1.3 to be set to traffic-class 3 and then get the desired scheduling treatment at egress, it would have to ingress be1, hair-pin, and then also egress be1. I do not believe this is what you intend.

Do you really want traffic destined to 192.168.1.3 to be in traffic-class 3 and receive 20% of the bandwidth remaining at egress? Likewise, traffic destined to 192.168.1.4 to be in traffic-class 2 and receive 20% of the egress bandwidth remaining? If so, then the ingress policy-map should be implemented on the interfaces where traffic destined for these two hosts ingress the NCS5500; this is not likely to be be1, but rather some other set of interfaces. The ACLs used as the ingress match conditions would also have to be revised to match on the 192.168.1.3 & .4 destinations, rather than sources.

[narx]

Thank you for your answer, 

i will put an other interface for my egress policy-map to test. But when 192.168.1.3 generates traffic and this one enters be1, i should already see POLICY_MARK_IN counters increments right ? which i don't see 

[Ramblin Tech]

One thing I just noticed was that the names of your ingress class maps (1-CLASS-IN, 2-CLASS-IN) do not match the class-map names referenced in your ingress policy-map (1-CLASS, 2-CLASS). Correct those and see if your counters increment. If not...

It has been a while since I have worked with QoS on the NCS5500, but... but you may need to set a qos-group in your ACL and then match on the qos-group in your class-map, rather than matching on access-group.

Example qos-group matching:

ipv4 access-list ACL_3
 10 permit ipv4 any host 192.168.1.3 set qos-group 3
!
class-map match-any 3-CLASS-IN
 match qos-group 3
 end-class-map

!
policy-map POLICY_MARK_IN
 class 3-CLASS-IN
  set traffic-class 3