Three-segment VXLAN tunnels can be configured to enable communication between VMs that belong to the same subnet but different DCs.
On the network shown in Figure 1, VXLAN tunnels are configured both within DC A and DC B and between transit leaf nodes in both DCs. To enable communication between VM 1 and VM 2, implement Layer 2 communication between DC A and DC B. If the VXLAN tunnels within DC A and DC B use the same VXLAN Network Identifier (VNI), this VNI can also be used to establish a VXLAN tunnel between Transit Leaf 1 and Transit Leaf 2. In practice, however, different DCs have their own VNI spaces, and therefore the VXLAN tunnels within DC A and DC B mostly likely use different VNIs. To configure a VXLAN tunnel between Transit Leaf 1 and Transit Leaf 2 in such cases, perform a VNI conversion.
Such as shown in Figure 1, the VXLAN tunnel in DC A uses the VNI 10, and that in DC B uses the VNI 20. Transit Leaf 2's VNI (20) must be configured as the outbound VNI on Transit Leaf 1, and Transit Leaf 1's VNI (10) as the outbound VNI on Transit Leaf 2. After the configuration is complete, Layer 2 packets can be forwarded properly. Take DC A sending packets to DC B as an example. After receiving VXLAN packets within DC A, Transit Leaf 1 decapsulates the packets and then uses the outbound VNI 20 to re-encapsulate the packets before sending them to Transit Leaf 2. Upon receipt, Transit Leaf 2 forwards them as normal VXLAN packets.
Layer 2 communication between VMs in different DCs is implemented here, therefore avoiding the need to configure a Layer 3 gateway.
If DC A and DC B belong to the same AS, configure an RR on the edge device. If DC A and DC B do not belong to the same AS, establish an EBGP EVPN peer relationship between edge devices.
Run bgp as-number
The BGP view is displayed.
Run l2vpn-family evpn
The BGP-EVPN address family view is displayed.
Run peer { group-name | ipv4-address } split-group split-group-name
A split horizon group (SHG) to which BGP EVPN peers (or peer groups) belong is configured.
In Layer 2 interworking scenarios, to prevent forwarding BUM traffic from causing a loop, an SHG must be configured. Separately specify the name of the SHG between Transit Leaf 1 and Transit Leaf 2 on each, so that devices within DC A and DC B belong to the default SHG and Transit Leaf 1 and Transit Leaf 2 belong to the specified SHG. In this manner, when a transit leaf node receives BUM traffic, it does not forward traffic to a device belonging to the same SHG, therefore preventing loops.
Run peer { ipv4-address | group-name } import reoriginate
The function to re-originate routes received from BGP EVPN peers is enabled.
Enable on transit leaf nodes the function to re-originate routes received from BGP EVPN peers within DCs and between the DCs (between transit leaf nodes).
Run peer { ipv4-address | group-name } advertise route-reoriginated evpn mac
The function to advertise re-originated EVPN routes to BGP EVPN peers is enabled.
In Layer 2 interworking scenarios, configure the function to advertise only re-originated MAC routes to BGP EVPN peers. Enable on transit leaf nodes the function to advertise re-originated MAC routes to BGP EVPN peers within DCs and between the DCs (between transit leaf nodes).
Run commit
The configuration is committed.