No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - IP Service

CloudEngine 8800, 7800, 6800, and 5800 V200R002C50

This document describes the configurations of IP Service, including IP address, ARP, DHCP, DNS, IP performance optimization, IPv6, DHCPv6, and IPv6 DNS.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
VXLAN Support for DHCPv4 Relay

VXLAN Support for DHCPv4 Relay

VXLAN support for DHCPv4 relay allows tenants to dynamically obtain IP addresses using DHCP. This section uses the distributed gateway as an example to describe the forwarding principles of DHCPv4 relay based on whether the DHCPv4 server and client belong to the same VPN.

DHCPv4 Client and Server on the Same VPN

On the network shown in Figure 3-9, the requirements are as follows:
  • Distributed Layer 3 VXLAN gateways are deployed on leaf1, leaf2, and leaf3, between which are connected over a Layer 3 VXLAN tunnel.
  • VM1 and VM3 belong to the subnet with VNI 10. VM2 and VM4 belong to the subnet with VNI 20.
  • The DHCP server connected to leaf3 belongs to the same VPN but different subnet as VM1, VM2, VM3, and VM4.
After DHCP relay is deployed on leaf1 and leaf2, VM1, VM2, VM3, and VM4 can all function as DHCP clients to dynamically request for IP addresses from the DHCP server.
Figure 3-9  VXLAN support for DHCPv4 relay in intra-VPN scenarios

DHCP relay is deployed on the BDIF interfaces of leaf nodes. In distributed scenarios, the gateway address is the same for all the leaf nodes in the same subnet. On the network shown in Figure 3-9, the gateway address for all the users on the subnet with VNI 10 where leaf1 and leaf2 reside is 10.1.1.1.

Generally, VM1 sends an address request to the DHCP server through leaf1. The DHCP server sends a response message to leaf1. There is a possibility that the response message is sent to leaf2. In this case, VM1 can still request for an IP address. The detailed forwarding procedure is as follows:
  • step1: VM1 broadcasts a Discover packet to request for DHCP server discovery.

  • step2: Upon receipt of the broadcast Discover packet, leaf1 converts it to a unicast Discover packet with the destination IP address as the DHCP server's IP address. Leaf1 encapsulates a VXLAN header in the unicast Discover packet and forwards it over a VXLAN tunnel.

  • step3: Leaf3 decapsulates the received packet and forwards the packet to the DHCP server based on the destination IP address.

  • step4: Upon receipt of the unicast Discover packet, the DHCP server assigns an IP address from the local address pool. The DHCP server replies with a unicast Offer packet in which the destination IP address is the GiAddr address of the unicast Discover packet.

  • step5: Upon receipt of the Offer packet, leaf3 searches the routing table based on the destination IP address (10.1.1.1, GiAddr address) and forwards the Offer packet to the next hop.

  • step6: Upon receipt of the Offer packet, leaf2 converts it to a broadcast Offer packet and broadcasts it to all the hosts within the broadcast domain.

    NOTE:

    This step can be ignored if the response packet sent by the DHCP server is sent to leaf1.

  • step7: Upon receipt of the Offer packet, leaf1 broadcasts it to all the hosts within the broadcast domain. VM1 receives the Offer packet.

DHCP client renewal in the intra-VPN scenario does not require processing of the DHCP relay. The following uses client renewal on VM1 as an example.
  • Before the lease expires, VM1 unicasts a Request packet for renewal, with the source IP address as the DHCP client's IP address and the destination IP address as the DHCP server's IP address.
  • Upon receipt of the Request packet, leaf1 does not send it to the DHCP relay. Instead, leaf1 searches the routing table and forwards the Request packet to the DHCP server over a Layer 3 VXLAN tunnel.
  • The DHCP server generates an ACK packet whose destination IP address is the DHCP client's IP address, searches for the routing table, and forwards the ACK packet to the DHCP server over a Layer 3 VXLAN tunnel.

DHCP Client and Server on Different VPNs

Figure 3-10 shows an inter-VPN scenario where VM1, VM2, VM3, and VM4 are in VPN10 while the DHCP server is in VPN20.

Figure 3-10  VXLAN support for DHCPv4 relay in inter-VPN Scenarios

The forwarding procedure in the inter-VPN scenario is similar to that in the intra-VPN scenario except for the following differences:
  • step2: The DHCP client and server that are in different VPNs must be reachable. Only in this way can leaf1 learn host routes from the DHCP server when leaf1 forwards a unicast Discover packet to the DHCP server.

  • step5: Leaf3 cannot identify the destination VPN by searching the routing table based on the GiAddr address. This is because response packets do not carry VPN information. In response, the network segments in different VPNs cannot overlap. For example, the GiAddr address of the DHCP relay in VPN30 cannot overlap with the GiAddr address (10.1.1.1) in VPN10.

To allow overlapping between network segments in different VPNs, insert suboption 151 and suboption 5 of Option 82. Table 3-6 describes the key fields in a DHCP relay packet.
Table 3-6  Description of key fields in a DHCP relay packet

Field

Description

Processing of the DHCP Relay

Processing of the DHCP Server

giaddr

This field uniquely identifies a DHCP relay and indicates the destination IP address of the DHCP server.

NOTE:
The GiAddr was originally designed to be a DHCP client's gateway address which is used as a reference for the DHCP server to allocate IP addresses. Because the GiAddr address can also be identified by the DHCP server as the destination IP address in a DHCP reply, the GiAddr address is altered to uniquely identify a DHCP relay and indicate the destination IP address of the DHCP server. As an alternative, suboption 5 of Option 82 is used to indicate a DHCP client's gateway address.

The DHCP relay specifies the GiAddr address as the VTEP IP address of leaf1 (1.1.1.1).

The DHCP server specifies the destination IP address as 1.1.1.1 in a DHCP reply.

Suboption 5 of Option 82

This field indicates the gateway address of a DHCP client.

The DHCP relay inserts suboption 5 into the DHCP relay packet with the value of 10.1.1.1.

During address assignment, the DHCP server searches for desired address pools based on suboption 5 and option 151.

Suboption 151 of Option 82

This field indicates VPN information of a DHCP client.

The DHCP relay inserts suboption 151 into the DHCP relay packet with the value of VPN10.

DHCP client renewal in the inter-VPN scenario requires processing of the DHCP relay. In intra-VPN scenarios, the DHCP relay does not need to participate in DHCP client renewal, and Layer 3 VXLAN gateways forward unicast packets via routing table lookup. In inter-VPN scenarios, due to a lack of VPN information, leaf1 cannot find the next hop IP address based on the destination IP address (DHCP server's IP address) of renewal packets. This is why DHCP relay is required.

Figure 3-11  Renewal procedure in inter-VPN scenarios

The blue numbers in Figure 3-11 are described as follows:
  1. When a DHCP client requests for an IP address for the first time, the DHCP server inserts the Option 54 field that contains the DHCP server's IP address into a DHCP reply.
  2. Upon receipt of the DHCP reply, the DHCP client uses the IP address contained in the Option 54 field as the destination IP address for sending the subsequent renewal packets.
  3. In case of a DHCP client renewal, the DHCP client and DHCP server exchange unicast packets.
The yellow numbers are described as follows:
  1. The DHCP relay inserts suboption 11 of Option 82, which indicates the DHCP relay's IP address, into the Discover packet.
  2. Before sending a DHCP reply, the DHCP server encapsulates the content of suboption 11 of Option 82 into Option 54. In this way, the DHCP client takes the DHCP relay's IP address as the destination IP address of renewal packets upon receipt of a DHCP reply.
  3. In case of a DHCP client renewal, renewal packets are sent to the DHCP relay for inter-VPN forwarding.
Translation
Download
Updated: 2019-03-21

Document ID: EDOC1000166635

Views: 131363

Downloads: 285

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next