2-level policy on NCS5500

[Mollerstrom]

Hi fellows, whats your thoughts about this.

As you probably know this is working fin on a 9K router, but fails on a NCS

You may also refer to the VOQ and the usage of qos-groups and output policy on the coresponding interface (core) interface when remarking traffic (IP and or MPLS)

But I would argue that the numbers of qos-groups (8) is not enough and you can not set both mpls exp and ip prec in the same policy/class-map

Anyhow I am not sure if this is suppose to work on a NCS plattform (Jericho) or not, if its a bug or if its a feature that will come later on.

What I'm trying to acheve is basically:

PE, ingress interface: rate limit the traffic and remark all traffic (as the exceed action in the policer is missing too)

on a 9K you would use a 2 lavel policy but that do not work instead I have to either police or remark/classify) 

any experience or feedback, is the 2 lavel policy suppose to work?

Running 6.5.3 and apologize if there are any typos in the naming of the Acl/class-maps/policys below as I change the names

Option A
OK, this remark to 0

ipv4 access-list NAME_1
10 permit ipv4 any any
!
class-map match-any NAME_2
description IPv4 permit any
match access-group ipv4 NAME_1
end-class-map
!
policy-map CHILD_1
class NAME_2
set traffic-class 0
set precedence 0
!
class class-default
!
end-policy-map
!

Interface
service-policy input CHILD_1

Option B
OK, this remark to 0

policy-map CHILD_2
class class-default
set traffic-class 1
set precedence 1
!
end-policy-map
!

Interface
service-policy input CHILD_2

Option C
NOK this will not remark to prec 0 only police

policy-map PARENT
class class-default
service-policy CHILD_1
police rate 100 mbps burst 6250 kbytes
!
!
end-policy-map
!

Interface
service-policy input PARENT

Regards

Jonas

[Aleksandar Vidakovic]

hi Jonas,

have you enabled HQoS in global configuration mode:

hw-module profile qos hqos-enable

Also, for understanding QoS on NCS5500, please refer these two pages/videos:

• https://xrdocs.io/ncs5500//tutorials/ncs5500-qos-part-1-understanding-packet-buffering/
• https://xrdocs.io/ncs5500//tutorials/ncs5500-qos-part-2-verifying-buffering/

/Aleksandar

[Mollerstrom]

Hi Alexander, thanks for your reply.

Yes that's enabled (hw-module profile qos hqos-enable)  but still the 2 level policy don't work as expected (by me).

Option C only police traffic but it do not remark, I will add a sous-group and play around with a (second) egress policy on the core interface to see if I can change it that way.

Regards

Jonas

[Mollerstrom]

Remark traffic on the uplink using qos-groups would not work since you can only set cos not ip prec (in version 6.5.3)

[Mollerstrom]

Hi Alexander, I generalised the question to much I think.

I understand it's crustial to mention that in the specific test setup I have I'm using a Bundle and a sub interface

Ixia A---/trunk/---NCS540-switch--------/trunk/-----NCS55A1-PE------(MPLS)------9K-PE---/trunk/----Ixia-B

The 2 level policy I mention in the original question is related to an inport policy on the NCS55A1 on the sub interface connected to the NCS Switch, meaning  traffic coming from ixia A to Ixia B needs to be policed and remarked on that sub interface in NCS55A1

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/qos/65x/b-qos-cg-ncs5500-65x/b-qos-cg-ncs5500-65x_chapter_0101.html

"Applying QoS on sub-interfaces is not supported"  this explains the problem I have but I did not expect this, can you elaborate this further ?

Rgds

Jonas

[Aleksandar Vidakovic]

hi Jonas,

thanks for drawing my attention that configuration guide. The statement you quoted is not correct, I'll make sure the document is updated. I suppose the authors wanted to say that "Applying QoS on sub-interfaces bundle members is not supported".

You can configure a 2-level HQoS policy on ingress and egress bundle sub-interface. Can you attach the full running config, "show qos interface <int> {input|output}" and "show policy-map interface <int>"?

regards,

/Aleksandar

[Mollerstrom]

Hi Aleksandar, thanks for sharing that information about the documentation.

I will get in touch with you regarding a more in detail information//Jonas

[xthuijs]

hi jonas,

since the policer ingress cannot be made conditional, that is applying extra actions to the confirm or exceed colors,

you could try to do this potentially, have you considered that?

We can use Discard Class to meet the Conditional policing requirement.

We have following behavior of DC in NCS5501:

1. Conform: DC is set to 0

2. Exceed: DC is set to 1

3. Violate: DC is set to 2. This is always drop. We cannot do any action for Violate case.

NOTE: The Discard class is set by default for Policer Conform and Exceed. No need to add any specific marking in the ingress policy-map.

policy-map test_conditional_policing
 class class-default
  police rate 100 mbps peak-rate 120 mbps 
  ! 
  set qos-group 2
 ! 
 end-policy-map

NNI egress:

policy-map test_cond_policing_egress
 class dc1_qos2         <<<< Exceed action
  set mpls experimental imposition 3
 ! 
 class dc0_qos2          <<<<<< Conform action
  set mpls experimental imposition 4  
 ! 
 class class-default
 ! 
 end-policy-map

Class-map definition:

class-map match-all dc1_qos2
 match discard-class 1 
 match qos-group 2 
 end-class-map
! 

class-map match-all dc0_qos2
 match discard-class 0 
 match qos-group 2 
 end-class-map
! 

xander

[Mollerstrom]

Hi Xander, thanks for taking time on this, highly appreciated!

Are you refer to a "Single-Rate Two-Color Policer" ?

matter of fact is that the policer in the parent policy is working, but the child policy is not getting processes so to say

I actually use a single rate 2 color policer in the child policy (using confirm and exceed action) on a 9K but will look at your solution.

So for the 2 level policy I'm using, if I use them separatly they work just fine but the combination dont traffic passing the interface/policy is getting policed by the parant policy but not remarked by the child policy 

[xthuijs]

oh sorry I meant to implement this as a flat (child) policy only... can you verify that to see if that meets the need?

cheers!!

xander

[Mollerstrom]

Hi Xander.

I did some further investigation/testing

for example if I have a Parant policy with a policer and a child policy with class-map's (one is mathcing icmp the other is matching ipv4 any any using acl's)

sending icmp and telnet and if I apply only the child policy as a 1 level policy on the (bundle sub) interface it's working

icmp match the icmp class-map and telnet match the ipv4 any any class-map

If I test with a 2 level policy the icmp traffic still match the icmp class-map (in the child policy) but the telnet dont match the ipv4 any any class-map (in teh child policy), however both streams are policed in the parant policy

//Jonas

[xthuijs]

hi jonas,

the icmp and telnet test traffic that is going through the device and not punted/locally consumed correct?

instead of doing the match any any in that special class, can you use the class default instead?

what class was the telnet traffic matching to? I am suspecting it was hitting a class-default in the child, right?

cheers!

xander

[Mollerstrom]

Hi Xander,

sorry for a late reply, but here is the latest testing results:

When using a specific class-map & ACL for Telnet it's working

When using class-default its working

When using class-map matching an ACL with permit ipv4 any any its not working

//Jonas

PS using a 55A1 in the lab, might be ok on 550"x", not clear yet.

[Aleksandar Vidakovic]

This sounds like a consequence of some optimisation attempt to reduce the TCAM usage. Could you remove the service policy, rollback the config and then capture the "show tech qos pi" and "show tech qos platform"? Let us know the time of the rollback, so that we know where to look in the traces.

/Aleksandar

[xthuijs · Accepted solution]

yeah thanks for that test jonas, we were suspecting that class-default colliding with a permit any any and that you just proven.

there had been an issue reported on the same:

CSCvg05548 Fretta - Qos : Classification using ACL with src/dst as any/any traffic always takes default class 

but it appears that there is still a gap with it.

as a workaround for this scenario since you can't use the default class, can you use potentially this solution:

permit ipv4 any 0.0.0.0 255.255.255.254

permit ipv4 any 0.0.0.1 255.255.255.254

effectively this would give you an any any thing also, this may bypass that programming issue for the any any condition.

cheers!

xander