APPENDIX: Example DHCP Relay in EVPN Multihoming Fabric

Campus Fabric Dialogue Configuration

In the campus fabric dialogue configuration, it is important to configure:

• The correct fabric type = EVPN multihoming
• Virtual gateway v4 MAC address = Enabled (this makes debugging easier as there is not a global MAC address used across all VLANs).

Assign the switches as collapsed cores and access switches in the next pane.

Then, in the “Networks” fabric dialogue, import two VLANs from the switch template.

• First VLAN (your desktop client requiring a lease will be here):
  • Name = vlan1099
  • VLAN ID = 1099
  • IPv4 subnet = 10.99.99.0/24
  • IPv4 virtual gateway = 10.99.99.1
• Second VLAN (your DHCP server will be here):
  • Name = vlan1091
  • VLAN ID = 1091
  • IPv4 subnet = 10.91.91.0/24
  • IPv4 virtual gateway = 10.91.91.1

Then, add them to a single VRF:

• VRF Configuration = Enabled
• VRF:
  • Name = customera
  • Networks = vlan1099 and vlan1091

See the example:

Also add the DHCP relay information:

• DHCP relay = Enabled
• vlan1099:
  • Network = vlan1099
  • DHCP servers = 10.91.91.42

Note:

Ensure you always use this dialogue to configure DHCP relay in all campus fabric designs.

Finish the remaining dialogues so that Juniper Mist cloud pushes configuration to setup the fabric.

Access Switch Configuration

Our Desktop1 client is attached to the ge-0/0/3 interface on the Access1 switch through the following port configuration:

Based on this configuration, Juniper Mist cloud configures the following Junos OS configuration on the two collapsed core switches where the VRF is located in this fabric.

Note:

At the time this document was created, not all options in Junos OS that are explained in the solution architecture chapter are created. Hence, we manually added the below additional Junos OS configuration on each collapsed core switch to have the optimal experience with the various DHCP servers tested.

DHCP Server Integration

We decided to position a switch between the fabric and the DHCP server which was a virtual machine. Microsoft Windows does not support the usage of LACP when the server is a VM. However, we do that at the fabric side, hence we use a switch as a kind of translation element. Another advantage is that towards the VM, we then have a single interface containing all messages which makes it easier to debug.

On the two collapsed core switches you configure:

• Port ID = ge-0/0/5
• Configuration profile = vlan1091
• Port aggregation = Enabled
  • AE Index = 1
  • ESI-LAG = Enabled

On the switch between the fabric and the DHCP server, you add a simple LAG configuration such as the one below:

• Port IDs = ge-0/0/1-2
• Interface = L2 interface
• Configuration profile = vlan1091
• Port aggregation = Enabled
  • LACP = Enabled
  • LACP force up = Disabled
  • LACP periodic slow = Disabled
  • AE Index = 1

The single interface towards the DHCP server then:

• Port ID = ge-0/0/0
• Interface = L2 interface
• Configuration profile = vlan1091

Check the DHCP Server Itself

We assume that you have installed Microsoft Windows 2022 Server edition and applied the configuration example from above chapter APPENDIX: Example Microsoft DHCP server configuration used for testing . When this is done, you need to check the connection to the fabric to ensure the server gets the relay messages. In our case, the server had more than one interface for bootstrapping it:

Verify that the server is listening on the IP address 10.91.91.42:

Final Test with a Wired Client

To complete the installation, perform a final test with a wired client. The initial state of our client is that it has a static IP address assigned and can communicate towards the internet:

We can see this client and its IP address in the Wired Client overview in the Juniper Mist portal:

Next, we unconfigure the static IP address and try to obtain a DHCP lease instead. The additional configuration below ensures that the client loses the static configuration and any prior knowledge of a DHCP lease. We then start up the DHCP client in the foreground to see a bit more of the debugging messages:

After a while (depending on local ARP age-outs), this change becomes visible in the Wired Client overview:

You can also see the lease handout on the DHCP server itself when opening the DHCP Manager as follows:

Below is an example of our client now appearing in the lease database of the DHCP server:

Example Trace of a DHCP Lease Handout

Below, you find the full sequence of a DHCP lease handout looking at the originating wired client and the DHCP server side getting the forwarded messages from the relay agent of the fabric. This was captured simultaneously through tcpdump.

We start the trace on the client sending the discover message through broadcast to the fabric relay agent:

We now review the relay message arriving on the DHCP server with the embedded information from the fabric relay agent such as gateway IP and option 82:

The DHCP server responds towards the fabric relay agent with the offer for the client:

The fabric relay agent filters some of the information out (such as option 82) and forwards the offer as Layer 2 unicast to the client:

Based on the previous offer received, the client now sends a request message through broadcast to the fabric relay agent:

We now review the relay messages arriving on the DHCP server with the embedded information from the fabric relay agent such as the gateway IP and option 82 like the previously forwarded discover message:

The DHCP server responds with the lease acknowledgement back towards the fabric relay agent:

The fabric relay agent filters some of the information out (such as option 82) and forwards the lease acknowledgement as Layer 2 unicast to the client: