Assigning IP Address Using Option 82 in one Subnet
Rico Zoss
rico.zoss at annax.ch
Fri Dec 10 06:44:02 UTC 2010
Hi,
Sorry for the delayed answer, I was out of office for some days.
Now I have added the option "stash-agent-options true;" to my dhcpd.conf
but this does not change the behavior. The Server print the following
debug information:
DHCPDISCOVER from XX:XX:XX:68:6b:7f via eth0.2: network XXXXXX-Net: no
free leases
DHCPDISCOVER from XX:XX:XX:68:6b:7f via 10.100.1.5
DHCPOFFER on 10.100.1.250 to XX:XX:XX:68:6b:7f via 10.100.1.5
DHCPREQUEST for 10.100.1.250 (10.100.1.1) from XX:XX:XX:68:6b:7f via
eth0.2: lease 10.100.1.250 unavailable.
DHCPNAK on 10.100.1.250 to XX:XX:XX:68:6b:7f via eth0.2
DHCPREQUEST for 10.100.1.250 (10.100.1.1) from XX:XX:XX:68:6b:7f via
10.100.1.5
DHCPACK on 10.100.1.250 to XX:XX:XX:68:6b:7f via 10.100.1.5
DHCPDISCOVER from XX:XX:XX:68:6b:85 via eth0.2: network XXXXXX-Net: no
free leases
DHCPDISCOVER from XX:XX:XX:68:6b:85 via 10.100.1.5
DHCPOFFER on 10.100.1.251 to XX:XX:XX:68:6b:85 via 10.100.1.5
DHCPREQUEST for 10.100.1.251 (10.100.1.1) from XX:XX:XX:68:6b:85 via
eth0.2: lease 10.100.1.251 unavailable.
DHCPNAK on 10.100.1.251 to XX:XX:XX:68:6b:85 via eth0.2
DHCPREQUEST for 10.100.1.251 (10.100.1.1) from XX:XX:XX:68:6b:85 via
10.100.1.5
DHCPACK on 10.100.1.251 to XX:XX:XX:68:6b:85 via 10.100.1.5
As you can see, the request after an offer is denied because there is no
address available.
Following the RFC3046 the behavior of the relay agent on the switches is
correct:
"Relay agents are NOT required to monitor or modify client-originated
DHCP packets addressed to a server unicast address. This includes the
DHCP-REQUEST sent when entering the RENEWING state."
Thanks again for your answers.
Regards
Am 06.12.2010 18:14, schrieb 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.5 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
>
>
> _______________________________________________
> 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/20101210/4ee7c91f/attachment.html>
-------------- 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/20101210/4ee7c91f/attachment.bin>
More information about the dhcp-users
mailing list