close

keyboard_arrow_left

Table of Contents Expand all

list Table of Contents

English

Configure an Edge-Routed Bridging Overlay on a Lean Spine Device
Verify the Edge-Routed Bridging Overlay on a Lean Spine Device
Configure an Edge-Routed Bridging Overlay on a Leaf Device
Verify the Edge-Routed Bridging Overlay on a Leaf Device
Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices
Verify Symmetric IRB Routing with EVPN Type 2 Routes on a Leaf Device

keyboard_arrow_right

Edge-Routed Bridging Overlay Design and Implementation

date_range 08-Apr-25

arrow_backward

arrow_forward

A second overlay option for this reference design is the edge-routed bridging overlay, as shown in Figure 1.

Figure 1: Edge-Routed Bridging Overlay

The edge-routed bridging overlay performs routing at IRB interfaces located at the edge of the overlay (most often at the leaf devices). As a result, Ethernet bridging and IP routing happen as close to the end systems as possible, but still support Ethernet dependent applications at the end system level.

You can configure edge-routed bridging overlay architectures using the traditional IPv4 EBGP underlay with IPv4 IBGP overlay, peering, or alternatively (with supported platforms) use an IPv6 EBGP underlay with IPv6 EBGP overlay peering. The configuration procedures in this section describe the configuration differences, where applicable, with an IPv6 Fabric instead of an IPv4 Fabric.

For a list of devices that we support as lean spine and leaf devices in an edge-routed bridging overlay, see the Data Center EVPN-VXLAN Fabric Reference Designs—Supported Hardware Summary. That list includes which devices support an IPv6 Fabric when serving in different device roles.

Lean spine devices handle only IP traffic, which removes the need to extend the bridging overlay to the lean spine devices. With this limited role, on these devices you configure only the IP fabric underlay and BGP overlay peering (either an IPv4 Fabric or an IPv6 Fabric).

On the leaf devices, you can configure an edge-routed bridging overlay using the default switch instance or using MAC-VRF instances.

Note:

Keep the following in mind when you configure an ERB overlay for an EVPN-VXLAN network:

On any Junos OS Evolved devices, we support EVPN-VXLAN configurations with MAC-VRF instances only.
We support the IPv6 Fabric infrastructure design with MAC-VRF instances only.
On the QFX5130 and QFX5700 switches in the EVPN fabric, make sure you configure the host-profile unified forwarding profile to support an EVPN-VXLAN environment (see Layer 2 Forwarding Tables for details):
```
set system packet-forwarding-options forwarding-profile host-profile
```

Some configuration steps that affect the Layer 2 configuration differ with MAC-VRF instances. Likewise, a few steps differ for IPv6 Fabric configurations. The leaf device configuration includes the following steps:

Configure the default instance with the loopback interface as a VTEP source interface. Or if your configuration uses MAC-VRF instances, configure a MAC-VRF instance with the loopback interface as a VTEP source interface. If your fabric uses an IPv6 Fabric, you configure the VTEP source interface as an IPv6 interface. In each MAC-VRF instance, you also configure a service type, a route distinguisher, and a route target.
Configure a leaf-to-end system aggregated Ethernet interface as a trunk to carry multiple VLANs. With MAC-VRF instances, you also include the interface in the MAC-VRF instance.
Establish LACP and ESI functionality.
Map VLANs to VXLAN network identifiers (VNIs). For a MAC-VRF instance configuration, you configure the VLAN to VNI mappings in the MAC-VRF instance.
Configure proxy-macip-advertisement, virtual gateways, and static MAC addresses on the IRB interfaces.
Configure EVPN/VXLAN in the default instance or in the MAC-VRF instance.
Enable Layer 3 (L3) tenant virtual routing and forwarding (VRF) instances and IP prefix route properties for EVPN Type 5.
Optionally enable symmetric IRB routing with EVPN Type 2 routes on the leaf devices. Symmetric Type 2 routing avoids scaling issue when your EVPN network has many VLANs and many attached hosts or servers. With symmetric Type 2 routing, on each leaf device you only need to configure the VLANs that leaf devices serves. We support symmetric Type 2 routing only with MAC-VRF EVPN instances.

For an overview of edge-routed bridging overlays, see the Edge-Routed Bridging Overlay section in Data Center Fabric Blueprint Architecture Components.

For more information about MAC-VRF instances and using them in an example customer use case with an edge-routed bridging overlay, see EVPN-VXLAN DC IP Fabric MAC-VRF L2 Services.

The following sections show the steps to configure and verify the edge-routed bridging overlay:

Configure an Edge-Routed Bridging Overlay on a Lean Spine Device

To enable the edge-routed bridging overlay on a lean spine device, perform the following:

Note:

The following example shows the configuration for Spine 1, as shown in Figure 2.

Figure 2: Edge-Routed Bridging Overlay – Lean Spine Devices

Ensure the IP fabric underlay is in place. To see the steps required to configure an IP fabric on a spine device, see IP Fabric Underlay Network Design and Implementation.
If you are using an IPv6 Fabric, see IPv6 Fabric Underlay and Overlay Network Design and Implementation with EBGP instead. Those instructions include how to configure the IPv6 underlay connectivity with EBGP and IPv6 overlay peering.
Confirm that your IBGP overlay is up and running. To configure an IBGP overlay on your spine device, see Configure IBGP for the Overlay.
If you are using an IPv6 Fabric, you don’t need this step. Step 1 also covers how to configure the EBGP IPv6 overlay peering that corresponds to the IPv6 underlay connectivity configuration.

Verify the Edge-Routed Bridging Overlay on a Lean Spine Device

To verify that IBGP is functional on a lean spine device, use the show bgp summary command as described in Configure IBGP for the Overlay. In the output that displays, ensure that the state of the lean spine device and its peers is Establ (established).

Use the same command if you have an IPv6 Fabric. In the output, look for the IPv6 addresses of the peer device interconnecting interfaces (for underlay EBGP peering) or peer device loopback addresses (for overlay EBGP peering). Ensure that the state is Establ (established).

Configure an Edge-Routed Bridging Overlay on a Leaf Device

To enable the edge-routed bridging overlay on a leaf device, perform the following:

Note:

The following example shows the configuration for Leaf 10, as shown in Figure 3.

Figure 3: Edge-Routed Bridging Overlay – Leaf Devices

Configure the fabric underlay and overlay:
For an IP Fabric underlay using IPv4:
- Ensure the IP fabric underlay is in place. To configure an IP fabric on a leaf device, see IP Fabric Underlay Network Design and Implementation.
- Confirm that your IBGP overlay peering is up and running. To configure IBGP overlay peering on your leaf device, see Configure IBGP for the Overlay.
For an IPv6 fabric underlay with EBGP IPv6 overlay peering:
- Ensure the IPv6 underlay is in place and the EBGP overlay peering is up and running. To configure an IPv6 Fabric, see IPv6 Fabric Underlay and Overlay Network Design and Implementation with EBGP.
Configure the loopback interface as a VTEP source interface.
If your configuration uses the default instance, you use statements at the [edit switch-options] hierarchy level, as follows:

Leaf 10 (Default Instance):
```
set switch-options vtep-source-interface lo0.0
set switch-options route-distinguisher 192.168.1.10:1
set switch-options vrf-target target:64512:1111
set switch-options vrf-target auto
```
If your configuration uses MAC-VRF instances, define a routing instance of type mac-vrf, and configure these statements at that MAC-VRF routing instance hierarchy level. You also must configure a service type for the MAC-VRF instance. We use the vlan-aware service type here so you can associate multiple VLANs with the MAC-VRF instance. This setting is consistent with the alternative configuration that uses the default instance.

Leaf 10 (MAC-VRF Instance):
```
set routing-instances MAC-VRF-1 vtep-source-interface lo0.0
set routing-instances MAC-VRF-1 instance-type mac-vrf
set routing-instances MAC-VRF-1 service-type vlan-aware
set routing-instances MAC-VRF-1 route-distinguisher 192.168.1.10:1
set routing-instances MAC-VRF-1  vrf-target target:64512:1111
```
If you have an IPv6 Fabric (supported only with MAC-VRF instances), in this step you include the inet6 option when you configure the VTEP source interface to use the device loopback address. This option enables IPv6 VXLAN tunneling in the fabric. This is the only difference in the MAC-VRF configuration with an IPv6 Fabric as compared to the MAC-VRF configuration with an IPv4 Fabric.

Leaf 10 (MAC-VRF Instance with an IPv6 Fabric):
```
set routing-instances MAC-VRF-1 vtep-source-interface lo0.0 inet6
set routing-instances MAC-VRF-1 instance-type mac-vrf
set routing-instances MAC-VRF-1 service-type vlan-aware
set routing-instances MAC-VRF-1 route-distinguisher 192.168.1.10:1
set routing-instances MAC-VRF-1  vrf-target target:64512:1111
```
(MAC-VRF instances only) Enable shared tunnels on devices in the QFX5000 line running Junos OS.
A device can have problems with VTEP scaling when the configuration uses multiple MAC-VRF instances. As a result, to avoid this problem, we require that you enable the shared tunnels feature on the QFX5000 line of switches running Junos OS with a MAC-VRF instance configuration. When you configure the shared-tunnels option, the device minimizes the number of next-hop entries to reach remote VTEPs. This statement is optional on the QFX10000 line of switches running Junos OS because those devices can handle higher VTEP scaling than QFX5000 switches. You also don’t need to configure this option on devices running Junos OS Evolved, where shared tunnels are enabled by default.

Include the following statement to globally enable shared VXLAN tunnels on the device:
```
set forwarding-options evpn-vxlan shared-tunnels
```
Note:
This setting requires you to reboot the device.
(Required on PTX10000 Series routers only) Enable tunnel termination globally (in other words, on all interfaces) on the device:
```
set forwarding-options tunnel-termination
```

Configure the leaf-to-end system aggregated Ethernet interface as a trunk carrying four VLANs. Include the appropriate ESI and LACP values for your topology.

Leaf 10:

content_copy zoom_out_map
set interfaces ae11 esi 00:00:00:00:00:01:00:00:00:01
set interfaces ae11 esi all-active
set interfaces ae11 aggregated-ether-options lacp active
set interfaces ae11 aggregated-ether-options lacp periodic fast
set interfaces ae11 aggregated-ether-options lacp system-id 00:01:00:00:00:01
set interfaces ae11 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_50000
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_60000
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_70000
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_80000

Note:

When configuring ESI-LAGs on the QFX5000 line of switches that serve as leaf devices in an edge-routed bridging overlay, keep in mind that we currently support only the Enterprise style of interface configuration, which is shown in this step.

If your configuration uses MAC-VRF instances, you must also add the configured aggregated Ethernet interface to the MAC-VRF instance:

content_copy zoom_out_map
set routing-instances MAC-VRF-1 interface ae11.0

Configure the mapping of VLANs to VNIs and associate one IRB interface per VLAN.

This step shows the VLAN to VNI mapping and IRB interface association either in the default instance or in a MAC-VRF instance configuration.

Leaf 10 (Default Instance):

content_copy zoom_out_map
set vlans VNI_50000 vlan-id 500
set vlans VNI_50000 l3-interface irb.500
set vlans VNI_50000 vxlan vni 50000
set vlans VNI_60000 vlan-id 600
set vlans VNI_60000 l3-interface irb.600
set vlans VNI_60000 vxlan vni 60000
set vlans VNI_70000 vlan-id 700
set vlans VNI_70000 l3-interface irb.700
set vlans VNI_70000 vxlan vni 70000
set vlans VNI_80000 vlan-id 800
set vlans VNI_80000 l3-interface irb.800
set vlans VNI_80000 vxlan vni 80000

Leaf 10 (MAC-VRF Instance):

The only difference with a MAC-VRF instance configuration is that you configure these statements in the MAC-VRF instance at the [edit routing-instances mac-vrf-instance-name] hierarchy level.

content_copy zoom_out_map
set routing-instances MAC-VRF-1 vlans VNI_50000 vlan-id 500
set routing-instances MAC-VRF-1 vlans VNI_50000 l3-interface irb.500
set routing-instances MAC-VRF-1 vlans VNI_50000 vxlan vni 50000
set routing-instances MAC-VRF-1 vlans VNI_60000 vlan-id 600
set routing-instances MAC-VRF-1  vlans VNI_60000 l3-interface irb.600
set routing-instances MAC-VRF-1 vlans VNI_60000 vxlan vni 60000
set routing-instances MAC-VRF-1 vlans VNI_70000 vlan-id 700
set routing-instances MAC-VRF-1 vlans VNI_70000 l3-interface irb.700
set routing-instances MAC-VRF-1 vlans VNI_70000 vxlan vni 70000
set routing-instances MAC-VRF-1 vlans VNI_80000 vlan-id 800
set routing-instances MAC-VRF-1 vlans VNI_80000 l3-interface irb.800
set routing-instances MAC-VRF-1 vlans VNI_80000 vxlan vni 80000

Configure the IRB interfaces for VNIs 50000 and 60000 with both IPv4 and IPv6 dual stack addresses for both the IRB IP address and virtual gateway IP address.

There are two methods for configuring gateways for IRB interfaces:

Method 1: Unique IRB IP Address with Virtual Gateway IP Address, which is shown in Step 7.
Method 2: IRB with Anycast IP Address and MAC Address, which is shown in Step 8.

Leaf 10:

content_copy zoom_out_map
set interfaces irb unit 500 family inet address 10.1.4.1/24 virtual-gateway-address 10.1.4.254
set interfaces irb unit 500 family inet6 address 2001:db8::10:1:4:1/112 virtual-gateway-address 2001:db8::10:1:4:254
set interfaces irb unit 500 family inet6 address fe80:10:1:4::1/64 virtual-gateway-address fe80:10:1:4::254
set interfaces irb unit 600 family inet address 10.1.5.1/24 virtual-gateway-address 10.1.5.254
set interfaces irb unit 600 family inet6 address 2001:db8::10:1:5:1/112 virtual-gateway-address 2001:db8::10:1:5:254
set interfaces irb unit 600 family inet6 address fe80:10:1:5::1/64 virtual-gateway-address fe80:10:1:5::254
set interfaces irb unit 500 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 500 virtual-gateway-v6-mac 00:00:5e:00:00:04
set interfaces irb unit 600 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 600 virtual-gateway-v6-mac 00:00:5e:00:00:04

Configure the IRB interfaces for VNIs 70000 and 80000 with a dual stack Anycast IP address.

Leaf 10:

content_copy zoom_out_map
set interfaces irb unit 700 family inet address 10.1.6.254/24
set interfaces irb unit 700 family inet6 address 2001:db8::10:1:6:254/112
set interfaces irb unit 700 family inet6 address fe80::10:1:6:254/112
set interfaces irb unit 700 mac 0a:fe:00:00:00:01
set interfaces irb unit 800 family inet address 10.1.7.254/24
set interfaces irb unit 800 family inet6 address 2001:db8::10:1:7:254/112
set interfaces irb unit 800 family inet6 address fe80::10:1:7:254/112
set interfaces irb unit 800 mac 0a:fe:00:00:00:02

For more information about IRB and virtual gateway IP address configuration, see the IRB Addressing Models in Bridging Overlays section in Data Center Fabric Blueprint Architecture Components.

Enable the ping operation for IRB interfaces 500 and 600, which are configured in Step 6.

content_copy zoom_out_map
set interfaces irb unit 500 family inet address 10.1.4.1/24 preferred
set interfaces irb unit 500 family inet6 address 2001:db8::10:1:4:1/112 preferred
set interfaces irb unit 500 virtual-gateway-accept-data
set interfaces irb unit 600 family inet address 10.1.5.1/24 preferred
set interfaces irb unit 600 family inet6 address 2001:db8::10:1:5:1/112 preferred
set interfaces irb unit 600 virtual-gateway-accept-data

Configure the EVPN protocol with VXLAN encapsulation on the leaf device.
This step shows how to configure either the default instance or a MAC-VRF instance.

Leaf 10 (Default Instance):
```
set protocols evpn encapsulation vxlan
set protocols evpn default-gateway no-gateway-community
set protocols evpn extended-vni-list all
```
Leaf 10 (MAC-VRF Instance):

The only difference with a MAC-VRF configuration is that you configure these statements in the MAC-VRF instance at the [edit routing-instances mac-vrf-instance-name] hierarchy level.
```
set routing-instances MAC-VRF-1 protocols evpn encapsulation vxlan
set routing-instances MAC-VRF-1 protocols evpn default-gateway no-gateway-community
set routing-instances MAC-VRF-1 protocols evpn extended-vni-list all
```

Configure a policy called EXPORT_HOST_ROUTES to match on and accept /32 and /128 host routes, direct routes, and static routes. You will use this policy in step 13.

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 the loopback interface with two logical interfaces. (You will assign one logical interface to each VRF routing instance in the next step).
```
set interfaces lo0 unit 3 family inet
set interfaces lo0 unit 4 family inet
```

Configure two tenant VRF routing instances, one for VNIs 50000 and 60000 (VRF 3), and one for VNIs 70000 and 80000 (VRF 4). Assign one logical interface from the loopback to each routing instance so that the VXLAN gateway can resolve ARP requests. Configure IP prefix route properties for EVPN Type 5 to advertise ARP routes to the spine devices. Enable load balancing for L3 VPNs (set the multipath option).

Leaf 10:

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 irb.600
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 vrf-target target:62273:50000
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 vni 16777214
set routing-instances VRF_3 protocols evpn ip-prefix-routes export EXPORT_HOST_ROUTES
set routing-instances VRF-3 routing-options multipath
set routing-instances VRF-3 routing-options rib VRF-3.inet6.0 multipath
set routing-instances VRF_4 instance-type vrf
set routing-instances VRF_4 interface irb.700
set routing-instances VRF_4 interface irb.800
set routing-instances VRF_4 interface lo0.4
set routing-instances VRF_4 route-distinguisher 192.168.1.10:600
set routing-instances VRF_4 vrf-target target:62273:60000
set routing-instances VRF_4 protocols evpn ip-prefix-routes advertise direct-nexthop
set routing-instances VRF_4 protocols evpn ip-prefix-routes encapsulation vxlan
set routing-instances VRF_4 protocols evpn ip-prefix-routes vni 16777105
set routing-instances VRF_4 protocols evpn ip-prefix-routes export EXPORT_HOST_ROUTES
set routing-instances VRF_4 routing-options multipath
set routing-instances VRF_4 routing-options rib VRF_4.inet6.0 multipath

(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
set routing-instances VRF_4 protocols evpn ip-prefix-routes reject-asymmetric-vni
```
Set up dummy IPv4 and IPv6 static routes for each tenant VRF instance, which enable the device to advertise at least one EVPN Type 5 route for the VRF. We include this step because all devices with Type 5 routes configured must advertise at least one route for forwarding to work. The device must receive at least one EVPN Type 5 route from a peer device and install an IP forwarding route in the Packet Forwarding Engine. Otherwise, the device doesn’t install the next hop required to de-encapsulate the received traffic and doesn’t forward the traffic.
Leaf 10:
```
set routing-instances VRF_3 routing-options static route 10.10.20.30/32 discard
set routing-instances VRF-3 routing-options rib VRF-3.inet6.0 static route 2001:db8::101:1:1:1/128 discard
set routing-instances VRF_4 routing-options static route 10.10.20.30/32 discard
set routing-instances VRF-4 routing-options rib VRF-4.inet6.0 static route 2001:db8::101:1:1:1/128 discard
```
If you are configuring a QFX5110, QFX5120-48Y, or QFX5120-32C switch, you must perform this step to support pure EVPN Type 5 routes on ingress EVPN traffic.
```
set routing-options forwarding-table chained-composite-next-hop ingress evpn
set forwarding-options vxlan-routing overlay-ecmp
```
Note:
Entering the overlay-ecmp statement causes the Packet Forwarding Engine to restart, which interrupts forwarding operations. We recommend using this configuration statement before the EVPN-VXLAN network becomes operational.
If you are configuring a QFX5110, QFX5120-48Y, or QFX5120-32C switch, and you expect that there will be more than 8000 ARP table entries and IPv6 neighbor entries, perform this step.
Configure the maximum number of next hops reserved for use in the EVPN-VXLAN overlay network. By default, the switch allocates 8000 next hops for use in the overlay network. See next-hop for more details.

Note:
Changing the number of next hops causes the Packet Forwarding Engine to restart, which interrupts forwarding operations. We recommend using this configuration statement before the EVPN-VXLAN network becomes operational.
```
set forwarding-options vxlan-routing next-hop 12288
```

Verify the Edge-Routed Bridging Overlay on a Leaf Device

To verify that the edge-routed bridging overlay is working, run the following commands.

The commands here show output for a default instance configuration. With a MAC-VRF instance configuration, you can alternatively use:

show mac-vrf forwarding commands that are aliases for the show ethernet-switching commands in this section.
The show mac-vrf routing database command, which is an alias for the show evpn database command in this section.

The output with a MAC-VRF instance configuration displays similar information for MAC-VRF routing instances as this section shows for the default instance. One main difference you might see is in the output with MAC-VRF instances on devices where you enable the shared tunnels feature. With shared tunnels enabled, you see VTEP interfaces in the following format:

content_copy zoom_out_map
vtep-index.shared-tunnel-unit

where:

index is the index associated with the MAC-VRF routing instance.
shared-tunnel-unit is the unit number associated with the shared tunnel remote VTEP logical interface.

For example, if a device has a MAC-VRF instance with index 26 and the instance connects to two remote VTEPs, the shared tunnel VTEP logical interfaces might look like this:

content_copy zoom_out_map
vtep-26.32823
vtep-26.32824

If your configuration uses an IPv6 Fabric, you provide IPv6 address parameters where applicable. Output from the commands that display IP addresses reflect the IPv6 device and interface addresses from the underlying fabric. See IPv6 Fabric Underlay and Overlay Network Design and Implementation with EBGP for the fabric parameters reflected in command outputs in this section with an IPv6 Fabric.

Verify that the aggregated Ethernet interface is operational.

content_copy zoom_out_map
user@leaf-10> show interfaces terse ae11
Interface               Admin Link Proto    Local                 Remote
ae11                    up    up
ae11.0                  up    up   eth-switch

Verify the VLAN information (associated ESIs, VTEPs, etc.).

content_copy zoom_out_map
user@leaf-10> show vlans
default-switch          VNI_50000             500      
                                                           ae11.0*
                                                           esi.7585*
                                                           esi.7587*
                                                           esi.8133*
                                                           et-0/0/16.0
                                                           vtep.32782*
                                                           vtep.32785*
                                                           vtep.32802*
                                                           vtep.32806*
                                                           vtep.32826*

...

default-switch          VNI_80000             800      
                                                           ae11.0*
                                                           esi.7585*
                                                           esi.8133*
                                                           et-0/0/16.0
                                                           vtep.32782*
                                                           vtep.32785*
                                                           vtep.32802*
                                                           vtep.32806*
                                                           vtep.32826*

Note: esi.7585 is the ESI of the remote aggregated Ethernet link for Leaf 4, Leaf 5, and Leaf 6.

content_copy zoom_out_map
user@leaf-10> show ethernet-switching vxlan-tunnel-end-point esi | find esi.7585
00:00:00:00:00:00:51:10:00:01 default-switch           7585  2097663 esi.7585            3    
    RVTEP-IP             RVTEP-IFL      VENH     MASK-ID   FLAGS
    192.168.1.5          vtep.32826     8169     2         2         
    192.168.1.6          vtep.32782     7570     1         2         
    192.168.1.4          vtep.32785     7575     0         2

Note: esi.7587 is the ESI for all leaf devices that have the same VNI number (Leaf 4, Leaf 5, Leaf 6, Leaf 11, and Leaf 12).

content_copy zoom_out_map
user@leaf-10> show ethernet-switching vxlan-tunnel-end-point esi | find esi.7587
05:19:17:f3:41:00:00:c3:50:00 default-switch           7587  2097665 esi.7587            5    
    RVTEP-IP             RVTEP-IFL      VENH     MASK-ID   FLAGS
    192.168.1.5          vtep.32826     8169     4         2         
    192.168.1.6          vtep.32782     7570     3         2         
    192.168.1.12         vtep.32802     8127     2         2         
    192.168.1.11         vtep.32806     8131     1         2         
    192.168.1.4          vtep.32785     7575     0         2

Note: esi.8133 is the ESI for the local aggregated Ethernet interface shared with Leaf 11 and Leaf 12.

content_copy zoom_out_map
user@leaf-10> show ethernet-switching vxlan-tunnel-end-point esi | find esi.8133
00:00:00:00:00:01:00:00:00:01 default-switch           8133  2098194 esi.8133  ae11.0,   2    
    RVTEP-IP             RVTEP-IFL      VENH     MASK-ID   FLAGS
    192.168.1.12         vtep.32802     8127     1         2         
    192.168.1.11         vtep.32806     8131     0         2

Verify the ARP table.

Note: 10.1.4.201 and 10.1.5.201 are remote end systems connected to the QFX5110 switches; and 10.1.4.202 and 10.1.5.202 are local end systems connected to Leaf 10 through interface ae11.

content_copy zoom_out_map
user@leaf-10> show arp no-resolve vpn VRF_3
MAC Address       Address         Interface         Flags
a7:39:9a:7b:c0 10.1.4.4        irb.500 [vtep.32785]     none
a7:39:f8:b1:00 10.1.4.5        irb.500 [vtep.32826]     none
e0:f3:1b:09:80 10.1.4.6        irb.500 [vtep.32782]     none
0c:10:04:02:01 10.1.4.201      irb.500 [.local..9]      none
0c:10:04:02:02 10.1.4.202      irb.500 [ae11.0]         none
00:5e:00:00:04 10.1.4.254      irb.500                  permanent published gateway
a7:39:9a:7b:c0 10.1.5.4        irb.600 [vtep.32785]     none
a7:39:f8:b1:00 10.1.5.5        irb.600 [vtep.32826]     none
e0:f3:1b:09:80 10.1.5.6        irb.600 [vtep.32782]     none
0c:10:05:02:01 10.1.5.201      irb.600 [.local..9]      none
0c:10:05:02:02 10.1.5.202      irb.600 [ae11.0]         none
00:5e:00:00:04 10.1.5.254      irb.600                  permanent published gateway
Total entries: 12
user@leaf-10> show arp no-resolve vpn VRF_4
MAC Address       Address         Interface         Flags
0c:10:06:02:01 10.1.6.201      irb.700 [.local..9]      permanent remote
0c:10:06:02:02 10.1.6.202      irb.700 [ae11.0]         none
0c:10:07:02:01 10.1.7.201      irb.800 [.local..9]      permanent remote
0c:10:07:02:02 10.1.7.202      irb.800 [ae11.0]         permanent remote
Total entries: 4
user@leaf-10> show ipv6 neighbors
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
db8::10:1:4:2           06:ac:ac:23:0c:4e  stale       523 yes no      irb.500 [vtep.32806]
db8::10:1:4:3           06:ac:ac:24:18:7e  stale       578 yes no      irb.500 [vtep.32802]
db8::10:1:4:201         02:0c:10:04:02:01  stale       1122 no no      irb.500 [.local..9]
db8::10:1:4:202         02:0c:10:04:02:02  stale       1028 no no      irb.500 [ae11.0]
db8::10:1:4:254         00:00:5e:00:00:04   reachable   0   no  no      irb.500     
db8::10:1:5:2           06:ac:ac:23:0c:4e  stale       521 yes no      irb.600 [vtep.32806]
db8::10:1:5:3           06:ac:ac:24:18:7e  stale       547 yes no      irb.600 [vtep.32802]
db8::10:1:5:201         02:0c:10:05:02:01  stale       508 no  no      irb.600 [.local..9]
db8::10:1:5:202         02:0c:10:05:02:02  stale       1065 no no      irb.600 [ae11.0]
db8::10:1:5:254         00:00:5e:00:00:04   reachable   0   no  no      irb.600     
db8::10:1:6:202         02:0c:10:06:02:02  reachable   0   no  no      irb.700 [ae11.0]
db8::10:1:7:201         02:0c:10:07:02:01  stale       647 no  no      irb.800 [.local..9]

Verify the MAC addresses and ARP information in the EVPN database.

For example, with an IPv4 Fabric:

content_copy zoom_out_map
user@leaf-10> show evpn database mac-address 02:0c:10:04:02:01 extensive
Instance: default-switch

VN Identifier: 50000, MAC address:: 02:0c:10:04:02:01
  Source: 00:00:00:00:00:00:51:10:00:01, Rank: 1, Status: Active
    Remote origin: 192.168.1.4
    Remote origin: 192.168.1.5
    Timestamp: Oct 10 16:09:54 (0x59dd5342)
    State: <Remote-To-Local-Adv-Done>
    IP address: 10.1.4.201
      Remote origin: 192.168.1.4
      Remote origin: 192.168.1.5
    IP address: 2001:db8::10:1:4:201
      Flags: <Proxy>
      Remote origin: 192.168.1.4
      Remote origin: 192.168.1.5    History db: 
      Time                  Event
      Oct 10 16:09:55 2017  Advertisement route cannot be created (no local state present)
      Oct 10 16:09:55 2017  Updating output state (change flags 0x0)
      Oct 10 16:09:55 2017  Advertisement route cannot be created (no local source present)
      Oct 10 16:09:55 2017  IP host route cannot be created (No remote host route for non-MPLS instance)
      Oct 10 16:09:55 2017  Updating output state (change flags 0x4000 <IP-Peer-Added>)
      Oct 10 16:09:55 2017  Creating MAC+IP advertisement route for proxy
      Oct 10 16:09:55 2017  Creating MAC+IP advertisement route for proxy
      Oct 10 16:09:55 2017  IP host route cannot be created (No remote host route for non-MPLS instance)
      Oct 10 16:09:55 2017  Clearing change flags <IP-Added>
      Oct 10 16:09:55 2017  Clearing change flags <IP-Peer-Added>
user@leaf-10> show evpn database mac-address 02:0c:10:04:02:02 extensive
Instance: default-switch

VN Identifier: 50000, MAC address:: 02:0c:10:04:02:02
  Source: 00:00:00:00:00:01:00:00:00:01, Rank: 1, Status: Active
    Remote origin: 192.168.1.11
    Remote origin: 192.168.1.12
    Timestamp: Oct 10 16:14:32 (0x59dd5458)
    State: <Remote-To-Local-Adv-Done>
    IP address: 10.1.4.202
      Remote origin: 192.168.1.11
      Remote origin: 192.168.1.12
      L3 route: 10.1.4.202/32, L3 context: VRF_3 (irb.500)
    IP address: 2001:db8::10:1:4:202
      Remote origin: 192.168.1.11
      L3 route: 2001:db8::10:1:4:202/128, L3 context: VRF_3 (irb.500)    History db: 
      Time                  Event
      Oct 10 16:14:32 2017  Advertisement route cannot be created (no local state present)
      Oct 10 16:14:32 2017  Sent MAC add with NH 0, interface ae11.0 (index 0), RTT 9, remote addr 192.168.1.12, ESI 0100000001, VLAN 0, VNI 50000, flags 0x0, timestamp 0x59dd5458 to L2ALD
      Oct 10 16:14:32 2017  Sent peer 192.168.1.12 record created
      Oct 10 16:14:32 2017  Sent MAC+IP add, interface <none>, RTT 9, IP 10.1.4.202 remote peer 192.168.1.12, ESI 0100000001, VLAN 0, VNI 50000, flags 0x80, timestamp 0x59dd5458 to L2ALD
      Oct 10 16:14:32 2017  Updating output state (change flags 0x4000 <IP-Peer-Added>)
      Oct 10 16:14:32 2017  Advertisement route cannot be created (no local source present)
      Oct 10 16:14:32 2017  Updating output state (change flags 0x0)
      Oct 10 16:14:32 2017  Advertisement route cannot be created (no local source present)
      Oct 10 16:14:32 2017  Clearing change flags <ESI-Peer-Added>
      Oct 10 16:14:32 2017  Clearing change flags <IP-Peer-Added>

Or for example, with an IPv6 Fabric:

content_copy zoom_out_map
user@leaf-1> show evpn database mac-address c8:fe:6a:e4:2e:00 l2-domain-id 1000
Instance: MAC-VRF-1
VLAN  DomainId  MAC address        Active source             Timestamp          IP address
      1000       c8:fe:6a:e4:2e:00  2001:db8::192:168:1:2     Jan 19 17:36:46   77.5.241.242
                                                                                2001:db8::77:0:5f1:242
                                                                                fe80::cafe:6a05:f1e4:2e00

user@leaf-1> show evpn database mac-address c8:fe:6a:e4:2e:00 l2-domain-id 1000 extensive
Instance: MAC-VRF-1

VN Identifier: 1000, MAC address: c8:fe:6a:e4:2e:00
  State: 0x0
  Source: 2001:db8::192:168:1:2, Rank: 1, Status: Active
    Mobility sequence number: 0 (minimum origin address 2001:db8::192:168:1:2)
    Timestamp: Jan 19 17:36:46.033965 (0x61e8bcae)
    State: <Remote-To-Local-Adv-Done Remote-Pinned>
    MAC advertisement route status: Not created (no local state present)
    IP address: 77.5.241.242
    IP address: 2001:db8::77:0:5f1:242
    IP address: fe80::cafe:6a05:f1e4:2e00
    History db: 
      Time                       Event
      Jan 19 16:15:00.440 2022   2001:db8::192:168:1:2 : Remote peer 2001:db8::192:168:1:2 created
      Jan 19 16:15:00.440 2022   2001:db8::192:168:1:2 : Created
      Jan 19 16:15:00.447 2022   Updating output state (change flags 0x1 <ESI-Added>)
      Jan 19 16:15:00.447 2022   Active ESI changing (not assigned -> 2001:db8::192:168:1:2)
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : 77.5.241.242 Selected IRB interface nexthop
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : 77.5.241.242 Reject remote ip host route 77.5.241.242 in L3 context VRF-1 since no remote-ip-host-routes configured
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : 2001:db8::77:0:5f1:242 Selected IRB interface nexthop
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : 2001:db8::77:0:5f1:242 Reject remote ip host route 2001:db8::77:0:5f1:242 in L3 context VRF-1 since no remote-ip-host-routes configured
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : fe80::cafe:6a05:f1e4:2e00 Selected IRB interface nexthop
      Jan 19 16:15:00.447 2022   2001:db8::192:168:1:2 : fe80::cafe:6a05:f1e4:2e00 Reject remote ip host route fe80::cafe:6a05:f1e4:2e00 in L3 context VRF-1 since no remote-ip-host-routes configured

Verify the IPv4 and IPv6 end system routes appear in the forwarding table.

content_copy zoom_out_map
user@leaf-10> show route forwarding-table table VRF_1 destination 10.1.4.202 extensive
Routing table: VRF_3.inet [Index 5] 
Internet:
Enabled protocols: Bridging, All VLANs, 
    
Destination:  10.1.4.202/32
  Route type: destination           
  Route reference: 0                   Route interface-index: 563 
  Multicast RPF nh index: 0             
  P2mpidx: 0              
  Flags: sent to PFE 
  Nexthop: b0:c:10:4:2:2
  Next-hop type: unicast               Index: 10210    Reference: 1    
  Next-hop interface: ae11.0
user@leaf-10> show route forwarding-table table VRF_1 destination 2001:db8::10:1:4:202 extensive
Routing table: VRF_3.inet6 [Index 5] 
Internet6:
Enabled protocols: Bridging, All VLANs, 
    
Destination:  2001:db8::10:1:4:202/128
  Route type: destination           
  Route reference: 0                   Route interface-index: 563 
  Multicast RPF nh index: 0             
  P2mpidx: 0              
  Flags: sent to PFE 
  Nexthop: b0:c:10:4:2:2
  Next-hop type: unicast               Index: 10244    Reference: 1    
  Next-hop interface: ae11.0

Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices

In EVPN-VXLAN ERB overlay networks, by default, leaf devices use an asymmetric IRB model with EVPN Type 2 routes to send traffic between subnets across the VXLAN tunnels, where:

L3 routing for inter-subnet traffic happens at the ingress device. Then the source VTEP forwards traffic at L2 toward the destination VTEP.
The traffic arrives at the destination VTEP, and that VTEP forwards the traffic on the destination VLAN.
For this model to work, you must configure all source and destination VLANs and their corresponding VNIs on all leaf devices.

You can alternatively enable symmetric IRB routing with Type 2 routes (called symmetric Type 2 routing here for brevity). We support symmetric Type 2 routing only in ERB overlay fabrics.

To use the symmetric IRB model to route traffic for a VRF, you must enable it in that VRF on all the leaf devices in the fabric. However, you don't need to configure all VLANs and VNIs in the VRF on all leaf devices. On each leaf device, you can configure only the host VLANs that leaf device serves. As a result, using symmetric Type 2 routing helps with scaling when your EVPN network has a large number of VLANs and many attached hosts or servers. We highlight this benefit here when we show how to enable symmetric Type 2 routing in the ERB overlay reference architecture in this chapter.

With the symmetric Type 2 routing model, the VTEPs route between subnets in a tenant VRF instance using the same VNI in either direction. Symmetric Type 2 routing for a VRF shares the L3 VNI tunnel you configure for EVPN Type 5 routing in the VRF. The implementation requires you to also configure EVPN Type 5 routing in the VRF. See Symmetric Integrated Routing and Bridging with EVPN Type 2 Routes in EVPN-VXLAN Fabrics for more details on asymmetric and symmetric IRB routing models, and how symmetric Type 2 routing works.

In this section, you update the configuration for the EVPN instance MAC-VRF-1 from Configure an Edge-Routed Bridging Overlay on a Leaf Device to include four more VLANs, VNI mappings, and corresponding IRB interfaces. You include the IRB interfaces in another tenant VRF called VRF_2 as follows:

Leaf 10—IRB 100
Leaf 11—IRB 200
Leaf 12—IRB 300 and IRB 400

See Figure 4.

The VNI for the L3 VNI tunnel in the figure is the VNI you configure for EVPN Type 5 routing in VRF_2. We enable symmetric Type 2 routing with the same VNI in VRF_2. Again, note that with symmetric Type 2 routing, you don't need to configure all VLANs in the VRF on all leaf devices.

Figure 4: Edge-Routed Bridging Overlay—Leaf Devices with Symmetric IRB Type 2 Routing

You must configure the EVPN instance using instance type MAC-VRF on the leaf devices in the ERB overlay fabric according to the instructions in Configure an Edge-Routed Bridging Overlay on a Leaf Device. Use a different route distinguisher on each leaf device—in this configuration, the route distinguishers mirror the device lo0.0 loopback addresses on the device. This configuration includes the same MAC-VRF instance and the same instance vrf-target value, but these don't need to be the same on all the leaf devices for symmetric Type 2 routing to work.

To enable symmetric Type 2 routing on the leaf devices according to Figure 4, perform these additional configuration steps as indicated in each step for Leaf 10, Leaf 11, and Leaf 12.

Configure the aggregated Ethernet interface ae11 trunk interface to carry the additional VLANs 100, 200, 300, and 400 (named VNI_10000, VNI_20000, VNI_30000, and VNI_40000, respectively) as the figure shows for the different leaf devices.
Leaf 10:
```
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_10000
```
Leaf 11:
```
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_20000
```
Leaf 12:
```
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_30000
set interfaces ae11 unit 0 family ethernet-switching vlan members VNI_40000
```

In the MAC-VRF EVPN instance, configure the VLANs, their associated IRB interfaces, and the VLAN to VNI mappings, as the figure shows.

Leaf 10 (VLAN 100):

content_copy zoom_out_map
set routing-instances MAC-VRF-1 vlans VNI_10000 vlan-id 100
set routing-instances MAC-VRF-1 vlans VNI_10000 l3-interface irb.100
set routing-instances MAC-VRF-1 vlans VNI_10000 vxlan vni 10000

Leaf 11 (VLAN 200):

content_copy zoom_out_map
set routing-instances MAC-VRF-1 vlans VNI_20000 vlan-id 200
set routing-instances MAC-VRF-1 vlans VNI_20000 l3-interface irb.200
set routing-instances MAC-VRF-1 vlans VNI_20000 vxlan vni 20000

Leaf 12 (VLANs 300 and 400):

content_copy zoom_out_map
set routing-instances MAC-VRF-1 vlans VNI_30000 vlan-id 300
set routing-instances MAC-VRF-1 vlans VNI_30000 l3-interface irb.300
set routing-instances MAC-VRF-1 vlans VNI_30000 vxlan vni 30000
set routing-instances MAC-VRF-1 vlans VNI_40000 vlan-id 400
set routing-instances MAC-VRF-1 vlans VNI_40000 l3-interface irb.400
set routing-instances MAC-VRF-1 vlans VNI_40000 vxlan vni 40000

Configure the IRB interfaces for VLANs 100, 200, 300 and 400 on their respective leaf devices with IPv4 and IPv6 dual stack addresses for the IRB IP addresses and virtual gateway IP addresses.

Here we use the same style of IRB interface configuration as VLAN 500 and VLAN 600 in VRF_3 (see Step 7 in Configure an Edge-Routed Bridging Overlay on a Leaf Device). Assign each IRB interface a unique IP address with a virtual gateway IP address (VGA) and a virtual gateway MAC address (the virtual gateway MAC is the same for all leaf devices).

Leaf 10 (IRB 100):

content_copy zoom_out_map
set interfaces irb unit 100 family inet address 10.1.0.1/24 virtual-gateway-address 10.1.0.254
set interfaces irb unit 100 family inet6 address 2001:db8::10:1:0:1/112 virtual-gateway-address 2001:db8::10:1:0:254
set interfaces irb unit 100 family inet6 address fe80:10:1:0::1/64 virtual-gateway-address fe80:10:1:0::254
set interfaces irb unit 100 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 100 virtual-gateway-v6-mac 00:00:5e:00:00:04

Leaf 11 (IRB 200):

content_copy zoom_out_map
set interfaces irb unit 200 family inet address 10.1.1.1/24 virtual-gateway-address 10.1.1.254
set interfaces irb unit 200 family inet6 address 2001:db8::10:1:1:1/112 virtual-gateway-address 2001:db8::10:1:1:254
set interfaces irb unit 200 family inet6 address fe80:10:1:1::1/64 virtual-gateway-address fe80:10:1:1::254
set interfaces irb unit 200 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 200 virtual-gateway-v6-mac 00:00:5e:00:00:04

Leaf 12 (IRB 300 and IRB 400):

content_copy zoom_out_map
set interfaces irb unit 300 family inet address 10.1.2.1/24 virtual-gateway-address 10.1.2.254
set interfaces irb unit 300 family inet6 address 2001:db8::10:1:2:1/112 virtual-gateway-address 2001:db8::10:1:2:254
set interfaces irb unit 300 family inet6 address fe80:10:1:2::1/64 virtual-gateway-address fe80:10:1:2::254
set interfaces irb unit 400 family inet address 10.1.3.1/24 virtual-gateway-address 10.1.3.254
set interfaces irb unit 400 family inet6 address 2001:db8::10:1:3:1/112 virtual-gateway-address 2001:db8::10:1:3:254
set interfaces irb unit 400 family inet6 address fe80:10:1:3::1/64 virtual-gateway-address fe80:10:1:3::254
set interfaces irb unit 300 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 300 virtual-gateway-v6-mac 00:00:5e:00:00:04
set interfaces irb unit 400 virtual-gateway-v4-mac 00:00:5e:00:00:04
set interfaces irb unit 400 virtual-gateway-v6-mac 00:00:5e:00:00:04

Enable ping for the IRB interfaces for VLANs 100, 200, 300, and 400 on their respective leaf devices.

Leaf 10:

content_copy zoom_out_map
set interfaces irb unit 100 family inet address 10.1.0.1/24 preferred
set interfaces irb unit 100 family inet6 address 2001:db8::10:1:0:1/112 preferred
set interfaces irb unit 100 virtual-gateway-accept-data

Leaf 11:

content_copy zoom_out_map
set interfaces irb unit 200 family inet address 10.1.1.1/24 preferred
set interfaces irb unit 200 family inet6 address 2001:db8::10:1:1:1/112 preferred
set interfaces irb unit 200 virtual-gateway-accept-data

Leaf 12:

content_copy zoom_out_map
set interfaces irb unit 300 family inet address 10.1.2.1/24 preferred
set interfaces irb unit 300 family inet6 address 2001:db8::10:1:2:1/112 preferred
set interfaces irb unit 300 virtual-gateway-accept-data
set interfaces irb unit 400 family inet address 10.1.3.1/24 preferred
set interfaces irb unit 400 family inet6 address 2001:db8::10:1:3:1/112 preferred
set interfaces irb unit 400 virtual-gateway-accept-data

Configure the additional VRF instance VRF_2 on all three leaf devices, similarly to how you configure the other VRF instances in Configure an Edge-Routed Bridging Overlay on a Leaf Device, Step 13. Assign a logical loopback interface (we use unit 2 in this case) to the new VRF instance so that the VXLAN gateway can resolve ARP requests. Include the IRB interfaces in VRF_2 for the VLANs supported on each leaf device in Figure 4. Note that on each device, we assign a VRF route distinguisher that is unique to the device (based on the device lo0.0 address for simplicity). However, we use the same VRF route target on all the devices.

Leaf 10:

content_copy zoom_out_map
set interfaces lo0 unit 2 family inet
set routing-instances VRF_2 instance-type vrf
set routing-instances VRF_2 interface irb.100
set routing-instances VRF_2 interface lo0.2
set routing-instances VRF_2 route-distinguisher 192.168.1.10:100
set routing-instances VRF_2 vrf-target target:62273:20000

Leaf 11:

content_copy zoom_out_map
set interfaces lo0 unit 2 family inet
set routing-instances VRF_2 instance-type vrf
set routing-instances VRF_2 interface irb.200
set routing-instances VRF_2 interface lo0.2
set routing-instances VRF_2 route-distinguisher 192.168.1.11:200
set routing-instances VRF_2 vrf-target target:62273:20000

Leaf 12:

content_copy zoom_out_map
set interfaces lo0 unit 2 family inet
set routing-instances VRF_2 instance-type vrf
set routing-instances VRF_2 interface irb.300
set routing-instances VRF_2 interface irb.400
set routing-instances VRF_2 interface lo0.2
set routing-instances VRF_2 route-distinguisher 192.168.1.12:300
set routing-instances VRF_2 vrf-target target:62273:20000

Enable EVPN Type 5 routing in VRF_2, and assign an L3 transit VNI value for Type 5 routing. We configure VNI value 16777123 here.
Similarly to how you configure the VRF instances and Type 5 routing in the other VRF instances in Configure an Edge-Routed Bridging Overlay on a Leaf Device, Step 13, in this step we also:
- Enable L3 load balancing by setting the multipath option for IPv4 and IPv6 traffic.
- Set up at least one dummy IPv4 and IPv6 route for the new tenant VRF instance, so the device can advertise at least one EVPN Type 5 route in the VRF.
However, we don't apply the EXPORT_HOST_ROUTES export policy for IP prefix routes from that step. For the devices to invoke symmetric Type 2 routing instead of Type 5 routing, we don't configure this Type 5 export policy in VRF_2 on the leaf devices.

Leaf 10, Leaf 11, and Leaf 12:
```
set routing-instances VRF_2 protocols evpn ip-prefix-routes advertise direct-nexthop
set routing-instances VRF_2 protocols evpn ip-prefix-routes encapsulation vxlan
set routing-instances VRF_2 protocols evpn ip-prefix-routes vni 16777123
set routing-instances VRF_2 routing-options multipath
set routing-instances VRF_2 routing-options rib VRF_2.inet6.0 multipath
set routing-instances VRF_2 routing-options static route 10.10.20.30/32 discard
set routing-instances VRF_2 routing-options rib VRF_2.inet6.0 static route 2001:db8::101:1:1:1/128 discard
```
Note:
ACX7100 routers and QFX5210 switches don't support asymmetric VNI values on either side of a VXLAN tunnel for a given VRF. To support EVPN Type 5 routing and symmetric IRB routing with EVPN Type 2 routes on those platforms, you must configure the same L3 VNI value for a particular VRF on each of the leaf devices. On other platforms, the L3 VNI can be different on either side of the tunnel for a given VRF. For simplicity, this step uses the same L3 VNI for VRF_2 on all leaf devices.
Enable symmetric Type 2 routing for VRF_2 on the leaf devices using the irb-symmetric-routing configuration statement at the [edit routing-instances l3-vrf-name protocols evpn] hierarchy level.
In Step 6 of this procedure, when you configure VRF instance VRF_2, you enable Type 5 routing and assign VNI 16777123 for the Type 5 VXLAN tunnel. You use the same VNI value when you enable symmetric Type 2 routing for VRF_2.

Leaf 10, Leaf 11, and Leaf 12:
```
set routing-instances VRF_2 protocols evpn irb-symmetric-routing vni 16777123
```

Verify Symmetric IRB Routing with EVPN Type 2 Routes on a Leaf Device

In Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices, you enable symmetric Type 2 routing in VRF_2 on:

Leaf 10 for VLAN 100 with VNI 10000, irb.100 = 10.1.0.1/24
Leaf 11 for VLAN 200 with VNI 20000, irb.200 = 10.1.1.1/24
Leaf 12 for:
- VLAN 300 with VNI 30000, irb.300 = 10.1.2.1/24
- VLAN 400 with VNI 40000, irb.400 = 10.1.3.1/24

In this section, on Leaf 10, we view routes toward Leaf 11 to verify that the leaf devices invoke symmetric Type 2 routing.

Verify that Leaf 10 adds IP host routes to the VRF_2 routing table for the remote EVPN Type 2 MAC-IP route toward Leaf 11.

content_copy zoom_out_map
user@leaf-10> show route 10.1.1.1

VRF_2.inet.0: 32 destinations, 48 routes (32 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

10.1.1.1/32    *[EVPN/7] 05:57:40
                    >  to 172.16.10.1 via ae1.0 
                       to 172.16.10.5 via ae2.0 

Verify that the device advertises EVPN Type 2 MAC-IP routes with the VRF_2 L3 context and the L3 transit VNI you configured for VRF_2.

From the configuration in Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices:

The vrf-target of MAC-VRF-1 is target:64512:1111.
The vrf-target for VRF_2 is target:62273:20000.
The route distinguisher for VRF_2 on Leaf 11 is 192.168.1.11:200.
The L3 transit VNI for EVPN Type 5 routing and symmetric Type 2 routing is 16777123.

content_copy zoom_out_map
user@leaf-10> show route table MAC-VRF-1.evpn.0 | match 10.1.1.1
2:192.168.1.11:200::20000::00:31:46:79:e4:9a::10.1.1.1/304 MAC/IP

user@leaf-10> show route table MAC-VRF-1.evpn.0 match-prefix 2:192.168.1.11:200::20000::00:31:46:79:e4:9a::10.1.1.1 extensive

MAC-VRF-1.evpn.0: 227 destinations, 417 routes (227 active, 0 holddown, 0 hidden)
2:192.168.1.11:200::20000::00:31:46:79:e4:9a::10.1.1.1/304 MAC/IP (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.1.11:200
                Next hop type: Indirect, Next hop index: 0
                Address: 0x74c2e14
                Next-hop reference count: 44424, key opaque handle: 0x0, non-key opaque handle: 0x0
                Source: 192.168.0.2 
                Protocol next hop: 192.168.1.11 
                Indirect next hop: 0x2 no-forward INH Session ID: 0
                State: <Secondary Active Ext>
                Peer AS: 4210000001
                Age: 6:00:19    Metric2: 0
                Validation State: unverified
         .
         .
         .
                Communities: target:62273:20000 target:64512:1111 encapsulation:vxlan(0x8) mac-mobility:0x1:sticky (sequence 0) router-mac:00:31:46:79:e4:9a
                Import Accepted
                Route Label: 20000
                Route Label: 16777123
                ESI: 00:00:00:00:00:00:00:00:00:00
                Localpref: 100
                Router ID: 192.168.0.2
                Primary Routing Table: bgp.evpn.0
                Thread: junos-main
                Indirect next hops: 1
                        Protocol next hop: 192.168.1.11 
                        Indirect next hop: 0x2 no-forward INH Session ID: 0
                        Indirect path forwarding next hops: 2
                                Next hop type: Router
                                Next hop: 172.16.10.1 via ae1.0
                                Session Id: 0
                                Next hop: 172.16.10.5 via ae2.0 
                                Session Id: 0
                                192.168.1.11/32 Originating RIB: inet.0
                                  Node path count: 1
                                  Forwarding nexthops: 2
                                        Next hop type: Router
                                        Next hop: 172.16.10.1 via ae1.0
                                        Session Id: 0
                                        Next hop: 172.16.10.5 via ae2.0
                                        Session Id: 0
         BGP    Preference: 170/-101
                Route Distinguisher: 192.168.1.11:200
                Next hop type: Indirect, Next hop index: 0
                Address: 0x74c2e14
         .
         .
         .

arrow_backward PREVIOUS Multihoming an Ethernet-Connected End System Design and Implementation

NEXT arrow_forward Routed Overlay Design and Implementation

Data Center EVPN-VXLAN Fabric Architecture Guide

ON THIS PAGE

Edge-Routed Bridging Overlay Design and Implementation

Configure an Edge-Routed Bridging Overlay on a Lean Spine Device

Verify the Edge-Routed Bridging Overlay on a Lean Spine Device

Configure an Edge-Routed Bridging Overlay on a Leaf Device

Verify the Edge-Routed Bridging Overlay on a Leaf Device

Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices

Verify Symmetric IRB Routing with EVPN Type 2 Routes on a Leaf Device

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry

Data Center EVPN-VXLAN Fabric Architecture Guide

ON THIS PAGE

Edge-Routed Bridging Overlay Design and Implementation

Configure an Edge-Routed Bridging Overlay on a Lean Spine Device

Verify the Edge-Routed Bridging Overlay on a Lean Spine Device

Configure an Edge-Routed Bridging Overlay on a Leaf Device

Verify the Edge-Routed Bridging Overlay on a Leaf Device

See Also

Configure Symmetric IRB Routing with EVPN Type 2 Routes on Leaf Devices

Verify Symmetric IRB Routing with EVPN Type 2 Routes on a Leaf Device

Related Documentation

Stay in touch