EVPN Type 2 and Type 5 Route Coexistence Implementation

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

• Type 2 and Type 5 Route Coexistence Preference Algorithm

• Limitations with Type 2 and Type 5 Route Coexistence Feature

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

• Routing Over an IRB Interface for BGP with EBGP

• Routing Over an IRB Interface with IS-IS or OSPF

• DHCP Relay Recommendation with Type 2 and Type 5 Route Coexistence

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:

• Step 6 in Configure Type 2 and Type 5 Routes to Coexist.

• EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN in the EVPN User Guide

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

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

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.
   user@Leaf-10> show arp no-resolve interface irb.500
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.

   user@Leaf-10> show ethernet-switching mac-ip-table instance MAC-VRF-1 vlan-name VNI_50000 ba:42:5f:01:e2:01
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.

   user@Leaf-10> show route forwarding-table destination 10.1.4.102 vpn VRF_3 extensive
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.
   user@Leaf-10> show route 10.1.4.102 table VRF_3.inet.0 extensive

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.