Replies to request coming over a relay goes to relay's internal IP, not to original request's source IP

Glenn Satchell glenn.satchell at
Sat Oct 6 14:39:57 UTC 2012

Hi Oguz

A dhcp relay talks to the dhcp server using unicast packets. So the dhcp
relay machine uses the routing table to send the packet, this will have a
source IP of the interface sending the packet, not necessarily the
external subnet. Likewise the dhcp server will send the packet back to the
relay. The path to deliver them uses normal routing table entries to
select the interface and next hop. Without a route it cannot work.

I don't understand what you are asking for. Do you want a different way to
direct the packets to the destination? Remember this has to work across
subnets and routers, so broadcast won't satisfy that requirement.

Perhaps give us some more information about what you are trying to
achieve? Such as describe your network layout, and why you can't route to
the subnet where the dhcrelay is running?


On Sat, October 6, 2012 6:33 pm, Oguz Yilmaz wrote:
> Your were right Simon. dhcprelay was not listening all interfaces. I
> have solved this. Please check my second email. Now I have no route to
> subnet delivering IP for. There should be configuration way to
> ditribute subnets to relays even if we have no route to those subnets.
> --
> On Sat, Oct 6, 2012 at 11:25 AM, Simon Hobson <dhcp1 at>
> wrote:
>> Oguz Yilmaz wrote:
>>> 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
>>> 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) >
>>> BOOTP/DHCP, Request from 00:1e:68:06:eb:37, length: 300, hops:1,
>>> xid:0xe378fc7e, flags: [none] (0x0000)
>>>           Gateway IP:
>>>           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( 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 to
>>> 00:1e:68:06:eb:37 (oguz-U300) via
>>> 10:35:02.050108 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF],
>>> proto: UDP (17), length: 328) >
>>> BOOTP/DHCP, Reply, length: 300, hops:1, xid:0xe378fc7e, flags: [none]
>>> (0x0000)
>>>           Your IP:
>>>           Gateway IP:
>>>           Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]
>>> Is this a normal behaviour?
>> Yes.
>> I'm not sure whether the server even considers the source address in the
>> packets. If the client is local then it will spit the packet out of the
>> local interface to which the client subnet is connected, if the client
>> is
>> remote then the packet is sent to the relay address.
>> The address the packet is sent to is what the relay agent should be
>> using to
>> determine which interface it has to send the packet out on to the
>> client.
>> Otherwise, it would need to keep a state table to keep track of what
>> packets
>> it had handled.
>> If your relay agent is not handling these return packets, then it's not
>> working right.
>> Does your relay agent log anything for the return packets ?
>> Is there a firewall that could be dropping the packets ?
>> Ah, suddenly I remember - I don't use any relays these days, but IIRC
>> the
>> relay agent is required to listen on all interfaces it handles packets
>> on -
>> thus it needs to listen on the interface to which it connect with the
>> server. I think.
>> --
>> Simon Hobson
>> Visit for books by acclaimed
>> author Gladys Hobson. Novels - poetry - short stories - ideal as
>> Christmas stocking fillers. Some available as e-books.
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at

More information about the dhcp-users mailing list