A VNI-aware-bundle represents a MAC-VRF that contains Layer 2 route entries from all VXLAN
Network Identifiers (VNI) available across multiple DCs. Use the
vni-aware-bundle command
available on CVX to create a MAC-VRF.
Use the rd (Router-BGP VRF and VNI Configuration Modes) command to add
a Route Distinguisher (RD) for uniquely identifying Layer 2 routes
for the VNI bundle. Use the route-target
command to configure a well-known extended community that is
attached to the routes exported by BGP-EVPN; and to import routes
with the specified well-known extended community into the MAC-VRF
that corresponds to the VNI bundle.
When BGP-EVPN module receives a route from its BGP peer, it generally tries to resolve the
next-hop indicated in the route. However, in the DCI topology, the
routes coming from a CVX in another DC contains next-hops (VTEP
addresses) that may not be reachable from the CVX receiving the
route. Use the next-hop resolution
disabled command to disable the next-hop
resolution on routes received from BGP-EVPN peers.
Note: CVX is a part of the control plane, and is only connected to the VTEPs in its own DC. It does
not have IP connectivity to the VTEPs in a different DC.
Use the redistribute bgp evpn VXLAN command to redistribute BGP-EVPN
routes to VCS, which, in turn advertises them to all VTEPs within
the DC.
Example
switch(config)# cvx
switch(config-cvx)# no shutdown
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# no shutdown
switch(config-cvx-VXLAN)# redistribute bgp evpn VXLAN
EVPN MPLS Virtual Private Wire Service (VPWS)
Traffic to/from a given Attachment Circuit (AC) without any MAC lookup/learning can be forwarded
using EVPN MPLS VPWS, which uses BGP for signalling. Port-based and VLAN-based services are
supported.
Configuring EVPN MPLS VPWS
Configure the patch panel to specify the ACs' connection to the VPWS service instances and
then the VPWS service instance, which is part of BGP. Finally, configure the individual
participating ACs.
Patch Panel Configuration
The following configures the local AC as Ethernet2 interface and
the remote VPWS service instance as evi-1 and
pseudowire
pw1.
The following configures the VPWS service instance with the BGP vpws
sub-mode. This defines an EVPN instance under which any number of VPWS service instances can
be configured. The BGP configuration itself can also define multiple EVPN instances under
multiple vpws blocks, each with a unique name and
Route-Distinguisher (RD) value. Only the mpls control-word and
mtuvalue configuration items are optional; the rest are required for
proper operation.
Note:It is strongly recommended that 'mpls control-word' is always enabled, when possible,
to avoid any potential mis-forwarding where the PWE frames may be incorrectly interpreted as
having an IP, as opposed to Ethernet, payload.
The following configures the AC in Flexible Encapsulation mode. The
client after 'network' preserves the corresponding client
encapsulation
specification.
Flexible encapsulation enables the following
actions for tags.
Remove incoming encapsulation tag(s) and forward.
Preserve incoming encapsulation tag(s) and forward.
Replace one or two tags when forwarding in encapsulation and decapsulation
directions.
The following table explains the encapsulation and decapsulation behaviors for
the various FlexEncap options. Applying a Flexible Encapsulation with a
network specification to a subinterface creates a bidirectional mapping
table that is applied to the sub-interface. The mapping embodied in this table is applied
from client to network in the encap direction, and
network to client in the decap direction.
Example
Behavior
client dot1q 10
From Client: match VLAN ID 10, consume and forward
To Client: add VLAN ID 10 before transmit
client dot1q 10 inner
20
From Client: match VLAN IDs 10, 20 consume and forward
To Client: add VLAN ID 10, 20 before transmit
client dot1q 10
network client
From Client: match VLAN ID 10 and retain it.
From Network: match vlan=10, retain.
client dot1q outer 10
inner 20 network client
From Client: match VLAN IDs 10, 20 and retain both.
From Network: match vlan=10,20, retain both.
client dot1q 10 network dot1q
100
client dot1q 10
network dot1q 100
From Client: match VLAN ID 10, consume. Before forwarding, write
vlan=100.
From Network: match vlan=100, consume. Before transmit, write
vlan=10.
This command shows both the client encapsulation and network encapsulation configured on
sub-interfaces.
switch(config-if-Et3/1.1003)# show interfaces encapsulation vlan
Interface Status Client Encapsulation Network Encapsulation
------------------------- ------------ ---------------------------------------------------
Ethernet3/1.1000 active dot1q outer 1000
Ethernet3/1.1001 active dot1q outer 1001 client
Ethernet3/1.1002 active dot1q outer 1002 inner 102
Ethernet3/1.1003 active dot1q outer 1003 inner 103 client
Ethernet3/1.1004 active dot1q outer 1004 dot1q 2004
Ethernet3/1.1005 active dot1q outer 1005 inner 104 dot1q outer 2005 inner 204
This command shows output of a patch with sub-interface as the local connector and VPWS as
the remote
connector.
switch(config-if-Et3/1.1003)# show patch panel PP_1000
Patch Connector Status
------- ------------------------------------- ------
PP_1000 1: Ethernet3/1.1000 Up
2: BGP VPWS VPWS_1 Pseudowire PW_1000
tg481.12:19:52(s2)(config-if-Et3/1.1003)#show patch panel PP_1000 detail
PW Fault Legend:
ET-IN - Ethernet receive fault
ET-OUT - Ethernet transmit fault
TUN-IN - Tunnel receive fault
TUN-OUT - Tunnel transmit fault
NF - Pseudowire not forwarding (other reason)
Patch: PP_1000, Status: Up
Connector 1: Ethernet3/1.1000
Status: Up
Connector 2: BGP VPWS VPWS_1 Pseudowire PW_1000
Status: Up
Local MPLS label: 135363
MTU: 1600, Control word: Y
Neighbor 103.37.123.72, MPLS label: 136350
Tunnel type: SR-TE Policy, Tunnel index: 132
MTU: 1600, Control word: Y
EVPN VPWS type: VLAN-based
Tag Matching Semantics
The matching rules are applied on a 'longest matching tag sequence' basis when rules are
configured for multiple subinterfaces of a parent port. Considering the following rules on
the same parent, the receive (encap) and transmit (decap) rule application is shown in the
following tables.
Enter the routing control functions configuration mode and then the control-functions
configuration mode:
switch(config)# router general
switch(config-router-general)# control-functions
switch(config-router-general-control-functions)#
Finally, add the JSON code to the configuration:
switch(config-router-general-control-functions)# code
Enter RCF code. Type 'EOF' on its own line to end.
function evpnDciMhBlockGwTx() {
if evpn.route_type is EVPN_IMET
{
community add {1:1};
}
return true;
}
function evpnDciMhBlockGwRx() {
return community has_none {1:1};
}
EOF
Displaying the Multihome EVPN Configuration
To display your configuration, use the show active command from the BGP configuration mode:
GW-A1(config-router-bgp)# show active
router bgp 64512
...
maximum-paths 4 ecmp 4
bgp bestpath d-path
...
!
vlan 10
rd evpn domain all 10.255.1.1:10
route-target import export 64500:10
route-target import export evpn domain remote 64501:10
redistribute learned
!
vrf red
rd 10.255.1.1:0
route-target import evpn 64500:20000
route-target export evpn 64500:20000
router-id 10.255.1.1
...
address-family evpn
neighbor WAN-RR activate
neighbor WAN-RR domain remote
neighbor RR-A activate
neighbor RR-A rcf in evpnDciMhBlockGwRx()
neighbor RR-A rcf out evpnDciMhBlockGwTx()
neighbor WAN-RR rcf in evpnDciMhBlockGwRx()
neighbor WAN-RR rcf out evpnDciMhBlockGwTx()
domain identifier 1:1
domain identifier 1:2 remote
...
!
evpn ethernet-segment domain local
identifier 0011:1111:1111:1111:1111
route-target import 11:11:11:11:11:11
!
evpn ethernet-segment domain remote
identifier 0022:2222:2222:2222:2222
route-target import 22:22:22:22:22:22
!
layer-2 fec in-place update
!
router general
control-functions
code
function evpnDciMhBlockGwTx() {
if evpn.route_type is EVPN_IMET
{
community add {1:1};
}
return true;
}
function evpnDciMhBlockGwRx() {
return community has_none {1:1};
}
The sample configuration displays the following parameters:
An interconnect Ethernet segment with an Ethernet Segment Identifier (ESI), 1111:1111:1111:1111:, configured for
the hosts sourced from the local domain.
An interconnect Ethernet segment with an ESI, 2222:2222:2222:2222, configured for the hosts sourced for the remote
domain.
The gateway, GW-A1, peers with a route reflector, the RR-A in the local
domain, and peers with a route reflector, WAN-RR, in the remote
domain.
For route loop detection, configure domain identifiers for the local and remote
domain, and the domain path best path. Use the same identifier for the same domain
on all gateways in one site, and configure RCF rules to reject the IMET routes from
peer gateways in the same DC.
Configuring iBGP PE-CE Protocol for BGP/EVPN L3 VLANs
Before configuring iBGP, configure BGP EVPN VPN routing with the following commands:
The command, local-as, configures the AS number, and if omitted, the VRF assumes the same AS number as the global BGP configuration.
The command, neighbor 10.11.0.2 remote-as 1000 sets the remote AS to the same number as the local AS. The third command,
neighbor 10.11.0.2 route-reflector-client, allows the CE to receive updates from the PE as the route reflector client. The last
command, neighbor 10.11.0.2 route-reflector-client, must be included for each configured address family in order to save
and restore CE attributes during export or import operations. This is disabled by default.
Note: Configure the AS number for the VRF and not for a single peer. Importing paths
requires this parameter.
Displaying iBGP PE-CE Protocol Information
EOS adds a new parameter in the output, evpnprefixdetail to display the
ATTR_SET, code 128 attributes.
switch#show bgp evpn
BGP routing table information for VRF default
Router identifier 10.11.0.1, local AS number 300
BGP routing table entry for ip-prefix 172.10.11.12/24, Route Distinguisher: 100:1
Paths: 1 available
Local
- from - (0.0.0.0)
Origin IGP, metric -, localpref -, weight 0, valid, internal, best
Extended Community: Route-Target-AS:100:1 TunnelEncap:tunnelTypeMpls
Rx path id: 0x0
MPLS label: 100000
Customer attributes (Origin ASN 1000)
Origin IGP, metric -, localpref 150, internal
Community: 47872:6 47872:6939
On the multi-homing Provider Edges (PEs), you must configure the Ethernet Segment (ES) to
the Customer Edge (CE). In addition, the configuration needed for asymmetric Integrated
Routing and Bridging (IRB) or symmetric IRB must be configured on the local and remote
PEs.Figure 1. Asymmetric IRB with IPv4
Configuring the Example Topology
In the example, CE1 is a multi-homed CE in
VLAN20 with CE2 as a remote
CE in VLAN30, and an asymmetric IRB configured for inter-VLAN
traffic.
The Ethernet segment to the multi-homed CE is configured on the port channel interface
Port-Channel 100. SVI 20 and
SVI 30 along with VARP IP are configured for
inter-subnet routing. PE1 has a VARP MAC configured
globally. The configuration on PE2 is similar to the
previous configuration. On PE3, configure SVI
20 and SVI 30 with the VARP IP and
VARP MAC.
Configure the Ethernet segment to the multi-homed CE1 on the
port channel interface Port-Channel 100. Configure
SVI 20 with the VARP IP and VARP MAC. Also,
configure the IP VRF for symmetric IRB. PE2 has a similar
configuration. On PE3, IP VRF and SVI
30 are configured for symmetric IRB.
Configuring the VXLAN
A network with two VRFs, red and blue
has VLANs 10 and 20 in
red and VLANs 30 and
40 in blue. The spines
act as a route reflectors. Multicast groups encapsulate traffic arriving in a VRF
and deliver it to VTEPs with VRF provisioned.
switch(config)# interface loopback 0
switch(config-if-Lo0)# ip address 10.0.0.20/32
!
switch(config)# vlan 10
switch(config)# vlan 20
switch(config)# vlan 30
switch(config)# vlan 40
!
switch(config)# interface ethernet 2/1
switch(config-if-Et2/1)# switchport access vlan 10
!
switch(config)# interface ethernet 2/2
switch(config-if-Et2/2)# switchport access vlan 20
!
switch(config-if-Et2/2)# interface ethernet 2/3
qzd496.01:05:52(config-if-Et2/3)# switchport access vlan 30
!
switch(config)# interface ethernet 2/4
switch(config-if-Et2/4)# switchport access vlan 40
!
switch(config)# interface vlan 10
switch(config-if-Vl10)# vrf red
switch(config-if-Vl10)# ip address virtual 192.168.1.1/24
switch(config-if-Vl10)# ip igmp
switch(config-if-Vl10)# pim ipv4 local-interface loopback 0
!
switch(config)# interface vlan 20
switch(config-if-Vl20)# vrf red
switch(config-if-Vl20)# ip address virtual 192.168.2.1/24
switch(config-if-Vl20)# ip igmp
!
switch(config)# interface vlan 30
switch(config-if-Vl30)# vrf blue
switch(config-if-Vl30)# ip address virtual 192.168.1.1/24
switch(config-if-Vl30)# ip igmp
!
switch(config)# interface vlan 40
switch(config-if-Vl40)# vrf blue
switch(config-if-Vl40)# ip address virtual 192.168.1.2/24
switch(config-if-Vl40)# ip igmp
!
switch(config)# interface vxlan 1
switch(config-if-Vx1)# vxlan source-interface loopback 0
switch(config-if-Vx1)# vxlan vlan 10 vni 10
switch(config-if-Vx1)# vxlan vlan 20 vni 20
switch(config-if-Vx1)# vxlan vlan 30 vni 30
switch(config-if-Vx1)# vxlan vlan 40 vni 40
switch(config-if-Vx1)# vxlan vrf red vni 100
switch(config-if-Vx1)# vxlan vrf blue vni 200
switch(config-if-Vx1)# vxlan vlan 10 flood group 225.1.1.2
switch(config-if-Vx1)# vxlan vlan 20 flood group 225.1.1.3
switch(config-if-Vx1)# vxlan vlan 30 flood group 226.1.1.2
switch(config-if-Vx1)# vxlan vlan 40 flood group 226.1.1.3
switch(config-if-Vx1)# vxlan vrf red multicast group 225.1.1.1
switch(config-if-Vx1)# vxlan vrf blue multicast group 226.1.1.1
!
Displaying ECPN VXLAN Information
The following examples are based on the sample topology and configuration in the previous
sections.
On the remote VTEP, to display the EVPN routes to the multi-homed CE
(20.0.20.2):
switch# show bgp evpn route-type mac-ip 20.0.20.2
BGP routing table information for VRF default
Router identifier 0.0.3.1, local AS number 302
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head,
e - ECMP S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > RD: 10.255.0.0:20 mac-ip 0000.0101.0000 20.0.20.2
10.255.0.0 - 100 0 303 300 i
* > RD: 10.255.0.1:20 mac-ip 0000.0101.0000 20.0.20.2
10.255.0.1 - 100 0 303 301 i
As shown above, there are two EVPN MAC-IP routes for the multi-homed CE.
On the remote PE, to display the installed routes to the multi-homed
CE:
switch# show ip route vrf red 20.0.20.2/32
VRF: red
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked
B E 20.0.20.2/32 [200/0] via VTEP 10.255.0.0 VNI 20000 router-mac 00:00:78:01:00:00
via VTEP 10.255.0.1 VNI 20000 router-mac 00:00:78:04:00:00
Two routes to the multi-homed CE install from the two EVPN MAC-IP routes and form the L3
ECMP.
On the remote PE, to check the details of the two routes in BGP
RIB:
switch# show ip bgp 20.0.20.2/32 vrf red
BGP routing table information for VRF red
Router identifier 10.255.0.2, local AS number 302
BGP routing table entry for 20.0.20.2/32
Paths: 2 available
303 300
10.255.0.0 from 10.0.2.1 (0.0.1.1), imported EVPN route, RD 10.255.0.0:20
Origin IGP, metric 0, localpref 100, IGP metric 0, weight 0, received 00:14:43 ago,
valid, external, ECMP head, ECMP, best, ECMP contributor
Extended Community: Route-Target-AS:64500:10020 Route-Target-AS:64500:20000
TunnelEncap:tunnelTypeVXLAN EvpnMacMobility:1 EvpnRouterMac:00:00:78:01:00:00
Remote VNI: 20000
Rx SAFI: Unicast
303 301
10.255.0.1 from 10.0.2.1 (0.0.1.1), imported EVPN route, RD 10.255.0.1:20
Origin IGP, metric 0, localpref 100, IGP metric 0, weight 0, received 00:14:43 ago,
valid, external, ECMP, ECMP contributor
Extended Community: Route-Target-AS:64500:10020 Route-Target-AS:64500:20000
TunnelEncap:tunnelTypeVXLAN EvpnMacMobility:1 EvpnRouterMac:00:00:78:04:00:00
EvpnNdFlags:pflag
Remote VNI: 20000
Rx SAFI: Unicast
The second route has EvpnNdFlags:pflag and indicates
a proxy MAC-IP route.
This command shows information about the SBD instance created when configuring an
evpn multicast for an IP
VRF:
switch# show bgp evpn instance sbd red
EVPN instance: SBD red
Route distinguisher: 100:1
Service interface: VLAN-based
Local IP address: 10.0.0.20
Encapsulation type: VXLAN
vtep2#show bgp evpn instance sbd blue
EVPN instance: SBD red
Route distinguisher: 200:1
Service interface: VLAN-based
Local IP address: 10.0.0.20
Encapsulation type: VXLAN
The OISM supported capability is set in IMET routes for the SBD when evpn
multicast is configured for a VRF. The IGMP proxy flag is not set in IMET
routes for VLANs in the VRF unlessredistribute igmp is configured in
a
VLAN:
switch# show bgp evpn route-type imet next-hop 10.0.0.10 detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for imet 10.0.0.10, Route Distinguisher: 10:1
Paths: 1 available
Local
10.0.0.10 from 10.0.0.1 (0.0.1.1)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Extended Community: Route-Target-AS:10:1 TunnelEncap:tunnelTypeVXLAN
VNI: 10
PMSI Tunnel: PIM-SSM Tree, MPLS Label: 10, Leaf Information Required: false,
Tunnel ID: 10.0.0.10, 225.1.1.2
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for imet 10.0.0.10, Route Distinguisher: 100:1
Paths: 1 available
Local
10.0.0.10 from 10.0.0.1 (0.0.1.1)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Extended Community: Route-Target-AS:100:1 TunnelEncap:tunnelTypeVXLAN Multicast
Flags: IGMP proxy, OISM-supported, SBD
VNI: 100
PMSI Tunnel: Ingress Replication, MPLS Label: 100, Leaf Information Required: false,
Tunnel ID: 10.0.0.10
This command shows information about the single SMET route for the group with the RD of
VRF
red:
switch# show bgp evpn route-type smet multicast 228.1.1.1
BGP routing table information for VRF default
Router identifier 0.0.1.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > RD: 100:1 smet (S, G): (*, 228.1.1.1) originating IP: 10.0.0.10
10.0.0.10 - 100 0 i
* > RD: 100:1 smet (S, G): (*, 228.1.1.1) originating IP: 10.0.0.20
- - - 0 i
* > RD: 100:1 smet (S, G): (*, 228.1.1.1) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 200:1 smet (S, G): (*, 228.1.1.1) originating IP: 10.0.0.20
- - - 0 i
* > RD: 200:1 smet (S, G): (*, 228.1.1.1) originating IP: 10.0.0.40
10.0.0.40 - 100 0 i
This command shows information about the SPMSI route for the
group:
switch# show bgp evpn route-type spmsi
BGP routing table information for VRF defaultRouter identifier 0.0.0.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > RD: 10:1 spmsi (S, G): (*, *) originating IP: 10.0.0.10
10.0.0.10 - 100 0 i
* > RD: 10:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 20:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 30:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 40:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 10:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 20:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 30:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 40:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 30:1 spmsi (S, G): (*, *) originating IP: 10.0.0.40
10.0.0.40 - 100 0 i
* > RD: 100:1 spmsi (S, G): (*, *) originating IP: 10.0.0.10
10.0.0.10 - 100 0 i
* > RD: 100:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 200:1 spmsi (S, G): (*, *) originating IP: 10.0.0.20
- - - 0 i
* > RD: 100:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 200:1 spmsi (S, G): (*, *) originating IP: 10.0.0.30
10.0.0.30 - 100 0 i
* > RD: 200:1 spmsi (S, G): (*, *) originating IP: 10.0.0.40
10.0.0.40 - 100 0 i
Configuration Considerations
The EVPN VXLAN all-active multi-homing integrated routing and bridging feature has the
following limitations:
L2 loop-free protocols, such as Spanning Tree Protocol (STP) are not supported
between PE-CE with EVPN VXLAN All-Active Multi-homing. The topology must be
loop-free. STP must be disabled for the Multihomed VLANs on PEs and
CEs.
A limit of two multi-homing destinations are installed at one time for any
particular MAC address. Any other valid destinations are ignored in the context
of switching unicast traffic, until one of the active destinations is removed.
The multi-homing PEs operate normally regardless of the number of PEs on the
ethernet segment; this limitation only affects the selection of a destination
for unicast traffic.
VXLAN GPE is not supported, so packets cannot be flagged as having been
broadcast. As a result, unicast packets that are known at the sender and unknown
at the receiver are dropped if the receiving PE is not a designated forwarder.
Similarly, unicast packets that are unknown at the sender and known at the
receiver are duplicated at the receiving CE. This state automatically resolves
itself as the BGP network distributes the appropriate type 1 auto-discovery and
type 2 MAC/IP advertisement EVPN routes.
Fast mass withdrawal is not supported, so there may be a delay if an interface
harboring a large number of MAC addresses goes down.
Flood Traffic Filtering with EVPN
The VXLAN fabric managed by EVPN does not always flood with broadcast, multicast, or
unknown MAC traffic. Sometimes, ARP request broadcast and Neighbor Discovery (ND)
multicast traffic flood the VXLAN fabric as well. There may be other cases where
flooding ARP plus other traffic is allowed, but not all broadcast traffic into the
fabric.
Most of the ARPs are learned through EVPN, and for some cases where the ARP is not
learned through EVPN, it is acceptable to flood such ARP requests. However, you should
rate limit the ARP flooding going into the VXLAN fabric.
Configuring Flood Traffic Filtering with EVPN
The default command disables flooding of different kinds of traffic into the VXLAN
fabric to restrict only ARP and ND traffic flooding.
The following command enables flooding of ARP packets into the VXLAN fabric
again.
switch(config-rtr-l2-vpn)# arp flooding
The above command starts flooding ARP traffic into the VXLAN fabric while all other
traffic including ND traffic is prevented from getting flooded into the fabric. The
following command enables flooding of ND
traffic.
switch(config-rtr-l2-vpn)# nd flooding
Note: These commands are in effect only when EVPN is enabled. ARP & ND flooding are
enabled by default.
Displaying VXLAN Counters
The show VXLAN counters software command shows the number
of ARP and ND packets that were prevented from getting flooded into the VXLAN
fabric.
switch# show VXLAN counters software
. . . . . . . .
Tx pkts after IPv6 encapsulation : 0
SW pkts forwarded to remote VTEPs via HW HER : 4
SW pkts forwarding to remote VTEPs via HW HER failed : 0
Packets suppressed from getting flooded : 0
