DHCP client address change

From CT3

Jump to: navigation, search

By Ivan Pepelnjak

The DHCP protocol specifications do not specify the exact mechanisms a DHCP server can use to force the address change on the DHCP client. It’s assumed that once a DHCP client received the IP address from a DHCP server, the address remains valid for the duration of the lease period. A DHCP server can influence the client’s IP address only when the client asks the server for lease extension or address validation using the DHCPREQUEST message.

A DHCP client asks for a lease extension when the T1 timer expires (usually at half the lease period) but could verify its IP address at any time, for example when the LAN interface becomes operational or when a workstation reboots or wakes from suspended/hibernated state.

When a DHCP server does not want to extend the IP address lease, it can:

  • Acknowledge the IP address without extending the lease by responding with the DHCPACK packet.
  • Reject the client’s IP address with the DHCPNAK packet.
  • Ignore the DHCPREQUEST packet and wait for the client’s lease to expire.
Internet Systems Consortium has decided to use the term authoritative DHCP server for the server that actively rejects client’s DHCPREQUEST packet with a DHCPNAK packet.

Contents

DHCP server behavior

Linux DHCP server

The ISC DHCP server available in most Linux distributions tries to accommodate the client’s requests. When a server that lost its bindings receives a DHCPREQUEST packet from a client, it responds with a DHCPACK message (and stores the client-ID-to-IP-address binding in its database) if the client’s IP address belongs to the correct subnet and is not already used by some other client. In other cases, the server does not respond to the request unless it’s configured to be authoritative. An authoritative ISC DHCP server rejects all mismatched DHCPREQUEST messages with a DHCPNAK response, causing the client to enter the INIT state immediately.

Cisco IOS DHCP server

Cisco IOS does not use the DHCPREQUEST packets to repopulate its DHCP binding database. The DHCPREQUEST packets coming from clients that are not in the DHCP binding database are ignored; the clients’ lease period has to expire before its IP address can be changed.

The Cisco IOS DHCP server rejects all DHCPREQUEST packets with invalid IP addresses (IP addresses not belonging to the subnet from which the DHCPREQUEST packet was received) with a DHCPNAK packet, causing the DHCP client to reacquire its IP address.

Requests with unexpected IP addresses coming from clients with known (statically mapped) Client-IDs are also rejected immediately with the DHCPNAK response.

Cisco IOS DHCP client behavior

Although the client DHCP state transition diagram treats lease expiration (timeout) and lease extension rejection (indicated by the DHCPNAK response) in an almost identical way (both events lead to the INIT state), the Cisco IOS DHCP client reacts to them in a completely different manner:

  • If the lease expires, the interface is bounced, new address is acquired and reported in a syslog message (DHCP_6-ADDRESS_ASSIGN).
  • If the DHCP server rejects the IP address included in the lease extension request, the DHCP client quietly acquires a new address and does not report the event. The only noticeable change is a slight disruption in the IP routing table which you can [with EEM IP routing detector].

Both behaviors were tested with IOS release 12.4(24)T and several earlier releases. The printouts included in the following sections were generated with the debug dhcp and debug ip routing commands.

Lease expiration behavior

When a DHCP lease expires, the Cisco IOS DHCP client shuts down the interface, resulting in route removal from the IP routing table.

DHCP lease expires

09:33:50.052: DHCP: SRequest attempt # 1 for entry:
09:33:50.052: DHCP: SRequest - ciaddr: 192.168.0.12
09:33:50.056: DHCP: SRequest placed lease len option: 60
09:33:50.056: DHCP: SRequest: 281 bytes
09:33:50.056: DHCP: SRequest: 281 bytes
09:33:50.056:             B'cast on FastEthernet0/0 interface from 192.168.0.12
09:33:59.052: DHCP: Address lease expired. Attempting Shutdown 

Interface is shut down, connected and static routes are removed from the IP routing table

09:33:59.052: %DHCP-5-RESTART: Interface FastEthernet0/0 is being restarted by DHCP
09:33:59.056: RAC: DHCP stopped on interface FastEthernet0/0
09:33:59.064: RT: Pruning routes for FastEthernet0/0 (1)
09:33:59.072: RT: delete route to 192.168.0.0 via 0.0.0.0, FastEthernet0/0
09:33:59.072: RT: no routes to 192.168.0.0, flushing
09:33:59.072: RT: NET-RED 192.168.0.0/24
09:34:01.072: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
09:34:02.072: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down 

The interface is immediately re-enabled (although the corresponding syslog messages appear after a few seconds) and the DHCP process is restarted:

DHCP is restarted

09:34:02.116: DHCP: DHCP client process started: 10
09:34:02.124: RAC: Starting DHCP discover on FastEthernet0/0 

The DHCP client sends DHCPDISCOVER and DHCPREQUEST messages ...

Initial DHCP messages

09:34:02.124: DHCP: Try 1 to acquire address for FastEthernet0/0
09:34:02.136: DHCP: allocate request
09:34:02.136: DHCP: zapping entry in DHC_PURGING state for Fa0/0
09:34:02.136: DHCP: deleting entry 6808A734 192.168.0.12 from list
09:34:02.136: DHCP: new entry. add to queue, interface FastEthernet0/0
09:34:02.136: DHCP: SDiscover attempt # 1 for entry:
09:34:02.136: DHCP: SDiscover: sending 275 byte length DHCP packet
09:34:02.136: DHCP: SDiscover 275 bytes
09:34:02.136:             B'cast on FastEthernet0/0 interface from 0.0.0.0
09:34:04.092: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
09:34:04.124: DHCP: Received a BOOTREP pkt
09:34:04.128: DHCP: offer received from 192.168.0.2
09:34:04.128: DHCP: SRequest attempt # 1 for entry:
09:34:04.132: DHCP: SRequest- Server ID option: 192.168.0.2
09:34:04.132: DHCP: SRequest- Requested IP addr option: 192.168.0.13
09:34:04.132: DHCP: SRequest placed lease len option: 60
09:34:04.132: DHCP: SRequest: 293 bytes
09:34:04.132: DHCP: SRequest: 293 bytes
09:34:04.132:             B'cast on FastEthernet0/0 interface from 0.0.0.0 

... and sets the interface IP address once it receives the DHCPACK response:

IP address is set on the interface

09:34:04.136: DHCP: Received a BOOTREP pkt
09:34:05.092: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
09:34:07.152: DHCP Client Pooling: ***Allocated IP address: 192.168.0.13 

Once the interface has an IP address, the connected route is inserted in the IP routing table, followed by a DHCP-generated default route:

Connected and static routes are inserted in the IP routing table

09:34:07.152: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True
09:34:07.152: RT: add 192.168.0.0/24 via 0.0.0.0, connected metric [0/0]
09:34:07.156: RT: NET-RED 192.168.0.0/24
09:34:07.156: RT: interface FastEthernet0/0 added to routing table
09:34:07.156: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True
09:34:07.260: Allocated IP address = 192.168.0.13  255.255.255.0 

Last but not least, a syslog message reports the new IP address:

DHCP client reports the new IP address in a syslog message

09:34:07.264: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.0.13, →
              mask 255.255.255.0, hostname Client 

Address change behavior

When the Cisco IOS DHCP client receives a DHCPNAK response to a lease extension request, it removes the interface IP address, resulting in loss of IP routes associated with the interface.

DHCP server sends a DHCPNAK response to the DHCPREQUEST message

09:37:49.604: DHCP: SRequest attempt # 1 for entry:
09:37:49.604: DHCP: SRequest - ciaddr: 10.17.1.30
09:37:49.604: DHCP: SRequest placed lease len option: 30
09:37:49.604: DHCP: SRequest: 281 bytes
09:37:49.604: DHCP: SRequest: 281 bytes
09:37:49.604: DHCP: Received a BOOTREP pkt 

Connected and static routes are removed from the IP routing table

09:37:49.604: RT: del 0.0.0.0 via 10.17.1.2, static metric [254/0]
09:37:49.604: RT: delete network route to 0.0.0.0
09:37:49.604: RT: NET-RED 0.0.0.0/0
09:37:49.604: RT: NET-RED 0.0.0.0/0
09:37:49.640: RT: Pruning routes for FastEthernet0/1 (1)
09:37:49.648: RT: delete route to 10.17.1.0 via 0.0.0.0, FastEthernet0/1
09:37:49.648: RT: no routes to 10.17.1.0, flushing
09:37:49.648: RT: NET-RED 10.17.1.0/24 

The DHCP client then starts the address acquisition process: it sends the DHCPDISCOVER message followed by the DHCPREQUEST message.

DHCP address acquisition process

09:37:49.656: DHCP: SDiscover attempt # 1 for entry:
09:37:49.656: DHCP: SDiscover: sending 275 byte length DHCP packet
09:37:49.656: DHCP: SDiscover 275 bytes 
09:37:49.656:             B'cast on FastEthernet0/1 interface from 0.0.0.0
09:37:50.468: DHCP: Received a BOOTREP pkt
09:37:50.472: DHCP: offer received from 10.17.1.2
09:37:50.472: DHCP: SRequest attempt # 1 for entry:
09:37:50.472: DHCP: SRequest- Server ID option: 10.17.1.2
09:37:50.472: DHCP: SRequest- Requested IP addr option: 10.17.1.17
09:37:50.472: DHCP: SRequest placed lease len option: 30
09:37:50.472: DHCP: SRequest: 293 bytes
09:37:50.472: DHCP: SRequest: 293 bytes
09:37:50.472:             B'cast on FastEthernet0/1 interface from 0.0.0.0
09:37:50.476: DHCP: Received a BOOTREP pkt 

After the DHCP client receives IP address from the DHCP server, it sets the interface IP address and inserts the DHCP-generated default route in the IP routing table. The change of interface IP address triggers the insertion of connected route in the IP routing table.

Connected and static default routes are inserted in the IP routing table

09:37:53.500: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
09:37:53.500: RT: network 10.0.0.0 is now variably masked
09:37:53.500: RT: add 10.17.1.0/24 via 0.0.0.0, connected metric [0/0]
09:37:53.500: RT: NET-RED 10.17.1.0/24
09:37:53.500: RT: interface FastEthernet0/1 added to routing table
09:37:53.504: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
09:37:54.496: DHCP Client Pooling: ***Allocated IP address: 10.17.1.17
09:37:54.504: RT: add 0.0.0.0/0 via 10.17.1.2, static metric [254/0]
09:37:54.508: RT: NET-RED 0.0.0.0/0
09:37:54.512: RT: default path is now 0.0.0.0 via 10.17.1.2
09:37:54.512: RT: new default network 0.0.0.0
09:37:54.512: RT: NET-RED 0.0.0.0/0 

References

Personal tools

CT3

Main menu