Recommendations

The following simple guidelines will help you to successfully implement DHCP relay using campus fabric.

Like WAN router integration, at the start of the campus fabric integration, the capabilities of the third-party DHCP server provided by the customer should be verified to meet the following requirements:

• It must provide at least two DHCP server instances for redundancy of this critical function. State sharing of the DHCP lease database between these instances simplifies the design by not needing to configure non-overlapping IP address ranges among separate instances.
• For DHCP relay to work properly, the DHCP server is required to listen on an IP address-based socket-interface.
• The location of the DHCP server is an important consideration. The closer to clients, the better. Attaching the DHCP server to the fabric should be considered.
• The DHCP server should be able to analyse the embedded option 82 information to make the decision on the DHCP lease assignment. Without additional Junos OS CLI configuration, the fabric will send:
  • Option 82 sub-option 1 (circuit ID) with the originating VLAN ID as a string.
  • Option 82 sub-option 5+11 contains the 4 bytes of the originating subnet.
  • The gateway IP address can also be used when the fabric is a virtual gateway fabric type.
• DNS integration with security systems (such as NAC) for monitoring client state should be left to the customer maintaining the third-party DHCP server.

Here, we summarize the best practice items already shared in the solution architecture section:

• Be aware that the communication towards the DHCP server happens based on embedded gateway IP addresses, which is dependent on the fabric type:
  • Static IP address of the overlay VLANs is used in virtual gateway fabrics such as:
    • In EVPN multihoming, this is always the case.
    • In CRB, this is optional when deleting the overlay loopback pool prefix from the fabric configuration.
  • Overlay loopback IP addresses coming from a pool and assigned globally as /32 across all VRF’s:
    • In CRB, this is optional when configuring the overlay loopback pool prefix from the fabric configuration.
    • In ERB, this is recommended, so configure the overlay loopback pool prefix in the fabric configuration.
    • In IP Clos, this is recommended, so configure the overlay loopback pool prefix in the fabric configuration.
    • When using overlay loopback IP addresses, ensure to use a routing protocol such as eBGP or OSPF towards the WAN router as it makes the propagation of the distributed /32 IP addresses over the VRFs easier to maintain.
    • If your fabric was deployed before June 21, 2024, you may need additional Junos OS configuration to propagate the /32 overlay loopback IP addresses. Please review the appendix for an example.
• The location of the DHCP server needs to be validated:
  • We recommend directly integrating the DHCP server into the service block function of the fabric.
  • Less preferred is locating the DHCP server outside the fabric. If this must be done, please make sure that:
    • You minimize the latency between the fabric and DHCP server. Deploying the DHCP server in a public cloud should be avoided, if possible.
    • No form of network address (NAT) translation between the fabric and the DHCP server is performed.

• All DHCP relay forwarding configuration must be performed as part of the campus fabric configuration dialogue when configuring networks and VRFs. Do not override the fabric DHCP relay configuration by manually configuring it on the switch.

For debugging, we also recommend the following practices:

• Deploy a spare Juniper access point in the fabric that you are allowed to reboot anytime during the DHCP server integration. The DHCP client on the access point is perfect for triggering a DHCP lease request for testing and you will directly see the effects of the lease assignment in the Juniper Mist portal.
• When activating DHCP snooping:
  • This is only allowed to be performed on the access switches in the fabric where DHCP traffic ingresses.
  • Turn this function off if you do not need it any longer. In contrast to a typical EX series switch branch deployment where this function can be used to report the IP address clients, fabrics usually have a VRF where the IP address for a given MAC address is reported to the Juniper Mist cloud. This also happens for static assigned IP addresses of clients in the fabric which is the reason it’s not needed really.