DHCP Helper-Address Issues

Unanswered Question
Mar 5th, 2007

This is driving me insanse... so any help is appreciated. The goal is to take a MPLS connected site and have it hit a Windows 2003 DHCP server on the other side of the cloud for address management. Sounds like a job for ip helper-address. Here's the config:

Remote side:

interface FastEthernet0/1

ip address

ip helper-address

ip directed-broadcast

duplex auto

speed auto

On the DHCP server... a scope is built for the network. If I do a debug ip udp I see the following:

Mar 5 11:20:50.843: UDP: rcvd src=, dst=, length=308

Mar 5 11:20:50.843: UDP: sent src=, dst=, length=308

It appears as though the forwarding is happening properly. I have verified that "ip directed-broadcast" is enabled on all interfaces between the remote site and the DHCP server. What am I doing wrong or mis-understanding here. This should work properly... right?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
clausonna Mon, 03/05/2007 - 10:47

Hey Mike.

Try putting the ip helper on the VLAN interface and not on the FastEthernet port.

Also maybe trying creating a DHCP scope on the router that the remote switch is connected to, and point ip helper to it (you'll have to do a 'no ip-helper' as well; IOS lets you define multiple IP helpers)

I can post a configlet for that if you like.

Also do a 'debug ip dhcp server events' and 'debug ip dhcp server packets' for the helper/forwarding events, and a 'debug dhcp' as well. Also, a 'debug ip arp' on the switch helps.

This doc is also really helpful: "Understanding and Troubleshooting DHCP in Catalyst Switch or Enterprise networks"


Let me know if you're still hung up, but this info should point you in the right direction.

Richard Burts Mon, 03/05/2007 - 13:56


If the FastEthernet has an IP address as the original post shows, then it is the appropriate place to put the helper-address.


I agree that the debug seems to show that the helper-address is sending the unicast as it should. So you should probably look at some other potential issues.

- is there good IP connectivity between the interface and the address of the server? (start with - can you ping from the interface to the address of the server). An even better test is: if you configure a PC on that segment with an IP address from the pool, can the PC ping to the server?

- does the server have a correct route back to the interface where helper-address is configured?

- by looking at the logs, can you tell if the DHCP request is getting to the server? Is the server generating a response?

The question of directed-broadcast seems to be misunderstood. Given the part of the config that you show I do not see any reason to need directed-broadcast. And if it was needed, it is not needed on every interface along the way, but is needed only on the interface where the directed broadcast will finally be delivered.



glen.grant Mon, 03/05/2007 - 14:58

Your config looks pretty good . As Ric said you do not need ip directed broadcast turned on . The only other thing to check is to make sure no one turn off the dhcp service on the router . To be sure config "service dhcp" on your router . i think normally it is on by default but just something else to check. A link to help. http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a00800f0804.shtml

wiluszm Mon, 03/05/2007 - 15:51

Hey all. Thanks for the great recommendations so far. I have verified "service dhcp" as enabled (I enter the command and never see it in the config...assuming it is on by default). IP connectivity between the sites is without hitch. I can src a ping from the fa0/1 interface and hit the DHCP server without issue. I'm thinking more and more this is a MPLS carrier issue. I have verified that the only time this issue exists is whenever the DHCP request must traverse the MPLS cloud. I'm thinking that I may be able to test this by creating a GRE tunnel between the two sites and route all traffic between the DHCP server and the fa0/1 interface over the tunnel. Anyone know if there's issues with doing this? Should I be able to route this request over the GRE tunnel or will I have issues. I'd like to prove beyond a doubt that the issue is carrier-side before opening a ticket with their NOC. We currently use GRE to bypass some routing filters in place by the carrier. We don't have to tell them that though...

Let me know.



Richard Burts Tue, 03/06/2007 - 04:14


I would think that a GRE tunnel would work ok and would be a good way to test this. When you get the tunnel set up I would think that at the remote side a static route for the address of the server pointing to the tunnel end point would send the requests over the tunnel. This might create an assymetric path and you might choose to route the entire subnet where the server is located so that all traffic to and from that subnet will use the tunnel. At the side where the server is located you would probably need a static route for the entire subnet where the request originates. Or you could use policy based routing if you wanted to route only the DHCP responses over the tunnel and prevent assymetric paths that way.

Also, I wonder if you were able to check the logs on the server, as I suggested, to verify whether the request is being received.




This Discussion