Earlier posts on this collection coated quite a few intricacies of DHCP relaying:
Now for the ultimate little bit of the puzzle: what if we wish to do inter-VRF DHCP relaying with redundant DHCP servers?
When you learn the earlier weblog posts (fastidiously sufficient) you may need already observed the gotcha:
- When relaying DHCP requests between VRFs, the DHCP relay acts as a DHCP server towards the shopper – the DHCP server handle within the DHCP OFFER or DHCP ACK replies is the IP handle of the ingress interface of the DHCP relay.
- The DHCP server IP handle within the DHCP REQUEST packet is utilized by the servers to determine whether or not to finish the IP handle allocation (and ensure it with DHCP ACK message) or abort the transaction and neglect about it.
- That process clearly can’t work if the shopper doesn’t know the precise IP handle of the DHCP server. Now what?
It’s time for one more lab take a look at…
Lab Topology
We’ll use the identical lab topology we used within the DHCP Relaying with Redundant DHCP Servers situation however join DHCP purchasers to a VRF (just like the Inter-VRFs relaying situation).
Lab topology diagram
Lab IPv4 addressing
Interface IPv4 handle Description
================================================================================
srv1 (10.0.0.2/32)
GigabitEthernet2 10.1.0.1/30 srv1 -> sw3
srv2 (10.0.0.3/32)
GigabitEthernet2 10.1.0.5/30 srv2 -> sw3
sw1 (10.0.0.4/32)
Ethernet1 10.1.0.9/30 sw1 -> sw2
Ethernet2 10.1.0.13/30 sw1 -> sw3
Vlan1000 172.16.0.4/24 VLAN cv1 (1000) -> [cl_a,cl_b,sw2]
sw2 (10.0.0.5/32)
Ethernet1 10.1.0.10/30 sw2 -> sw1
Ethernet2 10.1.0.17/30 sw2 -> sw3
Vlan1000 172.16.0.5/24 VLAN cv1 (1000) -> [cl_a,sw1,cl_b]
sw3 (10.0.0.6/32)
Ethernet1 10.1.0.2/30 sw3 -> srv1
Ethernet2 10.1.0.6/30 sw3 -> srv2
Ethernet3 10.1.0.14/30 sw3 -> sw1
Ethernet4 10.1.0.18/30 sw3 -> sw2
cl_a (10.0.0.7/32)
GigabitEthernet0/1 172.16.0.7/24 cl_a -> [sw1,cl_b,sw2]
cl_b (10.0.0.8/32)
GigabitEthernet0/1 172.16.0.8/24 cl_b -> [cl_a,sw1,sw2]
You may view the entire topology file and system configurations within the netlab-examples repository.
Discovering DHCP Servers
The primary few steps of this situation are nearly equal to the non-redundant inter-VRF DHCP relaying situation (full server- and shopper logs are on GitHub)
- Consumer broadcasts a DHCP DISCOVER packet:
00:18:56: Temp IP addr: 0.0.0.0 for peer on Interface: GigabitEthernet0/1
00:18:56: Temp sub web masks: 0.0.0.0
00:18:56: DHCP Lease server: 0.0.0.0, state: 3 Deciding on
00:18:56: DHCP transaction id: 1BFE
00:18:56: Lease: 0 secs, Renewal: 0 secs, Rebind: 0 secs
00:18:56: Subsequent timer fires after: 00:00:04
00:18:56: Retry depend: 1 Consumer-ID: cisco-5254.0015.f24f-Gi0/1
00:18:56: Consumer-ID hex dump: 636973636F2D353235342E303031352E
00:18:56: 663234662D4769302F31
00:18:56: Hostname: cl_a
00:18:56: DHCP: SDiscover positioned class-id possibility: 636973636F706E70
00:18:56: DHCP: SDiscover: sending 303 byte size DHCP packet
- Two copies of the DHCP DISCOVER packet are forwarded to every DHCP server (please notice totally different
giaddraddresses set to loopback interfaces of sw-1 and sw-2):
DHCP DISCOVER step on srv-1
00:18:57: DHCPD: Sending notification of DISCOVER:
00:18:57: DHCPD: htype 1 chaddr 5254.0015.f24f
00:18:57: DHCPD: circuit id 566c616e31303030
00:18:57: DHCPD: giaddr = 10.0.0.4
00:18:57: DHCPD: interface = GigabitEthernet2
00:18:57: DHCPD: class id 636973636f706e70
00:18:57: DHCPD: DHCPDISCOVER obtained from shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 by way of relay 10.0.0.4.
00:18:57: DHCPD: Possibility 125 not current within the msg.
00:18:57: DHCPD: utilizing obtained relay information.
...
00:18:57: DHCPD: Sending notification of DISCOVER:
00:18:57: DHCPD: htype 1 chaddr 5254.0015.f24f
00:18:57: DHCPD: circuit id 566c616e31303030
00:18:57: DHCPD: giaddr = 10.0.0.5
00:18:57: DHCPD: interface = GigabitEthernet2
00:18:57: DHCPD: class id 636973636f706e70
00:18:57: DHCPD: DHCPDISCOVER obtained from shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 by way of relay 10.0.0.5.
00:18:57: DHCPD: Possibility 125 not current within the msg.
00:18:57: DHCPD: utilizing obtained relay information.
- Each servers ought to reply with two DHCP supply message, one for every relayed packet, as you’ll be able to see on the printout from srv-1. Please notice how the server-id-override possibility is used to set the DHCP server IP handle to the VLAN IP handle of the DHCP relay:
00:18:57: DHCPD: Sending DHCPOFFER to shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 (172.16.0.6)
00:18:57: DHCPD: utilizing server-id-override 172.16.0.4
00:18:57: DHCPD: Possibility 125 not current within the msg.
00:18:57: DHCPD: egress Interfce GigabitEthernet2
00:18:57: DHCPD: unicasting BOOTREPLY for shopper 5254.0015.f24f to relay 10.0.0.4.
...
00:18:57: DHCPD: Sending DHCPOFFER to shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 (172.16.0.6).
00:18:57: DHCPD: utilizing server-id-override 172.16.0.5
00:18:57: DHCPD: Possibility 125 not current within the msg.
00:18:57: DHCPD: egress Interfce GigabitEthernet2
00:18:57: DHCPD: unicasting BOOTREPLY for shopper 5254.0015.f24f to relay 10.0.0.5.
Deciding on a DHCP Server
The DHCP shopper receives a number of DHCP OFFER replies. The primary supply is accepted, and the shopper proceeds with a DHCP REQUEST message (nonetheless despatched as a broadcast packet):
00:18:57: DHCP: Obtained a BOOTREP pkt
00:18:57: DHCP: Scan: Message sort: DHCP Supply
00:18:57: DHCP: Scan: Consumer ID: cisco-5254.0015.f24f-Gi0/1
00:18:57: DHCP: Scan: Server ID Possibility: 172.16.0.4 = AC100004
00:18:57: DHCP: Scan: Lease Time: 86400
00:18:57: DHCP: Scan: Renewal time: 43200
00:18:57: DHCP: Scan: Rebind time: 75600
00:18:57: DHCP: Scan: Subnet Deal with Possibility: 255.255.255.0
00:18:57: DHCP: Scan: Router Possibility: 172.16.0.1
00:18:57: DHCP: rcvd pkt supply: 172.16.0.4, vacation spot: 255.255.255.255
00:18:57: UDP sport: 43, dport: 44, size: 317
00:18:57: DHCP op: 2, htype: 1, hlen: 6, hops: 1
00:18:57: DHCP server identifier: 172.16.0.4
00:18:57: xid: 1BFE, secs: 0, flags: 8000
00:18:57: shopper: 0.0.0.0, your: 172.16.0.6
00:18:57: srvr: 0.0.0.0, gw: 172.16.0.4
00:18:57: choices block size: 69
00:18:57: DHCP Supply Message Provided Deal with: 172.16.0.6
00:18:57: DHCP: Lease Seconds: 86400 Renewal secs: 43200 Rebind secs: 75600
00:18:57: DHCP: Server ID Possibility: 172.16.0.4
00:18:57: DHCP: supply obtained from 172.16.0.4
00:18:57: DHCP: SRequest try # 1 for entry:
00:18:57: Temp IP addr: 172.16.0.6 for peer on Interface: GigabitEthernet0/1
00:18:57: Temp sub web masks: 255.255.255.0
00:18:57: DHCP Lease server: 172.16.0.4, state: 4 Requesting
00:18:57: DHCP transaction id: 1BFE
00:18:57: Lease: 86400 secs, Renewal: 0 secs, Rebind: 0 secs
00:18:57: Subsequent timer fires after: 00:00:03
00:18:57: Retry depend: 1 Consumer-ID: cisco-5254.0015.f24f-Gi0/1
00:18:57: Consumer-ID hex dump: 636973636F2D353235342E303031352E
00:18:57: 663234662D4769302F31
00:18:57: Hostname: cl_a
00:18:57: DHCP: SRequest- Server ID possibility: 172.16.0.4
00:18:57: DHCP: SRequest- Requested IP addr possibility: 172.16.0.6
00:18:57: DHCP: SRequest positioned class-id possibility: 636973636F706E70
00:18:57: DHCP: SRequest: 315 bytes
00:18:57: DHCP: SRequest: 315 bytes
00:18:57: B'forged on GigabitEthernet0/1 interface from 0.0.0.0
The second DHCP OFFER message is a relayed packet from the identical DHCP server however coming from the second DHCP relay, so it appears to be like prefer it’s coming from one other server. The shopper decides to disregard it as a result of it already requested handle allocation from what appears to be one other server:
00:18:57: DHCP: Obtained a BOOTREP pkt
...
00:18:57: DHCP Supply Message Provided Deal with: 172.16.0.6
00:18:57: DHCP: Lease Seconds: 86400 Renewal secs: 43200 Rebind secs: 75600
00:18:57: DHCP: Server ID Possibility: 172.16.0.5
00:18:57: DHCP: supply obtained from 172.16.0.5
00:18:57: DHCP: supply obtained in unhealthy state: Requesting punt
Lastly, the shopper receives supply(s) from the second DHCP server. These affords are additionally ignored:
00:19:01: DHCP: Obtained a BOOTREP pkt
00:19:01: DHCP: Scan: Message sort: DHCP Supply
...
00:19:01: DHCP Supply Message Provided Deal with: 172.16.0.132
00:19:01: DHCP: Lease Seconds: 86400 Renewal secs: 43200 Rebind secs: 75600
00:19:01: DHCP: Server ID Possibility: 172.16.0.4
00:19:01: DHCP: supply obtained from 172.16.0.4
00:19:01: DHCP: supply obtained in unhealthy state: Sure punt
00:19:01: Allotted IP handle = 172.16.0.6 255.255.255.0
Request an Deal with Allocation
The DHCP REQUEST message from the DHCP shopper is distributed as a broadcast, which signifies that it is going to be relayed to each DHCP servers, making one among them confused. Right here’s what srv-2 has to say about it:
00:19:02: DHCPD: DHCPREQUEST obtained from shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31.
00:19:02: DHCPD: DHCPREQUEST obtained on interface GigabitEthernet2.
00:19:02: DHCPD: no subnet configured for 10.1.0.5.
00:19:02: DHCPD: FSM state change INVALID
00:19:02: DHCPD: Workspace state modified from INIT to INVALID
00:19:02: DHCPD : Consumer request obtained seeing the shopper for first time
00:19:02: DHCPD: shopper is confused about its IP handle (requested 172.16.0.6, assigned 172.16.0.132).
00:19:02: DHCPD: Possibility 125 not current within the msg.
00:19:02: DHCPD: Sending notification of ASSIGNMENT FAILURE:
00:19:02: DHCPD: htype 1 chaddr 5254.0015.f24f
00:19:02: DHCPD: distant id 020a00000a01000500000000
00:19:02: DHCPD: giaddr = 10.0.0.5
00:19:02: DHCPD: interface = GigabitEthernet2
00:19:02: DHCPD: class id 636973636f706e70
Nonetheless, simply earlier than sending out the error message, srv-2 decides which may not be a good suggestion as a result of we could be coping with an inter-VRF relaying situation:
00:19:02: DHCPD: Not sending DHCPNAK to shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 due toServer-id-override.
In the meantime, the DHCP shopper receives a DHCP ACK message from one of many relaying switches and decides to make use of that change as its DHCP server sooner or later.
00:18:57: DHCP: Obtained a BOOTREP pkt
00:18:57: DHCP: Scan: Message sort: DHCP Ack
00:18:57: DHCP: Scan: Consumer ID: cisco-5254.0015.f24f-Gi0/1
00:18:57: DHCP: Scan: Server ID Possibility: 172.16.0.4 = AC100004
00:18:57: DHCP: Scan: Lease Time: 86400
00:18:57: DHCP: Scan: Renewal time: 43200
00:18:57: DHCP: Scan: Rebind time: 75600
00:18:57: DHCP: Scan: Subnet Deal with Possibility: 255.255.255.0
00:18:57: DHCP: Scan: Router Possibility: 172.16.0.1
00:18:57: DHCP: rcvd pkt supply: 172.16.0.4, vacation spot: 255.255.255.255
00:18:57: UDP sport: 43, dport: 44, size: 317
00:18:57: DHCP op: 2, htype: 1, hlen: 6, hops: 1
00:18:57: DHCP server identifier: 172.16.0.4
00:18:57: xid: 1BFE, secs: 0, flags: 8000
00:18:57: shopper: 0.0.0.0, your: 172.16.0.6
00:18:57: srvr: 0.0.0.0, gw: 172.16.0.4
00:18:57: choices block size: 69
00:18:57: DHCP Ack Message
00:18:57: DHCP: Lease Seconds: 86400 Renewal secs: 43200 Rebind secs: 75600
00:18:57: DHCP: Server ID Possibility: 172.16.0.4
00:19:00: DHCP: Releasing ipl choices:
00:19:00: DHCP: Making use of DHCP choices:
00:19:00: Setting default_gateway to 172.16.0.1
00:19:00: Including default route 172.16.0.1
00:19:01: DHCP: Sending notification of ASSIGNMENT:
00:19:01: Deal with 172.16.0.6 masks 255.255.255.0
00:19:01: DHCP Consumer Pooling: ***Allotted IP handle: 172.16.0.6
It additionally receives a second copy of the DHCP ACK message from the identical server (however coming by way of one other DHCP relaying change), and ignores it as a result of it already obtained an IPv4 handle from “one other” server:
00:19:01: DHCP: Obtained a BOOTREP pkt
00:19:01: DHCP: Scan: Message sort: DHCP Ack
...
00:19:01: DHCP: Server ID Possibility: 172.16.0.5
00:19:01: DHCP: rcv ack in Sure state: punt
Renewing the Lease
The DHCP shopper retains utilizing one of many relaying switches as its DHCP server all through the lifetime of the lease. For instance, when renewing the lease it sends the DHCP REQUEST message to the VLAN IP handle of the relaying change:
00:20:56: Temp IP addr: 172.16.0.6 for peer on Interface: GigabitEthernet0/1
00:20:56: Temp sub web masks: 255.255.255.0
00:20:56: DHCP Lease server: 172.16.0.4, state: 7 Renewing
00:20:56: DHCP transaction id: 1BFE
00:20:56: Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
00:20:56: Temp default-gateway addr: 172.16.0.1
00:20:56: Subsequent timer fires after: 04:30:01
00:20:56: Retry depend: 1 Consumer-ID: cisco-5254.0015.f24f-Gi0/1
00:20:56: Consumer-ID hex dump: 636973636F2D353235342E303031352E
00:20:56: 663234662D4769302F31
00:20:56: Hostname: cl_a
Makes an attempt to resume the lease fail if the DHCP shopper can’t attain the relaying change, for instance because of switch- or interface failure. Nonetheless, the DHCP shopper switches again to broadcast packets earlier than the lease expires, and may be capable to attain the DHCP server by way of one other relaying change.
There’s no info within the DHCP REQUEST packet that will assist the relaying change to determine what must be carried out, so it forwards the request to all DHCP servers. One in all them renews the lease, the opposite one is (but once more) confused, however decides to not reply:
00:21:17: DHCPD: DHCPREQUEST obtained from shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31.
00:21:17: DHCPD: DHCPREQUEST obtained on interface GigabitEthernet2.
00:21:17: DHCPD: no subnet configured for 10.1.0.5.
00:21:17: DHCPD: FSM state change INVALID
00:21:17: DHCPD: Workspace state modified from INIT to INVALID
00:21:17: DHCPD: Consumer both rebooted or rebinding we're seeing the shopper for first time
00:21:17: DHCPD: shopper is confused about its IP handle (requested 172.16.0.6, assigned 172.16.0.132).
...
00:21:17: DHCPD: Sending notification of ASSIGNMENT_FAILURE:
00:21:17: DHCPD: because of: CLIENT CONFUSED ABOUT ADDRESS
00:21:17: DHCPD: htype 1 chaddr 5254.0015.f24f
00:21:17: DHCPD: distant id 020a00000a01000500000000
00:21:17: DHCPD: giaddr = 10.0.0.4
00:21:17: DHCPD: interface = GigabitEthernet2
00:21:17: DHCPD: class id 636973636f706e70
00:21:17: DHCPD: Not sending DHCPNAK to shopper 0063.6973.636f.2d35.3235.342e.3030.3135.2e66.3234.662d.4769.302f.31 due toServer-id-override.
Abstract
- Inter-VRF DHCP relaying with redundant DHCP servers works, however ends in violations of DHCP protocol at a number of steps of the handle project and lease renewal course of.
- DHCP servers and purchasers written in strict accordance with Postel’s Legislation should not have any issues coping with the ensuing mess (Cisco IOS purchasers and Cisco IOS XE servers positively work).
- DHCP servers and purchasers that weren’t examined on this situation may misbehave. For instance, a DHCP server receiving a DHCP REQUEST for an sudden IP handle may mark that handle as already used, lowering the scale of its handle pool.
Lengthy story quick: construct a lab and run thorough assessments earlier than deploying a selected mixture of DHCP purchasers, DHCP relays, and DHCP servers in inter-VRF eventualities with redundant DHCP servers.
