Knowledge Search


×
 

[EX/QFX] OSPF hello packets trapped to CPU although EX/QFX work as pure L2 switches

  [KB34201] Show Article Properties


Summary:

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.

 

Symptoms:

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.

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.

 

Cause:

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)

 

Solution:

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

 

Related Links: