Example: Configuring VNI Route Targets Manually
This example shows how to manually set route targets for multiple virtual network identifiers (VNIs) in an EVPN-VXLAN topology.
Requirements
This example uses the following hardware and software components:
-
A QFX Series switch.
Overview
If you configure the vrf-target statement with the
auto option, the device automatically derives route targets in
a routing instance. You can also configure vrf-target with a
specific target value to configure a route
target manually in a routing instance.
In this example we show how to configure route targets manually by specifying a
target value. You can manually configure
route targets using the vrf-target statement at the following
levels:
-
Global level—For all VNIs extended in a routing instance.
This setting applies to all EVPN route types.
-
vni-optionslevel—For a specific VNI in a routing instance.This setting applies only to EVPN Type 2 and Type 3 routes. With this setting:
-
If you also manually configure a route target at the global level, for the specified VNIs, this setting overrides the global setting.
-
If you also set the
autooption to auto-derive route targets, for the specified VNIs, this setting overrides the auto setting.
-
Table 1 shows the corresponding CLI hierarchies in which you can manually configure a route target:
| Configuration Level | Default Switch Instance Hierarchy | Configured Routing Instance Hierarchy | Applicable EVPN Route Types |
|---|---|---|---|
|
Global (all VNIs) in Routing Instance |
|
|
All EVPN Route Types |
|
Specified VNI in Routing Instance |
|
|
Type 2 Type 3 |
We include sample configurations at each level later.
Notes for Manual Route Target Configuration
See the following notes when planning to configure route targets manually.
Use Limited, Stable Route Targets for Large-Scale EVPN-VXLAN Networks
The EVPN devices in an EVPN-VXLAN network advertise Ethernet segment (ES), VLAN, and VNI reachability information to each other using EVPN Type 1 (Auto-discovery per Ethernet VPN instance [AD/EVI]) routes with route target communities.
The EVPN Type 1 routes can only carry a limited number of route targets.
Large-scaled networks can have many Ethernet segment identifiers (ESIs), VLANs,
and route targets per bridge domain. In the EVPN instance, if you configure
vrf-export policies at the [edit
switch-options] hierarchy level that add many route targets to the
EVPN Type 1 route community attribute, the advertisement can exceed the maximum
BGP protocol message size. In that case, the BGP protocol processing on the
device drops the EVPN Type 1 route advertisement, so the other EVPN devices
don’t receive the route. You see the EVPN Type 1 route locally but not on the
remote EVPN peers.
You can avoid this problem if you design your EVPN-VXLAN network so the EVPN Type 1 routes only need to carry a small, stable set of route targets.
Instead of using a vrf-export policy with many route
targets:
- Configure a single
vrf-targetfor the EVPN instance. - Use a
vrf-importpolicy withpolicy-optionsto control which route targets each bridge domain or tenant imports.
For example, see the Leaf-1 step-by-step configuration for the
vrf-import policy in this full configuration example: Example: Configure an EVPN-VXLAN Centrally-Routed Bridging Fabric Using MX Routers as Spines.
The EVPN Type 1 routes only contain the common VRF route target and any other required encapsulation communities. With this model, you can scale your network while keeping BGP EVPN protocol messages within message size limits.
Configuration
This section shows some use cases to manually configure VNI route targets at the supported configuration levels.
- Configure VNI Route Targets Manually for all VNIs in the Default Switch Instance
- Configure VNI Route Targets Manually for all VNIs and Specific VNIs in a MAC-VRF EVPN Instance
Configure VNI Route Targets Manually for all VNIs in the Default Switch Instance
Step-by-Step Procedure
This procedure shows how to configure a route target manually for all VNIs in the default switch instance. This is a global level manual route target configuration.
-
At the
[edit switch-options]hierarchy level, configure thevtep-source-interfaceandroute-distiguisherstatements. Next, configure thevrf-targetstatement with atargetvalue. All EVPN routes for all VLANs and corresponding VNIs will use thevrf-targetaddress configured in this step.[edit switch-options] user@switch# set vtep-source-interface lo0.0 user@switch# set route-distinguisher 192.168.1.11:1 user@switch# set vrf-target target:1111:11
Note:You can optionally include
vrf-importandvrf-exportpolicies to further distinguish the routes to import and export that match the route target. See Notes for Manual Route Target Configuration for some best practices when usingvrf-exportpolicies. -
At the
[edit protocols evpn]hierarchy level, configure EVPN with VXLAN encapsulation, and specify the VNIs you want to extend into the EVPN instance. In this example, we configure theextended-vni-liststatement with thealloption to apply the route target to all VNIs.[edit protocols evpn] user@switch# set encapsulation vxlan user@switch# set extended-vni-list all
Results
After following the steps above and committing the configuration, use the
show configuration command to verify the results of
your configuration.
user@switch> show configuration switch-options
vtep-source-interface lo0.0;
route-distinguisher 192.168.1.11:1;
vrf-target {
target:1111:11;
}
user@switch> show configuration protocols evpn
encapsulation vxlan;
extended-vni-list all;
.
.
.
Configure VNI Route Targets Manually for all VNIs and Specific VNIs in a MAC-VRF EVPN Instance
Step by Step Procedure
This procedure shows how to configure a route target manually in an
EVPN-VXLAN fabric for all VNIs in a MAC-VRF instance (MAC-VRF1) with the
vlan-aware service type. We also manually configure a
different route target specifically for VNI 100 in the same instance.
-
At the
[edit routing-instances MAC-VRF1]hierarchy level, configure the routing instance with themac-vrfinstance type and service typevlan-aware. Set thevtep-source-interfaceandroute-distiguisherstatements for the instance. Manually configure avrf-targetvalue at the global level in the routing instance. This global level route target corresponds to EVPN Type 1, Type 2, and Type 3 routes for the VNIs you extend into the EVPN instance (see the next step).[edit routing-instances MAC-VRF1] user@switch# set vtep-source-interface lo0.0 user@switch# set instance-type mac-vrf user@switch# set service-type vlan-aware user@switch# set route-distinguisher 192.168.2.11:1 user@switch# set vrf-target target:1111:11
-
At the
[edit routing instances MAC-VRF1 protocols evpn]hierarchy level, configure EVPN with VXLAN encapsulation. List the VNIs you want to extend into the EVPN instance using theextended-vni-liststatement. In this example, we list two VNIs, 100 and 101. We also configure an export route target value at the[edit routing-instances name protocols evpn vni-options vni vni]hierarchy level specifically for VNI 100. As a result, the route target you set the previous step applies to any EVPN Type 1 routes and only to VNI 101 for EVPN Type 2 and Type 3 routes. The VNI level route target you set in this step applies to VNI 100 for EVPN Type 2 and Type 3 routes.[edit routing instances MAC-VRF1 protocols evpn] user@switch# set encapsulation vxlan user@switch# set extended-vni-list 100 101 user@switch# set vni-options vni 100 vrf-target export target:1234:11
You can optionally include vrf-import and
vrf-export policies to further distinguish the
routes to import and export that match the route target.
Results
After following the steps above and committing the configuration, use the
show configuration command to verify the results of
your configuration.
user@switch> show configuration routing-instances MAC-VRF1
vtep-source-interface lo0.0;
instance-type mac-vrf;
service-type vlan-aware;
route-distinguisher 192.168.2.11:1;
vrf-target {
target:1111:11;
}
protocols {
evpn {
encapsulation vxlan;
extended-vni-list 100 101;
vni-options {
vni 100 {
vrf-target export target:1234:11;
}
}
}
}
.
.
.