On QFX5000 series switches using an L2 (layer-2 i.e. configured with "family ethernet-switching") switch, transit OSPF packets may be redirected to the RE while they are switched to corresponding interfaces in the same VLAN. TCPDUMP on ports configured as pure L2 would show transit OSPF packets that are being sent to RE. Hence, any excess multicast traffic destined to 224.0.0.5 (OSPF Hello) received on a QFX L2 interface could cause RE CPU spike and Latency issues.
On a QFX5000 series switch, when multicast traffic destined to 224.0.0.5(OSPF Hello) is received on an L2 interface with no IRB or OSPF configuration, the OSPF packets are directed to the RE.
Topology:
MX (L3)-----ae15----(L2 trunk)QFX(L2 trunk) ge-0/0/94-----ge-0/0/46 EX4300 OSPF is between MX and EX4300. QFX is a transit L2 switch
Note: This issue is seen when the port is configured as a single physical port or LAG.
root@MX960> show ospf neighbor Address Interface State ID Pri Dead 110.1.1.2 ae15.0 Full 192.168.185.20 128 32 root@EX4300> show ospf neighbor Address Interface State ID Pri Dead 110.1.1.1 ge-0/0/46.0 Full 10.85.173.182 128 36 root@QFX-DUT> show configuration interfaces ae15 unit 0 { family ethernet-switching { interface-mode trunk; vlan { members [ vlan1 vlan2 ]; } } } root@QFX-DUT> show configuration interfaces ge-0/0/94 unit 0 { family ethernet-switching { interface-mode trunk; vlan { members [ vlan1 vlan2 ]; } } } root@QFX-DUT> show configuration vlans vlan1 { vlan-id 100; } vlan2 { vlan-id 200; } root@QFX-DUT> monitor traffic interface ae15.0 no-resolve verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on ae15.0, capture size 96 bytes 14:52:28.739414 In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60 14:52:36.472854 In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60 14:52:44.618814 In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60 14:52:52.679959 In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60
These transit packets are being treated as OSPF and redirected to RE as per the below dynamic filter. The OSPF dynamic filter counter increments for each packet (OSPF) destined to 224.0.0.5 and the filter action for this is to copy-to-cpu.
FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0 ... 41 U: 0 G:10 E: 66 H:0 A:CRV stat (id 66 val 0x00000001EF8440B2) P:00000001 I4: COSQ 36 -ospf-pkts <--- 41 U: 0 G:10 E: 67 H:0 A:CRV stat (id 67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts ... FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0 ... 41 U: 0 G:10 E: 66 H:0 A:CRV stat (id 66 val 0x00000001EF8440B3) P:00000001 I4: COSQ 36 -ospf-pkts <--- 41 U: 0 G:10 E: 67 H:0 A:CRV stat (id 67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts ... FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0 ... 41 U: 0 G:10 E: 66 H:0 A:CRV stat (id 66 val 0x00000001EF8440B4) P:00000001 I4: COSQ 36 -ospf-pkts <--- 41 U: 0 G:10 E: 67 H:0 A:CRV stat (id 67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts ... TFXPC0(vty)# set dc bc "fp show entry 66" HW (unit 0) EID 0x00000042: gid=0xa, slice=4, slice_idx=0x4d, part =0 prio=0x1, flags=0x10602, Installed, Enabled tcam: color_indep=1024, DstIp6 Offset: 8 Width: 128 DATA=0xe0000005 MASK=0xffffffff InPorts DATA=0x00000000000000000000000000000000000001fffffffffffffffffffffffffe MASK=0x00000000000000000000000000000000000001ffffffffffffffffffffffffff Drop Offset: 157 Width: 1 DATA=0x00000000 MASK=0x00000001 StageIngress Stage SrcVirtualPortValid Offset: 141 Width: 1 DATA=0x00000000 MASK=0x00000001 IngressStpState Offset: 245 Width: 2 DATA=0x00000003 MASK=0x00000003 slice=5, slice_idx=0x4d, part =1 prio=0x1, flags=0x10204, Installed, Enabled tcam: color_indep=0, EtherType Offset: 24 Width: 16 DATA=0x00000800 MASK=0x0000ffff action={act=CosQCpuNew, param0=36(0x24), param1=0(0x0), param2=0(0x0), param3=0(0x0)} action={act=RedirectVlan, param0=0(0x0), param1=0(0x0), param2=0(0x0), param3=0(0x0)} policer= statistics={stat id 66 slice = 4 idx=9 entries=1}{PACKETS.EN_US}
The dynamic filters for OSPF are installed during the init time when chassis/FPC is restarted, so the installation of these dynamic filters for OSPF are not configuration driven.
This is a platform limitation for QFX5000 series switches.
As a workaround, use lo0 filter to drop the transit OSPF packets on DUT when there is no OSPF configuration.
root@QFX-DUT# show interfaces lo0 unit 0 { family inet { filter { input ospf-block; } } } root@QFX-DUT# show firewall family inet filter ospf-block term BLOCK-OSPF { from { protocol ospf; } then { discard; } } term ALL { then accept; }
In a scenario where QFX has other L3 ports with OSPF configured, to ensure the above lo0 filter does not discard the real OSPF Hellos, modify EITHER to include another term to accept OSPF Hellos from the real OSPF peer (or) configure an interface filter instead of lo0 filter to discard the OSPF Hellos received on L2 port.
Include the other term in the above filter before BLOCK-OSPF to accept OSPF Hello from real OSPF peers:
root@QFX-DUT# show firewall family inet filter ospf-block term PERMIT-OSPF { from { source-address { 100.1.1.1/32; } protocol ospf; } then { count accept-ospf; accept; } } term BLOCK-OSPF { from { protocol ospf; } then { count discard-ospf; discard; } } term ALL { then accept; }
Configure an L2 filter and apply inbound on the interface instead of lo0 filter to block the OSPF Hellos:
root@QFX-DUT# show firewall family ethernet-switching filter blk-ospf-onL2 term BLOCK-OSPF { from { ip-destination-address { 224.0.0.5/32; } } then discard; } term ALL { then accept; } root@QFX-DUT# show interfaces ae15 unit 0 { family ethernet-switching { interface-mode trunk; vlan { members [ vlan1 vlan2 ]; } filter { input blk-ospf-onL2; } } }