EVPN LAG Configuration Best Practices
Junos OS on QFX Series switches support Enterprise style configuration and Service Provider style configuration.
Both configuration styles can be used to configure EVPN LAGs. We recommend using the Enterprise configuration style because it supports more data center features like storm control profiles and BPDU blocking without having to enable RSTP on the leaf devices.
This section covers EVPN LAG configuration using both configuration styles.
EVPN LAG Configuration of a CRB Architecture Using the Enterprise Configuration Style
The Enterprise configuration style is the recommended way to enable EVPN LAG functionality in most data center architectures. Enterprise style provisioning is generally simpler than Service Provider style provisioning and generally is more compatible with other Layer 2 features.
The following configuration provides a sample EVPN LAG configuration done using the Enterprise configuration style on the leaf devices in a Centrally Routed Bridging architecture.
user@leaf_node1>show configuration interfaces ae0
esi {
00:33:33:33:33:33:33:33:33:01; a unique but same value at leafs connected to given server
all-active;
}
aggregated-ether-options {
lacp {
active;
system-id 00:33:33:33:33:01; a unique but same value at leafs connected to given server
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ 100-101 ]; the explicit vlan-ids enabled with vxlan - can’t be mixed with regular vlans on same ESI-LAG
}
}
}
user@leaf_node1> show configuration vlans
vlan100 {
vlan-id 100; value provisioned at the ESI-LAG interface in enterprise-mode
vxlan {
vni 50100;
}
}
vlan101 {
vlan-id 101;
vxlan {
vni 50101;
}
}
user@leaf_node1> show configuration interfaces et-0/0/50
description esi-lag-member-link;
ether-options {
802.3ad ae0;
}
user@leaf_node1> show configuration switch-options
vtep-source-interface lo0.0; lo0.0 must be in the global routing table
route-distinguisher 1.1.1.21:1; RD must be a unique value per leaf
vrf-import MY-FABRIC-IMPORT;
vrf-target target:1:5555;
root@dc-tme-qfx5110-1> show configuration protocols evpn
vni-options {
vni 10001 {
vrf-target target:1:100;
}
vni 10002 {
vrf-target target:1:101;
}
}
encapsulation vxlan;
multicast-mode ingress-replication;
default-gateway do-not-advertise;
extended-vni-list [ 50100 50101 ];
user@leaf_node1> show configuration policy-options policy-statement MY-FABRIC-IMPORT
term term1 {
from community MY-FAB-COMMUNITY;
then accept;
}
term term2 {
from community COM-VNI-50100;
then accept;
}
term term3 {
from community COM-VNI-50101;
then accept;
}
then reject;
user@leaf_node1> show configuration policy-options community MY-FAB-COMMUNITY
members target:1:5555;
user@leaf_node1> show configuration policy-options
policy-statement LB {
term term1 {
from protocol evpn;
then {
load-balance per-packet;
}
}
term term2 {
then {
load-balance per-packet;
}
}
}
policy-statement MY-FABRIC-IMPORT {
term term1 {
from community MY-FAB-COMMUNITY;
then accept;
}
term term2 {
from community ESI-SPINE;
then accept;
}
term term3 {
from community COM-VNI-50100;
then accept;
}
term term4 {
from community COM-VNI-50101;
then accept;
}
then reject;
}
policy-statement MY_VTEPS {
term term1 {
from {
route-filter 1.1.1.0/24 prefix-length-range /32-/32;
}
then accept;
}
then reject;
}
community COM-VNI-50100 members target:1:100;
community COM-VNI-50101 members target:1:101;
community MY-FAB-COMMUNITY members target:1:5555;
community SPINE-ESI members target:1:8888;
user@leaf_node1> show configuration protocols bgp
log-updown;
group overlay {
type internal;
local-address 1.1.1.21;
family evpn {
signaling;
}
vpn-apply-export;
local-as 64512;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
multipath;
neighbor 1.1.1.11;
neighbor 1.1.1.12;
}
group underlay {
type external;
export MY_VTEPS;
multipath multiple-as;
neighbor 10.10.19.1 {
peer-as 65511;
}
neighbor 10.10.21.1 {
peer-as 65512;
}
}
user@leaf_node1> show configuration interfaces et-0/0/48
description spine0_connected;
mtu 9216;
unit 0 {
family inet {
address 10.10.19.2/24;
}
}
user@leaf_node1> show configuration interfaces et-0/0/49
description spine1_connected;
mtu 9216;
unit 0 {
family inet {
address 10.10.21.2/24;
}
}EVPN LAG Configuration of a CRB Architecture Using the Service Provider Configuration Style
The QFX5110 switches also support the Service Provider style of configuration. When configuring EVPN LAGs in the Service Provider configuration style, multiple units per given EVPN LAG are assigned. These multiple units provide an opportunity to enable more selective filter and rate limiting per unit interface, but these assignments must be done on a per unit basis and are therefore burdensome to configure and maintain. This granularity is generally not needed in data center architectures using spine and leaf topologies, so we do not recommend using Service Provider style configuration when enabling EVPN LAGs in most data center environments.
The following configuration provides a sample EVPN LAG configuration done using the Service Provider configuration style. This configuration is supported when QFX5110 or QFX5120 switches are operating in the leaf device role in an architecture where the IRBs are not on the leaf devices, which are the Centrally Routed Bridging (CRB) and Bridged Overlay (BO) architectures. The Enterprise configuration style must be used to enable EVPN LAGs when a QFX5110 or QFX5120 switch is used as the leaf device in an Edge Routed Bridging (ERB) architecture.
user@leaf_node1> show configuration interfaces ae11
flexible-vlan-tagging;
encapsulation extended-vlan-bridge;
esi {
00:33:33:33:33:33:33:33:33:01;
all-active;
}
aggregated-ether-options {
lacp {
active;
periodic fast;
system-id 00:33:33:33:33:01;
}
}
unit 100 {
vlan-id 100;
}
unit 101 {
vlan-id 101;
}
<- Corresponding VxLAN - > VLAN Mapping
user@leaf_node1> show configuration vlans vlan100
interface ae11.100;
vxlan {
vni 50100;
}
{master:0}
user@leaf_node1> show configuration vlans vlan101
interface ae11.101;
vxlan {
vni 50101;
}