F5F Stay Refreshed Power Users Networks No addresses were included because they came from the DHCP pool.

No addresses were included because they came from the DHCP pool.

No addresses were included because they came from the DHCP pool.

B
blakpanda
Member
57
09-03-2025, 02:42 PM
#1
Hello! I'm creating a topology with R1 as the default gateway at 192.168.10.1 and a subnet mask of 255.255.255.0. From my knowledge, I should avoid using the addresses 192.168.10.1 (the default), 192.168.10.0, and 192.168.10.255 in the DHCP pool. This is important because assigning these addresses would cause conflicts or disruptions. If a client like PC1 gets assigned 192.168.10.0, it would fall within the same network range, potentially leading to connectivity issues. Also, using 192.168.10.255 as a broadcast address could interfere with other devices on the network.
B
blakpanda
09-03-2025, 02:42 PM #1

Hello! I'm creating a topology with R1 as the default gateway at 192.168.10.1 and a subnet mask of 255.255.255.0. From my knowledge, I should avoid using the addresses 192.168.10.1 (the default), 192.168.10.0, and 192.168.10.255 in the DHCP pool. This is important because assigning these addresses would cause conflicts or disruptions. If a client like PC1 gets assigned 192.168.10.0, it would fall within the same network range, potentially leading to connectivity issues. Also, using 192.168.10.255 as a broadcast address could interfere with other devices on the network.

T
thisistame
Junior Member
1
09-05-2025, 03:41 AM
#2
You need to leave out the gateway address from the DHCP pool. Because the gateway isn't using DHCP for its IP, you should begin from .2 and continue accordingly.
T
thisistame
09-05-2025, 03:41 AM #2

You need to leave out the gateway address from the DHCP pool. Because the gateway isn't using DHCP for its IP, you should begin from .2 and continue accordingly.

T
tage_harry
Member
73
09-10-2025, 08:22 PM
#3
The DHCP server on Cisco routers doesn’t verify if an IP is already in use; it relies solely on its own lease list. It also doesn’t confirm whether the router’s IP falls within the range. Other DHCP servers often perform ARP or Ping checks on IPs before assigning them. Many DHCP clients, including iOS devices, will do the same before accepting an offer. You shouldn’t depend on this behavior, and in Cisco routers you should always exclude any static IPs in use, even the router’s own address. I don’t think you need to exclude network or broadcast IPs, as I haven’t seen that practice in production.
T
tage_harry
09-10-2025, 08:22 PM #3

The DHCP server on Cisco routers doesn’t verify if an IP is already in use; it relies solely on its own lease list. It also doesn’t confirm whether the router’s IP falls within the range. Other DHCP servers often perform ARP or Ping checks on IPs before assigning them. Many DHCP clients, including iOS devices, will do the same before accepting an offer. You shouldn’t depend on this behavior, and in Cisco routers you should always exclude any static IPs in use, even the router’s own address. I don’t think you need to exclude network or broadcast IPs, as I haven’t seen that practice in production.

M
mcraft2070
Junior Member
31
09-11-2025, 11:53 PM
#4
255 serves as the broadcast address. https://en.wikipedia.org/wiki/Broadcast_address 0 acts as the network identifier. Assigning a client with its own OS stack prevents it from understanding the subnet or forwarding rules, leading to L2 issues like ARP storms or L3 conflicts. In your scenario, the gateway handles this. If the client receives this address, all L3 traffic would be misrouted as if it were on the gateway. For a valid range, consider 192.168.10.0/23, covering 192.168.10.1 to 192.168.11.254. 192.168.10.0 fits in the middle and is fine. Let me know if this clarifies things.
M
mcraft2070
09-11-2025, 11:53 PM #4

255 serves as the broadcast address. https://en.wikipedia.org/wiki/Broadcast_address 0 acts as the network identifier. Assigning a client with its own OS stack prevents it from understanding the subnet or forwarding rules, leading to L2 issues like ARP storms or L3 conflicts. In your scenario, the gateway handles this. If the client receives this address, all L3 traffic would be misrouted as if it were on the gateway. For a valid range, consider 192.168.10.0/23, covering 192.168.10.1 to 192.168.11.254. 192.168.10.0 fits in the middle and is fine. Let me know if this clarifies things.