After determining how DHCP relaying works and testing it in a easy lab, I went a step additional and examined VRF-aware DHCP relaying.
Lab Topology
I needed to make just some adjustments to the DHCP relaying lab topology:
- DHCP server is working on CSR 1000v. IOSv DHCP server doesn’t help subnet choice DHCP choice and thus doesn’t work with relays that do inter-VRF DHCP relaying.
- I put the hyperlink between the DHCP consumer and DHCP relay right into a VRF.
Modifications in lab topology
teams:
change:
members: [ relay ]
module: [ ospf,vrf ]
vrfs:
consumer:
hyperlinks:
- consumer:
dhcp.consumer: True
relay:
dhcp.server: srv
sort: lan
vrf: consumer
Lab topology diagram
Lab IPv4 addressing
Interface IPv4 handle Description
================================================================================
srv (10.0.0.1/32)
GigabitEthernet2 10.1.0.2/30 srv -> relay
relay (10.0.0.2/32)
GigabitEthernet0/1 10.1.0.1/30 relay -> srv
GigabitEthernet0/2 172.16.0.2/24 relay -> consumer (VRF: consumer)
consumer (10.0.0.3/32)
GigabitEthernet0/1 172.16.0.3/24 consumer -> relay
You’ll be able to view the whole topology file on GitHub.
System Configurations
I configured VRF-aware DHCP relay (ip dhcp relay info choice vpn) and VRF-aware DHCP swimming pools (use vrf choice in ip dhcp pool). The last gadget configurations (with Cisco IOSv as DHCP relay) can be found in netlab-examples GitHub repository.
Cisco IOS VRF-aware DHCP relay configuration
ip dhcp relay info choice vpn
!
interface GigabitEthernet0/2
ip helper-address international 10.0.0.1
Cisco IOS VRF-aware DHCP server configuration
ip dhcp excluded-address vrf consumer 172.16.0.2
!
ip dhcp pool p_172.16.0.0
vrf consumer
community 172.16.0.0 255.255.255.0
default-router 172.16.0.2
Does It Work?
It does… as soon as I discovered IOSv DHCP server doesn’t work effectively with inter-VRF DHCP relaying and switched to CSR 1000v. Let’s go into among the fascinating (cleaned up) debugging printouts on the DHCP server. Full consumer and server logs are obtainable on GitHub.
Debugging printout of DHCP server discovery
DHCPD: tableid for 10.1.0.2 on GigabitEthernet2 is 0
DHCPD: discovered subnet_info_addr 172.16.0.0
DHCPD: Giaddr from server-id-override suboption 172.16.0.2
DHCPD: consumer's VPN is consumer.
DHCPD: DHCPDISCOVER obtained from consumer 0063.6973.636f.2d35.3235.342e.3030.3539.2e64.6664.352d.4769.302f.31 via relay 10.1.0.1.
DHCPD: utilizing server-id-override 172.16.0.2
DHCPD: Possibility 125 not current within the msg.
DHCPD: egress Interfce GigabitEthernet2
DHCPD: unicasting BOOTREPLY for consumer 5254.0059.dfd5 to relay 10.1.0.1.
Right here’s what’s happening behind the scenes.
DHCP relay:
- Specified its international IPv4 handle (10.1.0.1) because the relay IPv4 handle (giaddr)
- Used hyperlink choice sub-option (choice 82 sub-option 5, outlined in RFC 3527) to go the details about the VRF IP subnet during which the consumer resides.
- Included consumer VPN info (choice 82 sub-option 151, outlined in RFC 6607)
- Set the specified server ID to its VRF IP handle (choice 82 sub-option 11, outlined in RFC 5107)
DHCP server due to this fact assigned an IP handle from 172.16.0.0 pool to the consumer, set the server ID to 172.16.0.2, and despatched the reply to 10.1.0.1. Comparable processing occurs for all subsequent packets.
Let’s additionally examine the consumer lease:
DHCP lease on the DHCP consumer
consumer#present dhcp lease
...
Temp IP addr: 172.16.0.4 for peer on Interface: GigabitEthernet0/1
Temp sub web masks: 255.255.255.0
DHCP Lease server: 172.16.0.2, state: 5 Sure
DHCP transaction id: 2030
Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
Subsequent timer fires after: 11:36:39
Retry depend: 0 Shopper-ID: cisco-5254.0059.dfd5-Gi0/1
Shopper-ID hex dump: 636973636F2D353235342E303035392E
646664352D4769302F31
Hostname: consumer
As anticipated, the DHCP server IP handle is the VRF IP handle of the DHCP relay. All subsequent DHCP packets are thus despatched to the DHCP relay and never on to the DHCP server.
Vendor Interoperability Is Enjoyable
I attempted to check a mix of Arista vEOS DHCP relay (4.28.3M) and Cisco CSR DHCP server.
Arista vEOS VRF-aware DHCP relay configuration
ip dhcp relay info choice
!
interface Ethernet2
ip helper-address 10.0.0.1 vrf default
It didn’t work till I eliminated the vrf definition from the DHCP pool – right here’s the related a part of Cisco IOS XE debugging printout:
DHCPD: Unhealthy VPN info sort: 99.
DHCPD: consumer's VPN is .
Based on RFC 6607, the VPN choice sub-option (sub-option 151) begins with Digital Subnet Choice Kind (a binary zero for VRF identify), and that’s what Cisco IOS XE expects.
Arista EOS 4.29.1F documentation (part 13.1.9 – DHCP Relay Throughout VRF) claims that the worth of sub-option 151 created by EOS accommodates simply the VPN identify (with out the intervening binary zero that means “what follows is the VPN identify”). Confronted with consumer as the worth of sub-option 151, Cisco IOS understands the VSS Kind to be 99 (ASCII worth of c), which is invalid. The DHCP server on CSR 1000v thus ignores sub-option 151.
Takeaways
- Inter-VRF DHCP relaying is complicated – it’s attempting to make a easy protocol do issues it was by no means designed to do. We’ll get again to the enjoyable implications of this Rube Goldberg stack of kludges once we get to redundant designs.
- Two or three sub-options of option-82 are concerned in inter-VRF DHCP relaying, and DHCP relays and servers must help them completely for the entire thing to work.
- Specifically, the DHCP relay and DHCP server MUST help server identifier override sub-options of choice 82 and MUST help the identical means of figuring out the consumer subnet.
- There are a minimum of two methods of specifying the consumer subnet in DHCP – hyperlink choice sub-option of choice 82 and subnet choice choice (choice 118). Within the excellent world, all relay brokers and servers would use hyperlink choice sub-option – in any case, it was designed for use in DHCP relaying situations. I wouldn’t be shocked if the networking distributors fail to achieve that stage of consistency.
- Digital Subnet Choice Suboption (choice 151) it not wanted for inter-VRF DHCP relaying, however is required to implement multi-tenant DHCP with overlapping handle swimming pools. No less than one vendor carried out it incorrectly.
I’m constructive that you simply’ve skilled your share of horror tales on different platforms. Please share them within the feedback!
Reference: Configuration Templates
I needed to make the DHCP relay and DHCP server configuration templates VRF-aware to make this lab work.
DHCP relay has to make use of the international parameter of the ip helper-address. It additionally needs to be configured to insert VPN sub-option into Relay Agent DHCP choice (ip dhcp relay info choice vpn):
DHCP relay configuration template
{% for intf in interfaces if intf.dhcp.server is outlined and intf.vrf is outlined %}
{% if loop.first %}
ip dhcp relay info choice vpn
{% endif %}
{% endfor %}
!
{% for intf in interfaces if intf.dhcp.server is outlined %}
ipaddr('handle') %
interface {{ intf.ifname }}
{% if intf.vrf is outlined %}
ip helper-address international {{ helper }}
{% else %}
ip helper-address {{ helper }}
{% endif %}
{% endfor %}
All I needed to do within the DHCP server template was so as to add the vrf choice to ip dhcp excluded-address and ip dhcp pool configuration instructions:
DHCP relay server template
logging buffered
no service timestamp debug
!
do debug ip dhcp server packet
do debug ip dhcp server occasion
!
{% for h,v in hostvars.gadgets() %}
{% for intf in v.interfaces if intf.dhcp.server is outlined and intf.ipv4 is outlined %}
ip dhcp excluded-address {% if intf.vrf is outlined %}vrf {{ intf.vrf }} {% endif %}{ipaddr('handle') }
{% endfor %}
{% endfor %}
!
{% for h,v in hostvars.gadgets() %}
{% for intf in v.interfaces if intf.dhcp.server is outlined and intf.ipv4 is outlined %}
!
ip dhcp pool p_{ipaddr('community') }
{% if intf.vrf is outlined %}
vrf {{ intf.vrf }}
{% endif %}
community {ipaddr('community') } {ipaddr('netmask') }
default-router {ipaddr('handle') }
{% endfor %}
{% endfor %}
You’ll be able to obtain the configuration templates from GitHub;
Strive It Out!
Wish to run this lab by yourself, or attempt it out with totally different units? No drawback:
Coming Up Subsequent
Up to now so good: easy DHCP relaying works, as does (with just a few quirks) inter-VRF DHCP relaying. Will they nonetheless work in VXLAN segments? That’s the subject of the subsequent weblog publish on this sequence.
