Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

EVPN Type 2 and Type 5 Route Coexistence Implementation

By default, EVPN-VXLAN devices import and advertise EVPN Type 2 routes (MAC with IP advertisement routes) for ESI MAC address control plane learning. You can also enable the devices to import and advertise EVPN Type 5 routes (IP prefix routes) in a virtual routing and forwarding (VRF) instance using the ip-prefix-routes statement at the [edit routing-instances name protocols evpn] hierarchy level. With Type 5 routes enabled, the device will learn how to reach an IP host address from both a Type 2 route (the IP portion) and from a Type 5 route for the same prefix.

When the device learns either type of route for the same destination, it stores both as separate routes, so Type 2 and Type 5 routes might coexist for a VRF. You can configure the VRF with different import and export VRF route targets to prevent importing local Type 5 routes back into the device (essentially preventing coexistence entirely).

However, in some cases, you might want to accept coexisting routes for local or remote destinations. You can also apply routing policies to prevent the device from importing Type 2 or Type 5 host routes for particular prefixes or destinations.

Type 2 and Type 5 Route Coexistence in a Virtual Routing and Forwarding Instance

In a large data center with an edge-routed bridging (ERB) overlay fabric, Type 2 and Type 5 route coexistence can strain the device’s Packet Forwarding Engine (PFE) next-hop resources. Also, the device performs better in certain cases if it can prefer one type of route over the other. As a result, we provide a Type 2 and Type 5 route coexistence preference feature on supported platforms and releases. With this feature, when the device accepts coexisting Type 2 and Type 5 routes, the device applies a route preference algorithm by default. According to the preference algorithm, the device assigns only one type of route for the same destination prefix as the active route.

See EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN in the EVPN User Guide for more on this feature and the default preference algorithm.

Type 2 and Type 5 Route Coexistence Preference Algorithm

When you configure the device to accept coexisting Type 2 and Type 5 routes for a VRF, the device applies the following preference algorithm on imported routes:

  • If the device learns a Type 2 route for a destination and doesn’t have a matching prefix Type 5 route, it installs the Type 2 route.

  • If the device learns a Type 5 route for a local ESI Type 2 route (a local host route) for the same prefix, it installs the Type 2 route.

  • If the device learns a Type 5 route and has a matching Type 2 entry for a non-local interface, it installs the Type 5 route instead (and it deletes the Type 2 entry).

Essentially, if Type 2 and Type 5 routes coexist for the same prefix, the algorithm prefers Type 2 routes for local interfaces and prefers Type 5 routes for all other destinations. The device deletes non-local destination Type 2 route entries from the PFE when it installs a Type 5 route for the same prefix, saving next-hop table space in the PFE.

Limitations with Type 2 and Type 5 Route Coexistence Feature

The following sections describe some routing behavior limitations or constraints in a routing instance with the Type 2 and Type 5 route coexistence feature.

Routing Over an IRB Interface for BGP with EBGP

EBGP protocol is designed to establish peering between directly-connected interface addresses, so the EBGP message default time-to-live (TTL) is 1 (which corresponds to one next hop). In EBGP configurations with Type 2 and Type 5 route coexistence, the device prefers Type 5 routes for remote destination hosts. When the device routes a packet over an IRB interface for a Type 5 route tunnel, the routing might require more hops than traffic bridged or routed locally using Type 2 routes.

To ensure successful routing over IRB interfaces in EBGP configurations with Type 2 and Type 5 route coexistence, you must set the multihop option with a TTL value of 2 or more in the EBGP peer group configuration, as follows:

Routing Over an IRB Interface with IS-IS or OSPF

To ensure successful routing over IRB interfaces for destination hosts where the device resolves those routes using IS-IS or OSPF, you can’t allow Type 2 and Type 5 routes to coexist. ISIS and OSPF are link state protocols that expect peers to be directly connected. The device should not route IS-IS or OSPF control packets and should use Type 2 routes. When Type 2 and Type 5 routes coexist, the device must prefer the Type 2 route. As a result, in this case, define and apply a routing policy to avoid importing Type 5 routes for those host routes.

See the sample policies in:

These policies filter and don’t import routes for specific host addresses or prefixes.

DHCP Relay Recommendation with Type 2 and Type 5 Route Coexistence

In a VRF instance with DHCP relay enabled and Type 2 and Type 5 routes coexist, you should disable snooping in the DHCP relay configuration, as follows:

Configure Type 2 and Type 5 Routes to Coexist

To configure a VRF to have coexisting Type 2 and Type 5 routes, enable Type 5 routing (IP prefix routes) and ensure the device uses the same import and export VRF route targets in the routing instance. You also apply a routing policy in the instance for the host routes that you want the device to import or advertise. See EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN for more on policy options you might want to configure with this feature.

The following example configuration enables Type 2 and Type 5 route coexistence on a leaf device in the ERB overlay fabric introduced in Edge-Routed Bridging Overlay Design and Implementation. You can use the same general configuration from that ERB reference design example. The configuration here corresponds to the Type 5 route configuration on Leaf 10 in VRF_3. Refer to the steps there where we set the host routes export routing policy and enable Type 5 routes in routing instance VRF_3.

  1. Configure a policy called EXPORT_HOST_ROUTES to match on and accept /32 and /128 host routes (these correspond to all host routes). Include direct routes and static routes in the policy too.
  2. Configure a tenant VRF routing instance VRF_3 for VNI_50000. (In the configuration in Edge-Routed Bridging Overlay Design and Implementation, you can apply a similar step for VNI_60000 and irb.600 in VRF_3, and VNI_70000 and VNI_80000 in VRF_4.)
  3. Enable Type 5 routes (IP prefix routes ) in VRF_3. Apply the EXPORT_HOST_ROUTES routing policy from step 1. Make sure that Type 2 and Type 5 routes coexist by setting the import and export route targets to the same value. Supported devices apply the coexistence route preference algorithm when importing and installing routes.
    Note:

    You can configure the vrf-target route-target-value statement at the [edit routing-instances name] hierarchy without specifying separate import and export target options. In that case, if you’ve enabled Type 5 routes in the instance, the configuration applies the same route target value for import or export (advertisement) actions, which enables Type 2 and Type 5 route coexistence. Here we explicitly set the same route target using import and export options to show clearly that Type 2 and Type 5 routes coexist.

  4. (Required on ACX7100 routers only) Set the reject-asymmetric-vni option in the VRF routing instances where you enable Type 5 IP prefix routes. This option configures the device to reject EVPN Type 5 route advertisements with asymmetric VNIs—the device doesn’t accept traffic from the control plane with a received VNI that doesn’t match the locally configured VNI. We support only symmetric VNI routes on these devices.
  5. (For a VRF instance that learns host IP addresses using EBGP) To support routing over IRB interfaces with Type 2 and Type 5 coexistence for hosts that use EBGP, you must set the multihop option with a TTL value of 2 or more in the EBGP peer group configuration. (See Routing Over an IRB Interface for BGP with EBGP for more on this use case.)

    For example:

  6. (For a VRF instance that learns host IP addresses using IS-IS or OSPF) To support routing over IRB interfaces for hosts that use IS-IS or OSPF, ensure the instance always prefers Type 2 routes for those hosts. In other words, prevent Type 2 and Type 5 route coexistence for only those host IP addresses. (See Routing Over an IRB Interface with IS-IS or OSPF for more on this limitation.)

    To do this, define and apply a routing policy in the VRF instance that avoids importing Type 5 routes for those host IP addresses. For example, in the configuration for VRF_3, to filter out Type 5 routes for a host with IP address 10.1.4.106:

Verify Type 2 and Type 5 Route Coexistence

To verify the coexistence preference algorithm stores only the preferred routes with Type 2 and Type 5 route coexistence, use the following commands.

These sample commands use the ERB overlay fabric configured in Edge-Routed Bridging Overlay Design and Implementation on Leaf 10 with:

  • MAC-VRF instance: MAC-VRF-1

  • Tenant VRF: VRF_3

  • A local host with IP address 10.1.4.101

  • A remote host with IP address 10.1.4.102

These commands check routes to a remote host with IP address 10.1.4.102 on an Ethernet segment on another leaf device in the fabric. Leaf 10 has a host with IP address 10.1.4.101.

  1. Enter the show arp no-resolve command to check that the remote host with IP address 10.1.4.102 doesn’t appear in the ARP table. The device is saving next hop space in the PFE by avoiding installing both Type 2 and Type 5 routes for the same remote destination.
  2. Enter the show ethernet-switching mac-ip-table command to see routes for the remote host. When Type 2 and Type 5 routes coexist, the RTS flag in the Flags output field means the device skipped adding a Type 2 route in favor of a Type 5 route with a matching prefix.

    Here, the output includes the RTS flag for the remote host with IP address 10.1.4.102, so the Type 5 route is the preferred route.

  3. Enter the show route forwarding-table ... extensive command to see Type 5 route forwarding entries for the tenant VRF instance VRF_3.

    The Flags field includes the VxLAN Local flag when the route is a Type 5 local route that the device preferred over a learned Type 2 route for the same destination.

  4. Enter the show route ... extensive command to check that the (preferred) Type 5 route for the remote host is in the routing table. The State field in the output with the extensive option includes VxlanLocalRT for Type 5 routes. This is similar to the forwarding table output in the previous step where the VXLAN Local flag indicate the device preferred and stored the Type 5 local route instead of the Type 2 route.

EVPN Type 2 and Type 5 Route Coexistence Preference Feature — Release History

Table 1 provides a history of the feature in this section and its support within this reference design.

Table 1: EVPN Type 2 and Type 5 Route Coexistence Implementation– Release History

Release

Description

21.4R2

MX Series, QFX5110, QFX5120, and QFX10000 Series devices running Junos OS Release 21.4R2 and later releases in ERB overlay reference architectures.

21.4R2-EVO

ACX7100-48L, PTX10001, PTX10004, PTX10008, PTX10016, and QFX5130-32CD devices running Junos OS Evolved Release 21.4R2 and later releases in ERB overlay reference architectures.