Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Dhcpd running on Linux gets a dhcp request over dhcrelay which is running on other remote machine.

Oct  6 10:09:46 2012 dhcpd: DHCPDISCOVER from 00:1e:68:06:eb:37
(oguz-U300) via 172.16.17.81

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
10:35:01.112500 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 328) 192.168.0.81.67 > 192.168.0.1.67:
BOOTP/DHCP, Request from 00:1e:68:06:eb:37, length: 300, hops:1,
xid:0xe378fc7e, flags: [none] (0x0000)
          Gateway IP: 172.16.17.81
          Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

It matches to a subnet and send reply. However reply does not go to the requesting dhcrelay external IP(192.168.0.81). Instead, it goes to the internal interface IP of machine running dhcrelay. And I think because of this remote machine running dhcrelay or the dhcrealy itself discarding packet.

Oct  6 10:09:46 2012 dhcpd: DHCPOFFER on 172.16.17.11 to
00:1e:68:06:eb:37 (oguz-U300) via 172.16.17.81

10:35:02.050108 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 328) 192.168.0.1.67 > 172.16.17.81.67:
BOOTP/DHCP, Reply, length: 300, hops:1, xid:0xe378fc7e, flags: [none]
(0x0000)
          Your IP: 172.16.17.11
          Gateway IP: 172.16.17.81
          Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

Is this a normal behaviour?

Machine running dhcrelay:

eth1(ext)      Link encap:Ethernet  HWaddr 00:90:0B:21:43:F4
          inet addr:192.168.0.81  Bcast:192.168.0.255  Mask:255.255.255.0
eth2(int)      Link encap:Ethernet  HWaddr 00:90:0B:21:43:F5
          inet addr:172.16.17.81  Bcast:172.16.17.255  Mask:255.255.255.0

 3582 ?        Ss     0:00 /usr/sbin/dhcrelay -i eth2 192.168.0.1

Machine running dhcpd:

eth1      Link encap:Ethernet  HWaddr 00:90:0B:23:97:D1
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

option domain-name "test.com";
option subnet-mask 255.255.255.0;
authoritative;
ignore client-updates;

ddns-update-style ad-hoc;
default-lease-time 86400;
max-lease-time 86400;

 subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.135 192.168.0.169;
        option broadcast-address 192.168.0.255;
        option domain-name-servers 192.168.0.1;
        option domain-name "test.com";
        option routers 192.168.0.1;
 }

 subnet 172.16.17.0 netmask 255.255.255.0     {
        local-address 192.168.0.1;
        server-identifier 192.168.0.1;
        range 172.16.17.10 172.16.17.11;
        option broadcast-address 172.16.17.255;
        option routers 172.16.17.81;
        }

(I put local-address and server-identifier. But this does not help )

Regards,

-- Oguz YILMAZ

UPDATE:

The first problem is found. I have configured dhcrelay only on listening internel interface. It seems (of course) is should also listen to external interface for replies. It appears it is not important where the packet destined to. dhrelay will forward it to internal net.

HOWEVER, I have deleted route on dhcpd server to reach 172.16.17.x subnet. It again tries to send reply to 172.16.17.81. Because it does not know the route it send it from default gateway to the internet.

eth0:  IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP
(17), length: 328) 192.168.1.2.67 > 172.16.17.81.67: BOOTP/DHCP,
Reply, length: 300, hops:1, xid:0x32830125, secs:3, flags: [none]
(0x0000)
eth0:     Your IP: 172.16.17.11
eth0:     Gateway IP: 172.16.17.81
eth0:     Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]

How can I force dhcpd to force to send replies to requesting IP? Because, it is not much meaningful to add routes to subnet we distribute IP for.

Internet - dhcpd - 192.168.0.1 - SOMENET - 192.168.0.81 - dhcrelay - 172.16.17.0/24

192.168.0.1 has no route for 172.16.17.0 and has no interface directly attached to that net.

share|improve this question

1 Answer 1

up vote 0 down vote accepted

This is normal. The DHCP Server will use the IP Address present in the Gateway IP (giaddr) to send responses, as written in the specifications. In general, DHCP prefer to use the addresses present in the DHCP/BOOTP payload than the one in the IP and MAC headers.

The Gateway IP address must be the address of the interface connected to the client; so that if a relay has several interfaces connected to clients, then it can simply sends the IP address of the interface where the request was received, and the server will respond to that IP, so the relay can know on which interface the answer must be relayed. This allows the DHCP relay to be stateless.

If you relay reject it, then there is a problem with your relay. A routing problem, maybe ?


Update:

HOWEVER, I have deleted route on dhcpd server to reach 172.16.17.x subnet.

This is wrong on many regards. Once clients are configured via DHCP, they may contact the DHCP server directly with unicast, without using the relay. If the DHCP Server cannot answer these queries, bad things could happen, such as client being unable to extend or remove their leases.

Because, it is not much meaningful to add routes to subnet we distribute IP for.

Except this is how DHCP work...

share|improve this answer
    
I have added an update above –  seaquest Oct 6 '12 at 8:20
    
@seaquest: I have also added an update just above. –  BatchyX Oct 6 '12 at 8:37
    
I see. This means having a dhcp server over internet is not possible? Thank you. –  seaquest Oct 6 '12 at 8:52
    
client has no information of real dhcp server. They think their dhcp server is dhcrelay. Reply includes "Gateway IP: 172.16.17.81". So if they try to talk with dhcp server, again, dhcrelay will do the work I think? Is it? –  seaquest Oct 6 '12 at 8:57
    
@seaquest: "client has no information of real dhcp server": Yes they have, it's the "Server identifier" option of the DHCP message, which is mandatory. –  BatchyX Oct 6 '12 at 9:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.