DHCP Relaying in EVPN VRFs « ipSpace.internet weblog

After determining how DHCP relaying works and testing it with VRFs and in VXLAN segments, it looks like a no brainer to make it work with EVPN.

TL&DR: It really works, not less than when utilizing Arista vEOS because the relay and Cisco CSR 1000v because the DHCP server.

Lab Topology

We’ll maintain utilizing the very same “bodily” topology we used within the VXLAN DHCP relaying lab, add EVPN and BGP to the control-plane cocktail, and put the VXLAN phase right into a VRF. We’ll use CSR 1000v because the DHCP server as a result of Cisco IOSv doesn’t help a few of the DHCP option-82 sub-options we’d like.

Lab IPv4 addressing

  Interface                  IPv4 handle  Description
==============================================================================================
srv (10.0.0.2/32)
  GigabitEthernet2            10.1.0.1/30  srv -> sw1
  GigabitEthernet3            10.1.0.5/30  srv -> sw2

sw1 (10.0.0.3/32)
  Ethernet1                   10.1.0.2/30  sw1 -> srv
  Ethernet2                   10.1.0.9/30  sw1 -> sw2
  Vlan1000                  172.16.0.3/24  VLAN cv1 (1000) -> [cl_a,cl_b,sw2] (VRF: consumer)

sw2 (10.0.0.4/32)
  Ethernet1                   10.1.0.6/30  sw2 -> srv
  Ethernet2                  10.1.0.10/30  sw2 -> sw1
  Vlan1000                  172.16.0.4/24  VLAN cv1 (1000) -> [cl_a,sw1,cl_b] (VRF: consumer)

cl_a (10.0.0.5/32)
  GigabitEthernet0/1        172.16.0.5/24  cl_a -> [sw1,cl_b,sw2]

cl_b (10.0.0.6/32)
  GigabitEthernet0/1        172.16.0.6/24  cl_b -> [cl_a,sw1,sw2]

You may view the whole topology file on GitHub.

System Configurations

I configured VRF-aware DHCP relay (ip dhcp relay info possibility) on each switches. The DHCP swimming pools on the DHCP server will not be VRF-aware because of the Arista EOS bug (misformed sub-option 151). The last gadget configurations can be found in netlab-examples GitHub repository.

Arista EOS VRF-aware DHCP relay configuration

ip dhcp relay info possibility
!
vlan 1000
   title cv1
!
vrf occasion consumer
   rd 65000:1
!
interface Vlan1000
   description VLAN cv1 (1000) -> [cl_a,cl_b,sw2]
   vrf consumer
   ip handle 172.16.0.3/24
   ip helper-address 10.0.0.2 vrf default
   ip ospf space 0.0.0.0
   ip virtual-router handle 172.16.0.1/24
!
interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 1000 vni 101000
!
ip virtual-router mac-address 02:00:ca:fe:00:ff

Does It Work?

In fact, I didn’t anticipate anything based mostly on earlier check circumstances. The change of DHCP packets is straightforward to reconstruct from the logs (consumer, server). As earlier than:

• DHCP consumer sends a DHCP DISCOVER native broadcast
• The straight related swap forwards the DHCP request to the DHCP server. The supply IP handle of the relayed packet, and the giaddr (gateway IP handle) within the forwarded DHCP request is the IP handle of the outgoing interface (within the world IP routing desk). ^{The swap additionally forwards the printed Ethernet packet throughout the VXLAN phase.}
• The second swap receives the VXLAN-encapsulated DHCP request broadcast and forwards the second copy of the identical packet to the DHCP server.
• 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 obtained.
• The DHCP server IP handle within the DHCP OFFER packet is the relaying swap VRF IP handle specified within the server-id-override sub-option.

Because the DHCP request from the directly-connected swap often arrives earlier than the opposite copy that took the scenic VXLAN route, the DHCP server IP handle within the DHCP OFFER packet is often (however not essentially) the VRF IP handle of the swap to which the consumer is straight related.

• The DHCP OFFER packet is distributed to the chosen relay’s giaddr (world IP handle)
• The swap receiving the DHCP OFFER forwards the provide to the DHCP consumer. The DHCP consumer thinks the DHCP server IP handle is the DHCP relay VRF IP handle. Not surprisingly, Consumer-A makes use of SW-1 because the DHCP server, and Consumer-B makes use of SW-2 because the DHCP server:

DHCP lease on Consumer-A

cl_a#present dhcp lease
Temp IP addr: 172.16.0.2  for peer on Interface: GigabitEthernet0/1
Temp  sub internet masks: 255.255.255.0
   DHCP Lease server: 172.16.0.3, state: 5 Sure
   DHCP transaction id: 2329
   Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs
   Subsequent timer fires after: 11:27:58
   Retry rely: 0   Consumer-ID: cisco-5254.008f.e981-Gi0/1
   Consumer-ID hex dump: 636973636F2D353235342E303038662E
                       653938312D4769302F31
   Hostname: cl_a

DHCP lease on Consumer-A

cl_b#present dhcp lease
Temp IP addr: 172.16.0.5  for peer on Interface: GigabitEthernet0/1
Temp  sub internet masks: 255.255.255.0
   DHCP Lease server: 172.16.0.4, state: 5 Sure
   DHCP transaction id: 24BB
   Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs
   Subsequent timer fires after: 11:26:31
   Retry rely: 0   Consumer-ID: cisco-5254.0045.41d8-Gi0/1
   Consumer-ID hex dump: 636973636F2D353235342E303034352E
                       343164382D4769302F31
   Hostname: cl_b

• The DHCP consumer sends a DHCP REQUEST packet as an area broadcast (it nonetheless doesn’t have a confirmed IP handle). The DHCP server IP handle within the DHCP REQUEST packet is the VRF IP handle of the swap that relayed the DHCP OFFER packet.
• Each switches obtain the DHCP REQUEST broadcast and relay it to the DHCP server.
• The DHCP server receives two DHCP REQUEST packets and sends two DHCP ACK messages with the DHCP server IP handle set to the relay VRF IP handle.

• DHCP consumer receives a DHCP ACK message from the server it despatched the request to, but in addition a second DHCP ACK message from an unknown server. It ignores the second.

Takeaways:

• The DHCP consumer thinks one of many directly-connected switches is the DHCP server. That’s the one option to get a DHCP request throughout VRF boundary.
• When utilizing Arista EOS because the DHCP relay, the DHCP server IP handle utilized by the consumer is the unicast (not anycast) IPv4 handle of the swap.
• Totally different purchasers may very well be utilizing totally different switches as their “DHCP servers”.
• If the unicast IPv4 handle of the relaying swap disappears, the consumer loses its path to the DHCP server, and can’t prolong its lease, however the rebinding course of (part 4.4.5 of RFC 2131) ought to care for that. With the default settings, the rebinding course of begins earlier than 90% of the lease time expires which ought to be greater than sufficient.

Aside from the minor particulars listed above, all of it appears to be like like a stroll within the park, proper? It’s, and it ought to work with any DHCP server and any decently-implemented information middle swap… so long as you’re utilizing a single DHCP server. Extra about this juicy element within the final weblog put up on this collection.

Attempt It Out!

Wish to run this lab by yourself, or attempt it out with totally different gadgets? No drawback:

Coming Up Subsequent

We had a clean journey to date (other than an unknown Arista EOS developer failing to learn the RFC 6607), however we’re about to hit a minor hurdle: what occurs if we wish to have redundant DHCP servers? Keep tuned…