Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN Type 5 Route with VXLAN Encapsulation for EVPN-VXLAN

EVPN is a flexible solution that uses Layer 2 (L2) overlays to interconnect multiple edges (virtual machines) within a data center. Traditionally, the data center is built as a flat L2 network with issues such as flooding, limitations in redundancy and provisioning, and high volumes of MAC addresses learned, which cause churn at node failures. EVPN is designed to address these issues without disturbing flat MAC connectivity.

Virtual extensible local area network (VXLAN) overlay technology encapsulates MAC frames into a UDP header at L2. Communication is established between two virtual tunnel endpoints (VTEPs). VTEPs encapsulate the virtual machine traffic into a VXLAN header, as well as strip off the encapsulation. Virtual machines can only communicate with each other when they belong to the same VXLAN segment. A 24-bit virtual network identifier (VNID) uniquely identifies the VXLAN segment. This enables having the same MAC frames across multiple VXLAN segments without traffic crossover. Multicast in VXLAN is implemented as Layer 3 (L3) multicast, in which endpoints subscribe to groups.

When a bridge domain (BD) is not L2 extended across data centers (DCs), the IP subnet belonging to the BD is confined within a single DC. If all BDs within each DC network satisfy this requirement, there is no longer a need to advertise MAC+IP routes for each tenant between data centers, because host routes for the tenants can be aggregated. As a result, the L2 inter-DC connectivity issue can be simply transformed to an inter-DC L3 IP prefix reachability issue.

Starting with Junos OS Release 17.1, the EVPN Type 5 IP prefix route advertises the IP prefixes between the DCs. Unlike the Type-2 EVPN MAC advertisement route, the EVPN Type 5 IP prefix route separates the host MAC address from its IP address and cleanly advertises an IP prefix for the BD.

We also support:

  • Inter-DC connectivity with VXLAN encapsulation for EVPN-VXLAN using the EVPN Type 5 IP prefix route.

    Each BD within a DC is not L2 extended. If EVPN-VXLAN is enabled between the DC GW (Data Center Gateway) routers and top-of-rack devices (ToRs) while providing inter-DC connectivity, the spine, which acts as a DC GW router, performs L3 routing and IRB functions.

  • Inter-pod connectivity with VXLAN encapsulation by using the EVPN Type 5 IP prefix route.

    The IP prefix route VXLAN inter-pod connectivity does not address the L2 extension problem when a BD is stretched across different pods. The spines that provide the inter-pod connectivity perform L3 routing and integrated routing and bridging (IRB) functions.

Blocking Asymmetric EVPN Type 5 Routes

While Juniper devices support asymmetric routes in EVPN Type 5 routes, processing asymmetric EVPN Type 5 routes consume Packet Forwarding Engine (PFE) resources. In some cases, you may want to conserve PFE resources and block asymmetric EVPN Type 5 routes. When you block asymmetric EVPN Type 5 routes, the local device examines the incoming EVPN Type 5 route and rejects the route when the VNI in the ingress route differs from the locally configured VNI. The device still installs the route in the bgp.evpn.0 table, but rejects the routes (doesn't install them) in the routing-instance-name.inet.0 table.

To block asymmetric EVPN Type 5 routes in a virtual routing and forwarding (VRF) instance where EVPN Type 5 routes are enabled, include following statement:

Note:

ACX7100 routers running Junos OS Evolved Release 24.4R1 and earlier do not support asymmetric EVPN Type 5 routes. When you configure EVPN Type 5 routes on an ACX7100 router running Junos OS Evolved Release 24.4R1 and earlier, you must also configure the reject-asymmetric-vni option at the [edit routing-instances routing-instance-name protocols evpn ip-prefix-routes] hierarchy level in the same routing instance.

Related Documentation