Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASA and DHCP option 43

Hi all,

We are having issues with connecting IP phones to MS Lync. The problem is around DHCP being issued with option 43.

This doesn't relate to the ASA DHCP feature as we are not using it but it appears that the return from the Windows based DHCP server is being blocked by the ASA.

We have 2 DHCP servers, DHCP-1 issues your standard machine IP address stuff and DHCP-2 issues the Lync related information. In our case this is the certificate for connecting to Lync.

It works like this:

1. PC requests DHCP address (DHCP-1 responds),

2. PC is issued address from pool.

3. PC requests LYNC information             

4. DHCP-2 returns LYNC information but it is then dropped by the firewall. Instead of passing it back to the client.

We can see all this happening in wireshark, when we run debug dhcprelay event\error we get an error about binding.

"DHCPRA: dhcp_relay_agent_receiver:can't find binding"

When we put the IP phone in the same network it works so the issues appears to be with the firewall.

Our ASA is configured like this:


VLAN Staff

DHCP Relay to DHCP-1 and DHCP-2. Timeout 60s

ACL's are basically Allow any IP\ICMP (I know, this is bad. I didn't configure it and will fix it) and we are going from Staff to Prod.

Has anyone had this issue before or can tell me what the error is referring to? I have done a lot of searching but can't seem to find anything

New Member

ASA and DHCP option 43

Please check if the length value is set to 0 in DHCP OFFER packet coming from DHCP server?
If yes, then we need a finite value as ASA would be expected to drop it.

:RFC 2132



New Member

ASA and DHCP option 43

Hi Ajay, thanks for the reply.

below is the result i get when trying to run emulate client. On the ASA we receive:

DHCPRA: dhcp_relay_agent_receiver:can't find binding

C:\Users\User\dhcp>DHCPUtil.exe -emulateclient

Starting Discovery ...

Sending Packet (Size: 284, Network Adapter:, Attempt Type: Broadcas

t + Unicast)

--Begin Packet--

DHCP: INFORM                (xid=B05A2E0A)

DHCP: Op Code           (op)      = 1

DHCP: Hardware Type     (htype)   = 6

DHCP: Hops              (hops)    = 0

DHCP: Transaction ID    (xid)     = 2958700042

DHCP: Seconds           (secs)    = 0

DHCP: Flags             (flags)   = 0000

DHCP: Client IP Address (ciaddr)  =

DHCP: Your IP Address   (yiaddr)  =

DHCP: Server IP Address (siaddr)  =

DHCP: Relay IP Address  (giaddr)  =

DHCP: Client HW Address (chaddr)  = 08002774C6A2

DHCP: Server Host Name  (sname)   =

DHCP: Boot File Name    (file)    =

DHCP: Magic Cookie                =

DHCP: Option Field


    DHCP: Server Identifier(  54) = (Length: 0)

    DHCP: Client Identifier(  61) = (Length: 7) (0108002774C6A2)

    DHCP: SIP Server( 120)        = (Length: 0) enc:0  ()

    DHCP: Host Name(  12)         = (Length: 8) aaron-PC

    DHCP: Vendor Identifier(  60) = (Length: 12) MS-UC-Client

    DHCP: Param Req List(  55)    = (Length: 2) 120 43

    DHCP: Vendor Info(  43)       = (Length: 0)  ()

    DHCP: End of this option field

--End Packet--

Result: Failure =  1

When it works correctly this is followed up by an ACK with the Lync information in it.

It will randomly start working so i'm not sure if its the DHCP server playing up or if its the ASA....

New Member

ASA and DHCP option 43

I have dealt with Cisco and they have acknowdeldge there is a bug in  version 8.6(1) and recommend updating to 9.0(3), or to 9.1(2).

We are running a ASA5515 with 8.6.1

This is from their bug tracker:

ASA - dhcp relay - bindings are not created for DHCP Informs
When  acting as a DHCP relay, ASA doesn't forward the DHCP ACK from the dhcp  server in response to a Relayed DHCP Inform. The output of 'debug  dhcprelay packet' may show the following:

DHCPRA: dhcp_relay_agent_receiver:can't find binding

This is because the ASA did not build a DHCP Relay binding for the original DHCP Inform request.


More Info:
CreatePlease login to create content