DHCP option 82 behavior
crask at telesyn.com
Fri Sep 8 15:46:48 UTC 2006
Actually, the device in the middle is doing DHCP snooping instead of
relay. In that mode, it still inserts option 82 information in the DHCP
discovers. We have made the suggestion that a relay be inserted in the
network, but the user is being somewhat particular and wants to keep
their network setup as it currently stands.
Nicoson Dave wrote:
> -----Original Message-----
> From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
> Behalf Of Curt Rask
> Sent: Thursday, September 07, 2006 1:59 PM
> To: dhcp-users at isc.org
> Subject: DHCP option 82 behavior
> Hello all,
> We have some equipment which is doing DHCP snooping, which means that it
> forwards DHCP packets on through to upstream devices within their
> originating network. Prior to sending the packets on, they insert
> option 82 information. If the packets are received by the DHCP server
> on the same logical network, it fails to include the option 82
> information in the DHCP replies & acks. Unfortunately, due to the
> implementation of DHCP on the network devices, this causes a breakdown
> in the process (the box tries to prevent flooding the dhcp replies out
> to all user ports for security purposes) as it no longer 'knows' which
> port the request came from.
> In reading the RFC, it suggests that anytime a DHCP server receives
> option 82 information, it should always be contained in the reply or
> whatever communication is going back to the client. Does anyone know of
> a way to enable the inclusion of option 82 information for a local
> It seems that the DHCP server receives traffic directly from the hosts
> and not through a relay in the case of the local subnet. So the packets
> that reach the DHCP server don't contain an option 82, right?
> And you want to force the server to send a faked option 82 anyway. Is
> that right?
> My initial reaction is to add an actual relay in between the clients and
> the server, but I'm probably missing something about your problem.
> This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
More information about the dhcp-users