Notes - QoS on IOS-XR
QoS on IOS-XR is very similar to IOS-XE. The MQC syntax is essentially the same. There are a few extra features which are available.
WRED
On IOS-XR, you can configure regular RED by using “random-detect default”
policy-map EX
class class-default
random-detect defaultWhen using regular WRED, you can base it on DSCP, EXP, IPP, or CoS. For any of these cases, you must specify the values yourself. The platform does not provide defaults.
policy-map EX
class class-default
random-detect dscp af11,af21,af31,af41 140 packets 200 packets probability 10
random-detect dscp af12,af22,af33,af44 120 packets 200 packets probability 10
random-detect dscp af13,af22,af33,af44 100 packets 200 packets probability 10MDRR
IOS-XR uses MDRR (modified deficit round robin) instead of CBWFQ. However, it essentially operates in the same manner, even though it doesn’t use the same weighted fair queuing algorithm. I believe as the user you will not know the difference. LLQ can still be used, which brings strict priority queuing to the MDRR scheduling.
Overhead Accounting
Overhead accounting is done on the interface as the policy-map is applied, not on the policy-map itself as in IOS-XE. On XRv I only have the options for using layer1, layer2, or turning off layer2 accounting.
RP/0/0/CPU0:XR1(config-if)#service-policy input 100M_SHAPE account ?
layer1 Turn on l1 accounting
layer2 Turn on l2 accounting
nolayer2 Turn off l2 accountingPriority Queues
On IOS-XR, 8 priority levels are supported. On IOS-XE, only 2 levels are supported.
On IOS-XR, you cannot police on the priority command like you can on IOS-XE. Instead you must configure a separate policer.
RP/0/0/CPU0:XR1(config-pmap-c)#priority level 1 ?
<cr>
policy-map EX
class class-default
priority level 1
police rate 10 mbpsNote that on IOS-XE, the following configurations have two different meanings:
When the police rate is specified with the priority command, the queue can still use extra bandwidth when no congestion is present
When the police rate is specified separately, this queue can never go above the police rate
! Only police to 10M during congestion
policy-map EX1
class class-default
priority level 1 10000
! Police to 10M even when there is no congestion
policy-map EX2
class class-default
priority level 1
police rate 10 mSPI (Shared Policy Instance)
This is essentially the IOS-XR equivalent of IOS-XE’s service-group. You can apply an aggregate policy to multiple subinterfaces. All subinterfaces must belong to the same physical interface, just like on IOS-XE.
policy-map 100M_SHAPE
class class-default
shape average 100 mbps
!
interface GigabitEthernet0/0/0/0.100
service-policy output 100M_SHAPE shared-policy-instance INSTANCE1
ipv4 address 10.100.0.1 255.255.255.0
encapsulation dot1q 100
!
interface GigabitEthernet0/0/0/0.200
service-policy output 100M_SHAPE shared-policy-instance INSTANCE1
ipv4 address 10.200.0.1 255.255.255.0
encapsulation dot1q 200Shared policer buckets
This feature allows you to share a single policer bucket among multiple classes. This seems to be a way to use a single policer rate for multiple classes within a single policy.
policy-map EX
class X
police bucket shared BUCKET1 rate 100 mbps
!
class Y
police bucket referred BUCKET1Multiple QoS Policies
This feature allows you to apply multiple QoS policies in the same direction. One policy is used for classification, and marks traffic with traffic-class. The second policy does queuing, and matches the traffic-class. The classification policy will execute first. The queuing policy executes second, matching on the traffic class field that was set by the classification policy, which selects the queue.
policy-map CLASSIFICATION
class X
set traffic-class 1
class Y
set traffic-class 2
!
policy-map QUEUING
class TC1
shape average 50 m
class TC2
shape average 100 M
!
int Gi0/0/0/0
service-policy output CLASSIFICATION
service-policy output QUEUINGThe traffic-class tool does not appear to be very well documented. It is an internal marking mechanism similar to qos-group. But traffic-class is used for egress queuing, while qos-group is only used for marking(?).
From: https://community.cisco.com/t5/xr-os-and-platforms/ncs-55a2-xr-6-6-qos/td-p/4111848
A few things, qos-group matching on egress counts as a marking action and
queuing and marking are not supported at the same time. On NCS5500 we have
to apply different service-policy statements on the interface for queuing
and for remarking actions. This means separate policy-maps have to be created
for marking and queuing respectively.
NCS5500 implements a different concept for marking. It is based on traffic-class
and qos-group. On egress we match on these two parameters to remark traffic and
to select queues.Traffic-class determines priority through the fabric.
While “match traffic-class” has to be used for queuing features “match qos-group”
can only be used for marking.This comment provides more clarity:
In an egress QoS policy on DNX platforms (NCS540, NCS560, NCS5k, NCS5500) you
cannot match on packet header fields. You can only match on internal scope
traffic-class or qos-group. Traffic has to be classified into a given traffic-class
or qos-group in an ingress QoS policy. Match on a traffic-class if the action you
want to apply is queuing. Match on qos-group if the action you want to apply is
egress marking. Child-Conform-Aware
This feature makes the parent policy aware of the colors of traffic as marked by the child policy. This prevents conformed traffic from being dropped if it is mixed with exceeded traffic when presented to the parent policy.
policy-map PARENT
class class-default
police rate 100 m
child-conform-aware
service-policy CHILD
!
policy-map CHILD
class X
police rate 50 m
conform-action set dscp default
!
class Y
police rate 50 m
conform-action set dscp default
exceed-action set dscp cs1In this scenario, there might be a total of 100m of conforming traffic presented to the parent policy, and excess traffic marked with cs1 over 100m. The parent policy needs to be aware of the markings the child policy is doing in order to drop the exceeded traffic and not the conforming traffic.
Service-fragment
This feature allows individual classes in separate policies that are attached to subinterfaces on the same physical interface, to use an aggregate policy on the main interface.
This diagram helps explain the feature:
The default-class present on policies assigned to each individual subinterface is associated with an aggregate policy assigned to the main physical interface.
policy-map X
class class1
fragment FRAG1
class class2
!
policy-map Y
class class1
fragment FRAG1
class class2
!
policy-map PHYS
class class-default
service-fragment FRAG1
int Gi0/0/0/0.100
service-policy output X
int Gi0/0/0/0.200
service-policy output Y
int Gi0/0/0/0
service-policy PHYSFlow-aware QoS
This feature allows the router to classify traffic into flows for the purpose of call admission control (CAC). For example, let’s say that you want to provide priority treatment to video conference calls, but police then at 5mbps. Let’s say each call is 1mbps. If more than 5 calls are present, all video callas will suffer. We want to do call admission control so that the 6th call is dropped instead.
policy-map X
class video
priority level 1
admit cac local
flow idle-timeout <seconds>
flow rate 1 mbps
rate 5 mbpsLast updated