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 - VXLAN

CloudEngine 12800 and 12800E V200R003C00

This document describes the configurations of VXLAN.
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).
Configuring Inter-AS Segment VXLAN to Implement Layer 3 Interworking

Configuring Inter-AS Segment VXLAN to Implement Layer 3 Interworking

Inter-AS segment VXLAN tunnels can be configured to enable communications between inter-subnet VMs in DCs that belong to different ASs.

Context

As shown in Figure 10-3, DC A and DC B belong to different ASs. BGP EVPN must be configured to create VXLAN tunnels between distributed gateways in each DC and to create VXLAN tunnels between leaf nodes so that the inter-subnet VMs in DC A and DC B can communicate with each other.

Figure 10-3 Configuring an inter-AS segment VXLAN tunnel

Procedure

  1. Configure BGP EVPN within DC A and DC B to establish VXLAN tunnels. For details, see Configuring a VXLAN Tunnel in Distributed Gateway Mode (BGP EVPN).
  2. Configure BGP EVPN on Leaf 2 and Leaf 3 to establish a VXLAN tunnel between them. For details, see Configuring a VXLAN Tunnel in Distributed Gateway Mode (BGP EVPN).

    NOTE:

    BD configurations do not affect the creation of a VXLAN tunnel between Leaf 2 and Leaf 3 in a distributed gateway (BGP EVPN) scenario. However, in this scenario, VMs attached to Leaf 2 or Leaf 3 cannot access the network through Layer 2 sub-interfaces associated with a BD.

  3. Configure Leaf 2 and Leaf 3 to advertise routes that are re-originated by the EVPN address family to BGP EVPN peers.
    1. Run bgp as-number [ instance instance-name ]

      The BGP view or BGP multi-instance view is displayed.

    2. Run l2vpn-family evpn

      The BGP-EVPN address family view or BGP multi-instance EVPN address family view is displayed.

    3. Run peer { ipv4-address | group-name } import reoriginate

      The function to re-originate routes received from BGP EVPN peers is enabled.

    4. Run peer { ipv4-address | group-name } advertise route-reoriginated evpn { mac | mac-ip | ip }

      The function to advertise re-originated EVPN routes to BGP EVPN peers is enabled.

      After route re-origination is enabled, Leaf 2 or Leaf 3 changes the next hop of a received EVPN route to itself, replaces the router MAC address in the gateway MAC address attribute with its own router MAC address, and replaces the Layer 3 VNI with the VPN instance Layer 3 VNI.

  4. (Optional) Disable Leaf 2 and Leaf 3 from re-originating IRB routes when no BD is configured. By default, when no BD is configured, Leaf 2 and Leaf 3 can re-originate IRB routes for inter-DC VXLAN tunnel creation. To prevent IRB routes from being re-originated again after a BD is configured for Leaf 2 and Leaf 3, perform this step.
    1. Run quit

      The BGP view or BGP multi-instance view is displayed.

    2. Run quit

      The system view is displayed.

    3. Run evpn

      The global EVPN view is created and displayed.

      By default, the global EVPN view is not displayed.

    4. Run irb-reoriginated without-bridge-domain disable

      The function to re-originate IRB routes when no BD is configured is disabled.

      By default, the function to re-originate IRB routes when no BD is configured is enabled.

  5. (Optional) Run irb-reoriginated without-split-group disable

    Disable on Leaf 2 and Leaf 3 the function to advertise re-originated IRB routes without being restricted by a split horizon group (SHG).

    By default, re-originated IRB routes are advertised without being restricted by an SHG.

    In scenarios where segment VXLAN tunnels are used to implement DC interconnections, to prevent forwarding BUM traffic from causing a loop during Layer 2 interconnection, BGP EVPN peer-based SHG is introduced. If no BGP EVPN peer-based SHGs are specified on transit leaf nodes (edge devices interconnecting DCs), all BGP EVPN peers belong to the default system SHG. In this case, after a transit leaf node re-originates IRB routes received from an intra-DC device, the transit leaf node cannot advertise the re-originated IRB routes to the peer DC's transit leaf node because the transit leaf nodes both belong to the default system SHG. As a result, Layer 3 traffic forwarding is affected.

    To prevent this problem, a device advertises re-originated IRB routes without being restricted by an SHG by default. If SHGs are specified for all BGP EVPN peers on transit leaf nodes, to disable the function to advertise re-originated IRB routes without being restricted by an SHG, perform this step.

  6. Run commit

    The configuration is committed.

Translation
Download
Updated: 2019-05-05

Document ID: EDOC1100004207

Views: 30830

Downloads: 66

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