Earlier posts on this sequence (DHCP relaying ideas, inter-VRFs relaying, relaying in VXLAN segments and relaying from EVPN VRF) used a single DHCP server. It’s time so as to add one other layer of complexity: redundant DHCP servers.
Lab Topology
We’ll use a lab topology just like the VXLAN DHCP relaying lab, add a second DHCP server, and a 3rd change connecting the 2 DHCP servers to the remainder of the community.
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 on GitHub.
Including Redundancy to DHCP Relaying
You may add redundancy to the DHCP relaying course of in a number of methods:
- Have a number of switches with ip helper-address interface configuration related to the identical community (already lined in VXLAN and EVPN eventualities)
- Have a number of DHCP servers, and record all of them in ip helper-address configuration instructions.
- Use anycast IP handle throughout a number of DHCP servers, and because the vacation spot for ip helper-address command.
Utilizing anycast seems like an superior thought. In any case, DNS and DHCP run on high of UDP, and tons of individuals use anycast with DNS. Sadly, there’s a tiny distinction between DNS and DHCP. Whereas they each use unreliable transport, DNS is a stateless service, whereas DHCP handle acquisition is a multi-step course of, and DHCP servers should preserve long-term details about their shoppers. Attempting to implement anycast-based DHCP is thus an attention-grabbing train.
We’ll skip the unicorn pastures and concentrate on the straightforward state of affairs: a number of ip helper-address instructions (one per DHCP server) on ingress interfaces. It’s at all times value checking how that works, however each platforms I examined (Cisco IOS/XE and Arista EOS) relay broadcast packets to all configured servers in parallel.
System Configurations
I made the next configuration adjustments to the VXLAN DHCP relaying configuration:
- Edge switches ahead DHCP broadcasts to 2 DHCP servers.
- Every DHCP server has half of the VLAN subnet in its DHCP pool to stop handle project conflicts.
Arista EOS VRF-aware DHCP relay configuration
vlan 1000
identify cv1
!
interface Vlan1000
description VLAN cv1 (1000) -> [cl_a,cl_b,sw2]
ip handle 172.16.0.4/24
ip helper-address 10.0.0.2
ip helper-address 10.0.0.3
ip virtual-router handle 172.16.0.1/24
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 1000 vni 101000
vxlan vlan 1000 flood vtep 10.0.0.5
!
ip virtual-router mac-address 02:00:ca:fe:00:ff
DHCP pool on the primary DHCP server
ip dhcp excluded-address 172.16.0.4
ip dhcp excluded-address 172.16.0.1
ip dhcp excluded-address 172.16.0.5
!
ip dhcp pool p_172.16.0.0
community 172.16.0.0 255.255.255.0
default-router 172.16.0.1
DHCP pool on the second DHCP server
ip dhcp excluded-address 172.16.0.1 172.16.0.128
!
ip dhcp pool p_172.16.0.0
community 172.16.0.0 255.255.255.0
default-router 172.16.0.1
The ultimate gadget configurations can be found in netlab-examples GitHub repository.
What’s Going On Behind the Scenes?
By now, it is best to understand how the DHCP relaying course of works:
- DHCP consumer sends a DHCP DISCOVER native broadcast
- The switches hooked up to the consumer VLAN forwards the DHCP request to all DHCP servers configured within the ip helper-address interface configuration instructions.
- The supply IP handle of the relayed packet, and the giaddr (gateway IP handle) within the forwarded DHCP request, is the unicast VLAN IP handle of the relaying change.
- Every DHCP server receives two copies of the DHCP DISCOVER request however replies with a single DHCP OFFER packet to the primary DHCP REQUEST packet it acquired (see VXLAN DHCP relaying for extra particulars).
- The DHCP consumer receives two DHCP OFFERs with completely different IP addresses belonging to the VLAN subnet.
Listed below are the related bits from the DHCP consumer log, you may view the complete consumer and server (srv1, srv2) debugging logs on GitHub.
Two DHCP presents acquired by the DHCP consumer
00:12:17: DHCP: Scan: Message kind: DHCP Supply
00:12:17: DHCP: Scan: Shopper ID: cisco-5254.0064.6bd1-Gi0/1
00:12:17: DHCP: Scan: Server ID Choice: 10.1.0.1 = A010001
00:12:17: DHCP: Scan: Subnet Deal with Choice: 255.255.255.0
00:12:17: DHCP: Scan: Router Choice: 172.16.0.1
00:12:17: UDP sport: 43, dport: 44, size: 317
00:12:17: DHCP op: 2, htype: 1, hlen: 6, hops: 1
00:12:17: DHCP server identifier: 10.1.0.1
00:12:17: xid: 91D, secs: 0, flags: 8000
00:12:17: consumer: 0.0.0.0, your: 172.16.0.6
00:12:17: srvr: 0.0.0.0, gw: 172.16.0.4
00:12:17: choices block size: 69
00:12:17: DHCP: Scan: Message kind: DHCP Supply
00:12:17: DHCP: Scan: Shopper ID: cisco-5254.0064.6bd1-Gi0/1
00:12:17: DHCP: Scan: Server ID Choice: 10.1.0.5 = A010005
00:12:17: DHCP: Scan: Subnet Deal with Choice: 255.255.255.0
00:12:17: DHCP: Scan: Router Choice: 172.16.0.1
00:12:17: UDP sport: 43, dport: 44, size: 317
00:12:17: DHCP op: 2, htype: 1, hlen: 6, hops: 1
00:12:17: DHCP server identifier: 10.1.0.5
00:12:17: xid: 91D, secs: 0, flags: 8000
00:12:17: consumer: 0.0.0.0, your: 172.16.0.131
00:12:17: srvr: 0.0.0.0, gw: 172.16.0.4
00:12:17: choices block size: 69
Price noting:
- Provides are coming from two DHCP servers (10.1.0.1 and 10.1.0.5)
- Each presents are coming by the identical gateway (172.16.0.4) – the directly-connected change often propagates the DISCOVER packet sooner than the change receiving it over VXLAN, and the servers ignore the duplicate DISCOVER packet.
We’re not executed but. Whereas the consumer is aware of which DHCP server to make use of, and what IP handle it’d get, it nonetheless can’t use the allotted IP handle. There are a number of extra steps within the course of:
- The DHCP consumer sends a DHCP REQUEST message indicating which server it desires to speak with (server identifier, set to 10.1.0.1) as an area broadcast.
- Each switches propagate that native broadcast to each DHCP servers.
- The server chosen within the DHCP server identifier choice responds with a DHCP ACK message confirming the consumer IP handle.
- The opposite server acts confused (at the very least Cisco IOS XE DHCP server does), complains that the consumer doesn’t know what it’s doing and needs to ship an ASSIGNMENT FAILURE message, however then by some convoluted reasoning involves its senses. At the very least that’s how I’m studying the debugging logs.
Alternative bits from DHCP debugging logs on srv2
00:12:21: DHCPD: DHCPREQUEST acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3634.2e36.6264.312d.4769.302f.31.
00:12:21: DHCPD: DHCPREQUEST acquired on interface GigabitEthernet2.
00:12:21: DHCPD: no subnet configured for 10.1.0.5.
00:12:21: DHCPD: FSM state change INVALID
00:12:21: DHCPD: Workspace state modified from INIT to INVALID
00:12:21: DHCPD : Shopper request acquired seeing the consumer for first time
00:12:21: DHCPD: consumer rejected 172.16.0.131, despatched 172.16.0.6.
00:12:21: DHCPD: server-id specified by consumer (0) 10.1.0.1
...
00:12:21: DHCPD: returned 172.16.0.131 to handle pool p_172.16.0.0.
...
00:12:21: DHCPD: DHCPREQUEST acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3634.2e36.6264.312d.4769.302f.31.
00:12:21: DHCPD: DHCPREQUEST acquired on interface GigabitEthernet2.
00:12:21: DHCPD: no subnet configured for 10.1.0.5.
00:12:21: DHCPD: FSM state change INVALID
00:12:21: DHCPD: Workspace state modified from INIT to INVALID
00:12:21: DHCPD : Shopper request acquired seeing the consumer for first time
00:12:21: DHCPD: excluded handle: 172.16.0.6
...
00:12:21: DHCPD: Discovering a relay for consumer 0063.6973.636f.2d35.3235.342e.3030.3634.2e36.6264.312d.4769.302f.31 by relay 172.16.0.5.
00:12:21: DHCPD : Finding relay for Subnet 172.16.0.5
00:12:21: DHCPD: Choice 125 not current within the msg.
00:12:21: DHCPD: Sending notification of ASSIGNMENT FAILURE:
00:12:21: DHCPD: htype 1 chaddr 5254.0064.6bd1
00:12:21: DHCPD: distant id 020a00000a01000500000000
00:12:21: DHCPD: giaddr = 172.16.0.5
00:12:21: DHCPD: interface = GigabitEthernet2
00:12:21: DHCPD: class id 636973636f706e70
00:12:21: DHCPD: Sending notification of ASSIGNMENT_FAILURE:
00:12:21: DHCPD: as a consequence of: CANT FORWARD
00:12:21: DHCPD: htype 1 chaddr 5254.0064.6bd1
00:12:21: DHCPD: distant id 020a00000a01000500000000
00:12:21: DHCPD: giaddr = 172.16.0.5
00:12:21: DHCPD: interface = GigabitEthernet2
00:12:21: DHCPD: class id 636973636f706e70
00:12:21: DHCPD: can't discover a relay
Subsequent DHCP exchanges happen as unicast UDP packets between the consumer and the chosen DHCP server. Undergo the DHCP lease renewal (consumer, server) and DHCP handle launch (consumer, server) logs if you wish to know the main points, however there’s actually nothing to see there.
What the Requirements Say
The second DHCP shouldn’t act confused: sending a broadcast REQUEST with specified server identifier is a daily a part of the DHCP handle allocation course of even when the DHCP shoppers and servers sit in the identical IP subnet. That is what RFC 2131 says in step 4 of client-server interplay:
The servers obtain the DHCPREQUEST broadcast from the consumer. These servers not chosen by the DHCPREQUEST message use the message as notification that the consumer has declined that server’s supply. The server chosen within the DHCPREQUEST message commits the binding for the consumer to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting consumer.
No matter the way it involves its conclusions, the second DHCP server SHOULD determine it’s not wished and launch its handle allocation.
Attention-grabbing apart: when receiving the second DHCP REQUEST message, Cisco IOS XE DHCP server that was not chosen by the consumer the provides consumer IP handle to the record of excluded IP handle. I’m wondering how that works over an extended interval, specifically if the variety of units related to the subnet comes near the variety of IPv4 addresses within the subnet 😉
Attempt It Out!
Need to run this lab by yourself, or attempt it out with completely different units? No downside:
Coming Up Subsequent
DHCP relaying to a set of redundant DHCP servers works properly (extra so if the DHCP servers observe the RFC 2131 suggestions) as a result of the consumer can at all times determine the ultimate DHCP server, however what if we’re utilizing inter-VRF DHCP relaying the place the first-hop change pretends to be the DHCP server? Keep tuned…
