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

Mon May 25 13:59:23 EDT 2009

Hi Jake,

sorry for delay with the reply - and top-posting to avoid having 
the rest scroll through the debugs in case they find my scribbles 
of any use.

>From the messages you mentioned looks like it's the *reply* from the 
server (presumably, DHCPACK) that gets dropped by the ASA because of no 
binding, rather than the request - you should be able to verify with the 
sniffer trace (or capture, for that matter) on the DHCP server interface, 
that the request is forwarded, and the DHCPACK is being received and 
thrown away because of no binding.

Upon a quick look at the code, "in principle" this should work - the 
DHCPREQUEST should create a binding, and the DHCPACK from the server 
should hit it and get forwarded by the ASA. So, either the binding does 
not get created, or it does not get found. You can verify "show dhcpd 
binding all" if you see anything at all pertaining to that client during 
those. Actually, even better - if there is a simultaneous pcap from the 
client interface and the server interface, a simple tcpreplay of 
DHCPREQUEST and DHCPACK should allow to see the problem in the lab - 
please collect those captures if they're not yet in the case.

As far as explaining how the things should work: standards are a good 
tool for that :-)

RFC2131 (which is the standards-track one for DHCP), page 13:

"
    DHCPREQUEST  -  Client message to servers either (a) requesting
                    offered parameters from one server and implicitly
                    declining offers from all others, (b) confirming
                    correctness of previously allocated address after,
                    e.g., system reboot, or (c) extending the lease on a
                    particular network address.
"

The scenario is "(b)" right there, I think.

The more detailed procedure is described at bottom of page 16 (as per 
layout on http://www.ietf.org/rfc/rfc2131.txt) - it's a pretty clear 
explanation, IMHO.

If there is a misunderstanding after presenting that description - please 
use the standard escalation procedure 
(http://www.cisco.com/kobayashi/news_training/tac_overview.html#howcaniescalate)

cheers,
andrew

p.s. also could you please unicast me the SR#.

On Thu, 21 May 2009, Jacob Vargas wrote:

> 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
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>