After I bought the testing infrastructure in place (easy DHCP relay, VRF-aware DHCP relay), I used to be prepared for the actual enjoyable: DHCP relaying in VXLAN (and later EVPN) segments.
TL&DR: It really works precisely as anticipated. Despite the fact that I had anycast gateway configured on the VLAN, the Arista vEOS switches used their unicast IP addresses within the DHCP relaying course of. The DHCP server had completely no drawback coping with a number of copies of the identical DHCP broadcast relayed by totally different switches hooked up to the identical VLAN. One may solely want issues have been all the time as simple within the networking land.
Lab Topology
The lab is a bit larger than the unique DHCP relaying lab:
- The community core has three nodes linked in a triangle: two switches and a router operating DHCP server.
- Two DHCP purchasers are linked to the identical consumer VLAN (VLAN 1000)
- Two Arista vEOS switches use VXLAN to increase the consumer VLAN throughout the community core.
- Arista switches are doing DHCP relaying towards the DHCP server within the community core.
Lab IPv4 addressing
Interface IPv4 tackle Description
================================================================================
srv (10.0.0.2/32)
GigabitEthernet0/1 10.1.0.1/30 srv -> sw1
GigabitEthernet0/2 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 consumer (1000) -> [cl_a,cl_b,sw2]
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 consumer (1000) -> [cl_a,sw1,cl_b]
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
Along with IP addressing, VLAN, VXLAN, and OSPF configuration I configured anycast gateways and easy DHCP relay on the Arista switches, and a DHCP pool on the Cisco IOSv router. The ultimate system configurations can be found in netlab-examples GitHub repository.
Arista vEOS VLAN/VXLAN DHCP relay configuration
vlan 1000
identify consumer
!
interface Vlan1000
description VLAN consumer (1000) -> [cl_a,cl_b,sw2]
ip tackle 172.16.0.3/24
ip helper-address 10.0.0.2
ip virtual-router tackle 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.4
!
ip virtual-router mac-address 02:00:ca:fe:00:ff
Cisco IOS DHCP server configuration
ip dhcp excluded-address 172.16.0.3
ip dhcp excluded-address 172.16.0.1
ip dhcp excluded-address 172.16.0.4
!
ip dhcp pool p_172.16.0.0
community 172.16.0.0 255.255.255.0
default-router 172.16.0.1
Does It Work?
It does. Right here’s the DHCP lease on cl_a:
DHCP lease on cl_a
Temp IP addr: 172.16.0.2 for peer on Interface: GigabitEthernet0/1
Temp sub web masks: 255.255.255.0
DHCP Lease server: 10.1.0.1, state: 5 Sure
DHCP transaction id: 21A5
Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
Temp default-gateway addr: 172.16.0.1
Subsequent timer fires after: 11:53:03
Retry depend: 0 Consumer-ID: cisco-5254.0099.2272-Gi0/1
Consumer-ID hex dump: 636973636F2D353235342E303039392E
323237322D4769302F31
Hostname: cl_a
Attending to that time is a little more attention-grabbing; we’ll use debugging on the DHCP consumer (debug dhcp element) and the DHCP server (debug ip dhcp server packet) to determine what’s happening:
- DHCP consumer sends the preliminary DISCOVER packet
00:12:28: DHCP: SDiscover try # 1 for entry:
00:12:28: Temp IP addr: 0.0.0.0 for peer on Interface: GigabitEthernet0/1
00:12:28: Temp sub web masks: 0.0.0.0
00:12:28: DHCP Lease server: 0.0.0.0, state: 3 Deciding on
00:12:28: DHCP transaction id: 12E3
00:12:28: Lease: 0 secs, Renewal: 0 secs, Rebind: 0 secs
00:12:28: Subsequent timer fires after: 00:00:04
00:12:28: Retry depend: 1 Consumer-ID: cisco-5254.0099.2272-Gi0/1
00:12:28: Consumer-ID hex dump: 636973636F2D353235342E303039392E
00:12:28: 323237322D4769302F31
00:12:28: Hostname: cl_a
00:12:28: DHCP: SDiscover positioned class-id possibility: 636973636F706E70
00:12:28: DHCP: SDiscover: sending 303 byte size DHCP packet
00:12:28: DHCP: SDiscover 303 bytes
00:12:28: B'forged on GigabitEthernet0/1 interface from 0.0.0.0
- The published from the DHCP consumer is propagated throughout the entire VLAN1000 and reaches sw1 and (over VXLAN) sw2. Each switches relay the DHCP request to the DHCP server which will get two copies of the DHCP DISCOVER message. The switches use their unicast IP tackle in VLAN 1000 (172.16.0.3 and 172.16.0.4) because the giaddr (gateway IP tackle). Anycast IP tackle isn’t used.
DHCP DISCOVER message forwarded by sw1
00:12:27: DHCPD: Sending notification of DISCOVER:
00:12:27: DHCPD: htype 1 chaddr 5254.0099.2272
00:12:27: DHCPD: distant id 020a00000a01000101000000
00:12:27: DHCPD: circuit id 00000000
00:12:27: DHCPD: DHCPDISCOVER acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31
by way of relay 172.16.0.3.
00:12:27: DHCPD: Possibility 125 not current within the msg.
00:12:27: DHCPD: Seeing if there's an internally specified pool class:
00:12:27: DHCPD: htype 1 chaddr 5254.0099.2272
00:12:27: DHCPD: distant id 020a00000a01000101000000
00:12:27: DHCPD: circuit id 00000000
00:12:27: DHCPD: Allocate an tackle with out class info (172.16.0.0)
00:12:27: DHCPD: Allotted binding 1013E808
00:12:27: DHCPD: Including binding to radix tree (172.16.0.6)
00:12:27: DHCPD: Including binding to hash tree
00:12:27: DHCPD: assigned IP tackle 172.16.0.6 to consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31.
DHCP DISCOVER message forwarded by sw2
00:12:27: DHCPD: Sending notification of DISCOVER:
00:12:27: DHCPD: htype 1 chaddr 5254.0099.2272
00:12:27: DHCPD: distant id 020a00000a01000502000000
00:12:27: DHCPD: circuit id 00000000
00:12:27: DHCPD: DHCPDISCOVER acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31
by way of relay 172.16.0.4.
00:12:27: DHCPD: Possibility 125 not current within the msg.
00:12:27: DHCPD: Seeing if there's an internally specified pool class:
00:12:27: DHCPD: htype 1 chaddr 5254.0099.2272
00:12:27: DHCPD: distant id 020a00000a01000502000000
00:12:27: DHCPD: circuit id 00000000
00:12:27: DHCPD: Discovered earlier server binding
00:12:29: DHCPD: Reprocessing saved workspace (ID=0x10000003)
00:12:29: DHCPD: Possibility 125 not current within the msg.
00:12:29: DHCPD: Sending notification of DISCOVER:
00:12:29: DHCPD: htype 1 chaddr 5254.0099.2272
00:12:29: DHCPD: distant id 020a00000a01000101000000
00:12:29: DHCPD: circuit id 00000000
- DHCP server realizes it bought duplicate DHCP DISCOVER messages and sends a single DHCP OFFER to the consumer:
00:12:29: DHCPD: Sending DHCPOFFER to consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31 (172.16.0.6).
00:12:29: DHCPD: Possibility 125 not current within the msg.
00:12:29: DHCPD: no possibility 125
00:12:29: DHCPD: unicasting BOOTREPLY for consumer 5254.0099.2272 to relay 172.16.0.3.
00:12:29: DHCPD: consumer's VPN is .
00:12:29: DHCPD: No possibility 125
- sw1 (172.16.0.3) relays the DHCP OFFER to the DHCP consumer. Please word that the DHCP server IP tackle is ready to the IP tackle of the LAN interface, not the loopback IP tackle to which the request has been relayed:
00:12:30: DHCP: Acquired a BOOTREP pkt
00:12:30: DHCP: Scan: Message kind: DHCP Supply
00:12:30: DHCP: Scan: Server ID Possibility: 10.1.0.1 = A010001
00:12:30: DHCP: Scan: Lease Time: 86400
00:12:30: DHCP: Scan: Renewal time: 43200
00:12:30: DHCP: Scan: Rebind time: 75600
00:12:30: DHCP: Scan: Subnet Deal with Possibility: 255.255.255.0
00:12:30: DHCP: Scan: Router Possibility: 172.16.0.1
00:12:30: DHCP: rcvd pkt supply: 172.16.0.3, vacation spot: 255.255.255.255
00:12:30: UDP sport: 43, dport: 44, size: 308
00:12:30: DHCP op: 2, htype: 1, hlen: 6, hops: 1
00:12:30: DHCP server identifier: 10.1.0.1
00:12:30: xid: 12E3, secs: 0, flags: 8000
00:12:30: consumer: 0.0.0.0, your: 172.16.0.6
00:12:30: srvr: 0.0.0.0, gw: 172.16.0.3
00:12:30: choices block size: 60
If the DHCP server replied to the DHCP DISCOVER forwarded by sw2, the IP tackle of the DHCP server can be totally different, so it might appear to be you might have two DHCP servers in your community.
- The subsequent packet within the course of is a DHCP REQUEST packet despatched as a broadcast packet (as a result of the consumer nonetheless doesn’t have a usable IP tackle) to the chosen DHCP server:
00:12:30: DHCP: SRequest- Server ID possibility: 10.1.0.1
00:12:30: DHCP: SRequest- Requested IP addr possibility: 172.16.0.6
00:12:30: DHCP: SRequest positioned class-id possibility: 636973636F706E70
00:12:30: DHCP: SRequest: 315 bytes
00:12:30: DHCP: SRequest: 315 bytes
00:12:30: B'forged on GigabitEthernet0/1 interface from 0.0.0.0
- But once more, the DHCP REQUEST broadcast is relayed by each switches, and the DHCP server receives two copies of the request. This time, the DHCP server replies to each DHCP REQUEST packets with DHCP ACK packets. It’s higher to ship a number of ACKs than to threat not replying to the second request; the primary reply may have been misplaced.
00:12:29: DHCPD: DHCPREQUEST acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31.
...
00:12:29: DHCPD: Sending DHCPACK to consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31 (172.16.0.6).
00:12:29: DHCPD: unicasting BOOTREPLY for consumer 5254.0099.2272 to relay 172.16.0.3.
...
00:12:29: DHCPD: DHCPREQUEST acquired from consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31.
...
00:12:29: DHCPD: Sending DHCPACK to consumer 0063.6973.636f.2d35.3235.342e.3030.3939.2e32.3237.322d.4769.302f.31 (172.16.0.6)
00:12:29: DHCPD: unicasting BOOTREPLY for consumer 5254.0099.2272 to relay 172.16.0.4.
- Subsequent DHCP messages are exchanged as unicast messages between the DHCP consumer and the DHCP server.
Reference: Lab Topology
As within the earlier DHCP relaying labs, I needed to outline DHCP attributes within the lab topology:
defaults.attributes:
hyperlink.dhcp:
consumer: bool
server: str
Subsequent, I outlined teams of gadgets:
- DHCP server is operating on a Cisco IOS router operating OSPF. We’ll use an extra configuration template (
dhcp-server.j2
) to configure it.
teams:
dhcp_server:
members: [ srv ]
module: [ ospf ]
config: [ dhcp-server ]
system: iosv
- DHCP purchasers are Cisco IOS routers:
teams:
dhcp_client:
members: [ cl_a, cl_b ]
config: [ dhcp-client ]
system: iosv
- VXLAN switches are Arista vEOS gadgets. They want OSPF, VLAN, VXLAN, and first-hop gateway netlab configuration modules. We’ll use an extra configuration template (
dhcp-relay.j2
) to configure them.
teams:
swap:
members: [ sw1, sw2 ]
module: [ ospf,vlan,vxlan,gateway ]
config: [ dhcp-relay ]
system: eos
Subsequent, I needed to outline the consumer VLAN:
- It makes use of a shared first-hop gateway (default: anycast gateway). The anycast gateway is the primary IP tackle within the subnet.
- The subnet is marketed into core OSPF course of (the lab isn’t utilizing VRFs) however we’re not operating OSPF on the VLAN.
- The VLAN is mechanically mapped right into a VXLAN section (default netlab conduct):
vlans:
consumer:
gateway: True
ospf.passive: True
gateway.id: 1
We’ve got to record the nodes:
nodes: [ srv, sw1, sw2, cl_a, cl_b ]
And at last, it’s time to outline the hyperlinks:
- First the three core hyperlinks:
hyperlinks:
- srv-sw1
- srv-sw2
- sw1-sw2
- Final however positively not least, the client-facing hyperlinks. The hyperlinks are in entry VLAN consumer, the purchasers use DHCP to get their IP tackle, and the switches relay DHCP requests to
srv
:
hyperlinks:
- cl_a:
dhcp.consumer: True
sw1:
dhcp.server: srv
vlan.entry: consumer
- cl_b:
dhcp.consumer: True
sw2:
dhcp.server: srv
vlan.entry: consumer
You may obtain the lab topology file from GitHub.
Reference: Configuration Templates
I needed to make slight modifications to the DHCP server configuration template I used within the easy DHCP relaying lab:
- The default gateway IP tackle is the anycast IP tackle (if current)
- Anycast IP tackle must be excluded from the DHCP pool.
DHCP pool configuration template
{% for h,v in hostvars.objects() %}
{% for intf in v.interfaces if intf.dhcp.server is outlined and intf.ipv4 is outlined %}
ip dhcp excluded-address {ipaddr('tackle') }
{% if intf.gateway.ipv4 is outlined %}
ip dhcp excluded-address {ipaddr('tackle') }
{% endif %}
{% endfor %}
{% endfor %}
!
{% for h,v in hostvars.objects() %}
{% for intf in v.interfaces if intf.dhcp.server is outlined and intf.ipv4 is outlined %}
!
ip dhcp pool p_{ipaddr('community') }
community {ipaddr('community') } {ipaddr('netmask') }
{% if intf.gateway.ipv4 is outlined %}
default-router {ipaddr('tackle') }
{% else %}
default-router {ipaddr('tackle') }
{% endif %}
{% endfor %}
{% endfor %}
You may obtain the configuration templates from GitHub;
Strive It Out!
Wish to run this lab by yourself, or strive it out with totally different gadgets? No drawback:
Coming Up Subsequent
DHCP relaying works in VXLAN segments with static ingress replication. Will it additionally work after we add EVPN and EVPN VRFs to the combo? That’s the subject of the subsequent weblog publish on this collection.