ISC DHCP server ignores fixed address specification for Circuit-ID

[codedd713]

Hi Team,

I observed this behavior (below) on ISC DHCP server. Was wondering if this is to be expected or perhaps I overlooked some element.

If a Fixed Address for a Circuit-ID value exists in the DHCP client’s *giaddr* subnet, and if the MAC address or Client Identifier of a DHCP client has a Host/Fixed-Address specification in any other subnet, DHCP server ignores the Fixed Address statement for Circuit-ID in *giadder’s* subnet and looks to provide a free IP within the *giaddr’s* subnet

Test done:

1. Deploy ISC DHCP server version 4.3.5

2. Create and assign the below objects to server:

 

Network:  192.168.5.0/24

                 Fixed Address:  192.168.5.111 – Circuit-ID: 74:65:73:74

                Range:  192.168.5.200  –  192.168.5.250

 

Network:  10.1.1.0/24

 

                Fixed Address:  10.1.1.11 – MAC: aa:aa:aa:aa:aa:aa

 

dhcpd.conf

 

subnet 192.168.5.0 netmask 255.255.255.0 {

        host 192.168.5.99 {

                dynamic;

                host-identifier option agent.circuit-id 74:65:73:74;           <-- Hex value for the word -  test

                fixed-address 192.168.5.99;

        }

        range 192.168.5.10 192.168.5.50;                     <-- or any possible range with free IP addresses

}

 

subnet 10.1.1.0 netmask 255.255.255.0 {

        host 10.1.1.11 {

                dynamic;

                hardware ethernet aa:aa:aa:aa:aa:aa;

                fixed-address 10.1.1.11;

        }

}

3. Using DHCP client simulator, send DISCOVER packet to server with below parameters:

 

                Client MAC address: aa:aa:aa:aa:aa:aa

                Relay agent IP address: 192.168.5.1

                Agent Circuit ID: test       <-- Hex : 74:65:73:74

 

Outcome:

 On receiving the DHCP DISCOVER packet, server OFFERs IP address  192.168.5.50               <--  from subnet's range  192.168.5.10 - 192.168.5.50 , rather than from fixed-address

 

4. Remove fixed-address 10.1.1.11 for Ethernet address aa:aa:aa:aa:aa:aa . Repeat DHCP DORA with same parameters

 

Outcome:

 Server OFFERs correct IP address  192.168.5.99                   <-- from fixed-address for the Circuit-ID in subnet 

 

Any input is much appreciated.

Best Regards,

Edward

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

codedd713 <[hidden email]> wrote:

> I observed this behavior (below) on ISC DHCP server. Was wondering if this is to be expected or perhaps I overlooked some element.

Yes you've overlooked a critical bit of knowledge - something that's tripped up a few people over the years. All host declarations are global in scope - even when written within a subnet declaration. So the host statement matching the MAC address will always match - even when the client is in the other subnet. This may well prevent the other host declaration from matching - don't know what happens if two host declarations match a client.

Also, I don't know if you can match on that option (circuit ID). AIUI there are only a small number of fields you can match on within a host statement.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Patrick Trapp]

Probably irrelevant to the larger conversation, but I am successfully using circuit ID to determine if a host belongs to a class. I only share that in case it's helpful to the OP if their host statements turn out to not use circuit ID like desired.

-----Original Message-----
From: dhcp-users <[hidden email]> On Behalf Of Simon Hobson
Sent: Tuesday, November 20, 2018 3:31 PM
To: Users of ISC DHCP <[hidden email]>
Subject: Re: ISC DHCP server ignores fixed address specification for Circuit-ID

codedd713 <[hidden email]> wrote:

> I observed this behavior (below) on ISC DHCP server. Was wondering if this is to be expected or perhaps I overlooked some element.

Yes you've overlooked a critical bit of knowledge - something that's tripped up a few people over the years. All host declarations are global in scope - even when written within a subnet declaration. So the host statement matching the MAC address will always match - even when the client is in the other subnet. This may well prevent the other host declaration from matching - don't know what happens if two host declarations match a client.

Also, I don't know if you can match on that option (circuit ID). AIUI there are only a small number of fields you can match on within a host statement.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[codedd713]

Thank you for that information! If the host declaration (even if on a different subnet) takes higher precedence to the client's subnet, it would really explain quite a bit.

But exploring on that front, here is something I came across on the ISC portal describing the dhcpd.conf file, quoted :

Link : https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html

"

When dhcpd tries to find a host declaration for a client, it first LOOKS FOR A HOST DECLARATION which has a fixed-address declaration that lists an IP address THAT IS VALID FOR THE SUBNET or shared network ON WHICH THE CLIENT IS BOOTING. If it doesn’t find any such entry, it tries to find an entry which has no fixed-address declaration.

" 

- pardon the CAPS, just wanted to place that in focus

Would this suggest that dhcpd picks the host declaration that is within the subnet of the client, and not other subnets?

Host declarations do support circuit-id. I will try using class declarations.

------------------------------

Date: Tue, 20 Nov 2018 21:31:10 +0000 From: Simon Hobson <[hidden email]> To: Users of ISC DHCP <[hidden email]> Subject: Re: ISC DHCP server ignores fixed address specification for Circuit-ID Message-ID: <[hidden email]> Content-Type: text/plain; charset=us-ascii codedd713 <[hidden email]> wrote: > I observed this behavior (below) on ISC DHCP server. Was wondering if this is to be expected or perhaps I overlooked some element. Yes you've overlooked a critical bit of knowledge - something that's tripped up a few people over the years. All host declarations are global in scope - even when written within a subnet declaration. So the host statement matching the MAC address will always match - even when the client is in the other subnet. This may well prevent the other host declaration from matching - don't know what happens if two host declarations match a client. Also, I don't know if you can match on that option (circuit ID). AIUI there are only a small number of fields you can match on within a host statement. ------------------------------ Message: 3 Date: Tue, 20 Nov 2018 21:45:38 +0000 From: Patrick Trapp <[hidden email]> To: Users of ISC DHCP <[hidden email]> Subject: RE: ISC DHCP server ignores fixed address specification for Circuit-ID Message-ID: <[hidden email]> Content-Type: text/plain; charset="us-ascii" Probably irrelevant to the larger conversation, but I am successfully using circuit ID to determine if a host belongs to a class. I only share that in case it's helpful to the OP if their host statements turn out to not use circuit ID like desired.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

codedd713 <[hidden email]> wrote:

> Thank you for that information! If the host declaration (even if on a different subnet) takes higher precedence to the client's subnet, it would really explain quite a bit.
>
> But exploring on that front, here is something I came across on the ISC portal describing the dhcpd.conf file, quoted :
>
> Link : https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html
>
> "
> When dhcpd tries to find a host declaration for a client, it first LOOKS FOR A HOST DECLARATION which has a fixed-address declaration that lists an IP address THAT IS VALID FOR THE SUBNET or shared network ON WHICH THE CLIENT IS BOOTING. If it doesn’t find any such entry, it tries to find an entry which has no fixed-address declaration.
> "
>
> - pardon the CAPS, just wanted to place that in focus
>
> Would this suggest that dhcpd picks the host declaration that is within the subnet of the client, and not other subnets?

It's not quite how (as I read what you've written) you think.

It doesn't mean :

subnet 192.168.1....
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.1...;
  }
}
subnet 192.168.2...
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.2...;
  }
}

What it means is :

subnet 192,168.1...
  ...
}
subnet 192,168.1...
  ...
}
host ... {
  match hardware 1:aa:bb:cc:dd:ee:ff;
  fixed address 192.168.2...;
}

If the client is connected to the 192.168.2... subnet then the host statement will be valid and used. If the client is connected to the 192.168.1... network then the host statement won't be used as the fixed address isn't valid.
However, if you were to put the host statement within the subnet like this :

subnet 192,168.1...
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.2...;
  }
}
subnet 192,168.1...
  ...
}
then the effect would be the same as the host statement is global and matches when the client is connected to the 192.168.2... network. **BUT** the host would also inherit options from the wrong network in that case - getting (eg) 192.168.1.1 as the router even though it's fixed address is (eg) 192.168.2.123.

Since this latter inheritance issue is almost always not what anyone wants, the general advice is never put host statements other than in the global scope (or within a group statement if you want them to share common options).


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

Yes, always put host declarations in the global context.  However, you can do this:
host Brother-MFC-J615W    {
  hardware ethernet 00:1B:A9:3D:2D:E3;
  fixed-address 192.168.4.63, 192.168.6.63;
  ddns-hostname "Brother-MFC-J615W";
}
This host statement will be used for both the 192.168.4.0/24 and the 192.168.6.0/24
subnets.

Bill

On 11/21/2018 4:02 PM, Simon Hobson wrote:

codedd713 [hidden email] wrote:

Thank you for that information! If the host declaration (even if on a different subnet) takes higher precedence to the client's subnet, it would really explain quite a bit.

But exploring on that front, here is something I came across on the ISC portal describing the dhcpd.conf file, quoted :

Link : https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html

"
When dhcpd tries to find a host declaration for a client, it first LOOKS FOR A HOST DECLARATION which has a fixed-address declaration that lists an IP address THAT IS VALID FOR THE SUBNET or shared network ON WHICH THE CLIENT IS BOOTING. If it doesn’t find any such entry, it tries to find an entry which has no fixed-address declaration.
" 

- pardon the CAPS, just wanted to place that in focus

Would this suggest that dhcpd picks the host declaration that is within the subnet of the client, and not other subnets?

It's not quite how (as I read what you've written) you think.

It doesn't mean :

subnet 192.168.1....
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.1...;
  }
}
subnet 192.168.2...
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.2...;
  }
}

What it means is :

subnet 192,168.1...
  ...
}
subnet 192,168.1...
  ...
}
host ... {
  match hardware 1:aa:bb:cc:dd:ee:ff;
  fixed address 192.168.2...;
}

If the client is connected to the 192.168.2... subnet then the host statement will be valid and used. If the client is connected to the 192.168.1... network then the host statement won't be used as the fixed address isn't valid.
However, if you were to put the host statement within the subnet like this :

subnet 192,168.1...
  ...
  host ... {
    match hardware 1:aa:bb:cc:dd:ee:ff;
    fixed address 192.168.2...;
  }
}
subnet 192,168.1...
  ...
}
then the effect would be the same as the host statement is global and matches when the client is connected to the 192.168.2... network. **BUT** the host would also inherit options from the wrong network in that case - getting (eg) 192.168.1.1 as the router even though it's fixed address is (eg) 192.168.2.123.

Since this latter inheritance issue is almost always not what anyone wants, the general advice is never put host statements other than in the global scope (or within a group statement if you want them to share common options).


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users