DHCP Server Delay

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.

DHCP Server Delay

Not applicable

Hey all,

Has anyone ever encountered a delay when the PA is handing out DHCP?  I have a test network setup to do some captive portal testing for our guest network and I'm noticing it's taking anywhere between 5 - 25 seconds to get an IP address.  Wireless network is set for open with no encryption (just for testing remember).

Not saying it's not something to do with our wireless controllers, just wondering if anyone else has ever experienced anything like this...

1 accepted solution

Accepted Solutions

Upgrading to 4.1.13 or 5.0.5 will solve the issue... it was an implementation issue in the way that PA's DHCP server was implemented. The PA wasn't responding with a NACK when a  DCHP  client requested an IP outside of the PA's IP pool (a "SHOULD" implementation detail as defined per the DHCP RFC), so the client was timing out, which was causing the delay.

FYI we went to 4.1.13 on our internal firewalls and the issue has gone away.

View solution in original post

3 REPLIES 3

L4 Transporter

You may be running into a delay for the client to send a discover. If you run a PCAP you can confirm. Windows will sometimes make a DHCP request with a transactionID which does not belong to the pan. The request is also using DHCP option 50 and requesting the same Ip address.

It will retry for 30 seconds and then send another discover with new transaction ID and the pan will respond to this.

The pan does not send a Neg Ack to the original request but will answer a new discover.

Hope this helps.

Dominic

So was it ever determined how to resolve this issue identified?

Upgrading to 4.1.13 or 5.0.5 will solve the issue... it was an implementation issue in the way that PA's DHCP server was implemented. The PA wasn't responding with a NACK when a  DCHP  client requested an IP outside of the PA's IP pool (a "SHOULD" implementation detail as defined per the DHCP RFC), so the client was timing out, which was causing the delay.

FYI we went to 4.1.13 on our internal firewalls and the issue has gone away.

  • 1 accepted solution
  • 3486 Views
  • 3 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!