[c-nsp] Hardening LPTS

Saku Ytti saku at ytti.fi
Fri Jun 4 02:47:46 EDT 2021


Hey Mark,

> Any comments on this? @Saku Ytti you probably have good opinions and inside
> knowledge?

Sorry, not really. LPTS is quite a blockbox and there is not much you
can do to improve if you have actual control-plane issues after LPTS.
Unlike in Junos where you can have multiple levels of policers (flow
=> ifl => ifd => npu => aggregate) ASR9k has just npu level LPTS
policer, this means if the LPTS policers are being violated there is
collateral damage shared by all ports on NPU. We've had several
outages due to this, the typical reason is the customer has maybe an
L2 loop, and gives us a large rate of say ND/ARP, and all ports
experience L2 cache expiring and total outage.

You can protect yourself from this scenario to a degree with 'lpts
punt excessive-flow-trap' but it is very poorly documented and
understood by everyone, including Cisco. Infact whole LPTS is
extremely poorly understood by Cisco. We recently had an problem on
injection path which caused PE-CE BGP to time out, Cisco spent good
month trying to review our MQC config, even though we kept telling
them LPTS packets are not subject to MQC in either punt or inject
path, but they wouldn't have any of it.
But because LPTS is not subject to MQC you can't put MQC policy to
your customer QoS in, where you police arp/nd/bgp to avoid collateral
damage, as this MQC policy won't be consulted for LPTS punt.

As far as I am aware JNPR Trio is the only networking platform which
actually is possible to protect against motivated attackers, but it is
far too hard to configure correctly.

-- 
  ++ytti


More information about the cisco-nsp mailing list