ProHoster > Blog > Administration > Configuring Microsoft Windows Server 2016/2019 to provide DHCP services for VXLAN (DFA)
Configuring Microsoft Windows Server 2016/2019 to provide DHCP services for VXLAN (DFA)
The purpose of this article is to make it easy to configure a DHCP service for a VXLAN BGP EVPN and DFA fabric using Microsoft Windows Server 2016/2019.
In the official DHCP documentation, a service based on Microsoft Windows Server 2012 for the factory is configured as a SuperScope containing a Loopback pool (in this pool, the highlight is the exclusion from the pool of all IP addresses of the pool (excluded IP address = pool)) and pools for issuing IP addresses for real networks (here the highlight - the policy is configured - in which DHCP Relay Circuit IDs are filtered and this DHCP relay Circuit ID contains VNI for the network, i.e. for another pool this DHCP Relay Circuit ID will be slightly different).
To configure DHCP on Windows server.
1. Create a super scope. Within the super scope, create scope B, S1, S2, S3, …, Sn for the subnet B and the subnets for each segment.
2. In scope B, specify the 'Exclusion Range' to be the entire address range (so that the offered address range must not be from this scope).
3. For every segment scope Si, specify a policy that matches on Agent Circuit ID with value of '0108000600XXXXXX', where '0108000600' is a fixed value for all segments, the 6 numbers "XXXXXX" is the segment ID value in hexadecimal. Also ensure to check the Append wildcard(*) check box.
4. Set the policy address range to the entire range of the scope.
This article contains answers to the following questions:
This part briefly lists all the initial data: Instructions for configuring network equipment, RFC used in DHCP packets in eVPN factories, for reference, the evolution of DHCP server settings on Microsoft Windows Server 2012 is given in the Cisco documentation. As well as brief information about Superscope and Policy in the DHCP service on Microsoft Windows Servers.
How DHCP Relay is configured on the VXLAN BGP EVPN, DFA factory
Configuring a DHCP Relay on a VXLAN BGP EVPN fabric is not the main topic of this article, as it is quite simple. I give links to the documentation and a spoiler on the settings on the network equipment.
Example of configuring DHCP Relay on Nexus 9000V v9.2(3)
service dhcp
ip dhcp relay
ip dhcp relay information option
ip dhcp relay information option vpn
interface loopback10
vrf member VRF1
ip address 10.120.0.1/32 tag 1234567
interface Vlan12
no shutdown
vrf member VRF1
no ip redirects
ip address 10.120.251.1/24 tag 1234567
no ipv6 redirects
fabric forwarding mode anycast-gateway
ip dhcp relay address 10.0.0.5
ip dhcp relay source-interface loopback10
RFCs that are implemented in the operation of the DHCP Relay service in the VXLAN BGP EVPN factories
• Sub-option 151(0x97) - Virtual Subnet Selection (Defined in RFC#6607)
Used to convey VRF related information to the DHCP server in an MPLS-VPN and VXLAN EVPN multi-tenant environment.
The "name" of the VRF in which the client is located is transmitted.
RFC#5107: Sub-option 11(0xb) - Server ID Override
• Sub-option 11(0xb) - Server ID Override (Defined in RFC#5107.)
The server identifier (server ID) override sub-option allows the DHCP relay agent to specify a new value for the server ID option, which is inserted by the DHCP server in the reply packet. This sub-option allows the DHCP relay agent to act as the actual DHCP server such that the renew requests will come to the relay agent rather than the DHCP server directly. The server ID override sub-option contains the incoming interface IP address, which is the IP address on the relay agent that is accessible from the client. Using this information, the DHCP client sends all renew and release request packets to the relay agent. The relay agent adds all of the appropriate sub-options and then forwards the renew and release request packets to the original DHCP server. For this function, Cisco’s proprietary implementation is sub-option 152(0x98). You can use the ip dhcp relay sub-option type cisco command to manage the function.
This option is used to have the client send an address renewal request to the IP address used in this option. (In Cisco VXLAN BGP, EVPN is the Anycast default gateway address for the client.)
RFC#3527: Sub-option 5(0x5) - Link Selection
Sub-option 5(0x5) - Link Selection (Defined in RFC#3527.)
The link selection sub-option provides a mechanism to separate the subnet/link on which the DHCP client resides from the gateway address (giaddr), which can be used to communicate with the relay agent by the DHCP server. The relay agent will set the sub-option to the correct subscriber subnet and the DHCP server will use that value to assign an IP address rather than the giaddr value. The relay agent will set the giaddr to its own IP address so that DHCP messages are able to be forwarded over the network. For this function, Cisco’s proprietary implementation is sub-option 150(0x96). You can use the ip dhcp relay sub-option type ciscocommand to manage the function.
The address of the network from which the client needs an IP address.
Evolution of the Cisco Documentation on Configuring DHCP on Microsoft Windows Server 2012
I included this section because there is a positive trend on the part of the vendor:
This article states that each network/VNI needs its own SuperScope bundle and its own set of Loopback addresses:
If multiple DHCP Scopes are required for multiple subnets, you need to create one LoopbackX per subnet/vlan on all LEAFS and create a superscope with a loopbackX range scope and actual client IP subnet scope per vlan.
Added Windows 2012 Server settings to the documentation for setting up network equipment. All address pools in use require one SuperScope per data center, and this SuperScope is the boundary of the data center:
Create Superscope for all scopes you want to use for Option 82-based policies.
Note
The Superscope should combine all scopes and act as the administrative boundary.
Let us assume the switch is using the address from subnet B (it can be the backbone subnet, management subnet, or any customer designated subnet for this purpose) to communicate with the Windows DHCP server. In DFA we have subnets S1, S2, S3, …, Sn for segment s1, s2, s3, …, sn.
To configure DHCP on Windows server.
1. Create a super scope. Within the super scope, create scope B, S1, S2, S3, …, Sn for the subnet B and the subnets for each segment.
2. In scope B, specify the 'Exclusion Range' to be the entire address range (so that the offered address range must not be from this scope).
3. For every segment scope Si, specify a policy that matches on Agent Circuit ID with value of '0108000600XXXXXX', where '0108000600' is a fixed value for all segments, the 6 numbers "XXXXXX" is the segment ID value in hexadecimal. Also ensure to check the Append wildcard(*) check box.
4. Set the policy address range to the entire range of the scope.
DHCP in Microsoft Windows Server (superscope & policy)
Superscope is an administrative feature of a DHCP server that can be used to group multiple scopes as a single administrative entity. Superscope allows a DHCP server to provide leases from more than one scope to clients on a single physical network. Scopes added to a superscope are called member scopes.
What is SuperScope - this is a functionality that allows you to combine several pools of IP addresses into one administrative unit. To announce to users in the same physical network (in the same VLAN) ip addresses from several pools. If the request came to a pool of addresses as part of a SuperScope, then you can issue an address to the client from another Scope included in this SuperScope.
The DHCP Server role in Windows Server 2012 introduces a new feature that allows you to create IPv4 policies that specify custom IP address and option assignments for DHCP clients based on a set of conditions.
The policy based assignment (PBA) feature allows you to group DHCP clients by specific attributes based on fields contained in the DHCP client request packet. PBA enables targeted administration and greater control of the configuration parameters delivered to network devices with DHCP.
Policies - allow you to assign IP addresses to users depending on the type of user or parameter. Cisco engineers use policies in Windows Server 2012 to filter by VNI (Virtual Network Identifier).
Main part
This section contains the results of research, why it is not supported, how it works (logic), what is new and how this new will help us.
Why is Microsoft Windows Server 2000/2003/2008 not supported?
Microsoft Windows Server 2008 and earlier versions do not process option 82 (Option 82) and the return packet is sent without option 82.
The request from the client is sent by Broadcast (DHCP Discover).
The hardware (Nexus) sends the packet to a DHCP server (DHCP Discover + Option 82).
DHCP Server receives the packet, processes it, sends it back, but without option 82. (DHCP Offer - without option 82)
The hardware (Nexus) receives a packet from a DHCP server. (DHCP Offer) But does not send this packet to the end user.
Sniffer data - on Windows Server 2008 and on DHCP clientWindows Server 2008 receives a request from network equipment. (Option 82 is listed)
Windows Server 2008 sends a response to the network equipment. (Option 82 is not in the list of options in the package)
Request from client - DHCP Discover present and DHCP Offer absent
Statistics on network equipment:
NEXUS-9000V-SW-1# show ip dhcp relay statistics
----------------------------------------------------------------------
Message Type Rx Tx Drops
----------------------------------------------------------------------
Discover 8 8 0
Offer 8 8 0
Request(*) 0 0 0
Ack 0 0 0
Release(*) 0 0 0
Decline 0 0 0
Inform(*) 0 0 0
Nack 0 0 0
----------------------------------------------------------------------
Total 16 16 0
----------------------------------------------------------------------
DHCP L3 FWD:
Total Packets Received : 0
Total Packets Forwarded : 0
Total Packets Dropped : 0
Non DHCP:
Total Packets Received : 0
Total Packets Forwarded : 0
Total Packets Dropped : 0
DROP:
DHCP Relay not enabled : 0
Invalid DHCP message type : 0
Interface error : 0
Tx failure towards server : 0
Tx failure towards client : 0
Unknown output interface : 0
Unknown vrf or interface for server : 0
Max hops exceeded : 0
Option 82 validation failed : 0
Packet Malformed : 0
Relay Trusted port not configured : 0
DHCP Request dropped on MCT : 0
* - These counters will show correct value when switch
receives DHCP request packet with destination ip as broadcast
address. If request is unicast it will be HW switched
NEXUS-9000V-SW-1#
Why is setup so complicated in Microsoft Windows Server 2012?
Microsoft Windows Server 2012 does not yet support RFC#3527 (Option 82 Sub-option 5(0x5) - Link Selection)
But the Policy functionality has already been implemented.
How it works:
Microsoft Windows Server 2012 has a super pool (SuperScope) that has Loopback addresses and pools for real networks.
The choice of a pool for issuing an IP address falls into the SuperScope, since the response came from the DHCP Relay from the Loopback Source address included in the SuperScope.
Using Policy, the query selects from the Superscope that member scope whose VNI is contained in Option 82 Suboption 1 Agent Circuit ID. (“0108000600”+ 24 VNI bits + 24 bits whose values I don't know, but the sniffer shows values of 0 in this field.)
How is setup made easier in Microsoft Windows Server 2016/2019?
Microsoft Windows Server 2016 implements RFC#3527 functionality. That is, Windows Server 2016 is able to recognize the correct network from the attribute Option 82 Sub-option 5(0x5) - Link Selection
Three questions immediately arise:
Can we do without Superscope?
Can we do without Policy and converting VNI to hexadecimal form?
Can we do without Scope for Loopback DHCP Source Addresses?
Q. Can we do without Superscope? A. Yes, scope can be created immediately in the scope of IPv4 addresses. Q. Can we do without Policy and converting VNI to hexadecimal form? A. Yes, network selection is based on Option 82 Suboption 0x5, Q. Can we do without Scope for Loopback DHCP Source Addresses? A. No we can not. Because Microsoft Windows Server 2016/2019 has protection against malicious DHCP requests. That is, all requests from addresses that are not in the DHCP server pool are considered malicious.
Note
All relay agent IP addresses (GIADDR) must be part of an active DHCP scope IP address range. Any GIADDR outside of the DHCP scope IP address ranges is considered a rogue relay and Windows DHCP Server will not acknowledge DHCP client requests from those relay agents.
A special scope can be created to "authorize" relay agents. Create a scope with the GIADDR (or multiple if the GIADDR's are sequential IP addresses), exclude the GIADDR address(es) from distribution, and then activate the scope. This will authorize the relay agents while preventing the GIADDR addresses from being assigned.
Those. to configure a DHCP pool for VXLAN BGP EVPN factory on Microsoft Windows Server 2016/2019, you only need:
Create a pool for Relay Source addresses.
Create a pool for client networks
Which is not necessary (but can be configured and it will work, and will not interfere with work):
Create Policy
Create a SuperScope
ExampleAn example of configuring a DHCP server (there are 2 real DHCP clients - the clients are connected to the VXLAN factory)
An example of setting up a user pool:
An example of setting up a user pool (policies are selected - to prove that the policies were not used for the correct operation of the pool):
An example of configuring a pool for DHCP Relay Source addresses (the range of addresses for issuance fully corresponds to the exclusion from the address pool):
Configuring DHCP service on Microsoft Windows Server 2019
Configuring a pool for Loopback addresses (source) for DHCP Relay.
We create a new pool (Scope) in the IPv4 space.
Pool Creation Wizard. Next >
Set up the pool name and description (Description) of the pool.
Set the range of IP addresses for Loopback and the mask for the pool.
Adding exceptions. The exclusion range must exactly match the pool range.
Rental time. Next >
Query: Will you configure DHCP options now (DNS, WINS, Gateway, Domain) or do it later. It will be faster to answer no, and then activate the pool manually. Or go to the end without filling in any information and at the end of the wizard activate the pool.
We confirm that the options are not configured, the pool is not activated. Finish
Activate the pool manually. - Select Scope and in the context menu - select "Activate".
We create a pool for users/servers.
We create a new pool.
Pool Creation Wizard. Next >
Set up the pool name and description (Description) of the pool.
Set the range of IP addresses for Loopback and the mask for the pool.
Adding exceptions. (No exceptions required by default) "Next >"
Rental time. Next >
Query: Will you configure DHCP options now (DNS, WINS, Gateway, Domain) or do it later. Let's set it up now.
Set the default gateway address.
Set up the domain and DNS server addresses.
Set up IP addresses of WINS servers.
Scope activation.
The pool is configured. Finish
Conclusion
Using Windows Server 2016/2019 reduces the complexity of configuring a DHCP server for the VXLAN of a factory (or any other factory). (It is not required to transfer special bundles to IT specialists: Network / Agent Circuit ID for prescribing filters.)
Will the configuration for Windows Server 2012 work on new servers 2016/2019 - yes it will work.
This document provides links to 2 versions: 7.X and 9.3. This is due to the fact that version 7.0(3)I7(7) is the Cisco Suggested release, and version 9.3 is the most innovative (up to Multicast support via VXLAN Multisite).