05-19-2019 02:51 AM
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
Solved! Go to Solution.
06-03-2019 06:48 AM
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
05-19-2019 10:07 PM
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:
/Aleksandar
05-19-2019 11:36 PM
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
05-21-2019 01:31 AM
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)
05-23-2019 12:25 AM
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
"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
05-23-2019 01:58 AM
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
05-23-2019 02:20 AM
Hi Aleksandar, thanks for sharing that information about the documentation.
I will get in touch with you regarding a more in detail information//Jonas
05-24-2019 05:24 AM
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
05-24-2019 06:31 AM
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
05-28-2019 10:52 AM
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
05-31-2019 03:32 AM
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
05-31-2019 05:58 AM
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
06-03-2019 01:04 AM - edited 06-03-2019 01:59 AM
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.
06-03-2019 04:01 AM
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
06-03-2019 06:48 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide