UDP issues after network outage

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

UDP issues after network outage

L2 Linker

We're experiencing multiple issues with udp-based applications after network outages. A common problem is that udp tracking sessions (I assume from ALG) in PA for DHCP create issues and clients are unable to attain IP-address. This error must be manually solved by clearing sessions. We've also seen this error for other udp applications.

 

Question is: Are the configuration steps we can take to alleviate our problems with udp tracking sessions getting invalid in PA?

4 REPLIES 4

Cyber Elite
Cyber Elite

Hello there

 

I am not aware of an ALG for DHCP.   UDP has a global time out of 30 secs, by default.

Here is a screen capture of what DHCP looks like on my FW.

Note the start time and receive time (receive time is when the log was received to the traffic log, which logs at session end)

 

Session ID
38741
Action
allow
Action Source
from-policy
Application
dhcp
Rule
Internal
Rule UUID
6270e459-1170-4495-a10d-2822cd36b2f5
Session End Reason
aged-out
Category
any
Device SN
 
IP Protocol
udp
Log Action
 
Generated Time
2019/10/30 15:00:02
Start Time
2019/10/30 14:59:30
Receive Time
2019/10/30 15:00:02
Elapsed Time(sec)
0
Tunnel Type
N/A

 

 

 

So unless someone has manipulated the global timers, or it is anomoly in the software, 30 secs is reasonable max time a UDP is maintained.

 

That is different for SIP which has an ALG.

 

 

 

 

 

Help the community: Like helpful comments and mark solutions

L2 Linker

Hi

In logs and sessions browser the dhcp sessions between ip gateways (remote locations) and dhcp servers are often long running, up to 1-2 weeks. So I'm pretty sure the dhcp application is dependent on more than the udp timeout. It seems unlikely that we should receive continuous dhcp relay traffic from the gateways.

Our config for dhcp application seems standard also:

clipboard_image_0.png

 

Also checked ou firewall timeouts which seems to be default:

 

Session timeout
TCP default timeout: 3600 secs
TCP session timeout before SYN-ACK received: 5 secs
TCP session timeout before 3-way handshaking: 10 secs
TCP half-closed session timeout: 120 secs
TCP session timeout in TIME_WAIT: 15 secs
TCP session delayed ack timeout: 250 millisecs
TCP session timeout for unverified RST: 30 secs
UDP default timeout: 30 secs
ICMP default timeout: 6 secs
SCTP default timeout: 3600 secs
SCTP timeout before INIT-ACK received: 5 secs
SCTP timeout before COOKIE received: 60 secs
SCTP timeout before SHUTDOWN received: 30 secs
other IP default timeout: 30 secs
Captive Portal session timeout: 30 secs
Session timeout in discard state:
  TCP: 90 secs, UDP: 60 secs, SCTP: 60 secs, other IP protocols: 60 secs

 


Trond,

 

Can you show a screen capture showing a DHCP session that has been in your Session Browser for more than 2 minutes?

You may need to do a "show session ID xxxxx" from the CLI

 

I am not able to confirm your issue.  DHCP is just and only 4 UDP packet exchange.

When I go into my Session Browser and look for DHCP, I get none, meaning, I have zero sessions that are in the session table.

 

But even when I look at a UDP session (DNS in my example), this is what I see

 

start time : Thu Oct 31 12:10:36 2019
timeout : 30 sec

 

So we are missing some details... 😕

Please advise. 

Help the community: Like helpful comments and mark solutions

Here's an example of traffic currently in session today. These are all from gateways doing DHCP relay (IP information has been removed).

clipboard_image_0.png

  • 3207 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!