Policer V/S Shaper in ASR9K

[arun.mallappally123]

Hi All,

Need your valuable view on the below query.

We have couple of internet customers terminated in ASR9K PW-HE interface ( CPE -->Access-PE --->Service-PE (ASR9K) PW-HE --->Internet). We applied egress policer in PW-HE egress direction (towards CPE). Customer is complaining that they are getting less download throughput and we are observing policer drops in the ASR9K also. So we are planning to change it to a egress Shaper to get better download throughput. 

1. What is the desired/efficient design for the internet download traffic , policer or shaper . We are planning shaper since burst from the internet in uncontrollable.

2. Is there any scaling issues, if we change policer to shaper. We would like to know the scale figure for both  shaper and policer in ASR9K (XR 6.3.3). Is the scale is per system or per LC. We are using tomahawk LC.

3. Is there any document for the scale reference of ASR9K.

Thanks,

Arun Mohan 

[Aleksandar Vidakovic]

In general policer is recommended on ingress and shaper on egress. But before you change the QoS design read about default policer burst sizes and how to modify them:

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-qos-default-marking-behavior-and/ta-p/3128709

If you want to deploy egress shaping instead of egress policer, the scale is a differentiator, but you can realistically hit the limits only in a high scale BNG scenario. I don't suppose any deployment has as many configured sub-interfaces as there are subscriber interfaces. For the exact QoS scale numbers, refer to one of the BRKSPG-2904 Cisco Live sessions:

https://community.cisco.com/t5/service-providers-documents/cisco-live-brkspg-2904-asr9000-selected-topics-and/ta-p/3844269

You can also look for BRKARC-2003.

/Aleksandar

[arun.mallappally123]

Hi Aleksandar,

Thanks a lot for the swift response. Really appreciate.

Our design is a single GIL system with multiple PW-HE's are mapped to it and each PW-HE's are having multiple sub-interfaces with internet customer (3000 Customer/box) terminated. One solution is to allow more burst to the policer so that traffic from the internet towards the CPE will not get dropped  but if all the customers are bursting at the same time, then the pin-down member will get congested .  That is the reason we are not increasing the policer burst instead planning to move to shaper.

Unfortunately I am not seeing any scale limit of shaper for tomahawk ( I can see only policer scale which is 32K/NPU for TR card) in the Cisco live doc. Could you please share the shaper limit for Tomahawk in 6.3.3.

1. When internet traffic hits the PW-HE interface, we will add two VLAN's to it so the packet overhead is 8bytes/packets. Since ASR9K consider L2 header also in to the Shaper action, We need to provision more than the Customer CIR to compensate the 8byte overhead/packet. Is there any recommendation for this over provisioning (for compensating the overhead)

2.  PW-HE traffic will be having two L2encap, one for PW-HE and second is core interface ethernet encap. Shaper applied on the PE-HE will account for these two overhead or only the first one?

Thanks,

Arun Mohan

[arun.mallappally123]

Hi,

Could you please help.

Thanks,

Arun Mohan

[Aleksandar Vidakovic]

On Tomahawk we support 1 million queues per NP. For 3000 customers per chassis, you we not likely to hit any scale limit.

You can configure the accounting overhead of choice using the "service-policy {input|output} <policy_name> account user-defined <bytes>". Granularity of shaping overhead is 4 bytes.

Accounting in QoS policies applied to PW-Ether takes into account the entire encapsulated frame (including the encapsulated ethernet header). It doesn't take into account the encapsulation header (outer Eth header, MPLS headers and optional control word).

[arun.mallappally123]

Hi Aleksandar,

Good day!

Thanks a lot for the swift response and apologies for more questions.

On Tomahawk we support 1 million queues per NP ==> I believe this limit includes queues created by the Bandwidth , Priority and Shape average commands. Is there any specific limit for shaper/NPU and Shaper/LC. We are using A99-8*100GE-CM line card.How CM is different from TR and SE.

You can configure the accounting overhead of choice using the "service-policy {input|output} <policy_name> account user-defined <bytes>". Granularity of shaping overhead is 4 bytes. == > My apologies, I don't understand "Granularity of shaping overhead is 4 bytes", is it means, if I configure user-defined as "5 or 6" bytes, system will round it off to "4bytes". (I tried to enter  user-defined 9 in one of our lab device running 6.3.3 and is it showing as "9" only in the running-config)

For ex: if one of our customer BW is 100Mbps  and  in case of two vlan overhead, we are adding 8% extra to the policer/shaper (108mbps will be configured instead of 100Mbps) . What is the difference if I am adding account user-defined 8", is the system will add extra mbps to the configured value  (if yes, how much ) or will ignore 8bytes from each frame when doing the shaping or policing.

Thanks,

Arun Mohan

[Aleksandar Vidakovic]

hi Arun,

at level 2, there are 4k queues per chunk. Each Traffic Manager (TM) chip on the NP has 4 chunks. This translates into 4k grandparent shapers (with only a class-default at that level), per chunk. You can bind a sub-interface to a chunk by using the " service-policy output <name> subscriber-parent resource-id <0-3>" command. At level 3, there are 32k queues per chunk. At level 4, there are 256k queues per chunk.

If you configure an overhead that's not a multiple of 4, HW will round it up to the closest multiple of 4. When you define the overhead of 8 bytes and say a packet that needs to be transmitted has 576 bytes, the shaper will consider that this packet actually has 584 bytes.

/Aleksandar

[arun.mallappally123]

Hi Aleksandar,

Thanks for the swift response and apologies for dragging the thread.

Regarding the scheduler hierarchy  levels, I referred many documents also Cisco live presentation but unable to understand the concept clearly. As per my understanding  Child policy is "L4" , Parent is "L3" , Grand parent is "L2"  and the physical port level policies are "L1&L0".

Just want to understand the hierarchy levels of the below policy-maps since there is no GRANT PARENT policies.

1. 

policy-map POLICY-PARENT   <<< is this parent policy is "L2" or "L4" ?
class class-default
service-policy POLICY-CHILD
shape average <Rate> mbps
!
end-policy-map
!
policy-map POLICY-CHILD   <<<is there any hierarchy since there is no queuing ? 
class class-default
set mpls experimental imposition 4

2. 

policy-map POLICY-PARENT <<<<  Is this "L2" or "L3" policy.
class class-default
service-policy  POLICY-CHILD
shape average <Rate> mbps
!
end-policy-map
!

policy-map POLICY-CHILD   >>> Is this "L4"
class CLASS-1
priority level 1
police rate percent <Number>
conform-action transmit
confirm-action set mpls experimental imposition 5
exceed-action drop
!
!
class CLASS-2
bandwidth remaining percent <Number>
set mpls experimental imposition 3

class CLASS-2
bandwidth remaining percent <Number>
set mpls experimental imposition 2

3.

policy-map POLICY-PARENT >>> Is this "L4" or "L2"
class class-default
service-policy POLICY-CHILD
shape average <Rate> mbps
!
end-policy-map
!

policy-map POLICY-CHILD <<<is there any hierarchy since there is no queuing ? 
class CLASS-1
priority level 1
police rate percent <Number>
conform-action transmit
confirm-action set mpls experimental imposition 5
exceed-action drop

4. 

policy-map 100Mbps-IA-NoQoS-Egress <<< Is this "L4" or "L2"

class class-default

  set mpls experimental imposition 0

  shape average 5000 mbps 500 kbytes

 !

 end-policy-map

Thanks,

Arun Mohan

[Aleksandar Vidakovic]

hi Arun,

you can interpret the levels like this:

On Typhoon:

• L1: port
• L2: grandparent
• L3: parent
• L4: child

On Tomahawk:

• L0: plughole on the LC faceplate. This is identical to a "port" if you're not using breakout.
• L1: port in case you're using breakout
• L2: grandparent
• L3: parent
• L4: child

Hope this helps,

/Aleksandar

[arun.mallappally123]

Hi Aleksandar,

Thanks a lot for the swift response.  One last question.

We have below policies applied to PW-HE sub-interfaces. Just want to understand the hierarchy levels of the below policy-maps since there is no GRANT-PARENT policies. And also I read in some documentation that "L4" is the policy-map where the first queuing action  take place (Top in the hierarchy) 

All these policies are applied to PW-HE sub-interface and there is no policy in the PW-HE main interface. Reason for this question is recently we came to know that there is a shaper limitation of 4G in the "L4" hierarchy for tomahawk LC.  

1. 

policy-map POLICY-PARENT   <<< is this parent policy is "L2" or "L4" ?
class class-default
service-policy POLICY-CHILD
shape average <Rate> mbps
!
end-policy-map
!
policy-map POLICY-CHILD   <<<is there any hierarchy since there is no queuing ? 
class class-default
set mpls experimental imposition 4

2. 

policy-map POLICY-PARENT <<<<  Is this "L2" or "L3" policy.
class class-default
service-policy  POLICY-CHILD
shape average <Rate> mbps
!
end-policy-map
!

policy-map POLICY-CHILD   >>> Is this "L4"
class CLASS-1
priority level 1
police rate percent <Number>
conform-action transmit
confirm-action set mpls experimental imposition 5
exceed-action drop
!
!
class CLASS-2
bandwidth remaining percent <Number>
set mpls experimental imposition 3

class CLASS-2
bandwidth remaining percent <Number>
set mpls experimental imposition 2

3.

policy-map POLICY-PARENT >>> Is this "L4" or "L2"
class class-default
service-policy POLICY-CHILD
shape average <Rate> Mbps
!
end-policy-map
!

policy-map POLICY-CHILD <<<is there any hierarchy since there is no queuing ? 
class CLASS-1
priority level 1
police rate percent <Number>
conform-action transmit
confirm-action set mpls experimental imposition 5
exceed-action drop

4. 

policy-map 100Mbps-IA-NoQoS-Egress <<< Is this "L4" or "L2"

class class-default

  set mpls experimental imposition 0

  shape average 5000 mbps 500 kbytes

 !

 end-policy-map

Thanks,

Arun Mohan

[Aleksandar Vidakovic]

hi Arun,

queueing happens only once, at the highest level in the scheduler hierarchy (L4). All the other levels have schedulers, but no queues. This is explained well in one of the BRKSPG-2904 Cisco Live sessions. If you google "community.cisco.com BRKSPG-2904" you'll find an index page that lists the agenda of all BRKSPG-2904 sessions in the last 6 years.

A QoS policy applied to PW-Ether is effectively applied to the scheduler hierarchy of all generic interfaces bound to the PW-Ether. 

/Aleksandar

[arun.mohan@colt.net]

---

Hi Aleksandar,

Thanks a lot for your support.

Thanks,

Arun Mohan

[arun.mallappally123]

.

[arun.mallappally123]

.