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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
