top of page
Writer's pictureMc Cube

The Nightmare of Reserving IPs in IOS

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.



A Screaming face emerging from a struggling switch


This presented a dilemma, either

  1. an engineer would need to book the day to go back to the DC to reconfigure the device.

  2. 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.

  1. Only addresses 131, 135, 168, and 178 can be used

  2. DHCP CANNOT be enabled for the whole network

  3. 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.0

While 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/1

If 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 5

And 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 5

Under 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     Vlan100

For 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 packets

This 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 = Vlan100

The 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-networkd

This 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 5

This 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     Vlan100

We 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.

120 views0 comments

Recent Posts

See All

Comentários


bottom of page