Re: Rate limit subscriber ASR9k BNG - Page 2

prague · ‎09-11-2021

Hi everyone ,

I use the policy map below to limit the subscriber, but when I try to use the whole package or when the speed test is at full load on router, I see packet losses. Anyone know the reason?

policy-map 20M
class class-default
police rate 20 mbps burst 3840000 bytes peak-rate 20 mbps peak-burst 7680000 bytes
conform-action transmit
exceed-action drop
!
!
end-policy-map

Thanks

prague · ‎10-15-2021

Working with shape. However, when the traffic is 20, the delays (ms) increases, probably due to the shape structure.

Aleksandar Vidakovic · ‎10-15-2021

On ingress, PPPoE control frames (Ethertype 0x8863) are prioritised, but PPPoE keepalives (Ethertype 0x8864) are not. If the CPE is continuously exceeding the ingress policer rate, it's possible that keepalives will be dropped.

prague · ‎10-15-2021

We're not rate limit pppoe right now. We are only limiting the interface as in the configuration I just wrote.. There is no such problem in our TR card type, on the same ASR9K in our tests.

I think this issue is related to our A9K-MOD400-SE card. Could the limiting structure be different?

Aleksandar Vidakovic · ‎10-15-2021

When you have an ingress policer applied to the subscriber interface and there's congestion, policer will start dropping. PPPoE keepalive packets are not getting preferential treatment, so they may be dropped as well. If 3 consecutive PPPoE keepalives happen to be dropped, subscriber session will flap.

The question is how realistic is this in real life scenario. By far the most traffic that subscribers originate is TCP. TCP window mechanism will never allow the subscriber to continuously generate high traffic rate, so the ingress policer may only instantaneously become oversubscribed. In that scenario it's highly unlikely that three consecutive PPPoE keepalives are dropped by the policer.

Btw, the config snapshot that you have shared from TenGigE0/0/0/0 is not likely to be from a BNG solution. Can you share the "sh subscriber running-config ..." and "sh policy-map interface"?

prague · ‎03-02-2022

Hi Aleksandar,

Current bng configuration is below . As seen in the screenshot, one of our main problems is that icmp is among in these drops.

interface TenGigE0/0/0/1
description ## BNG
!
interface TenGigE0/0/0/1.100
service-policy type control subscriber PPP
pppoe enable bba-group PPPOE
encapsulation ambiguous dot1q 100 second-dot1q any

dynamic-template
type ppp PPP_TPL
ppp authentication pap
keepalive 10 2
ppp lcp send-termreq-on-shutdown
ppp ipcp dns 172.16.12.40 172.16.12.41
ppp ipcp mask 255.255.255.255
accounting aaa list PPPOE type session periodic-interval 60
ipv4 verify unicast source reachable-via rx
ipv4 unreachables disable
ipv4 access-group S_Security_in ingress
ipv4 access-group S_Security_out egress
!
-----------------------------------------------------------

sh subscriber running-config interface name Te0/0/0/0.100.pppoe16141
Wed Mar 2 15:38:19.762 GMT
Building configuration...
!! IOS XR Configuration 6.7.3
subscriber-label 0x400b3d1
dynamic-template
type user-profile U8400b3d1
ipv4 unnumbered Loopback1001
ppp timeout absolute 359685 25
service-policy input 2M
service-policy output NET_5M_DOWN
vrf CGNAT_SUBS_VRF
!
type ppp PPP_TPL
accounting aaa list PPPOE type session periodic-interval 60
ipv4 verify unicast source reachable-via rx
ipv4 unreachables disable
ipv4 access-group S_Security_in ingress
ipv4 access-group S_Security_out egress
ppp ipcp dns 172.16.12.40 172.16.12.41
ppp ipcp mask 255.255.255.255
ppp authentication pap
keepalive 10 2
ppp lcp send-termreq-on-shutdown
!

Aleksandar Vidakovic · ‎03-02-2022

Can you show me the config of both policy-maps and related class-maps?

/Aleksandar

prague · ‎03-02-2022

policy-map NET_5M_DOWN

class class-default

police rate 5242880 bps burst 983040 bytes peak-burst 1966080 bytes

!

end-policy-map

policy-map 2M

class class-default

police rate 2097152 bps burst 393216 bytes peak-burst 786432 bytes

!

end-policy-map

During our tests we observed dropping icmp packages only on SE cards but we didn't encounter the same problem in the test on the TR card.

SE LC Tested: A9K-24X10GE-SE

TR LC Tested : A9K-36X10GE-TR

Aleksandar Vidakovic · ‎03-03-2022

I don't see how the policer in this case would be so selective to drop ICMP packets. Do you see total loss of ICMP packets or intermittent drops?

prague · ‎03-03-2022

Yes we see intermittent icmp packet drops when the subscriber starts using whole package . Do we have a chance to prioritize icmp so that it doesn't drop even in full use?

In full use under the same conditions, subscriber doesn't experience these intermittent icmp drops in ASR 1K

Aleksandar Vidakovic · ‎03-03-2022

There are two things you can try. The current peak-burst size is equivalent to ~0.6s of traffic on a 10Gbps interface. I would suggest increasing it to 1.5s. If you configure it in seconds instead bytes it's kind of easier to understand what the policer will do.

Alternatively, if you want to protect ICMP, you can always carve it into a separate class in the ingress QoS policy. You can use ACL or prec/dscp for matching.

prague · ‎03-03-2022

Honestly i have no idea how to do this. Is it possible to give an example for the first and second scenarios? (peak-burst size and prec/dscp for matching)

Thanks in advance

Aleksandar Vidakovic · ‎03-03-2022

One way to achieve protection of ICMP (presuming you'll be using precedence 5 for important ICMP traffic) would be this:

class-map match-any prec5
 match precedence 5
!
policy-map 2M
 class class-default
  service-policy 2M-Child
  police rate 2097152 bps burst 750 ms
!
policy-map 2M-Child
 class prec5
  priority level 1
  police rate 150 kbps burst 500 ms

This way you keep overall policer rate at 2Mbps, but you carve out a dedicated policer for prec 5 traffic. This is just a template, you may want to increase further the prec5 policer rate (up to the rate of parent policer rate) to ensure that ICMP will always be protected.

To see what's programmed in HW, use the "show qos interface ..." command:

RP/0/RSP0/CPU0:our9001#sh qos interface GigabitEthernet0/0/1/1 input
Thu Mar 3 19:39:11.482 CET
Interface: GigabitEthernet0_0_1_1 input
Bandwidth configured: 1000000 kbps Bandwidth programed: 1000000 kbps
ANCP user configured: 0 kbps ANCP programed in HW: 0 kbps
Port Shaper programed in HW: 0 kbps
Policy: 2M Total number of classes: 3
----------------------------------------------------------------------
Level: 0 Policy: 2M Class: class-default
QueueID: N/A
Policer Profile: 87 (Single)
Conform: 2096 kbps (2097152 bps) Burst: 196593 bytes (750 ms)
----------------------------------------------------------------------
Level: 1 Policy: 2M-Child Class: prec5
Parent Policy: 2M Class: class-default
QueueID: 131136 (Port Priority 1)
Policer Profile: 88 (Single)
Conform: 144 kbps (150 kbps) Burst: 9375 bytes (500 ms)
Child Policer Conform: TX
Child Policer Exceed: DROP
Child Policer Violate: DROP
Parent Policer Conform: TX
Parent Policer Exceed: DROP
Parent Policer Violate: DROP
----------------------------------------------------------------------
Level: 1 Policy: 2M-Child Class: class-default
Parent Policy: 2M Class: class-default
QueueID: 131138 (Port Default)
Parent Policer Conform: TX
Parent Policer Exceed: DROP
Parent Policer Violate: DROP
----------------------------------------------------------------------
RP/0/RSP0/CPU0:our9001#

Btw, you'll notice see that on asr9k we don't make a distinction between burst and peak-burst.