Assigning IP Address Using Option 82 in one Subnet
Adam Moffett
adamlists at plexicomm.net
Mon Dec 6 17:14:33 UTC 2010
If what you're describing is truly happening, then I think your switch
is broken.
Out of curiosity have you tried adding the global option
"stash-agent-options true;"?
> Hi
>
> We have a problem when we try to assign the ip addresses in our network
> using option 82.
>
> We have the following network architecture:
>
> - DHCP Server with one physical interface (but several vlans)
> - Several witches (Octopus from HIrschmann) as dhcp relay agents
> - Several clients at the switch ports which send unique
> client-identifiers per switch but not in the whole network
>
> The problem is now that the dhcp relay client on the switches forwards
> the broadcast DHCP_DISCOVER (without Option 82) and sends in addition
> the unicast DHCP_DISCOVER (with Option 82) to the server.
>
> The following happens if a dhcp discover appears:
>
> Client: Sends broadcast DHCP_DISCOVER
> Relay: forward broadcast DHCP_DISCOVER (without 82) and sends a
> unicast DHCP_DISCOVER (with 82) to the server.
> Server: Receive broadcast DHCP_DISCOVER (without 82) and do not reply
> because this doesn't match with his dhcpd.conf.
>
> Server: Receive unicast DHCP_DISCOVER (with 82) and replay with a
> DHCP_OFFER unicast to the relay.
> Relay: Receive unicast DHCP_OFFER (with 82) and forward it to the
> client (without 82).
> Client: Receive the DHCP_OFFER and sends a DHCP_REQUEST with the
> offered ip address.
>
> Relay: forward the DHCP_REQUEST (without 82) and send a unicast
> DHCP_REQUEST (with 82) to the server.
> Server: Receive broadcast DHCP_REQUEST (without 82) and refuse it
> because it seems to bee a misconfigured client.
> (Combination does not match the class with the requested ip,
> because of the missing option 82 tag.)
> ===> The Server sends a DHCP_NACK!!!
>
> Relay: forward the broadcast DHCP_NACK (without 82) to the client.
> Client: Receive the DHCP_NACK , finish the request negative and
> restarts the process.
>
> Server: Receive unicast DHCP_REQUEST (with 82) and answer with a
> DHCP_ACK (unicast to the relay)
> because the combination match the config.
> Relay: forward the unicast DHCP_ACK to the client.
>
> Client: receive the DHCP_ACK but cannot handle it because the process
> is already restarted.
>
> ======== corresponding dhcpd.conf ===========
>
> # dhcpd.conf
>
> default-lease-time 300;
> max-lease-time 360;
>
> # Declaration of the network in the project XXXXX.
> # All subnets have to be declared in a shared network
> # because we are using one phsical network (eth0) with
> # several alias IPs (eth0:0 - eth0:n) and VLANs.
>
> shared-network XXXXXX-Net {
>
> omapi-port 7911;
> #local-address 10.100.1.1;
>
> # ganzes Subnetz (vlan5)
> subnet 10.200.0.0 netmask 255.255.224.0 {
> }
>
> # lokales Subnetz (vlan2)
> # 10.100.0.x für temporäre Adressen aus den pools
> # 10.100.1.x für die definitiven Adressen
> subnet 10.100.0.0 netmask 255.255.254.0 {
>
> ############ Switche ###############################
> class "SWITCH_MW4_1" {
> match if substring(option dhcp-client-identifier, 1, 14) =
> "XXXXXXD_MW4_41";
> }
> pool{
> allow members of "SWITCH_MW4_1";
> range 10.100.1.5 10.100.1.5;
> }
>
> class "SWITCH_MW4_2" {
> match if substring(option dhcp-client-identifier, 1, 14) =
> "XXXXXXD_MW4_42";
> }
> pool{
> allow members of "SWITCH_MW4_2";
> range 10.100.1.6 10.10.1.6;
> }
>
> class "CHAIN_MW4_3" {
> match if ( suffix (option agent.circuit-id, 3) = 1:1:3);
> }
> pool{
> allow members of "CHAIN_MW4_3";
> range 10.100.1.250 10.100.1.252;
> }
> }
>
> ======== end dhcpd.conf ===========
>
> I'm not sure if the behavior of the switches corresponds with RFC3046.
> But I think that they should forward both packages, broadcast without
> option 82 tag and unicast with option 82 tag to the server, because they
> are switches and not routers.
>
> One solution would be if there is any possibility to configure the
> dhcp-server to ignores any broadcast dhcp-messages. (Because we assume
> that every dhcp-message is forwarded unicast to the server this would
> not be a problem.) Is this option or something similar available?
>
> Or did anyone of you see an other solution for this problem?
>
> Thank you a lot for your hints.
>
>
> Regards
>
> Rico Zoss
>
>
>
>
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20101206/0e9382f0/attachment.html>
More information about the dhcp-users
mailing list