[c-nsp] WAS: dhcprelay regression on latest pix 515 firmware (8.0.4) NOW: ASA5510 8.0(4) issue with DHCP RELAY

[Jacob Vargas]

I've seen some issues out in the wild about the ASA 8.0(4) not honoring DHCP
Request packets when a windows system boots. 

The conversation correlates as follows:

PCAP conversation on ASA:

1: 15:42:05.537783 0.0.0.0.68 > 255.255.255.255.67:  udp 323 (DHCP Request)
<-"can't find binding"
2: 15:42:08.526416 0.0.0.0.68 > 255.255.255.255.67:  udp 323 (DHCP Request)
<-"can't find binding"
3: 15:42:16.542025 0.0.0.0.68 > 255.255.255.255.67:  udp 323 (DHCP Request)
<-"can't find binding"
4: 15:42:44.558061 0.0.0.0.68 > 255.255.255.255.67:  udp 300 (DHCP Discover)
<- fall back after 40 sec timeout
5: 15:42:44.558671 172.20.0.3.67 > 255.255.255.255.68:  udp 326 (DHCP Offer)
6: 15:42:44.559022 0.0.0.0.68 > 255.255.255.255.67:  udp 329 (DHCP Request)
7: 15:42:44.559709 172.20.0.3.67 > 255.255.255.255.68:  udp 331 (DHCP ACK)
<- we finally have an IP address

DHCP Debug on ASA (1 single DHCP Request): 

DHCPD: setting giaddr to 172.20.0.3.
dhcpd_forward_request: request from 0015.17aa.4ae8 (DHCP CLIENT) forwarded
to 172.20.3.15 (DHCP SERVER).
DHCPD/RA: Punt 172.20.3.15/17152 --> 172.20.0.3/17152 to CP
DHCPRA: Received a BOOTREPLY from interface 3
DHCPRA: dhcp_relay_agent_receiver:can't find binding
DHCPRA: Can't Create binding

The "can't create binding" correlates to the DHCP Request packet and the
client fails to obtain an IP from the DHCP Server. 

If you look at the timestamp, it takes 40 seconds for the DHCP client to
give up on requesting and fall back to doing a discover which then the ASA
honors, creates the binding and provides clear communication between client
and server. 

Under normal working circumstances, a DHCP Request to 255.255.255.255 would
be heard by the relay and would be forwarded to the DHCP server as per the
ASA configuration.

It should work like this if it had an IP address via DHCP before:
1: 15:42:16.542025 0.0.0.0.68 > 255.255.255.255.67:  udp 323 (DHCP Request)
2: 15:42:16.553119 172.20.0.3.67 > 255.255.255.255.68:  udp 331 (DHCP ACK)

If the IP address that it had previously was announced via the DHCP Request
was not part of the authoritative scope on the DHCP Server, the server would
send a NACK and this would trigger the client to immediately go into DHCP
Discover mode. This would easily resolve the problem with waiting 40 seconds
for a timeout of the Windows DHCP client and drastically cut the time. 

What's happening in the case of the 8.0(4) code of the ASA is that it
ignores the DHCP Request, if not preceded by a DHCP Discover. Causing the
DHCP Client to fail after the timeout and fall back to the DHCP Discover
mode (after 40 seconds). 

In the event of DHCP Discover, this is what happens:

4: 15:42:44.558061 0.0.0.0.68 > 255.255.255.255.67:  udp 300 (DHCP Discover)
<- fall back after 40 sec timeout
5: 15:42:44.558671 172.20.0.3.67 > 255.255.255.255.68:  udp 326 (DHCP Offer)
6: 15:42:44.559022 0.0.0.0.68 > 255.255.255.255.67:  udp 329 (DHCP Request)
7: 15:42:44.559709 172.20.0.3.67 > 255.255.255.255.68:  udp 331 (DHCP ACK)
<- we finally have an IP address

dhcpd_forward_request: request from 0015.17aa.4ae8 forwarded to 172.20.3.15.
DHCPD/RA: Punt 172.20.3.15/17152 --> 172.20.0.3/17152 to CP
DHCPRA: Received a BOOTREPLY from interface 3
DHCPRA: dhcp_relay_agent_receiver:can't find binding
DHCPRA: relay binding created for client 0015.17aa.4ae8.
DHCPD: setting giaddr to 172.20.0.3.
dhcpd_forward_request: request from 0015.17aa.4ae8 forwarded to 172.20.3.15.
DHCPD/RA: Punt 172.20.3.15/17152 --> 172.20.0.3/17152 to CP
DHCPRA: Received a BOOTREPLY from interface 3
DHCPRA: relay binding found for client 0015.17aa.4ae8.
DHCPRA: Adding rule to allow client to respond using offered address
172.20.1.199
DHCPRA: forwarding reply to client 0015.17aa.4ae8.
DHCPRA: relay binding found for client 0015.17aa.4ae8.
DHCPD: setting giaddr to 172.20.0.3.
dhcpd_forward_request: request from 0015.17aa.4ae8 forwarded to 172.20.3.15.
DHCPD/RA: Punt 172.20.3.15/17152 --> 172.20.0.3/17152 to CP
DHCPRA: Received a BOOTREPLY from interface 3
DHCPRA: relay binding found for client 0015.17aa.4ae8.
DHCPRA: exchange complete - relay binding deleted for client 0015.17aa.4ae8.
DHCPD: returned relay binding 172.20.0.3/0015.17aa.4ae8 to address pool.
dhcpd_destroy_binding() removing NP rule for client 172.20.0.3
DHCPRA: forwarding reply to client 0015.17aa.4ae8.

It will allow a DHCP Inform, DHCP Release, DHCP Discover from the client but
not the DHCP Request! This causes problems for automated servers that
require auto-logon and scripts to run after boot (being that Always wait for
network is part of the group policy). There is no issue with port-fast or
edge-port spanning tree configurations. We even had this issue confirmed on
a hub ;).

I am currently working with Cisco on this problem but am having a hard time
explaining things to them. Has anyone had this problem and have a viable
solution? It would help my case a lot. 

Much obliged, 

Jake Vargas