Multiple dhcrelay setup causing multiple duplicate DHCP requests

Michael Hodgkinson Michael.Hodgkinson at solnetsolutions.co.nz
Tue Aug 17 22:17:37 UTC 2010


Suggestions 1 & 2 aren't really practical with our network design and 3
won't work as you hinted.

"The other one that comes to mind is to figure out how to make the
relay agent more intelligent and add the missing features. I know one
that's cropped up from time to time is that the outgoing interface to
the server (eth5 in this case) must be a broadcast capable network -
ie it can't be something like a ppp link. I believe the same fix for
your problem would fix that.

I think the answer is probably that the relay agent needs to be able
to listen only on those interface to which clients will be connected,
and only use the normal OS network stack for unicast packets back
to/from the server(s). And of course, only deal with packets on the
'backhaul' that are to/from the server(s)"

I think you are correct in regards to this. The relay agent needs to be
more intelligent about what it does and doesn't relay. Perhaps only
intercepting and relaying broadcasts.

Also I wondered if the "-m" flag would be of assistance in resolving this
issue. The documentation for this is poor, so I tested various options.
However in my testing, nothing changed or DHCP stopped responding to
requests. Which put me off doing further tests.

Thanks for your input Simon.

Cheers

Mike Hodgkinson
Support & Managed Services
Solnet Solutions Limited
Level 12, Solnet House
70 The Terrace, Wellington 6011, New Zealand
PO Box 397, Wellington 6140, New Zealand
DDI +64 4 462 5064, Mobile +64 21 754 339
Main +64 4 462 5000, Fax +64 4 462 5012

www.solnetsolutions.co.nz
A Solnet Group Company



                                                                                                                
  From:       Simon Hobson <dhcp1 at thehobsons.co.uk>                                                             
                                                                                                                
  To:         Users of ISC DHCP <dhcp-users at lists.isc.org>                                                      
                                                                                                                
  Date:       17/08/2010 19:03                                                                                  
                                                                                                                
  Subject:    Re: Multiple dhcrelay setup causing multiple duplicate DHCP requests                              
                                                                                                                
  Sent by:    dhcp-users-bounces+michael.hodgkinson=solnetsolutions.co.nz at lists.isc.org                         
                                                                                                                





Michael Hodgkinson wrote:

>The clients are broadcasting requests/discovers and the dhcrelays are
>unicasting to both dhcpd servers.
>
>I ran tcpdump on the firewalls and confirmed the dhcrelays are the cause
of
>the duplicate packets. The capture was many MB and probably a security
>concern, otherwise I would attach it.
>
>It appears that the client sends a request, which is received by fw1's
>dhcrelay, the request is sent to both dhcp1 and dhcpd2 which is
intercepted
>by fw2's dhcrelay which also sends the request to both dhcp1 and dhcpd2
>causing a loop between the two dhcrelays.

I see it now. Ordinarily fw2 wouldn't see unicast traffic relayed by
fw1, but because the servers are actually in the packet path, they do.

Two methods come to mind :

1) Move the relay agents. They do NOT have to be in the gateways,
they can be on any device that is physically connected to the same
network as the clients. It's just customary to put them in the
routers since the routers are by definition connected, and are always
on - ie it's a convenient place to put them.

2) Move the servers. This may be harder, but can you move the server
so that the relayed traffic doesn't go through the other relay agent.

3) If you have the facilities, put some filters on fw1 and fw2 to
block the traffic from the other device. Ie, on fw1 only allow DHCP
traffic from server dhcpd2 on that eth5 into the firewall.
Actually, I'm not sure this last one will work.


The other one that comes to mind is to figure out how to make the
relay agent more intelligent and add the missing features. I know one
that's cropped up from time to time is that the outgoing interface to
the server (eth5 in this case) must be a broadcast capable network -
ie it can't be something like a ppp link. I believe the same fix for
your problem would fix that.

I think the answer is probably that the relay agent needs to be able
to listen only on those interface to which clients will be connected,
and only use the normal OS network stack for unicast packets back
to/from the server(s). And of course, only deal with packets on the
'backhaul' that are to/from the server(s)

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ 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 lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users





Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or postmaster at solnetsolutions.co.nz as
soon as possible. The content of this email does not necessarily
reflect the views of Solnet Solutions Ltd.




More information about the dhcp-users mailing list