Even when EX/QFX Series switches work as pure L2 switches, Open Shortest Path First (OSPF) hello packets from peer devices are being trapped to CPU. This behavior, however, is not seen with legacy EX switches such as EX4200.
This article describes the reason for the OSPF hello packets to be trapped to CPU, and suggests a way in which CPU trapping of OSPF hello packets can be avoided.
Even when EX/QFX switches work as pure L2 switches, you can see that the OSPF hello packets coming from a peer device are being trapped to CPU.
An example where a QFX5100 device is working as an L2 switch and receiving OSPF hello packets from a peer device is as follows:
Topology
Peer device (ge-0/0/0)---------(xe-0/0/0)QFX5100
Peer device
set interfaces ge-0/0/0 unit 0 family inet address 192.168.200.1/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
QFX5100
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members vlan100 set vlans vlan100 vlan-id 100
Monitoring OSPF hello packets on QFX5100
OSPF hello packets can be monitored via a tcpdump on QFX5100 as shown.
tcpdump
lab@QFX5100# run monitor traffic interface xe-0/0/0 size 1500 verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on xe-0/0/0, capture size 1500 bytes Reverse lookup for 224.0.0.5 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use <no-resolve> to avoid reverse lookups on IP addresses. 10:26:53.199827 In IP 192.168.200.2 > 224.0.0.5: OSPFv2, Hello, length 60 10:27:01.071742 In IP 192.168.200.2 > 224.0.0.5: OSPFv2, Hello, length 60
Note that the DDOS counter for OSPF hello is increasing.
lab@QFX5100# run show ddos-protection protocols ospf-hello | match received Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 0 Received: 21836 Arrival rate: 0 pps Received: 0 Arrival rate: 0 pps Received: 21836 Arrival rate: 0 pps {master:0}[edit] lab@QFX5100# run show ddos-protection protocols ospf-hello | match received Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 0 Received: 21837 Arrival rate: 0 pps Received: 0 Arrival rate: 0 pps Received: 21837 Arrival rate: 0 pps
These results indicate that OSPF hello packets have been trapped to CPU.
This behavior is as per design. As a design, link local multicast packets will be trapped to CPU even though they are received on L2 ports, and are transit packets.
Because OSPF hello packets use 224.0.0.5 (Reserved multicast IP address) as the Dst IP address, these packets get trapped to CPU. However, these trapped packets are just copied packets, hence distributed denial-of-service attack (DDOS) protection will not affect the transit packets.
The test result when the QFX5100 device is receiving OSPF hello packets at 10,000 pps is demonstrated as follows. Since the DDOS rate limit value is 1,500 pps, DDOS continues to work but it does not affect the transit packet rate as shown.
lab@QFX5100# run show ddos-protection protocols ospf-hello Packet types: 1, Modified: 0, Received traffic: 1, Currently violated: 1 Currently tracked flows: 0, Total detected flows: 0 * = User configured value Protocol Group: OSPF-hello Packet type: aggregate (Aggregate for OSPF Hello) Aggregate policer configuration: Bandwidth: 1500 pps Burst: 200 packets Recover time: 300 seconds Enabled: Yes Flow detection configuration: Detection mode: Automatic Detect time: 0 seconds Log flows: Yes Recover time: 0 seconds Timeout flows: No Timeout time: 0 seconds Flow aggregation level configuration: Aggregation level Detection mode Control mode Flow rate Subscriber Automatic Drop 0 pps Logical interface Automatic Drop 0 pps Physical interface Automatic Drop 1500 pps System-wide information: Aggregate bandwidth is being violated! No. of FPCs currently receiving excess traffic: 1 No. of FPCs that have received excess traffic: 1 Violation first detected at: 2019-04-12 05:36:34 UTC Violation last seen at: 2019-04-12 05:39:09 UTC Duration of violation: 00:02:35 Number of violations: 1 Received: 1638424 Arrival rate: 10001 pps Dropped: 1340118 Max arrival rate: 10003 pps Routing Engine information: Bandwidth: 1500 pps, Burst: 200 packets, enabled Aggregate policer is never violated Received: 0 Arrival rate: 0 pps Dropped: 0 Max arrival rate: 0 pps Dropped by individual policers: 0 FPC slot 0 information: Bandwidth: 100% (1500 pps), Burst: 100% (200 packets), enabled Aggregate policer is currently being violated! Violation first detected at: 2019-04-12 05:36:34 UTC Violation last seen at: 2019-04-12 05:39:09 UTC Duration of violation: 00:02:35 Number of violations: 1 Received: 1638424 Arrival rate: 10001 pps Dropped: 1340118 Max arrival rate: 10003 pps Dropped by individual policers: 0 Dropped by aggregate policer: 1340118 Dropped by flow suppression: 0 Flow counts: Aggregation level Current Total detected State Subscriber 0 0 Active xe-0/0/0 Up 11079 (0) 1413259 (10001) <<== egress xe-0/0/1 Up 11089 (0) 1413526 (9999) <<== egress xe-0/0/2 Up 42687564 (9999) 50 (0)
To stop CPU trapping, you can add a loopback filter. A sample configuration for a loopback filter is shown below.
Note: Transit packets will not be affected by a loopback filter.
set interfaces lo0 unit 0 family inet filter input lo0-filter set firewall family inet filter lo0-filter term 0 from protocol ospf set firewall family inet filter lo0-filter term 0 then discard set firewall family inet filter lo0-filter term 1 then accept