Assigning IP Address Using Option 82 in one Subnet

[Adam Moffett]

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>