close

keyboard_arrow_left

Table of Contents Expand all

list Table of Contents

English

EVPN Type 2 and Type 5 Route Coexistence Implementation

date_range 11-Feb-25

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

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

content_copy zoom_out_map
set routing-instances VRF-instance protocols bgp group BGP-peer-group-name multihop ttl 2

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:

content_copy zoom_out_map
set routing-instances VRF-instance forwarding-options dhcp-relay no-snoop

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.

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.

content_copy zoom_out_map
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_1 from protocol evpn
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_1 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_1 then accept
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_2 from protocol direct
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_2 then accept
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_3 from protocol static 
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_3 then accept
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_4 from family inet6
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_4 from protocol evpn
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_4 from route-filter 0::0/0 prefix-length-range /128-/128
set policy-options policy-statement EXPORT_HOST_ROUTES term TERM_4 then accept

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.)

content_copy zoom_out_map
set routing-instances VRF_3 instance-type vrf
set routing-instances VRF_3 interface irb.500
set routing-instances VRF_3 interface lo0.3
set routing-instances VRF_3 route-distinguisher 192.168.1.10:500
set routing-instances VRF-3 routing-options multipath
set routing-instances VRF-3 routing-options rib VRF-3.inet6.0 multipath

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.
```
set routing-instances VRF_3 protocols evpn ip-prefix-routes advertise direct-nexthop
set routing-instances VRF_3 protocols evpn ip-prefix-routes encapsulation vxlan
set routing-instances VRF_3 protocols evpn ip-prefix-routes export EXPORT_HOST_ROUTES
set routing-instances VRF_3 vrf-target import target:62273:50000
set routing-instances VRF_3 vrf-target export target:62273:50000
```
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.
(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.
```
set routing-instances VRF_3 protocols evpn ip-prefix-routes reject-asymmetric-vni
```
(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:
```
set routing-instances VRF_3 protocols bgp group EBGP-peer-group-name multihop ttl 2
```
(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:
```
set policy-options policy-statement RejectType5HostRoutes term 1 from route-filter 10.1.4.106/32 exact
set policy-options policy-statement RejectType5HostRoutes term 1 then reject
set policy-options policy-statement RejectType5HostRoutes term 2 then accept
set routing-instances VRF_3 protocols evpn ip-prefix-routes import RejectType5HostRoutes
```

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.

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.

content_copy zoom_out_map
user@Leaf-10> show arp no-resolve interface irb.500

MAC Address       Address         Interface                Flags
ba:41:5f:01:e2:01 10.1.4.101      irb.500[ ae3.0 ]         permanent remote
fc:96:43:eb:63:33 10.1.4.2        irb.500[ .local..1408 ]  permanent remote
00:31:46:7b:e1:18 10.1.4.3        irb.500[ .local..1408 ]  permanent remote
ec:3e:f7:89:15:1a 10.1.4.4        irb.500[ .local..1408 ]  permanent remote

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.

content_copy zoom_out_map
user@Leaf-10> show ethernet-switching mac-ip-table instance MAC-VRF-1 vlan-name VNI_50000 ba:42:5f:01:e2:01

MAC IP flags  (S - Static, D - Dynamic, L - Local , R - Remote, Lp - Local Proxy,
               Rp - Remote Proxy, K - Kernel, RT - Dest Route, (N)AD - (Not) Advt to remote,
               RE - Re-ARP/ND, RO - Router, OV - Override, Ur - Unresolved,
               RTS - Dest Route Skipped, RGw - Remote Gateway, FU - Fast Update)
 Routing instance : MAC-VRF-1
 Bridging domain : VNI_50000
   IP                           MAC                  Flags             Logical            Active
   address                      address                                Interface          source
   10.1.4.102                   ba:42:5f:01:e2:01    DR,K,RTS          esi.234220         00:00:00:ff:00:02:00:01:00:03
   2001:db8::10:1:4:102         ba:42:5f:01:e2:01    DR,K,RTS          esi.234220         00:00:00:ff:00:02:00:01:00:03

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.

content_copy zoom_out_map
user@Leaf-10> show route forwarding-table destination 10.1.4.102 vpn VRF_3 extensive

Routing table: VRF_3.inet [Index: 1597]
Internet:

Destination:  10.1.4.102/32
  Route type: user
  Route reference: 0                   Route interface-index: 0
  Multicast RPF nh index: 0
  P2mpidx: 0
  Flags: rt nh decoupled, VxLAN Local
  Next-hop type: unilist               Index: 13236    Reference: 1
  Next-hop type: composite             Index: 15829    Reference: 1
 .
 .
 .

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.

content_copy zoom_out_map
user@Leaf-10> show route 10.1.4.102 table VRF_3.inet.0 extensive
VRF_3.inet.0: 28 destinations, 68 routes (28 active, 0 holddown, 0 hidden)
10.1.4.102/32 (3 entries, 1 announced)
        State: <CalcForwarding>
TSI:
KRT in-kernel 10.1.4.102/32 -> -> {list:composite(15829), composite(15828)}
        @EVPN   Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0x286ccd9c
                       .
                       .
                       .
                Indirect next hop: 0x1fc89b08 15827 INH Session ID: 4104
                State: <Active Int Ext VxlanLocalRT>
                Age: 31:22      Metric2: 0
                Validation State: unverified
 .
 .
 .

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.

arrow_backward PREVIOUS Collapsed Spine Fabric Design and Implementation

NEXT arrow_forward Data Center Interconnect Design and Implementation Using Type 5 Routes

Data Center EVPN-VXLAN Fabric Architecture Guide

ON THIS PAGE