I recently had a case where some new servers were installed in to a Data Centre. However, there seemed to be some confusion around the IP configuration of the devices. Regardless of what the configuration should have been, the end result was that the devices were left plugged in with no IP addresses configured. The network that these server belong to is also isolated and has no access to other parts of the networking including the DHCP server.
This presented a dilemma, either
an engineer would need to book the day to go back to the DC to reconfigure the device.
Or network engineers can come to the rescue.
Obviously, the latter was the most beneficial option for everyone involved.
And many of you may have already guessed... Just configure a DHCP pool on the switch..
conf t
ip dhcp pool LAN-POOL
network 192.168.100.0 255.255.255.0 Job done, devices pick up an IP, we can then connect and reconfigure to our hearts content.
... But, there were a few caveats that needed to be considered in this case.
Only addresses 131, 135, 168, and 178 can be used
DHCP CANNOT be enabled for the whole network
DHCP cannot be allowed to be picked up by any other devices.
So this creates an issue, DHCP by nature is (at its core) a broadcast application (for the most part). The above configuration would mean that any device that connected to the network with automatic IP addressing would pick up an IP. Given all of these rules that need to follow. DHCP reservations start to come to mind.
With DHCP reservations the configuration is a little different.
First we want to create a new dhcp pool specifically for a single host. Rather than specify "network" in the command we will instead use the "host" keyword.
*Notice that the subnetmask is still a match for the overall /24 network
ip dhcp pool CLIENT131
host 192.168.100.131 255.255.255.0While this would address points 1 and 2. It does not address point 3.
Unfortunately, any device looking to get an IP address would receive this IP on a first come first served basis. In short, this does not provide control to which device gets this address.
There is however, a way to control this using a "Client Identifier". The most common of which would be the MAC address of the network interface cards.
But how do I know what they are? There are a couple ways you can achieve this. A simple method is by using the MAC table. Even though the devices do not have an IP address as of yet, they have attempted to communicate with the network to get one. So naturally if we know which interfaces these devices connect to, the MAC table is will hold the information we need.
show mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
100 5254.0000.ab14 DYNAMIC Gi1/0/4
100 5254.0000.ab12 DYNAMIC Gi1/0/2
100 5254.0000.ab13 DYNAMIC Gi1/0/3
100 5254.0000.ab11 DYNAMIC Gi1/0/1If you are not seeing anything on the expected interfaces, you can always issue the "shutdown" / "no shutdown" commands which should trigger some new traffic flow.
Now we can use the "hardware-address" identifier within the DHCP pool making our config look a bit like this. For testing we will also include the lease command to reduce the lease time to 5 minutes.
conf t
ip dhcp pool CLIENT131
hardware-address 5254.0000.ab11
host 192.168.100.131 255.255.255.0
lease 0 0 5And simply repeat for each host.
ip dhcp pool CLIENT135
hardware-address 5254.0000.ab12
host 192.168.100.135 255.255.255.0
lease 0 0 5
ip dhcp pool CLIENT168
hardware-address 5254.0000.ab13
host 192.168.100.168 255.255.255.0
lease 0 0 5
ip dhcp pool CLIENT178
hardware-address 5254.0000.ab14
host 192.168.100.178 255.255.255.0
lease 0 0 5Under normal circumstances this should be a successful piece of configuration but there is a catch!
By using the "show ip dhcp binding" command we can see what is going on with our DHCP pools.
Notice in this instance that addresses .131 and .135 seem to be stuck in a selecting state.
show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration State Interface
Hardware address/
User name
192.168.100.131 5254.0000.ab11 Infinite Selecting Unknown
192.168.100.135 5254.0000.ab12 Infinite Selecting Unknown
192.168.100.168 5254.0000.ab13 Infinite Active Vlan100
192.168.100.178 5254.0000.ab14 Infinite Active Vlan100For some reason these addresses are not picking up. Why is this?
Considering we don't have access to the devices, we can utilise some debug commands to assist us.
debug ip dhcp server events
debug ip dhcp server packetsThis will enable you to see the requests come in. This can get a little messy in the logs be we are interested in involve the DHCPDISCOVER header.
show logging | include DHCPDISCOVER
*Sep 8 11:59:00.247: DHCPD: DHCPDISCOVER received from client 5254.0000.ab13 on interface Vlan100.
*Sep 8 11:59:00.264:DHCPD: DHCPDISCOVER received from client 5254.0000.ab14 on interface Vlan100.
*Sep 8 11:59:04.318: DHCPD: DHCPDISCOVER received from client ff32.39f9.b500.0200.00ab.11b0.0bff.53b9.c374.62 on interface Vlan100.
*Sep 8 11:59:14.499: DHCPD: DHCPDISCOVER received from client ff32.39f9.b500.0200.00ab.11b6.98f4.3913.9098.f3 on interface Vlan100. While all of our configuration is correct, we now need to dig in to the failure. The key note in this case is that the DHCP Discover message's that contained the MAC address have been successful. The Discovers containing longer IDs failed.
If we look at the entire logs from
*Sep 8 12:14:05.575: DHCPD: DHCPDISCOVER received from client ff32.39f9.b500.0200.00ab.11b6.98f4.3913.9098.f3 on interface Vlan100.
*Sep 8 12:14:05.575: DHCPD: Option 125 not present in the msg.
*Sep 8 12:14:05.575: Option 82 not present
*Sep 8 12:14:05.575: Option 82 not present
*Sep 8 12:14:05.575: DHCPD: Option 125 not present in the msg.
*Sep 8 12:14:05.575: DHCPD: Sending notification of DISCOVER:
*Sep 8 12:14:05.575: DHCPD: htype 1 chaddr 5254.0000.ab12
*Sep 8 12:14:05.575: DHCPD: interface = Vlan100
*Sep 8 12:14:05.575: DHCPD: FSM state change INVALID
*Sep 8 12:14:05.575: DHCPD: Workspace state changed from INIT to INVALID
*Sep 8 12:14:05.575: DHCPD: classname not set in msg
*Sep 8 12:14:05.575: DHCPD: there is no address pool for 192.168.100.1.
*Sep 8 12:14:05.575: DHCPD: there is no address pool for 192.168.100.1.
*Sep 8 12:14:05.575: DHCPD: Option 125 not present in the msg.
*Sep 8 12:14:05.575: DHCPD: Sending notification of ASSIGNMENT FAILURE:
*Sep 8 12:14:05.575: DHCPD: htype 1 chaddr 5254.0000.ab12
*Sep 8 12:14:05.575: DHCPD: interface = Vlan100
*Sep 8 12:14:05.575: DHCPD: Sending notification of ASSIGNMENT_FAILURE:
*Sep 8 12:14:05.575: DHCPD: due to: NO POOL
*Sep 8 12:14:05.575: DHCPD: htype 1 chaddr 5254.0000.ab12
*Sep 8 12:14:05.575: DHCPD: interface = Vlan100The last highlighted message is probably the most interesting to us. While we most certainly see the correct MAC address within the DHCPD messages, it fails claiming there is NO POOL.
This comes down to how we chose to identify the devices. Using MAC works well. But in this instance we have IPv6 also enabled on a Linux client. And in this instance the identifier uses this longer hex string.
This being the case we have two possible options. The first is to disabled the IPv6 on the linux client.
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo systemctl restart systemd-networkdThis should trigger a device to no longer use the longer ID, instead using the MAC address within its DHCP Discover Message.
If you recall however we are not able to gain access to the devices. So this isn't a possibility in the current scenario. What we can do however is use the Client-Identifier command within the DHCP pool
conf t
ip dhcp pool CLIENT131
client-identifier ff32.39f9.b500.0200.00ab.11b6.98f4.3913.9098.f3
host 192.168.100.131 255.255.255.0
lease 0 0 5
ip dhcp pool CLIENT135
client-identifier ff32.39f9.b500.0200.00ab.11b0.0bff.53b9.c374.62
host 192.168.100.131 255.255.255.0
lease 0 0 5This should now be successful, you can use the show ip dhcp bindings again to confirm, but in this instance you should see a difference in the client id section.
show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration State Interface
Hardware address/
User name
192.168.100.131 ff32.39f9.b500. Infinite Selecting Unknown
0200.00ab.11b6.
98f4.3913.9098.f3
192.168.100.135 ff32.39f9.b500. Infinite Selecting Unknown
0200.00ab.11b0.
0bff.53b9.c374.62
192.168.100.168 5254.0000.ab13 Infinite Active Vlan100
192.168.100.178 5254.0000.ab14 Infinite Active Vlan100We nailed it!
Finally!
DHCP reservations are configured.
I hope you enjoyed this dive in to madness with me.
Let me know your thoughts in the comments below.
Comments