cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

ASR9000/XR: Understanding QOS, default marking behavior and troubleshooting

61967
Views
29
Helpful
236
Comments

Introduction

This document provides details on how QOS is implemented in the ASR9000 and how to interpret and troubleshoot qos related issues.

 

Core Issue

QOS is always a complex topic and with this article I'll try to describe the QOS architecture and provide some tips for troubleshooting.

Based on feedback on this document I'll keep enhancing it to document more things bsaed on that feedback.

 

The ASR9000 employs an end to end qos architecture throughout the whole system, what that means is that priority is propagated throughout the systems forwarding asics. This is done via backpressure between the different fowarding asics.

One very key aspect of the A9K's qos implementation is the concept of using VOQ's (virtual output queues). Each network processor, or in fact every 10G entity in the system is represented in the Fabric Interfacing ASIC (FIA) by a VOQ on each linecard.

That means in a fully loaded system with say 24 x 10G cards, each linecard having 8 NPU's and 4 FIA's, a total of 192 (24 times 8 slots) VOQ's are represented at each FIA of each linecard.

The VOQ's have 4 different priority levels: Priority 1, Priority 2, Default priority and multicast.

The different priority levels used are assigned on the packets fabric headers (internal headers) and can be set via QOS policy-maps (MQC; modular qos configuration).

When you define a policy-map and apply it to a (sub)interface, and in that policy map certain traffic is marked as priority level 1 or 2 the fabric headers will represent that also, so that this traffic is put in the higher priority queues of the forwarding asics as it traverses the FIA and fabric components.

If you dont apply any QOS configuration, all traffic is considered to be "default" in the fabric queues. In order to leverage the strength of the asr9000's asic priority levels, you will need to configure (ingress) QOS at the ports to apply the priority level desired.

qos-archi.jpg

In this example T0 and T1 are receiving a total of 16G of traffic destined for T0 on the egress linecard. For a 10G port that is obviously too much.

T0 will flow off some of the traffic, depending on the queue, eventually signaling it back to the ingress linecard. While T0 on the ingress linecard also has some traffic for T1 on the egress LC (green), this traffic is not affected and continues to be sent to the destination port.

Resolution

 

The ASR9000 has the ability of 4 levels of qos, a sample configuration and implemenation detail presented in this picture:

 

shared-policy.jpg

 

 

Policer having exceeddrops, not reaching configured rate

 

When defining policers at high(er) rates, make sure the committed burst and excess burst are set correctly.
This is the formula to follow:

Set the Bc to CIR bps * (1 byte) / (8 bits) * 1.5 seconds

and

Be=2xBc

Default burst values are not optimal

Say you are allowing 1 pps, and then 1 second you don’t send anything, but the next second you want to send 2. in that second you’ll see an exceed, to visualize the problem.

 

Alternatively, Bc and Be can be configured in time units, e.g.:

     policy-map OUT

      class EF

       police rate percent 25 burst 250 ms peak-burst 500 ms

 

For viewing the Bc and Be applied in hardware, run the "show qos interface interface [input|output]".

 

 

Why do I see non-zero values for Queue(conform) and Queue(exceed) in show policy-map commands?

On the ASR9k, every HW queue has a configured CIR and PIR value. These correspond to the "guaranteed" bandwidth for the queue, and the "maximum" bandwidth (aka shape rate) for the queue.

In some cases the user-defined QoS policy does NOT explicitly use both of these.  However, depending on the exact QoS config the queueing hardware may require some nonzero value for these fields.  Here, the system will choose a default value for the queue CIR.  The "conform" counter in show policy-map is the number of packets/bytes that were transmitted within this CIR value, and the "exceed" value is the number of packets/bytes that were transmitted within the PIR value.

Note that "exceed" in this case does NOT equate to a packet drop, but rather a packet that is above the CIR rate on that queue.

You could change this behavior by explicitly configuring a bandwidth and/or a shape rate on each queue, but in general it's just easier to recognize that these counters don't apply to your specific situation and ignore them.

 

What is counted in QOS policers and shapers?

 

When we define a shaper in a qos pmap, the shaper takes the L2 header into consideration.

The shape rate defined of say 1Mbps would mean that if I have no dot1q or qinq, I can technically send more IP traffic then having a QIQ which has more L2 overhead. When I define a bandwidth statement in a class, same applies, also L2 is taken into consideration.

When defining a policer, it looks at L2 also.

In Ingress, for both policer & shaper, we use the incoming packet size (including the L2 header).

In order to account the L2 header in ingress shaper case, we have to use a TM overhead accounting feature, that will only let us add overhead in 4 byte granularity, which can cause a little inaccuracy.

In egress, for both policer & shaper we use the outgoing packet size (including the L2 header).

 

ASR9K Policer implementation supports 64Kbps granularity. When a rate specified is not a multiple of 64Kbps the rate would be rounded down to the next lower 64Kbps rate.

 

For policing, shaping, BW command for ingress/egress direction the following fields are included in the accounting.

 

MAC DA

MAC SA

EtherType

VLANs..

L3 headers/payload

CRC

 

Port level shaping

Shaping action requires a queue on which the shaping is applied. This queue must be created by a child level policy. Typically shaper is applied at parent or grandparent level, to allow for differentiation between traffic classes within the shaper. If there is a need to apply a flat port-level shaper, a child policy should be configured with 100% bandwidth explicitly allocated to class-default.

Understanding show policy-map counters

 

QOS counters and show interface drops:

 

Policer counts are directly against the (sub)interface and will get reported on the "show interface" drops count.
The drop counts you see are an aggregate of what the NP has dropped (in most cases) as well as policer drops.

 

Packets that get dropped before the policer is aware of them are not accounted for by the policy-map policer drops but may
show under the show interface drops and can be seen via the show controllers np count command.

 

Policy-map queue drops are not reported on the subinterface drop counts.
The reason for that is that subinterfaces may share queues with each other or the main interface and therefore we don’t
have subinterface granularity for queue related drops.

 

 

Counters come from the show policy-map interface command

 

 

Class name as per   configuration Class   precedence6
Statistics for this class   Classification statistics          (packets/bytes)     (rate - kbps)
Packets that were matched     Matched             :            31583572/2021348608           764652
packets that were sent to the wire     Transmitted         : Un-determined
packets that were dropped for any reason   in this class     Total Dropped       : Un-determined
Policing stats   Policing statistics                (packets/bytes)     (rate - kbps)
Packets that were below the CIR rate     Policed(conform)    :            31583572/2021348608           764652
Packets that fell into the 2nd bucket   above CIR but < PIR     Policed(exceed)     :                   0/0                    0
Packets that fell into the 3rd bucket   above PIR     Policed(violate)    :                   0/0                    0
Total packets that the policer dropped     Policed and dropped :                   0/0
Statistics for Q'ing   Queueing statistics  <<<----
Internal unique queue reference     Queue ID                             : 136

how many packets were q'd/held at max one   time

(value not supported by HW)

    High watermark  (Unknown)

number of 512-byte particles which are currently

waiting in the queue

    Inst-queue-len  (packets)            : 4096

how many packets on average we have to   buffer

(value not supported by HW)

    Avg-queue-len   (Unknown)

packets that could not be buffered   because we held

more then the max length

    Taildropped(packets/bytes)           : 31581615/2021223360
see description above (queue exceed section)     Queue(conform)      :            31581358/2021206912           764652
see description above (queue exceed section)     Queue(exceed)       :                   0/0                    0

Packets subject to Randon Early detection

and were dropped.

    RED random drops(packets/bytes)      : 0/0

 

 

Understanding the hardware qos output

 

RP/0/RSP0/CPU0:A9K-TOP#show qos interface g0/0/0/0 output

 

With this command the actual hardware programming can be verified of the qos policy on the interface

(not related to the output from the previous example above)


Tue Mar  8 16:46:21.167 UTC
Interface: GigabitEthernet0_0_0_0 output
Bandwidth configured: 1000000 kbps Bandwidth programed: 1000000
ANCP user configured: 0 kbps ANCP programed in HW: 0 kbps
Port Shaper programed in HW: 0 kbps
Policy: Egress102 Total number of classes: 2
----------------------------------------------------------------------
Level: 0 Policy: Egress102 Class: Qos-Group7
QueueID: 2 (Port Default)
Policer Profile: 31 (Single)
Conform: 100000 kbps (10 percent) Burst: 1248460 bytes (0 Default)
Child Policer Conform: TX
Child Policer Exceed: DROP
Child Policer Violate: DROP
----------------------------------------------------------------------
Level: 0 Policy: Egress102 Class: class-default
QueueID: 2 (Port Default)
----------------------------------------------------------------------

 

 

Default Marking behavior of the ASR9000

 

If you don't configure any service policies for QOS, the ASR9000 will set an internal cos value based on the IP Precedence, 802.1 Priority field or the mpls EXP bits.

Depending on the routing or switching scenario, this internal cos value will be used to do potential marking on newly imposed headers on egress.

 

Scenario 1

Slide1.JPG

Scenario 2

Slide2.JPG

 

Scenario 3

Slide3.JPG

 

Scenario 4

 

Slide4.JPG

 

Scenario 5

 

Slide5.JPG

 

Scenario 6

Slide6.JPG

 

Special consideration:

If the node is L3 forwarding, then there is no L2 CoS propagation or preservation as the L2 domain stops at the incoming interface and restarts at the outgoing interface.

Default marking PHB on L3 retains no L2 CoS information even if the incoming interface happened to be an 802.1q or 802.1ad/q-in-q sub interface.

CoS may appear to be propagated, if the corresponding L3 field (prec/dscp) used for default marking matches the incoming CoS value and so, is used as is for imposed L2 headers at egress.

 

If the node is L2 switching, then the incoming L2 header will be preserved unless the node has ingress or egress rewrites configured on the EFPs.
If an L2 rewrite results in new header imposition, then the default marking derived from the 3-bit PCP (as specified in 802.1p) on the incoming EFP is used to mark the new headers.

 

An exception to the above is that the DEI bit value from incoming 802.1ad / 802.1ah headers is propagated to imposed or topmost 802.1ad / 802.1ah headers for both L3 and L2 forwarding;

 

Related Information

ASR9000 Quality of Service configuration guide

 

Xander Thuijs, CCIE #6775

 

Comments

Hello Xander.

Thanks for a good write-up. Not sure if was updated (or even needs to be updated) in the light of newer IOS XR version being out.

Anyway, a quick question.

Default Marking behavior of the ASR9000 scenario 3, where we have an ingress untagged MPLS frame with EXP 3. Your chart shows that by default with label swap EXP bits are not honored and egress MPLS EXP is 0. Am I reading it wrong?

TIA

Alexei.

xthuijs
Cisco Employee

hi alexei, thank you! this default marking has not changed over time, so it still applies :) when you have an untagged frame coming in on bridging, the internal COS is 0. the internal cos value is what gets applied to imposed headers on egress, that includes any added labels, or vlans.

if you are doing label swapping, that is routed interfaces, you are likely in scenario 6 instead.

in that case you'll honor/trust the exp to set the internal cos and that would transport over into the swap label egress.

this is to support pipe mode by default, that was the train of thought behind these default marking operations.

cheers

xander

Hello Xander,

thanks for your quick reply. Indeed, scenario 3 is for bridged interface. IN scenarios 5 and 6, why do we have dot1p=1 ingress? Provided that we have a pure L3 routed interface with MPLS enabled.

So the EXP bit should be honored with label swap. This is how I always thought it should work. But then I have a problem with one of my MPLS QoS implementation with a customer.

This is a long read. :-)

The customer has the following chain CE1-ME1-PE1-PE2-P1-P2-PE3-PE4-ME2-CE2 and running a L2 pseudo wire across the board from CE1 to CE2.

Classification and queueing looks as follows:

1.1 ME1 Ingress - classification DHSCP based, policing to contractual rates, marking with COS

1.2 ME1 egress - queueing COS based

2.1 PE1 ingress - classification COS based, marking with EXP and QoS groups

2.2 PE1 egress - queueing QoS group based

3.1 PE2 ingress - classification EXP based, marking with QoS groups

3.2 PE2 egress - queueing QoS group based

4.1 P1 ingress - classification EXP based, marking with QoS groups

4.2 P1 egress - queueing QoS group based

5.1 P2 ingress - classification EXP based, marking with QoS groups

5.2 P2 egress - queueing QoS group based

6.1 PE3 ingress - classification EXP based, marking with QoS groups

6.2 PE3 egress - queueing QoS group based

Between these steps EXP bits are not honored

7.1 PE4 ingress - classification EXP based, marking with QoS groups

7.2 PE2 egress - queueing QoS group based

COS is dot1p bits

EXP is MPLS EXP bits

QoS group is local QoS groups per router

DSCP is customer DSCP marking

 

When we first perform a label imposition in steps 2.1 - 2.2 (PE1 ASR 901), we set EXP bits as follows:

2.1 PE1 INGRESS

class-map match-all CM-QOS-COS-REALTIME-CLASS  match cos  5 ! policy-map PM-QOS-COS2EXP&QG-IN-V1.0  class CM-QOS-COS-REALTIME-CLASS   set mpls experimental imposition 5   set qos-group 5 ! interface GigabitEthernet0/1  service-policy input PM-QOS-COS2EXP&QG-IN-V1.0

2.2 PE1 EGRESS

class-map match-all CM-QOS-QG-REALTIME-CLASS  match qos-group 5 ! policy-map PM-QOS-QG-QUEUE-OUT-V1.0  class CM-QOS-QG-REALTIME-CLASS   priority ! interface GigabitEthernet0/5  service-policy output PM-QOS-QG-QUEUE-OUT-V1.0

There are more classes defined, I am just showing one as an example.

 

Now we forward the traffic from PE1 to PE2 (also ASR 901) and performing steps 3.1 - 3.2 as follows:

3.1 PE2 INGRESS

Here we see the traffic coming with correct EXP bits imposed by PE1, all good.

class-map match-all CM-QOS-EXP-REALTIME-CLASS  match mpls experimental topmost 5 ! policy-map PM-QOS-EXP2QG-IN-V1.0  class CM-QOS-EXP-REALTIME-CLASS   set qos-group 5 ! interface GigabitEthernet0/5  service-policy input PM-QOS-EXP2QG-IN-V1.0

3.2 PE2 EGRESS - should honor EXP bits with label swap

class-map match-all CM-QOS-QG-REALTIME-CLASS  match qos-group 5 ! policy-map PM-QOS-QG-QUEUE-OUT-V1.0  class CM-QOS-QG-REALTIME-CLASS   priority ! interface GigabitEthernet0/0  service-policy output PM-QOS-QG-QUEUE-OUT-V1.0

 

Now we forward the traffic from PE2 to P1 (ASR 9006 XR 5.3.1) and performing steps 4.1 - 4.2 as follows:

4.1 P1 INGRESS

Here we see the traffic coming with correct EXP bits imposed by PE1 and honored by PE2, all good.

class-map match-all CM-QOS-EXP-REALTIME-CLASS  match mpls experimental topmost 5 ! policy-map PM-QOS-EXP2QG-IN-V1.0  class CM-QOS-EXP-REALTIME-CLASS   set qos-group 5  ! interface GigabitEthernet0/0/1/0  service-policy input PM-QOS-EXP2QG-IN-V1.0

4.2 P1 EGRESS - should honor EXP bits with label swap

class-map match-all CM-QOS-QG-REALTIME-CLASS  match qos-group 5 ! policy-map PM-QOS-QG-QUEUE-OUT-V1.0  class CM-QOS-QG-REALTIME-CLASS   priority level 1   police rate percent 50 ! interface Bundle-Ether1  service-policy output PM-QOS-QG-QUEUE-OUT-V1.0

 

Now we forward the traffic from P1 to P2 (ASR 9006 XR 5.3.1) and performing steps 5.1 - 5.2 as follows:

5.1 P2 INGRESS

Here we see the traffic coming with correct EXP bits imposed by PE1 and honored by PE2 and P1, all good.

class-map match-all CM-QOS-EXP-REALTIME-CLASS  match mpls experimental topmost 5 ! policy-map PM-QOS-EXP2QG-IN-V1.0  class CM-QOS-EXP-REALTIME-CLASS   set qos-group 5  ! interface Bundle-Ether1  service-policy input PM-QOS-EXP2QG-IN-V1.0

5.2 P2 EGRESS - should honor EXP bits with label swap

class-map match-all CM-QOS-QG-REALTIME-CLASS  match qos-group 5 ! policy-map PM-QOS-QG-QUEUE-OUT-V1.0  class CM-QOS-QG-REALTIME-CLASS   priority level 1   police rate percent 50 ! interface GigabitEthernet0/0/1/1  service-policy output PM-QOS-QG-QUEUE-OUT-V1.0

 

Now we forward the traffic from P2 to PE3 (ASR 920 XE 03.18.00.SP) and performing steps 6.1 – 6.2 as follows:

6.1 PE3 INGRESS

Here we see the traffic coming with correct EXP bits imposed by PE1 and honored by PE2, P1 and P2, all good.

class-map match-all CM-QOS-EXP-REALTIME-CLASS  match mpls experimental topmost 5 ! policy-map PM-QOS-EXP2QG-IN-V1.0  class CM-QOS-EXP-REALTIME-CLASS   set qos-group 5 ! interface GigabitEthernet0/0/1  service-policy input PM-QOS-EXP2QG-IN-V1.0

6.2 PE3 EGRESS - should honor EXP bits with label swap

class-map match-all CM-QOS-QG-REALTIME-CLASS  match qos-group 5 ! policy-map PM-QOS-QG-QUEUE-OUT-V1.0  class CM-QOS-QG-REALTIME-CLASS   priority   police cir percent 50 ! interface TenGigabitEthernet0/0/25  service-policy output PM-QOS-QG-QUEUE-OUT-V1.0

 

Now we forward the traffic from PE3 to PE4 (also ASR 920 XE 03.18.00.SP) and performing steps 7.1 - 7.2 as follows:

7.1 PE4 INGRESS

Here we see the traffic coming with EXP bits DROPPED to 0.

I do not see any matches in CM-QOS-EXP-REALTIME-CLASS, all goes to BE class, that matches EXP 0

class-map match-all CM-QOS-EXP-REALTIME-CLASS  match mpls experimental topmost 5 ! policy-map PM-QOS-EXP2QG-IN-V1.0  class CM-QOS-EXP-REALTIME-CLASS   set qos-group 5 ! interface TenGigabitEthernet0/0/25  service-policy input PM-QOS-EXP2QG-IN-V1.0

So, on step 7.1 we detect a problem of dropping EXP bits to 0 on the previous step.

If we add "set mpls experimental topmost 5" to egress policy of PE3 on step 6.2, REALTIME traffic gets matched correctly by step 7.1.

I understand ASR 920 crimes is not directly your responsibility :-), just wanted a second opinion on the problem at hand.

Thanks a lot for your time while reading it!

Cheers

Alexei.

xthuijs
Cisco Employee

hi alexei,

that is quite a novel indeed, I can do that too! :) very descriptive btw, some thoughts/answers:

you know the scenario's painted above are somewhat hypothetical also, considering it makes no sense to have a dot1p of 1, an exp of 3 and an ipp of 5 that doesnt look like a uniform marking scheme :) it is merely to paint the picture of what internal COS we derive to show what the operations would be if you were not do anything on qos configuration.

one and other of this standard behavior was done in consultation with fellas from the MEF while we were implementing the EVC based model.

IOS devices follow the IEEE model and there are some differences there as you have noticed in the way trunking works, bridge domains, tagging significances, vlan rewrite policies and mtu to name a few :)

That would explain some differences between the 9xx and 9yyy series, which is horrific for users indeed that 2 products with almost the same numbers run different versions and have different (default) operations.

Now when it comes to QOS and defaults, in all my years I have not been able to identify a solid default that would go across the board all the way. One and other also depending on the policy (enforcement) a network wants to serve/provide.

The best recommendation I can give you is being aware of this default behavior, and use qos policies to either enforce the default behavior or to deviate from it.

In general it makes sense on the edge to classify and (re)mark (untrusted model) and use dot1q=exp=ipp type tagging so that you are not running into one platform limitations or capabilities as now it doesnt matter which header they look at or can, but always look at the same priority class.

cheers!

xander

wenqli
Community Member

Hi, Xander

I am wondering what is the queue size/limit for a VOQ and all its individual VQI? Any CLI command to verify this?

Another way of my question is that how many packets it can back up to ingress FIA queue before tail drop happens? Thanks

xthuijs
Cisco Employee

the FIA memory for Q'ing is 256M. technically a single VOQ can allocate that whole space, but that would mean that another voq requiring some buffering may not get any and tail drop.

therefore we cap the single voq usage to 50% of the space available.

show controller fabric fia stat q-depth shows you which voq is buffering and how many packets it is currently holding.

xander

wenqli
Community Member

HI, Xander

For example, one VOQ in Typhoon has 4 VQI. Does this mean every VQI has 32M buffer allocated ?

If packet size is 9000byte, the maximum number of packets can be hold without tail drop is around 32*1000*1000/8*9000 = 444 packets. Is this correct ? 

With the example of 192VOQ's in one FIA, since they're all sharing the same physical buffer, I'm thinking one VOQ can easily cause tail drop in another VOQ. Isn't it ?

xr-rules
Enthusiast

Hi,

our customer has a policy-map with police 800 Mbps. Default burst size is 80 Mbps (10%). They have configured the burst size with x3 of the default value, i.e. 240 Mbps. 

After some time a DDoS attack has occurred and traffic rate has jumped to 1.9Gbps. 

Can you please tell me how this is possible? Is this because of the large burst size?

xthuijs
Cisco Employee

hi smail,

mind you that when setting the burst, you allow it to go up to linerate pretty much. so the average rate whenever the burst is exercised will also increase the perceived average traffic rate.

with this large burst size, you would indeed expect the average rate to be higher, since you are replenishing tokens very frequently allowing a constant burst almost (or effectively a 3rd of the time pretty much.

generally I guess you'd want to define a time (>5msec) or a number of mtu times (10 to allow 10 paks burst).

if you really want to be "anal" about it, you would want to perceive the RTT/2 and use the calculation on that to help tcp smoothen the transmission to its max performance for that (one way) transmission delay. but this can lead to very high burst sizes again which as you noted also makes you more susceptible to drinking of a firehose during an attack.

cheers!

xander

xr-rules
Enthusiast

Thank you for the swift reply Xander.

This is the pmap.

policy-map 800_Mbps
class class-default
police rate 800 mbps burst 30000000 bytes
conform-action transmit
exceed-action drop
!
set dscp 0

So you are saying that the customer should define a time beside the 30000000 bytes? 

Under the configuration I can define ms, bytes, us, packets etc.

How can I add additional burst but also be protected from further attacks?

xthuijs
Cisco Employee

hey smail, you have a 2 color policer here, that is either accept or drop. to provide a bit more granularity you can opt for a 3 color policer whereby you can tolerate the yellow and possibly remark for it to be eligible for a later drop.

in the end between ms/us and bytes, the burst is programmed as a number of bytes. the usec/msec option gives you the ability to think in time as opposed to bytes.

you probably want to start with a 10xMTU and possibly increase from there or consider the 3 color policer. during CL this year I discussed the different policer options and some pros and cons with operation. check lasvegas 2017 id 2904 for some more details on that.

cheers

xander

xr-rules
Enthusiast

Great. I have the presentation and I will take a look at the QoS section.

Have a nice weekend!

Chris Mason
Beginner

Hi Xander,

 

Apologies if this has already been asked as I have been through most of the comments but couldn't find it.

 

On an ASR 9010 (IOS-XR 5.3.4), I am trying to determine if it is possible to mark sub-interface traffic (using layer 3 and 4 headers) when applying an ingress policy to the main interface of a l2transport and l3 routed interface?

 

In the l2transport scenario I have the following configuration:

 

 

ipv4 access-list ACL-CLA-NMGT
permit tcp host x.x.x.x eq 22 any
permit tcp any host x.x.x.x eq 22
!
class-map match-any CM-CLA-NMGT
match access-group ipv4 ACL-CLA-NMGT
!

policy-map PM-CLA
class CM-CLA-NMGT
set dscp cs2
!
class class-default
set dscp cs1
!
!

interface Gi0/7/0/8 service-policy input PM-CLA ! interface Gi0/7/0/8.501 l2transport encapsulation dot1q 501 rewrite ingress tag pop 1 symmetric ! interface Gi0/7/0/8.800 l2transport encapsulation dot1q 800 rewrite ingress tag pop 1 symmetric !

I am migrating some configuration across from a 7600 where we had a trunk port and I was able to mark traffic by applying a similar ingress policy to the switchport. In IOS-XR is it possible to match layer 3 and layer 4 information on the physical interface in this way or would I have to apply "PM-CLA" to each of the individual l2transport sub-interfaces?

 

 

In the same sense when working with l3 routed interfaces, is the following possible or would the same apply?

interface Gi0/7/0/9
 service-policy input PM-CLA
!
interface Gi0/7/0/9.200
 encapsulation dot1q 200
 vrf x
ipv4 address x.x.x.x/y
! interface Gi0/7/0/9.300 encapsulation dot1q 300
vrf y ipv4 address y.y.y.y/x !

The testing that I have done seems to imply this works, but I wanted to confirm if this is by design and not due to the way I have tested it.

 

Thanks,

Chris

Hi Xander,

 

For a 36x10G linecard which does not support ingress qos, how does VOQ works? Or how is it enabled? 

 

Thanks,

jagannath.iob
Beginner

Hi Xander,

 

we are having an issue while configuring service policys on the main and sub interface. here we are using Cisco ASR9k. Please find the below details and help us to resolve them.

 

show configuration failed

Fri Dec 15 14:11:26.359 UTC

!! SEMANTIC ERRORS: This configuration was rejected by

!! the system due to semantic errors. The individual

!! errors with each failed configuration command can be

!! found below.

 

interface TenGigE0/0/2/0

service-policy input POLICE-WAN-IN

!!% 'qos-ea' detected the 'warning' condition 'Ingress queueing features is not supported on this line card'

!

end

 

show configuration failed

Fri Dec 15 14:21:15.257 UTC

!! SEMANTIC ERRORS: This configuration was rejected by

!! the system due to semantic errors. The individual

!! errors with each failed configuration command can be

!! found below.

 

interface TenGigE0/0/2/2.403

service-policy input POLICE-CIO-IN

!!% 'qos-ea' detected the 'warning' condition 'Ingress queueing features is not supported on this line card'

service-policy output SHAPE-CIO-OUT

!!% 'qos-ea' detected the 'warning' condition 'priority cannot be configured without a finite rate policer/shaper'

!

end

 

Thankyou,

Jagan

Content for Community-Ad