[Solved]Does the order of DHCP pool configurations in /etc/config/dhcp actually matter?

My home network consists of an E8450 router (running OpenWrt 23.05 latest snapshot), a switch, and several APs, with the network topology as shown in the diagram.

The E8450 has three VLANs (10/20/30) configured for IoT, Guest, and Home networks respectively. The LAN1 port is tagged with VLANs 10/20/30.

The E8450's LAN1 port connects to the switch, with corresponding switch ports also tagged for VLANs 10/20/30. The APs' connected switch ports are similarly configured with tagged VLANs 10/20/30.

Configuration files:

/etc/config/network

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'

config bridge-vlan
        option device 'br-lan'
        option vlan '10'
        list ports 'lan1:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '20'
        list ports 'lan1:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '30'
        list ports 'lan1:t'
        list ports 'lan2:t'
        list ports 'lan3:u*'

config interface 'IoT'
        option proto 'static'
        option device 'br-lan.10'
        option ipaddr '10.100.10.254'
        option netmask '255.255.255.0'

config interface 'Guest'
        option proto 'static'
        option device 'br-lan.20'
        option ipaddr '10.100.20.254'
        option netmask '255.255.255.0'

config interface 'lan'
        option device 'br-lan.30'
        option proto 'static'
        option ipaddr '10.100.30.254'
        option netmask '255.255.0.0'
        option ip6assign '60'

/etc/config/dhcp

config dhcp 'lan'
        option interface 'lan'
        option start '7681'
        option limit '100'
        option leasetime '3m'
        option dhcpv6 'hybrid'
        option ra 'hybrid'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option netmask '255.255.0.0'
        option ndp 'hybrid'
        option ra_management '1'

config dhcp 'IoT'
        option interface 'IoT'
        option start '1'
        option limit '200'
        option leasetime '3m'
        option netmask '255.255.255.0'

config dhcp 'Guest'
        option interface 'Guest'
        option start '1'
        option limit '200'
        option leasetime '3m'
        option netmask '255.255.255.0'
        option dhcpv6 'hybrid'
        option ndp 'hybrid'
        option ra 'hybrid'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

With the above configuration, I expected IoT devices to receive 10.100.10.xxx addresses, but they actually get assigned 10.100.30.xxx addresses.

However, if I reorder the DHCP pools in /etc/config/dhcp as follows:

config dhcp 'IoT'
        ...

config dhcp 'Guest'
        ...

config dhcp 'lan'
        ...

Then IoT devices correctly receive 10.100.10.xxx addresses, Guest devices get 10.100.20.xxx, and Home devices obtain 10.100.30.xxx as intended.

This makes me wonder: Does the order of DHCP pool configurations in /etc/config/dhcp actually matter?

The order in the dhcp file does not matter, but you do have some errors:

Starting in the network file, you've got your main lan setup as a /16 -- this overlaps with your other networks. This should nominally be a /24.

now, in the DHCP file, you need to change the start to something <=154:

also, remove the net mask from the above.

Likewise, remove the netmask from your other DHCP servers.

Finally, why are you using a 3m lease time? This is unnecessarily short, and is not recommended. It's not a technical problem, per-se, but there is little reason to use such a short time; the default is 12h.

2 Likes

Thank you for your reply! Now I understand the issue. I originally tried to create DHCP pools for two specific subnets (10.100.20.0/24 and 10.100.30.0/24) within a larger network (10.100.0.0/16), but this isn’t feasible because dnsmasq does not support nested DHCP pools.

I redesigned the network and IP address ranges as follows:

/etc/config/network

config interface 'IoT'
        option proto 'static'
        option device 'br-lan.10'
        option ipaddr '10.10.10.254'
        option netmask '255.255.255.0'

config interface 'Guest'
        option proto 'static'
        option device 'br-lan.20'
        option ipaddr '10.20.20.254'
        option netmask '255.255.255.0'

config interface 'lan'
        option device 'br-lan.30'
        option proto 'static'
        option ipaddr '10.30.30.254'
        option netmask '255.255.0.0'
        option ip6assign '60'

/etc/config/dhcp

config dhcp 'lan'
        option interface 'lan'
        option start '7681'
        option limit '100'
        option leasetime '7d'
        option dhcpv6 'hybrid'
        option ra 'hybrid'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ndp 'hybrid'
        option ra_management '1'

config dhcp 'IoT'
        option interface 'IoT'
        option start '1'
        option limit '200'
        option leasetime '7d'

config dhcp 'Guest'
        option interface 'Guest'
        option start '1'
        option limit '200'
        option leasetime '12h'
        option dhcpv6 'hybrid'
        option ndp 'hybrid'
        option ra 'hybrid'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

Now everything works as expected.

PS: The earlier leasetime setting of 3min was only for testing purposes. It will not be used in the final configuration.

Why are you still using a /16 on the lan?

To be clear, this does not constitute a technical problem or misconfiguration, but it is not usually considered good practice, especially when you have a pool size of just 100 devices starting so late in the address space. Why not use 10.30.30.254/24 with start '1' and limit '100' (that would be the same DHCP pool range as you've got with the /16, but without using such a huge subnet). Obviously you may have static devices elsewhere in the range, but you surely aren't working with 16K devices.

This isn't dnsmasq specific, actually. Regardless of the DHCP server and regardless of the router environment, it is critical that all subnets are unique and non-overlapping.

In the meantime...

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile: