cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
88608
Views
39
Helpful
240
Comments
xthuijs
Cisco Employee
Cisco Employee

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
xthuijs
Cisco Employee
Cisco Employee

child confirm policer means that the parent policer will always allow green traffic to go through if there is contention at the parent policer level.

if there is room at the parent policer level (eg tokens left) then yellow traffic from the children can be allowed.

In order to make that distinction there needs to be a color on the packet to see what the child policer marking is so the parent can make the right decission by looking at that color.

without a policer it is grey and it needs to be yellow or green for the policer to make a decisson

regards

xander

Carlos A. Silva
Level 3
Level 3

Hi, Xander:

I was wondering if you could help me out with the following: I'm working with a customer in trying to update their NPEs.  Basically customer sells L2VPN and L3VPN services.

Customer has 6500s (NPE) with SUP720B, that currently dual-home  to ASR9k (P for L3/NPE for L2).  there are actually 2 connections between the 6500 and each 9k. One is MPLS for L3VPN, the other is L2 so that the 9k can handle the L2VPN stuff.

We're trying to have L3/MPLS all the way to the NPE and get rid of the 6500, but when we look at cost, 6500 with SUP2T is far cheaper (3:1) and as far as I can tell would allow the functionality we're looking for. I was wondering if you have comparison between ASR9k and 6500/7600-SUP2T so I can take a look and see if there's something I might be missing. One our concerns would be the QoS side of things.

Thanks in advance,

c.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

Hi Carlos,

I'm not Xander, but let me take a stab at this.

Sup2T on Cat6500/C7600 is a big step forward compared to Sup720, but with regards to QoS you have to keep in mind that there is no support for queueing/shaping on Sup2T or any line cards that come with it.

Aleksandar

xthuijs
Cisco Employee
Cisco Employee

name's close enough aleks

few more things Carlos:

the on paper cost of one vs the other is may be a bit higher, but there are other factors to take into consideration:

OS consistency (OPEX reduction), density (eg price per 10g), power consumption (watts per 10G).

Interestingly 20 7609's would give you 5.6T, a single 9922 can give you 7.2T. Feature, scale and feature performance are other things to consider. But yeah it all depends on what you need and where right.

Also I would recommend connecting with your account team representatives, there may be trade in programs or things like that you could make use of. I am not sure however, but worth checking in.

Let me see if there is a side by side comparison between the two, in in the end however, "you get what you pay for".

regards

xander

Carlos A. Silva
Level 3
Level 3

Thanks so much for your reply, both Aleks and Xander.

I think we're on the same page as to the considerations that have to be made, considering customer is 'only' looking for stuff like L3VPN/QoS and L2VPN (ELINE/ELAN).

One thing did chatch my eye, though, Aleks:

that there is no support for queueing/shaping on Sup2T or any line cards that come with it.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/data_sheet_c78-451794.html

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-652042.html

As far as I can tell I do have a per-port 1p3q4t in, say, the WS-X6848 card for the 6500.

Am I missing something?

TIA,

c.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

Hi Carlos,

no, you are not missing anything. Cat6500 line cards do have per-port HW queues. It's just that in a typical service provideer environment, one will be hard pressed to implement the typical QoS policy requirements using per-port HW queues. Maybe in your customer's particular design you can find a way to do it. In general, only HQF provides the framework typically required by service providers. Hence when someone asks me about QoS in the context of ASR9k, I immediatelly think of HQF.

Aleksandar

Carlos A. Silva
Level 3
Level 3

Thank you very much, Aleksandar.

amit.bhagat
Level 1
Level 1

Hi Xander,

Could you please explain how policing works when applied to Parent or Grand-Parent policy shared between traffic ingressing from multiple interfaces of different line-cards? Where is policing done? As I understand, FIA is per LC. In case of multiple LCs, how is traffic metered?

Regards,

Amit.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

Hi Amit,

this is very straihgtforward on the ASR9000. Egress policing is applied as close as possible to the egress port: on the egress NP. At this point, it doesn't matter on which interfaces or line cards the traffic came in.

Aleksandar

amit.bhagat
Level 1
Level 1

Hi Aleksander,

Thanks for replying but I was wondering how policing works in 4-level H-QoS in Ingress direction.

Regards,

Amit.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

Hi Amit,

it's the same logic: as close as possible to the ingress port ==> on the ingress NP.

regards,

Aleksandar

amit.bhagat
Level 1
Level 1

Hi Aleksander,

This is starting to make some sense to me but I need one more clarification to solidify the concept. Consider this-

Traffic Ingressing to ASR9K on multiple LCs for the same service (VPLS, for example).

At Child-level, I am classifying traffic into 4 different classes.

At Parent-level, I am trying to Police for each class at a particular rate. <---- So this happens in NPU at each LC.

At GrandParent-level, I am trying to Police for entire VPLS at a particular rate. <--- This is where I am not sure how accumulated rate of each class is policed on NPUs of different LCs.

Could you please clarify?

Thanks.

Amit.

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

Hi Amit,

interesting concept, but I'm not sure that I understand how did you envisage to "police the entire VPLS". Policing is a congestion management mechanism. For it to kick in, you need a congestion to happen somewhere, meaning that some traffic must flow in certain direction (ingress or egress) across some entity on which the policing is applied. At the level of "entire VPLS", what would be your entity where you would apply the policer? How do you know at the level of "entire VPLS" what is ingress and what is egress?

On ASR9k, we support policing at two level of MQC policy hierarchy. If you have a 3 level MQC policy, policing is supported at child and parent level, not at grandparent.

Regards,

Aleksandar

amit.bhagat
Level 1
Level 1

Hi Aleksander,

I think this concept is quite popular with wholesale layer-2 SPs. Consider a wholesale layer-2 provider providing access network to retail SPs. At one end, the retail SPs connect their BNGs, and the other end the wholesale provider has its DSLAMs connected. This DSLAM could be shared among multiple retail SPs. The retail SPs provide different kinds of services but the wholesale SP must also check that the end customer is only allowed the bandwidth they paid for. The wholesale provider must also keep in check that the retail SP does not over utilize the access network.

Actually, this setup is already in place using other vendor in our network, but I want to understand how this is done using ASR9k.

Regards,

Amit.

xthuijs
Cisco Employee
Cisco Employee

if you spread the attachment circuits over multiple NP's there is no way you can have an aggregated shaper or something like that. the token buckets are not synchronised between NP's or LC's.

If they are on the same NP or interface (different vlans) you can use the shared policy instance functionality.

Could you maybe draw a picture as to what you have today or what you are looking for as there might be options.

You can do bridge domain accounting also and graph that out via eg mrtg that might be worth looking into.

controlling the bandwidth is generally done on a per AC bases.

regards

xander

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links