Using QOS to police control-plane traffic to local device

Adam Vitkovsky · ‎07-12-2018

Is it really not possible to police control-plane traffic to local device, that is otherwise be subject to the LPTS please?

The problems with LPTS is that its policers are only on aggregated per LC per NPU per protocol bases, I’m missing the per interface/sub-interface policer granularity.

Thank you

adam

netconsultings.com

::carrier-class solutions for the telecommunications industry::

adam

Aleksandar Vidakovic · ‎07-13-2018

hi Adam,

you can configure an ingress QoS policy on the sub-interface. Alternatively, you could also consider the EPFT ("lpts punt excessive-flow-trap ..."), which polices punted traffic on a per-source basis, if the punt rate exceeds the threshold.

/Aleksandar

Adam Vitkovsky · ‎07-18-2018

Thank you very much Aleksandar,

I was gonna try the QOS on ingress but now it seems I have a bigger problem.

I tried to match OSPF or PIM and didn’t get any matches.

So I tried very generic policy –and it seems I can’t get the QOS to match anything at all.

(although I have ICMP (data) as well as OSPF and PIM (control) traffic running)

What I have is:

policy-map TEST

class class-default

police rate 10 mbps

conform-action transmit

exceed-action drop

!

end-policy-map

interface TenGigE0/0/0/15

service-policy input TEST

show policy-map targets

Wed Jul 18 12:41:29.917 EDT

1) Policymap: TEST Type: qos

Targets (applied as main policy):

TenGigE0/0/0/15 input

Total targets: 1

Targets (applied as child policy):

Total targets: 0

sh qos int TenGigE0/0/0/15 in

Wed Jul 18 12:42:10.205 EDT

Interface: TenGigE0_0_0_15 input

Bandwidth configured: 10000000 kbps Bandwidth programed: 10000000 kbps

ANCP user configured: 0 kbps ANCP programed in HW: 0 kbps

Port Shaper programed in HW: 0 kbps

Policy: TEST Total number of classes: 1

----------------------------------------------------------------------

Level: 0 Policy: TEST Class: class-default

QueueID: 98 (Port Default)

Policer Profile: 61 (Single)

Conform: 10000 kbps (10 mbps) Burst: 125000 bytes (0 Default)

Child Policer Conform: TX

Child Policer Exceed: DROP

Child Policer Violate: DROP

----------------------------------------------------------------------

RP/0/RSP0/CPU0:nyc.dc1.hub1.asr9010#sh policy-map int TenGigE0/0/0/15 input

Wed Jul 18 12:43:04.441 EDT

TenGigE0/0/0/15 input: TEST

Class class-default

Classification statistics (packets/bytes) (rate - kbps)

Matched : 0/0 0

Transmitted : N/A

Total Dropped : 0/0 0

Policing statistics (packets/bytes) (rate - kbps)

Policed(conform) : 0/0 0

Policed(exceed) : 0/0 0

Policed(violate) : 0/0 0

Policed and dropped : 0/0

RP/0/RSP0/CPU0:nyc.dc1.hub1.asr9010#sh int TenGigE0/0/0/15 | in input

Wed Jul 18 12:45:05.490 EDT

output flow control is off, input flow control is off

Last input 00:00:00, output 00:00:00

30 second input rate 211000 bits/sec, 215 packets/sec

14185362 packets input, 881437330 bytes, 8129 total input drops

167 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

It’s been a while since I played with ASR9k, I seem to recall some HW counters –but that’s probably related ACL counters, not QOS counters.

I’d welcome any pointers please.

Thank you very much

adam

Aleksandar Vidakovic · ‎07-18-2018

Packets that we classify as network control packets are bypassing feature processing in the microcode.

Adam Vitkovsky · ‎07-26-2018

Thank you very much Aleksandar and sorry for the late reply,

Thank you for the confirmation, so that actually answers my original question in that there’s no way how I can rate limit a particular eBGP session on a particular interface then and I have to rely on the aggregate per NPU dropping which affects all eBGP sessions on a given NPU if triggered.

Just out of curiosity is this inability to use QOS on “to-us” CP traffic because everything in the CTRL queue on pre-classifier gets punted to the internal path straight away and never enters the NPU pipeline please?

EPFT

The lpts punt excessive-flow-trap also doesn’t give me the desired flexibility of per session policing unfortunately.

The granularity can be per interface (I guess physical) with “interface-based-flow “ enabled

But then the “penalty-rate” can be set only per IP (ipv4/v6 combined) for instance I can’t say just TCP or just BGP for that matter.

(although “penalty-timeout” has option to specify OSPF and BGP –isn’t this just missing from the “penalty-rate” command please?)

But I guess I could use:

“lpts punt excessive-flow-trap non-subscriber-interfaces mac” –maybe to enable per mac granularity?

Also the rate of max 100pps is quite conservative, isn’t it?

Thank you very much

adam

netconsultings.com

::carrier-class solutions for the telecommunications industry::

adam

Aleksandar Vidakovic · ‎07-26-2018

hi Adam,

correct, LPTS will work best when you identify bad actors based on MAC address. In case of BGP this can help if the eBGP peer is directly connected (which should usually be case).

Can you explain better what you want to achieve and with what motive? The LPTS implementation on all XR routers already separates BGP sessions into unknown (default), configured and known. Hence a router pretending to be our BGP peer can never impact the already established BGP sessions. If you worry that an already known BGP peer can start misbehaving, that's an issue raising a concern, but if that's a directly connected eBGP peer, QoS policy on an interface can take care of that...

/Aleksandar

Adam Vitkovsky · ‎07-26-2018

So there are two concerns:

a) Policers are per protocol, one BGP customer having a L2 loop, and all BGP customers in NPU suffer (my hope is, that the excessive flow trap per mac may address this hopefully)

b) LPTS packets are not subject to MQC, so you cannot complement LPTS with MQC. Imagine one customer congesting specific LPTS policer, and you want to add MQC policer to an interface, to relieve the LPTS policer from all the trash generated by this misbehaving customer, that seems not possible.

adam

netconsultings.com

::carrier-class solutions for the telecommunications industry::

adam

Aleksandar Vidakovic · ‎07-31-2018

hi Adam,

your bullet point (a) describes a scenario where the BGP peer is connected to the asr9k through a L2 switch (vs point-to-point connection) and a loop happens in that L2 domain. This is typical for the Internet Exchange. Should we have a loop in that broadcast domain, we'd have a much bigger problem on our hands. :) But in that case the EPFT based on source MAC will address your concern.

I also see the reasoning behind bullet point (b). In release 6.5.1 this scenario will be addressed automatically at TCP level. A misbehaving source will be detected and a LPTS policer specific to that flow will be installed. Thus other BGP sessions will be protected.

/Aleksandar