- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-20-2012 11:09 AM
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...
07-19-2013 12:48 PM
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.
11-20-2012 12:19 PM
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
07-19-2013 12:08 PM
So was it ever determined how to resolve this issue identified?
07-19-2013 12:48 PM
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.
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!