ASR9000 QoS on Subinterfaces. Use individual Policies

[victor.lyapunov]

Hello

I need some help tounderstand how QoS works in ASR9K and the capabilities it offers.

Typically We terminate multiple metro ethernet clients at Gigabit interfaces (each client having a dedicated subinterface of his own)
We need to apply for each subinterface shaping + bandwidth reservation according to the client needs.

One way is have a policy applied to the GigE interface with multiple classes that match individual vlan-ids for each subinterface. But I am
afraid that this approach will soon lead to very big policies that are difficult to maintain.

Is is possible to create individual policies - one for each client, that :
- will be applied to the corresponding subinterfaces
- In case of congestion in the major interface will ensure that the bandwidth is allocated according to the rates defined in each policy

For example if we have three clients / subinterfaces:

interface Bundle-Ether30002.100
 service-policy output CLIENT_100
 ipv4 address 10.0.100.1 255.255.255.252
 encapsulation dot1q 100
!
interface Bundle-Ether30002.101
 service-policy output CLIENT_101
 ipv4 address 10.0.101.1 255.255.255.252
 encapsulation dot1q 101
!
interface Bundle-Ether30002.102
 service-policy output CLIENT_102
 ipv4 address 10.0.102.1 255.255.255.252
 encapsulation dot1q 102
!
!
!
policy-map CLIENT_100
 class CLIENT_100
  shape average 500 mbps
  bandwidth remaining ratio 50
 !
 end-policy-map
!
policy-map CLIENT_101
 class class-default
  shape average 500 mbps
  bandwidth remaining ratio 30
 !
 end-policy-map
!
policy-map CLIENT_102
 class class-default
  shape average 500 mbps
  bandwidth remaining ratio 20
 !
 end-policy-map
!

I would like to make sure that during congestion in the major interface, the remaining bw is allocated to each subinterface
according to CLIENT 100 = 50%, CLIENT 101 = 30%, CLIENT 102 = 20% using policies that are applied on the subinterfaces.
- Is there any way to achieve this or the only solution is use a hierarchical policy in the major interface?
(The config above does not work as intented the traffic will be equally allocated among the three subinterfaces)

I have seen in the documentation refering to service-fragments but have not been able to test them. Can they help me in this
setup?

Thank you

[xthuijs · Accepted solution]

the way you probably want to do this is by defining shapers for the desired rate in a parent child model like this:

policy-map RATE-X

class class-default

shape average <x>

service-policy child

And a child policy to set a queue limit (buffer limitation)

policy-map child

class class-default

queue-limit 10 packets (or something)

when you apply the policy-map RATE-X/Y/Z to the subinterfaces they will get their assigned rate and when there is congestion they will get a fair share based on their parent rate.

shape sets the PIR, badnwidth sets the CIR.

more info? check cisco live ID 2904 from 2013/orlando and 2014/sanfran.

xander

[victor.lyapunov]

Happy new year, by adding the Child policy it worked. I cannot understand why it worked. In the presentations mention that asr9k support 4 layers of Hierarchical Queuing.

In the test I used initially only the first two:

- L1 (is port level) where congestion occurs

- L2 (subscriber group) should be the subinterface level

The test worked as inteneded only after adding a Child policy (this should correspond to L4 class level)

So for bandwidth allocation in asr9k we need to define policies with at least 3 levels of queing?

Thanx for your help

[xthuijs]

hi victor,

a single shaper in a flat policy map won't do a hell of a lot at the subinterface level. it needs to shape over something and since we don't have individual queues for the subinterfaces with a flat pmap having a shaper only, they all try to do their own thing over the parent interface default queue it has.

So by making it hierarchical, we create a queue from the child policy map over which we apply the parent shaper. Now we have an individually created queue defined for the subif, that will enqueue towards the parent interface queue.

You are correct that there are 4 levels of shaping and here we effectively use the queing hierachy of L3.

(L4 would be the child classes which we have not explicitly defined)

L1 would be the phy port shaper.

the document on asr9000 quality of sevice architecture here on the forums details it out a bit more (I think I covered it as part of one of the discussions on the document). As well as the CLive preso's referenced.

regards

xander

[CC11]

Hi Xander,

I too would like to have individual service policy per subinterface, though I don't need the parent policer on the physical port.

From the command reference, it said only 2000 policy-map could be created but I was told 10000(don't know at what level)

Currently we have RSP440-TR & MOD 80-TR, how many policy-map could be created per system/LC/NP?

Thanks!!

Chris

[xthuijs]

hi chris,

with the TR linecards (RP not a factor here) you have only 8 Q's per interface.

the statements bandwidth and priority create queues. a policer only or marker does not use a queue.

So if you have a policy that has one PQ, a bandwidth queue a marker in another class and a policer in the 4th, you will need 2 Q's and you can only apply this then to 4 subinterfaces.

on the SE cards you have 512k queues, and you can configure 10k unique policy-maps in the system.

regards

xander

[CC11]

Hi Xander,

For my case, the service-policy have policers only, all traffic are best effort.

I have applied 1024 in + 1024 out different policy-map to different subinterfaces in the Lab (one sample config. is attached FYR). Then failed on the 1025th one. I have tried to applied the 1025th one to another interface of the same MOD80-TR but failed too.

Is this the limit of the max. no. of policers? (now I have 1024 policy x 2 class x 2 (in + out)=4096 policers). I think I am missing something here as it should be 8k policers /NPU. (https://supportforums.cisco.com/discussion/11782221/a9k-mod80-se-a9k-mod80-tr-difference)

I don't have another MOB80-TR to try on. Would this be a system limit or I could apply more policers to different MOB80-TR.

(Current IOS-XR version: 4.3.4)

Thanks a lot for your help!!

Regards

Chris

 policy-map 1001_IN
  class AAA
   police rate 2500 kbps burst 468750 bytes
    conform-action transmit
    exceed-action drop
   !
  !
  class BBB
   police rate 1 mbps burst 187500 bytes
    conform-action transmit
    exceed-action drop
   !
  !
  class class-default
  !
  end-policy-map
 !
 policy-map 1001_OUT
  class AAA
   police rate 2500 kbps burst 468750 bytes
    conform-action transmit
    exceed-action drop
   !
  !
  class BBB
   police rate 1 mbps burst 187500 bytes
    conform-action transmit
    exceed-action drop
   !
  !
  class class-default
  !
  end-policy-map
 !

interface TenGigE0/0/0/0.1001
 service-policy input 1001_IN
 service-policy output 1001_OUT
 ipv4 bgp policy propagation input qos-group destination
 ipv4 address 10.0.1.1 255.255.255.248
 ipv4 unreachables disable
 encapsulation dot1q 1001
!

!!!!!!!!!!!!!!!!!!!

interface TenGigE0/0/0/0.2025
 service-policy input 2025_IN
!!% 'km' detected the 'warning' condition 'KM reaches max policymap supported'
 service-policy output 2025_OUT
!!% 'km' detected the 'warning' condition 'KM reaches max policymap supported'
!

[xthuijs]

hi chris,

correct, you have 8k policers (but note that there are some reserved for lpts). in this case however you exhausted the number of pmaps that could be configured on the NPU which is 2k.

I see in and out for this 1001 example being the same, I would just leave it be one policy then and reuse/attach it to all interfaces that need it. that saves config and also will prevent this limitation of 2k being hit.

cheers

xander

[Phil Clemens]

Xander, you bring up a question I had under XE, and now under XR as well.  In my case I have many customers who subscribe to 50Mbps service, which is policed on our XE routers.  I considered creating a single 50Mbps policy that I would use against every applicable interface.  However, I was concerned that every interface would count against the same sum of 50Mbps, leaving everybody with about 500Kbps.  So, it sounds like under XR I can use a policy map and apply it both in and out on any number of applicable interfaces.  Is that also the case with XE on an ASR1K?

[xthuijs]

hi phil,

this would apply to both a1k and a9k and effectively how every forwarder would operate:

in the absence of any shaping policy, all interfaces, whether it be subscribers or vlan subinterfaces etc, will share the same egress queue.

what feeds that egress queue is the above laying circuits.

that means if the phy interface is say 100M, and you have 3 subinterfaces on top of that each having a say 50M policer; all 3 of them at max would feed 50M = 150M to the egress queue, which it cannot hold, MDRR/WRR/WFQ or any other sort of q'ing mech would take the paks from the 3 feeders and probably would hopefully give about a 3rd to each circuit, but it is not said/guaranteed that way either!

so with policers you merely "cap" what goes into a "shared" queue. whether that queue is shared between different subinterfaces/subscribers or whether that is part of a parent shaper riding on top of the child policy for that individual subinterface/subscriber.

with shapers, you cannot oversubscribe the *guaranteed* bw. that is defined by CIR, which on a9k in this case is 64k specifically, unless defined by the bw keyword.

the shape av rate here is what the PIR is. but PIR is not guaranteed. CIR is.

so here the CIR will define the weight that this circuit will get in case there is congestion to give in a weighted ratio.

so in short, regardless of the bw of a circuit, you can provide and oversubscribe the policed bw no problem, when there is a congestion, the behavior is less controlled.

you can control that by a shaper. and use the CIR to provide the weight of that circ.

oh hey also I had a specific topic on that also during cisoc live this year in vegas, check out session id 2904 and check the qos section. also in 2015 in san diego we discussed this on what service rates mean and how these weights are used etc. I think that will help also.

cheers!

xander

[Phil Clemens]

Thanks, Xander.  My question was on a more basic level.  If I have 10 customers that all subscribe to 50Mbps, I can have a single 50Mbps policy map defined and apply it to all 10 sub-interfaces.  Rather than have 10 individual 50Mbps policy maps.  In terms of oversubscription of a PHY, and the QoS around that, that's where I need to watch the presentations and do some reading.

[xthuijs]

oh haha!! sorry about that phil! :) but yes you are correct, you can define one policy of whatever rate and apply it to all subinterfaces. each subinterface will instantiate its own policer.

cheers

xander

[Sumanta Ghosh]

Hi Xander

Will the below shaping work, if applied to egress interface running labelled e-BGP peering with a customer? The interface is TenGigE with sub-interface VLAN. Total traffic should not exceed 1 Gbps.

policy-map to_customer-1_egress
 description ***Outbound policy map for customer-1 uplink***
 class class1
  shape average 50 mbps
  bandwidth percent 5
 !
 class class2
  shape average 100 mbps
  bandwidth percent 10
 !
 class class3
  shape average 100 mbps
  bandwidth percent 10
 !
 class class4
  bandwidth remaining percent 30
 !
 class class5
  bandwidth remaining percent 30
 !
 class class6
  bandwidth remaining percent 30
 !
 class class-default
  bandwidth remaining percent 10
 !
 end-policy-map
!

!

interface TenGigE0/0/0/15.2339
 description ***Customer-1_Uplink-ASR-2***

 service-policy output to_customer-1_egress

!

Regards,

Sumanta.

[Aleksandar Vidakovic]

It will not work for several reasons. The first is that the BW guarantee is higher than configured shaper; this is a contradicting request. Second is that mixing "bandwidth [percent]" and "bandwidth remaining [percent]" at the same level is not supported. It would be the best if you took this configuration to a router and try to commit. If the configuration commit fails, the system will provide a very good description of the reason. You simply need to run "show configuration failed".

/Aleksandar

[Sumanta Ghosh]

Hi Aleksandar

Thanks. Commit worked fine. I am yet to apply service policy to the interface. Do you think I will get error during that time?

Regards,

Sumanta.