Static VXLAN

Benefits of Static VXLAN

• Instead of using an Ethernet VPN (EVPN) control plane to learn the MAC addresses of hosts, static VXLAN uses a flooding-and-learning technique in the VXLAN data plane. Therefore, using static VXLAN reduces complexity in the control plane.

• For a small MC-LAG network, EVPN might be overly complex to configure and maintain. Static VXLAN provides the benefits of VXLAN and is relatively easy to design and configure.

How Static VXLAN Works

To enable static VXLAN on a Juniper Networks device that functions as a VTEP, you must configure:

• A list that includes one or more remote VTEPs with which the local VTEP can form a VXLAN tunnel.

• Ingress node replication.

• The VTEP’s loopback interface (lo0):

  • Configure an anycast IP address as the primary interface.

  • Specify this interface as the source interface for a VXLAN tunnel.

When a VTEP receives a BUM packet, the VTEP uses ingress node replication to replicate and flood the packet to the statically defined remote VTEPs on your list. The remote VTEPs in turn flood the packet to the hosts in each VXLAN of which the VTEPs are aware.

The VTEPs learn the MAC addresses of:

• Remote hosts from the VTEPs on the remote VTEP list.

• Local hosts from the local access interfaces

Upon learning a MAC address of a host, the device adds the MAC address to the Ethernet switching table.

You can view information about remote static VXLAN VTEP interfaces using the following CLI show commands:

• show ethernet-switching vxlan-tunnel-end-point-remote—Shows the remote VTEPs on the device, including their IP addresses and VTEP interface names . See the RVTEP-IP and Interface output fields.

• show interfaces vtep-interface-name—Displays status of a VTEP interface. The VTEP interfaces you configure as static VXLAN VTEPs display the value Configured-remote in the VXLAN Endpoint type output field of this command.

For example, with static VXLAN remote VTEPs configured for VLANs 200 and 300 in an L2 routing instance named ri1:

user@leaf-1> show ethernet-switching vxlan-tunnel-end-point remote 
Logical System Name       Id  SVTEP-IP         IFL   L3-Idx    SVTEP-Mode    ELP-SVTEP-IP 
<default>                 0   192.168.1.1      lo0.0    0 
RVTEP-IP      IFL-Idx     Interface    NH-Id   RVTEP-Mode  ELP-IP        Flags 
192.168.2.1     19307     vtep.32771   53035   RNVE 
RVTEP-IP       L2-RTT                  IFL-Idx   Interface     NH-Id  RVTEP-Mode  ELP-IP        Flags 
192.168.2.1    ri1                     671522819 vtep-53.32771 53035  RNVE 
    VNID          MC-Group-IP 
    200           0.0.0.0 
    300           0.0.0.0 
  
user@leaf-1> show interfaces vtep.32771 
  Logical interface vtep.32771 (Index 20108) (SNMP ifIndex 537) 
    Flags: Up Encapsulation: Unspecified 
    VXLAN Endpoint Type: Configured-remote, VXLAN Endpoint Address: 192.168.2.1, L3 Routing Instance: default 
    Input packets : 0 
    Output packets: 0 
    Protocol ethernet-switching, MTU: Unlimited 
      Flags: None 
  

Small MC-LAG Network Static VXLAN Use Case

Here we show a static VXLAN at the global level in a small network that uses MC-LAGs.

Figure 1: Sample MC-LAG Network with Static VXLAN

In the MC-LAG network in Figure 1:

• The bottom layer includes hosts (Host 1 through Host 4), each of which is multihomed to leaf devices and is a member of a VXLAN.

• The middle layer includes leaf devices (Leaf 1 through Leaf 4), each of which functions as an L2 VXLAN gateway. In addition, Leaf 1 and Leaf 2 form an MC-LAG and together, both leaf devices function as VTEP 1. Leaf 3 and Leaf 4 form another MC-LAG and function as VTEP 2.

• The top layer includes spine devices (Spine 1 and Spine 2), which form an MC-LAG. These devices function as IP routers.

Note the following about the configuration of Leaf 1 through Leaf 4 on which static VXLAN is configured:

• Instead of EVPN-VXLAN, here we enable static VXLAN.

• Each leaf device is an MC-LAG member and functions along with its MC-LAG peer as a VTEP. That is, two physical leaf devices make up each virtual VTEP. This situation impacts the configuration in the following ways:

  • On each leaf device that forms a VTEP, you must configure the same loopback address.

  • On each leaf device that forms a VTEP, you must configure the same remote VTEP list.

  For a sample configuration of this use case, see Configure Static VXLAN at the Global Level.

• Instead of an IP multicast feature, we enable ingress node replication.

VLAN or Bridge Domain Level Static VXLAN Use Case

On some platforms, you can set up an L2 VXLAN gateway without EVPN at the VLAN or bridge domain level, In this case, you statically configure a list of one or more remote VTEPs at the global level, and map the list to a particular VLAN or bridge domain.

First, statically configure a global list of remote VTEPs using the remote-vtep-list [...] statement. Then map the same list of remote VTEPs at the VLAN or bridge domain level using the static-remote-vtep-list [...] statement. Each VLAN must also have a VXLAN network identifier (VNI) mapping.

We support configuring static VXLAN at the global level, VLAN level, and bridge domain level as follows:

When you specify the remote VTEPs at the VLAN or bridge domain level:

• In the default switch instance:

  You must also specify the same VTEPs at the global level in the default switch instance at the [edit switch-options] hierarchy level.

• In a virtual-switch routing instance:

  You must also specify the same VTEPs at the global level in the same routing instance at the [edit routing-instances name] hierarchy level.

To replicate and flood BUM traffic over static VXLAN tunnels at the VLAN or bridge domain level for VXLANs, you must also configure ingress node replication mode (ingress-node-replication option) at that level. This mode restricts the BUM traffic flood domain to only those VTEPs mapped to the particular VLAN or bridge domain.

For a sample configuration of this use case, see Configure Static VXLAN at the VLAN or Bridge Domain Level on L2 VXLAN Gateway Devices.