X670 CPU defend against broadcast, multicast, IPV6

[Nikolay_Chernya]

Hi. Im preparing pair of x670-G1 for mlag production and in process of testing some fail scenarios in lab. Since production switches working in heavy l2 load enviroment, i have potential probability of broadcast\multicast storm.

X670 platform control plane protection desingn сompared to similar Huawei or Juniper Trident+ devices looks very poor.

Im running on 16.1\16,2 trail. 
Digging in to XOS guide gives me following:

Normally, x670 will send to CPU following packets:

0 : Broadcast and IPv6 packets

1 : sFlow packets

2 : vMAC destined packets (VRRP MAC and ESRP MAC)

3 : L3 Miss packets (ARP request not resolved) or L2 Miss packets (Software MAC learning)

 4 : Multicast traffic not hitting hardware ipmc table (224.0.0.0/4 normal IP multicast packets neither IGMP nor PIM)

 5 : ARP reply packets or packets destined for switch itself

 6 : IGMP or PIM packets

 7 : Packets whose TOS field is "0xc0" and Ethertype is "0x0800", or STP, EAPS, EDP, OSPF packets

Mitigation:

Like been said, XOS have not any centralised control plane policy like others. You cannot set rate of ARP or any other protocol hitting CPU.

1)Storm control on XOS 16.x is very coarse and cant preciesely control rate of BUM traffic - this is related to 15.625 ms time slots. So, if i have rate of 300pps on ports, setting flood control rate of 10000 will drop some little amount of packets.  This will help, but not much.

This behavior is fixed in 22.x trail, but since im on G1 devices, i cant upgrade, so no luck here.

2)Yes, i know about dos-protect, but it will not help me in case of storm. Too much source-destination pairs.

3)Policy. Yep, i can use optins like deny-cpu matching broadcast and IPV6.  But, i have complex scenario, where L3 ring, MPLS\VPLS. ERPS and OSPF is runnig. Maintainng this with such policy installed will be pure design.

After some testing, have some questions here: 
1)Why switch sends to CPU IPV6 Neighbor Advertisement , Neighbor Solicitation etc frames, when i dont have any IPv6 interface configured ?  Can i change this behavior ?
2) Same for ARP broadcast - i dont have any L3 interfaces in those vlans.

Currently on production switches i have following rates hitting CPU :

MC_PERQ_PKT(0).cpu0     :        35,948,519,436          +7,961,581           1,064/s
MC_PERQ_PKT(3).cpu0     :         1,844,892,096          +1,545,150               1/s
MC_PERQ_PKT(4).cpu0     :            28,464,148             +10,055
MC_PERQ_PKT(5).cpu0     :         3,008,692,593            +714,726              80/s
MC_PERQ_PKT(6).cpu0     :           191,770,235             +67,442              10/s
MC_PERQ_PKT(7).cpu0     :         2,289,556,745            +667,560              88/s

Will be glad to hear and advice about CPU protection on X670 platform.
 

[Necheporenko__N]

Hello Nikolay Chernyaev,

The interface cpu0 is the same kind of interfaces which are belongs to l2 domain. So by hardware design all broadcast should be replicated to all intefaces including cpu0.
That is why you could observe broadcast ARPs and IPv6 lifted up to the CPU in the MC_PERQ_PKT(0) queue. This is expected and could not be changed. In a case of a pure l2 vlan you could safely flood this in hardware and avoid them (acl action "redirect-vlan"). However for L3 vlans the hosts sending huge broadcast should be controlled.

Example for multicast case - https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-flood-service-multicast-in-a-hardwa... 

Best Regards,
Nikolay