UDP floods present a unique concern for stateful firewalls.

On SRX firewalls, the first packet of a new session takes the most processing time. It requires router lookup, policy lookup, and often more processing to create the session. After the session is created, the rest of the packets flow with very little processing through the fast path.

Given that UDP is connectionless, a UDP source may continue to send UDP traffic indefinitely even if the firewall is denying every packet. If a UDP stream is coming into the SRX, and the SRX does not permit the packet, a session will not be created. When the next packet of the UDP stream comes it, it will also be treated as a first packet. Every packet of the UDP stream will be very processor intensive as all the same look-ups to determine if a session should created will apply to all the packets.

A moderate UDP flood may cause a very significant impact to the SRX flow CPU.

root@srx> show security monitoring 

          Flow session  Flow session   CP session   CP session 

FPC PIC CPU Mem     current     maximum     current     maximum

  0   0  99  35       276      32768       N/A       N/A

One indication that this may be the case is if the invalidated sessions count remains abnormally high.

root@srx> show security flow session summary 

Unicast-sessions: 371

Multicast-sessions: 0

Services-offload-sessions: 0

Failed-sessions: 0

Sessions-in-use: 390

 Valid sessions: 371

 Pending sessions: 0

 Invalidated sessions: 9865

 Sessions in other states: 0

Maximum-sessions: 32768

The box typically has under 400 sessions, yet we see almost 10k invalidated sessions. These are most likely candidate sessions that were deleted when the SRX decided to drop the packet.

This can be confirmed by checking the recent packet drop reasons.

18:06:17.623070:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49159,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.623944:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49122,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.623968:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49159,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.624293:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49122,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.624629:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49159,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.628496:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49122,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.6286s7:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49159,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

18:06:17.628351:LSYS-ID-00 10.20.0.53/300-->10.10.10.10/514;udp,ipid-49122,ae2.101,Dropped by POLICY:Denied by Policy default-policy-logical-system-00

The solution depends on if this traffic is expected and if the SRX should allow the traffic.

• If the UDP should be allowed, add the proper security policy to permit the traffic.
• If it should not be allowed, the best thing to do is to stop it at the source, or as close to the source as possible. Typically with a stateless filter on a router or switch.
• If it is not possible to stop the traffic before reaching the SRX, or the issue is too urgent for a more proper solution, a stateless firewall can be configured on the SRX itself to drop the UDP traffic. This is far less CPU intensive than dropping it with flow CPU.
• You may also want to consider using a UDP flood screen.