dhcpd question

[Methix]

Hey all, hoping someone here can help me answer this because I can't seem to find much info on it.

I have dhcpd 3.1.1 running on SLES 11. It has one interface with 2 addresses on it, master ip and an alias ip specifically for dhcp services.

Anyways...the issue I'm having is that one of our wireless wlans using dhcp proxy can't get DHCPREQUEST back to the dhcp server. What ends up happening is that the router get the DHCPDISCOVER broadcast, sends it to the dhcp server on the alias ip, which replies with the DHCPOFFER, but it sends that from the master ip. The DHCPREQUEST then gets sent to the master ip because that's where the DHCPOFFER sourced from. That master ip was blocked by an access list on one of our routers. I've since opened it (and it now works), but I'm trying to figure out if there is a way to make dhcpd actually source all it's dhcp related traffic from that alias address.

So condensed version of the question: Client broadcasts DHCPDISCOVER, router (172.16.1.1) receives it. Sends the request to the dhcp servers alias ip address (10.1.1.11). Server sends back DHCPOFFER from it's master ip address (10.1.1.10). Is there a way to force dhcpd to source the traffic from 10.1.1.10?

[daayou]

post your dhcpd.conf file.

[Grah]

is your router a cisco device?

[lornfang]

I don't think there is a dhcpd address bind option, as it sends responses as broadcasts. The closest you'll find in dhcpd is that you can bind it to an interface. Is there a compelling reason the device has two ips?

[Methix]

The devices doing the dhcp proxy are several Cisco 4404 Wireless controllers.

The main reason for having the seperate IP is for portability. This has already been moved a couple times and is sure to get moved again at some point in the future, so it's nice to be able to simple move that alias ip to a new server without affecting anything else the old server might be doing.

Here's the dhcpd.conf and dhcpd.master files without all the scope information. It (and it's peer) service about 50 subnets, so just leaving that out to make it easier to read. Also just blanked out a few company identifying things since this is in the public forum.

dhcpd.conf:

ddns-update-style none;
failover peer "xxx" {
#my state down;
primary;
address 10.2.1.156;
port 519;
peer address 10.16.10.36;
peer port 520;
max-response-delay 3600;
max-unacked-updates 10;
# Split and mclt parameters required on the Primary DHCP server.
split 128;
mclt 3600;
load balance max seconds 3;
}

include "/etc/dhcpd.master";


dhcpd.master


#Global default options
#Next 5 lines for DDNS update.
ddns-updates on;
allow client-updates;
ddns-domainname "xxxxx.com";
ddns-update-style interim;
update-optimization false;
update-static-leases true;
option nds-servers 10.2.1.17, 10.16.10.3;
# ----
#New lines for Aironet Access Points-mpl
option cisco-43 code 241 = ip-address;
option netbios-name-servers 10.2.1.16;
option ntp-servers 10.2.1.17;
option domain-name-servers 10.2.1.40, 10.2.1.32;
dynamic-bootp-lease-length 259200;
next-server 10.16.10.3;
filename "dinic.sys";
option domain-name "xxxxx.com";
option domain-name-servers 10.2.1.40, 10.2.1.32;
option time-offset -18000;
option ntp-servers 10.2.1.17;
option netbios-name-servers 10.2.1.16;
option tftp-server-name "10.16.10.3";
option bootfile-name "dinic.sys";
max-lease-time 5184000;
authoritative;
omapi-port 7911;

#The following Class for vendor-class-identifier Cisco AP's
class "Cisco Aironet"
{ match if (option vendor-class-identifier = "Cisco Aironet");
option cisco-43 10.77.1.15;
option cisco-43 10.77.1.16;
}

[Grah]

do the cisco devices have a dhcp helper? Back in the day we used to have to tell the routers where to point requests to to get dhcp addresses.

[daayou]

It has been a while since I have done this. So I could be messed up. Take this info at your own risk.

If I remember correct, there was a setting in the .conf file for trusted devices that you could set to pull from a pool. You might want to look up about trusted devices and see if there is a way to do it that way.

But I am with lorn. Two ips - same interface - argh.

[lornfang]

There may be a way to do this with iproute2 if this is running on linux. I will try to dig through the docs tonight if I have some free cycles.

[Methix]

They have something similar to the ip helper. The wireless controllers don't run IOS, but the dhcp proxy is very similar. From a functionality standpoint, it's doing the same thing.

As for the second ip address, it has proven extremely useful to have that portability. Even in other applications, multiple addresses bound to a single interface generally isn't a big deal. Our BIND servers have an option for source addresses that is particularly useful for handling replication of different views.

As Lorn said, I think the problem here is that dhcp is generally designed to be a broadcasting protocol. Even though dhcp relay is able to transcend the limitations of layer 2, it's not really designed with that in mind.

Don't waste too many cycles on this. Changing the access lists on one of the routers effectively fixed the issue. I'm just curious now if this is possible or not. And it'd be good to know just for future reference.

[Mod]

Maybe try this:

http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9

Also make sure you have the correct route on the server interface. You want to route all the information for that subnet out the proper interface, even if it is "virtual". If you have a default gateway set, you will be forwarding it out the wrong interface if you don't have the correct route.

Try this:

http://linux.about.com/od/commands/l/blcmdl8_route.htm

[lornfang]

What you want is actually source based routing. If dhcpd is actually replying back to the dhcp relay rather than broadcasting, it should work like a charm, but I'd need to see a tcpdump to know for sure. Take a look at this: http://www.wlug.org.nz/SourceBasedRouting I was going to write some examples but didn't end up with any time.

I did this about 4 years ago when I was transitioning a bunch of servers from one range of ips to another. I wanted the systems to reply on both ips until I was sure dns had propagated.

[Methix]

I'll look at that source based routing link, that sounds pretty promising.

Here's a good tcpdump of the behavior I'm seeing:

08:39:16.267738 IP 172.16.36.5.67 > 10.2.1.156.67: BOOTP/DHCP, Request from 00:25:48:05:0c:13, length 352
08:39:17.001655 IP 10.2.1.174.67 > 172.16.36.5.67: BOOTP/DHCP, Reply, length 300
08:39:17.007583 IP 172.16.36.5.67 > 10.2.1.174.67: BOOTP/DHCP, Request from 00:25:48:05:0c:13, length 368
08:39:17.009529 IP 10.2.1.174.67 > 172.16.36.5.67: BOOTP/DHCP, Reply, length 300

[Methix]

Maybe try this:

http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9

Also make sure you have the correct route on the server interface. You want to route all the information for that subnet out the proper interface, even if it is "virtual". If you have a default gateway set, you will be forwarding it out the wrong interface if you don't have the correct route.

Try this:

http://linux.about.com/od/commands/l/blcmdl8_route.htm

Hrm...setting up static routes could do this. It's interesting that the routing table doesn't actually show it as being tied to the virtual interface (just shows eth0 instead of eth0: DHCP, but it does work nonetheless. Only tough part about that is it's not really scalable.


dhcp1:~ # route add -host 10.255.255.100 gw 10.1.1.1 eth1:DHCP
dhcp1:~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.255.255.100 10.1.1.1 255.255.255.255 UGH 0 0 0 eth1
link-local * 255.255.0.0 U 0 0 0 eth1
10.0.0.0 * 255.252.0.0 U 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 10.1.1.1 0.0.0.0 UG 0 0 0 eth1
dhcp1:~ # tcpdump | grep 10.255.255.100
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:07:44.535533 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 1, length 64
09:07:45.548037 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 2, length 64
09:07:46.548340 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 3, length 64
09:07:47.547946 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 4, length 64
09:07:48.548219 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 5, length 64
09:07:49.547938 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 6, length 64
09:07:50.548097 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 7, length 64
09:07:51.548438 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 8, length 64
09:07:52.547990 IP 10.2.1.156 > 10.255.255.100: ICMP echo request, id 1584, seq 9, length 64
^C1067 packets captured
1071 packets received by filter
0 packets dropped by kernel

dhcp1:~ # route del -host 10.255.255.100 gw 10.1.1.1 eth1
dhcp1:~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
link-local * 255.255.0.0 U 0 0 0 eth1
10.0.0.0 * 255.252.0.0 U 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 10.1.1.1 0.0.0.0 UG 0 0 0 eth1
dhcp1:~ # tcpdump | grep 10.255.255.100
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:12:19.735769 IP 10.2.1.174 > 10.255.255.100: ICMP echo request, id 48944, seq 1, length 64
09:12:20.748199 IP 10.2.1.174 > 10.255.255.100: ICMP echo request, id 48944, seq 2, length 64
09:12:21.748242 IP 10.2.1.174 > 10.255.255.100: ICMP echo request, id 48944, seq 3, length 64
^C224 packets captured
228 packets received by filter
0 packets dropped by kernel

[lornfang]

Which side is that tcpdump from? I'm not seeing the ips mentioned in the OP

[Methix]

Ahh sorry, the original post was just done with fake IPs to make it simpler.

That dump is from the dhcp server.

10.2.1.174 is its master ip
10.2.1.156 is the alias ip
172.16.36.5 is the dhcp proxy (wireless controller)