Assigning IP Address Using Option 82 in one Subnet

[Rico Zoss]

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20101203/da998733/attachment.bin>