Introduction
In a typical network a DHCP flow would look something like this.
If your DHCP server resides on a different subnet (which will most probably be the case) you would use the command “ip helper-address x.x.x.x” to overcome the broadcast barrier that a Layer3 Network device has by taking the DHCP broadcast request and forwarding it in a DHCP unicast request to the DHCP server.
In the Fabric the behavior is slightly different, as our DHCP server will reside outside the fabric , like in Data Center for example.
We also use Anycast GW in the fabric to allow for seamless mobility and this will also have affect on a normal DHCP flow.Requirements
Before reading this document, you must have a basic understanding of the following Architectural terms:
Understanding of SDA
Virtual Network Identifier (VNI)
Virtual Routing and Forwarding (VRF)
Switch Virtual Interface (SVI)
Dynamic Host Configuration Protocol (DHCP) / Flow
Anycast Gateway
Anycast address is an address allocated to a set of interfaces that typically belong to different routers and in the fabric, this allows for seamless mobility as the endpoint moving from one fabric edge device to another does not need to change their Default GW address. For this reason, you will notice that every Switch Virtual Interface (SVI) that is provisioned by Cisco DNA Center is present on every Fabric Edge device with the same virtual IP and MAC address.
The SVI will have the DHCP Server IP address configured as its ip helper address, just as you would in a typical non-fabric network where the DHCP Server resides on a different subnet than your endpoint.
Now imagine you have 5 Fabric Edge devices and the SVI address is identical across all of them (See Illustration 1 below).
The fabric edge device sends a DHCP Request on behalf of the endpoint using its own SVI address.
How will the Border Device know to which Edge device it needs to return the DHCP reply to?
Illustration 1
DHCP Flow in The Fabric
When creating the fabric, we create VNs for the different services we require.
For example we may create
- INFRA_VN – Used for Access Points and Extended Nodes in the GRT
- DEFAULT_VN – We can use as our Underlay VN
- USERS_VN – Created for user access
Whats important to keep in mind is that VNs in the fabric are the equivalent to VRFs but with added attributes.
The USERS VN for example will need access to a DHCP server which is beyond the fabric meaning it resides in a different routing table (what we refer to as the Global Routing Table in the network), and in order to reach the DHCP server we need to leak the routes between the VRFs routing table and the GRT, and this is done using what we call a “Fusion Router”.
In the illustration above we are using a “GLOBAL” VRF as our Global Routing Table (GRT).
On the left-hand side, we will defer to "USERS" VRF as an example for the user access.
We route-leak the routes in the VRFs on the “Fusion Router” which can be seen in this CLI example.
ip vrf USERS
rd 1:4099
route-target export 1:4099
route-target import 1:4099
route-target import 1:4097
ip vrf GLOBAL
rd 1:4097
route-target export 1:4097
route-target import 1:4097
route-target import 1:4099
The endpoint device will now be able to reach the DHCP server.
In the next section will discuss how exactly the Border GW actually knows to which Fabric Edge device it needs to send the DHCP reply to.
- Client from subnet 10.1.18.0/24 sends DHCP request
- The DHCP request is sent from the Edge device to the DHCP server adding option 82/Circuit ID.
The “magic” lays in option 82 which provides additional DHCP information regarding the clients point of attachment, in this case it would be the RLOC loopback address 1.1.1.1 as well as the
VN-ID 10 (vrf id 10).
- The Border will forward the DHCP request via the Fusion Router so it may reach the DHCP server as explained earlier.
Before proceeding with the flow let’s look at the configurations that are needed to accomplish this.
The following configurations are needed to enable option 82 as well as pointing to the ip helper-address.
This is Automated by Cisco DNA Center.
“ip dhcp relay information option” – enables option 82 and is also automatically enabled by Cisco DNA Center.
Without this command DHCP in the Fabric will not work.
In order for the DHCP server (which is outside the fabric) to learn the endpoints subnet we need to advertise it into BGP, and we do this by using the config below in the diagram.
Notice how we use the “Interface Loopback3000” to advertise the subnet.
This is common rule in networking - if router does not know of a route to the endpoints subnet it will not advertise the subnet to others. Which makes sense right? so we “fool” the router thinking it knows of subnet 10.1.18.0/24 by adding loopback3000 with an IP from the endpoint’s subnet (in this case the SVI address).
This to is automated by Cisco DNA Center.
The DHCP server will check the GIADDR address and offer an ip address from that subnet.
In the process option 82 is also sent back to the Border GW without the DHCP server processing it.
NOTE: Make sure your DHCP server supports option 82, Windows Server 2008 for example does not support Option 82.
Proceeding with the step 4 or the DHCP flow
4.
5. The Border GW will extract the option 82 information and send the DHCP reply.
Fabric Edge device is RLOC=1.1.1.1 VNI=10
The following commands on the Border GW achieve step 5
Inteface Loopback3000
vrf forwarding User
ip address 10.1.18.1 255.255.255.255
When using an ASR1K or an ISR4K as your Border Device and additional command will be added to the interface loopback which is
“dhcp-border-relay”
This to is automated by Cisco DNA Center but good to keep in mind.
6. At this final step the Border gw will send the reply to the Fabric Edge device in which the request originally came from by using the RLOC address and VNI 10.
