BGP for EVPN¶
This chapter explains how to configure EVPN routing and bridging services. To be able
to perform EVPN, the core technology relies on a VXLAN interface bridged with a
bridge interface. The VXLAN interface link-interface must be on the same VRF where
the backbone is, that is to say, the main vrf. Also, you can note that you have to
colocate both VXLAN and bridge interfaces on the same VRF. There is no other
restriction regarding which VRF both interfaces should be. Regarding the VXLAN
interface, VNI value will be configured. The destination IP address of the VXLAN
interface does not need to be configured, as BGP will configure its own destination
IP on the underlay.
The configured VXLAN and bridge interfaces will be used by BGP to discover which
VNI is present on the device, and which information to send to remote peers.
EVPN common configuration¶
In EVPN, BGP must be configured to learn VNIs of local VXLAN interfaces, as follows:
vsr running config# vrf main
vsr running vrf main# routing
vsr running routing# bgp
vsr running bgp#! as 65500
vsr running bgp# address-family
vsr running address-family# l2vpn-evpn
vsr running l2vpn-evpn# advertise-all-vni true
vsr running l2vpn-evpn# ..
Note
Only default L3VRF BGP instance can be configured with advertise-all-vni,
and can exchange EVPN information with remote peers.
The following configuration activates EVPN for the 10.125.0.2 neighbor.:
vsr running config# vrf main
vsr running vrf main# routing bgp
vsr running bgp# neighbor 10.125.0.2 remote-as 65500
vsr running bgp# neighbor 10.125.0.2 address-family l2vpn-evpn
vsr running l2vpn-evpn# enabled true
vsr running l2vpn-evpn#
Note
It is not necessary to enable advertise-all-vni keyword when configuring a
route-reflector-server.
To operate in either mode, a bridged VXLAN interface needs to be configured.
All bridged vxlan interfaces located on the VRF, and with link-interface or
link-vrf set to the default L3VRF will be discovered.
The below figure illustrates what is EVPN routing mode and EVPN bridging mode. As can
be seen, two pe devices are interconnected with EVPN. On each device, a VXLAN
interface and a bridged interface are linked together, as well as an ethernet port
connected to localhost devices. Two data flows are illustrated. The blue data flow stands
for L2 connectivity: data traffic is bridged from ethernet port to vxlan port. The
green data flow stands for L3 routing mode: data traffic from network B is redirected
to the gateway in rt2.
Note
The scheme reuses the same VXLAN interface, but practically, it is necessary to create a VXLAN interface for each kind of connectivity.
BGP evpn use case example¶
EVPN routed configuration¶
For the routing service, it is recommended to configure a bridged VXLAN interface
on a separate L3VRF. Its L3 VNI value must be declared as follows. also a
separate BGP instance must be declared to on the given L3VRF. That instance will
import routing information from the L3VRF.
vsr running vrf main# interface physical eth0
vsr running physical eth0#! port pci-b0s5
vsr running physical eth0# ipv4 address 10.125.0.1/24
vsr running physical eth0# .. ..
vsr running vrf main# interface vxlan vxlan2
vsr running vxlan vxlan2#! vni 102
vsr running vxlan vxlan2# local 10.125.0.1
vsr running vxlan vxlan2# link-interface eth0
vsr running vxlan vxlan2# .. ..
vsr running vrf main# l3vrf customer1
vsr running l3vrf customer1#! table-id 10
vsr running l3vrf customer1# interface physical eth2
vsr running physical eth2#! ipv4 address 10.51.0.100/24
vsr running physical eth2#! port pci-b0s3
vsr running physical eth2# .. ..
vsr running l3vrf customer1# interface bridge bridge2
vsr running bridge bridge1# link-interface vxlan2
vsr running bridge bridge1# ipv4 address 10.51.0.100/32
vsr running bridge bridge1# .. ..
vsr running l3vrf customer1# routing bgp
vsr running bgp# l3vni 102
vsr running bgp# address-family ipv4-unicast
vsr running ipv4-unicast# redistribute connected
vsr running ipv4-unicast# .. ..
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# advertise ipv4-unicast
vsr running l2vpn-evpn#
BGP route distribution for routed services¶
In order to choose how to interconnect EVPN domains together, Virtual Service Router permits to
configure an RD and RTs on a given L3 domain. The below configurations
shows how to reconfigure RD for an L3 VNI:
vsr running config# vrf main
vsr running vrf main# l3vrf customer1
vsr running l3vrf customer1# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# export route-distinguisher 65500:102
The below configurations shows how to configure RTs for an L3 VNI:
vsr running config# vrf main
vsr running vrf main# l3vrf customer1
vsr running l3vrf customer1# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# export route-target 65500:102
vsr running l2vpn-evpn# import route-target 65500:102
You can also let the RT be auto derivated from AS and VNI values like indicated in RFC 8365 in section 5.1.2.1.
vsr running config# vrf main
vsr running vrf main# l3vrf customer1
vsr running l3vrf customer1# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# del export route-target 65500:102
vsr running l2vpn-evpn# del import route-target 65500:102
vsr running l2vpn-evpn# auto-route-target rfc8365
The auto-configured RTs values can be dumped for a given VPN with the following command:
vsr> show bgp l2vpn evpn vni 102 vrf main
VNI: 102 (known to the kernel)
Type: L3
Tenant VRF: customer1
RD: 65500:102
Originator IP: 10.125.0.1
Advertise-gw-macip : n/a
Advertise-svi-macip : n/a
Advertise-pip: Yes
System-IP: 10.125.0.1
System-MAC: 76:9f:2c:82:79:41
Router-MAC: 76:9f:2c:82:79:41
Import Route Target:
65500:268435558
Export Route Target:
65500:268435558
Getting EVPN information¶
To get information about the VXLAN interfaces detected, classified per VNI, the following command can be used to dump the contexts.
vsr> show evpn vni all
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
102 L3 vxlan2 0 0 n/a customer1
The below example shows detailed information about L3 VNI.
vsr> show evpn vni 102
VNI: 102
Type: L3
Tenant VRF: customer1
Local Vtep Ip: 10.125.0.1
Vxlan-Intf: vxlan2
SVI-If: bridge2
State: Up
VNI Filter: none
System MAC: e6:78:32:83:8e:9f
Router MAC: e6:78:32:83:8e:9f
L2 VNIs:
To get information about the BGP information exchanged, the following command dumps the
BGP prefixes exchanged. BGP prefixes are emphasized. Each entry stands for an EVPN
route entry. The first number stands for the kind of information shared, ie the route type.
5 stands for EVPN RT2 route type. The tunnel endpoint can be seen here with the
next hop information. As depicted below, 10.125.0.3 is the tunnel endpoint.
vsr> show bgp l2vpn evpn
BGP table version is 3, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65500:102
*> [5]:[0]:[24]:[10.51.0.0]
10.125.0.1 0 32768 ?
ET:8 RT:65500:268435558 Rmac:76:9f:2c:82:79:41
*> [5]:[0]:[32]:[10.51.0.100]
10.125.0.1 0 32768 ?
ET:8 RT:65500:268435558 Rmac:76:9f:2c:82:79:41
Route Distinguisher: 65500:103
*> [5]:[0]:[24]:[10.52.0.0]
10.125.0.3 0 32768 ?
ET:8 RT:65500:268435558 Rmac:0a:16:46:ff:64:eb
*> [5]:[0]:[32]:[10.152.0.1]
10.125.0.3 0 32768 ?
ET:8 RT:65500:268435558 Rmac:0a:16:46:ff:64:eb
Displayed 4 out of 4 total prefixes
EVPN bridged configuration¶
For bridging services, the bridge VXLAN interface can be on the default L3VRF.
vsr running vrf main# interface physical eth0
vsr running physical eth0#! port pci-b0s5
vsr running physical eth0# ipv4 address 10.125.0.1/24
vsr running physical eth0# .. ..
vsr running vrf main# interface physical eth1 port pci-b0s4
vsr running vrf main# interface vxlan vxlan1
vsr running vxlan vxlan1#! vni 100
vsr running vxlan vxlan1# local 10.125.0.1
vsr running vxlan vxlan1# learning true
vsr running vxlan vxlan1# .. ..
vsr running vrf main# interface bridge bridge1
vsr running bridge bridge1# ipv4 address 10.50.0.100/24
vsr running bridge bridge1# link-interface vxlan1
vsr running bridge bridge1# link-interface eth1
vsr running bridge bridge1#
BGP route distribution for bridged services¶
In order to choose how to interconnect EVPN domains together, Virtual Service Router permits to
configure an RD and RTs on a given L2 domain. The below configurations
illustrates how to configure a separate RD, and RTs for two L2 VNIs:
vsr running vrf main# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# vni 100
vsr running vni 100# export route-distinguisher 65500:100
vsr running vni 100# export route-target 65500:100000
vsr running vni 100# import route-target 65500:100000
vsr running vni 100#
Note
It is not possible to override RD and RTs specifically for a L2 VNI while
a L3 VNI is configured.
Getting EVPN information¶
To get information about the VXLAN interfaces detected, classified per VNI, the following command can be used to dump the contexts.
vsr> show evpn vni all
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
100 L2 vxlan1 0 0 0 default
The below example shows detailed information about L2 VNI: a certain number of L2 entries
have been learned, either via bgp signalisation, or by locally listening for ARP/MAC. The first
mac information learned is the MAC address of the bridged interface.
vsr> show evpn vni 100
VNI: 100
Type: L2
Tenant VRF: default
VxLAN interface: vxlan1
VxLAN ifIndex: 9
Local VTEP IP: 10.125.0.1
Mcast group: 0.0.0.0
Remote VTEPs for this VNI:
10.125.0.3 flood: HER
Number of MACs (local and remote) known for this VNI: 3
Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 4
Advertise-gw-macip: No
Advertise-svi-macip: No
vsr> show evpn arp-cache vni 100
Number of ARPs (local and remote) known for this VNI: 4
IP Type State MAC Remote VTEP Seq #'s
10.50.0.2 remote active de:ed:01:14:d3:ee 10.125.0.3 0/0
fe80::dced:1ff:fe98:f24f local active 5e:a9:f3:5a:88:7b 0/0
10.50.0.1 local active de:ed:01:86:ce:15 0/0
10.50.0.100 local active 5e:a9:f3:5a:88:7b 0/0
To get information about the BGP information exchanged, the following command dumps the
BGP advertisements exchanged. The first number stands for the kind of information shared,
ie the route type. For instance, 2 stands for MAC-level information shared (RT2), while
3 (RT3) means that this tunnel endpoint is authorized to exchange BUM traffic. The
tunnel endpoint can be seen here with the next-hop information. As depicted below,
10.125.0.3 is the tunnel endpoint.
vsr> show bgp l2vpn evpn
BGP table version is 3, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.125.0.1:2
*> [2]:[0]:[48]:[de:ed:01:86:ce:15]
10.125.0.1 32768 i
ET:8 RT:65500:100
*> [2]:[0]:[48]:[de:ed:01:86:ce:15]:[32]:[10.50.0.1]
10.125.0.1 32768 i
ET:8 RT:65500:100
*> [3]:[0]:[32]:[10.125.0.1]
10.125.0.1 32768 i
ET:8 RT:65500:100
Route Distinguisher: 10.125.0.3:3
*>i[2]:[0]:[48]:[de:ed:01:14:d3:ee]
10.125.0.3 100 0 i
RT:65500:100 ET:8
*>i[2]:[0]:[48]:[de:ed:01:14:d3:ee]:[32]:[10.50.0.2]
10.125.0.3 100 0 i
RT:65500:100 ET:8
*>i[3]:[0]:[32]:[10.125.0.3]
10.125.0.3 100 0 i
RT:65500:100 ET:8
Displayed 6 out of 6 total prefixes
It is also possible to do some variants of the call by filtering based on the route type.
vsr> show bgp l2vpn evpn route type multicast
BGP table version is 4, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 10.125.0.1:2
*> [3]:[0]:[32]:[10.125.0.1]
10.125.0.1 32768 i
ET:8 RT:65500:100
Route Distinguisher: 10.125.0.3:2
*>i[3]:[0]:[32]:[10.125.0.3]
10.125.0.3 100 0 i
RT:65500:100 ET:8
Displayed 2 prefixes (2 paths) (of requested type)
Also, it is possible to get some details of BGP route entry attributes.
vsr> show bgp l2vpn evpn route detail type macip
[..]
BGP routing table entry for 10.125.0.3:2:[2]:[0]:[48]:[de:ed:01:14:d3:ee]:[32]:[10.50.0.2]
Paths: (1 available, best #1)
Not advertised to any peer
Route [2]:[0]:[48]:[de:ed:01:14:d3:ee]:[32]:[10.50.0.2] VNI 100
Local
10.125.0.3 from 10.125.0.3 (10.125.0.3)
Origin IGP, localpref 100, valid, internal, best (First path received)
Extended Community: RT:65500:100 ET:8
Last update: Tue Nov 23 15:16:52 2021
Advanced configuration¶
Flooding BUM traffic¶
When dumping BGP RIB for l2vpn-evpn address-family, BGP RT2 and RT3 prefixes
stand for the L2 information shared between BGP instances. It is possible to filter
BUM traffic such as ARP packets, to pass through VXLAN interface, by using the below
configuration:
vsr running config# vrf main
vsr running vrf main# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# flooding disabled
vsr running address-family#
It is possible to reenable flooding by using the following command. Consequently, RT3 updates will be propagated.
vsr running config# vrf main
vsr running vrf main# routing bgp
vsr running bgp# address-family l2vpn-evpn
vsr running l2vpn-evpn# flooding head-end-replication
vsr running address-family#
Note
It is not recommended to disable flooding, unless all the L2 domain uses static MAC provisioning, and the multicast services are not used. Not complying with mentioned constraints results in dropped traffic that is not noticed by BGP.
Distributed versus centralised gateway¶
L2 connectivity extends L2 domain. An user may also need to get a known gateway to send
traffic out of this domain.
Note
Specifically for this use case, L2 VNI can be hosted under a given L3VRF
There are two modes of working:
centralised mode: a unique gateway is defined and known by each VTEP. The gateway can be advertised by using the below configuration command under the desired VNI:vsr running vrf main# l3vrf customer2 vsr running l3vrf customer2#! table-id 20 vsr running l3vrf customer2# interface physical eth3 vsr running physical eth3#! port pci-b0s7 vsr running physical eth3# ipv4 address 10.0.2.1/24 vsr running physical eth3# .. .. vsr running l3vrf customer2# routing static ipv4-route 0.0.0.0/0 next-hop 10.0.2.2 vsr running l3vrf customer2# interface bridge bridge1 vsr running bridge bridge1# ipv4 address 10.50.0.100/24 vsr running bridge bridge1# link-interface vxlan1 vsr running bridge bridge1# link-interface eth1 vsr running bridge bridge1# .. .. vsr running l3vrf customer2# .. vsr running vrf main# routing bgp vsr running bgp# address-family l2vpn-evpn vsr running l2vpn-evpn# vni 100 vsr running vni 100# advertise-default-gw true vsr running vni 100#
distributed mode: each VTEP is defined with its own gateway. AnanycastIP address with same MAC address is configured, like the below configuration illustrates:vsr running vrf main# l3vrf customer2 vsr running l3vrf customer2#! table-id 20 vsr running l3vrf customer2# interface physical eth3 vsr running physical eth3#! port pci-b0s7 vsr running physical eth3# ipv4 address 10.0.2.1/24 vsr running physical eth3# .. .. vsr running l3vrf customer2# routing static ipv4-route 0.0.0.0/0 next-hop 10.0.2.2 vsr running l3vrf customer2# interface bridge bridge1 vsr running bridge bridge1# ethernet mac-address de:ad:de:83:82:c8 vsr running bridge bridge1# ipv4 address 10.50.0.100/24 vsr running bridge bridge1# link-interface vxlan1 vsr running bridge bridge1# link-interface eth1 vsr running bridge bridge1#
Use case for routing mode¶
The below configuration gathers all above configurations and is based on
BGP EVPN use case example, where rt1 and rt2
devices configuration is exposed.
rt1
rt1 running config# vrf main
rt1 running vrf main# interface vxlan vxlan2
rt1 running vxlan vxlan2#! vni 102
rt1 running vxlan vxlan2# local 10.125.0.1
rt1 running vxlan vxlan2# link-interface eth0
rt1 running vxlan vxlan2# ..
rt1 running interface# physical eth0
rt1 running physical eth0#! ipv4 address 10.125.0.1/24
rt1 running physical eth0#! port pci-b0s5
rt1 running physical eth0# mtu 1550
rt1 running physical eth0# ..
rt1 running interface# ..
rt1 running vrf main# routing bgp
rt1 running bgp#! router-id 10.125.0.1
rt1 running bgp#! as 65500
rt1 running bgp# address-family
rt1 running address-family# l2vpn-evpn
rt1 running l2vpn-evpn# advertise-all-vni true
rt1 running l2vpn-evpn# auto-route-target rfc8365
rt1 running l2vpn-evpn# ..
rt1 running address-family# ..
rt1 running bgp# neighbor 10.125.0.3
rt1 running neighbor 10.125.0.3#! remote-as 65500
rt1 running neighbor 10.125.0.3# address-family
rt1 running address-family# l2vpn-evpn
rt1 running l2vpn-evpn# ..
rt1 running address-family# ..
rt1 running neighbor 10.125.0.3# ..
rt1 running bgp# ..
rt1 running routing# ..
rt1 running vrf main# l3vrf customer1
rt1 running l3vrf customer1#! table-id 10
rt1 running l3vrf customer1# interface
rt1 running interface# bridge bridge2
rt1 running bridge bridge2# ipv4 address 10.100.0.1/32
rt1 running bridge bridge2# link-interface vxlan2
rt1 running bridge bridge2# ..
rt1 running interface# physical eth2
rt1 running physical eth2#! port pci-b0s6
rt1 running physical eth2# ipv4 address 10.100.0.1/24
rt1 running physical eth2# .. ..
rt1 running l3vrf customer1# routing bgp
rt1 running bgp# l3vni 102
rt1 running bgp# as 65500
rt1 running bgp# address-family ipv4-unicast
rt1 running ipv4-unicast# redistribute connected
rt1 running ipv4-unicast# ..
rt1 running address-family# ..
rt1 running bgp# address-family l2vpn-evpn
rt1 running l2vpn-evpn# auto-route-target rfc8365
rt1 running l2vpn-evpn# advertise ipv4-unicast
rt1 running l2vpn-evpn# ..
rt1 running address-family# ..
rt1 running bgp# ..
rt1 running routing# ..
rt1 running l3vrf customer1#
rt2
rt2 running config# vrf main
rt2 running vrf main# interface
rt2 running interface# physical eth0
rt2 running physical eth0#! port pci-b0s4
rt2 running physical eth0# mtu 1550
rt2 running physical eth0# ipv4
rt2 running ipv4# address 10.125.0.3/24
rt2 running ipv4# ..
rt2 running physical eth0# ..
rt2 running interface# vxlan vxlan2
rt2 running vxlan vxlan2#! vni 102
rt2 running vxlan vxlan2# local 10.125.0.3
rt2 running vxlan vxlan2# link-interface eth0
rt2 running vxlan vxlan2# ..
rt2 running interface# ..
rt2 running vrf main# routing
rt2 running routing# bgp
rt2 running bgp#! as 65500
rt2 running bgp# router-id 10.125.0.3
rt2 running bgp# address-family
rt2 running address-family# l2vpn-evpn
rt2 running l2vpn-evpn# advertise-all-vni true
rt2 running l2vpn-evpn# ..
rt2 running address-family# ..
rt2 running bgp# neighbor 10.125.0.1
rt2 running neighbor 10.125.0.1#! remote-as 65500
rt2 running neighbor 10.125.0.1# address-family
rt2 running address-family# l2vpn-evpn
rt2 running l2vpn-evpn# ..
rt2 running address-family# ..
rt2 running neighbor 10.125.0.1# .. ..
rt2 running routing# bgp
rt2 running bgp# address-family l2vpn-evpn
rt2 running l2vpn-evpn# export route-distinguisher 65500:100
rt2 running l2vpn-evpn# .. ..
rt2 running bgp# .. ..
rt2 running vrf main# l3vrf customer1
rt2 running l3vrf customer1#! table-id 10
rt2 running l3vrf customer1# routing bgp
rt2 running bgp# as 65500
rt2 running bgp# l3vni 102
rt2 running bgp# router-id 10.125.0.3
rt2 running bgp# address-family
rt2 running address-family# ipv4-unicast
rt2 running ipv4-unicast# redistribute connected
rt2 running ipv4-unicast# ..
rt2 running address-family# l2vpn-evpn
rt2 running l2vpn-evpn# advertise ipv4-unicast
rt1 running l2vpn-evpn# auto-route-target rfc8365
rt2 running l2vpn-evpn# ..
rt2 running address-family# ..
rt2 running bgp# ..
rt2 running routing# ..
rt2 running l3vrf customer1# interface
rt2 running interface# physical eth2
rt2 running physical eth2#! port pci-b0s6
rt2 running physical eth2# ipv4
rt2 running ipv4# address 10.200.0.2/24
rt2 running ipv4# ..
rt2 running physical eth2# ..
rt2 running interface# bridge bridge2
rt2 running bridge bridge2# ipv4 address 10.200.0.2/32
rt2 running bridge bridge2# link-interface vxlan2
rt2 running bridge bridge2# .. ..
rt2 running l3vrf customer1#
A summary of the discovered VXLAN interfaces can be seen with the following command:
rt1> show evpn vni all
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
102 L3 vxlan2 0 0 n/a customer1
A list of available EVPN entries in customer1 configuration can be dumped with the
following command:
rt1> show bgp l2vpn evpn route type prefix
BGP table version is 2, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 10.125.0.1:3
*> [5]:[0]:[24]:[10.100.0.0]
10.125.0.1 0 32768 ?
ET:8 RT:65500:268435558 Rmac:0a:16:46:ff:64:eb
*> [5]:[0]:[32]:[10.100.0.1]
10.125.0.1 0 32768 ?
ET:8 RT:65500:268435558 Rmac:0a:16:46:ff:64:eb
Route Distinguisher: 10.125.0.3:2
*>i[5]:[0]:[24]:[10.200.0.0]
10.125.0.3 0 100 0 ?
RT:65500:268435558 ET:8 Rmac:3a:77:e0:f1:b6:9e
*>i[5]:[0]:[32]:[10.200.0.2]
10.125.0.3 0 100 0 ?
RT:65500:268435558 ET:8 Rmac:3a:77:e0:f1:b6:9e
Displayed 4 prefixes (4 paths) (of requested type)
The resulting routes to remote VPN 10.200.0.0/24 network can be seen wih the below
following command:
rt1> show ipv4-routes l3vrf customer1
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF customer1:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:22:39
C>* 10.100.0.0/24 is directly connected, eth2, 00:22:39
C>* 10.100.0.1/32 is directly connected, bridge2, 00:22:39
B>* 10.200.0.0/24 [200/0] via 10.125.0.3, bridge2 onlink, weight 1, 00:16:56
B>* 10.200.0.2/32 [200/0] via 10.125.0.3, bridge2 onlink, weight 1, 00:16:56
Use case for bridging mode¶
The below drawing illustrates a bridging EVPN setup with two devices that connect
two L2 VPNs together.
BGP evpn bridging use case¶
The devices configuration is exposed below. A centralised configuration is implemented
with rt1 acting as default gateway for all L2 domain.
rt1
rt1 running config# vrf main
rt1 running vrf main# interface vxlan vxlan1
rt1 running vxlan vxlan1#! vni 100
rt1 running vxlan vxlan1# local 10.125.0.1
rt1 running vxlan vxlan1# learning true
rt1 running vxlan vxlan1# link-interface eth0
rt1 running vxlan vxlan1# ..
rt1 running interface# physical eth0
rt1 running physical eth0#! ipv4 address 10.125.0.1/24
rt1 running physical eth0#! port pci-b0s5
rt1 running physical eth0# mtu 1550
rt1 running physical eth0# ..
rt1 running interface# physical eth1
rt1 running physical eth1#! port pci-b0s4
rt1 running physical eth1#! .. ..
rt1 running vrf main# l3vrf customer2
rt1 running l3vrf customer2#! table-id 20
rt1 running l3vrf customer2# interface physical eth3
rt1 running physical eth3#! port pci-b0s7
rt1 running physical eth3# ipv4 address 10.0.2.1/24
rt1 running physical eth3# .. ..
rt1 running l3vrf customer2# routing static ipv4-route 0.0.0.0/0 next-hop 10.0.2.2
rt1 running l3vrf customer2# interface bridge bridge1
rt1 running bridge bridge1# ethernet mac-address de:ad:de:83:82:c8
rt1 running bridge bridge1# ipv4 address 10.50.0.100/24
rt1 running bridge bridge1# link-interface vxlan1
rt1 running bridge bridge1# link-interface eth1
rt1 running bridge bridge1# .. .. ..
rt1 running vrf main# routing bgp
rt1 running bgp#! router-id 10.125.0.1
rt1 running bgp#! as 65500
rt1 running bgp# address-family
rt1 running address-family# l2vpn-evpn
rt1 running l2vpn-evpn# advertise-all-vni true
rt1 running l2vpn-evpn# auto-route-target rfc8365
rt1 running l2vpn-evpn# vni 100
rt1 running vni 100# advertise-default-gw true
rt1 running vni 100# ..
rt1 running l2vpn-evpn# ..
rt1 running address-family# ..
rt1 running bgp# neighbor 10.125.0.3
rt1 running neighbor 10.125.0.3#! remote-as 65500
rt1 running neighbor 10.125.0.3# address-family
rt1 running address-family# l2vpn-evpn
rt1 running l2vpn-evpn# ..
rt1 running address-family# ..
rt1 running neighbor 10.125.0.3# ..
rt1 running bgp# ..
rt1 running routing# ..
rt1 running vrf main#
rt2
rt2 running config# vrf main
rt2 running vrf main# interface
rt2 running interface# physical eth0
rt2 running physical eth0#! port pci-b0s4
rt2 running physical eth0# mtu 1550
rt2 running physical eth0# ipv4
rt2 running ipv4# address 10.125.0.3/24
rt2 running ipv4# ..
rt2 running physical eth0# ..
rt2 running interface# physical eth1
rt2 running physical eth1#! port pci-b0s5
rt2 running physical eth1# ..
rt2 running interface# vxlan vxlan1
rt2 running vxlan vxlan1#! vni 100
rt2 running vxlan vxlan1# learning true
rt2 running vxlan vxlan1# local 10.125.0.3
rt2 running vxlan vxlan1# link-interface eth0
rt2 running vxlan vxlan1# ..
rt2 running interface# bridge bridge1
rt2 running bridge bridge1# ethernet mac-address de:ad:de:83:82:c8
rt2 running bridge bridge1# link-interface vxlan1
rt2 running bridge bridge1# link-interface eth1
rt2 running bridge bridge1# ipv4 address 10.50.0.101/24
rt2 running bridge bridge1# ..
rt2 running interface# ..
rt2 running vrf main# routing
rt2 running routing# bgp
rt2 running bgp#! as 65500
rt2 running bgp# router-id 10.125.0.3
rt2 running bgp# address-family
rt2 running address-family# l2vpn-evpn
rt2 running l2vpn-evpn# advertise-all-vni true
rt2 running l2vpn-evpn# auto-route-target rfc8365
rt2 running l2vpn-evpn# ..
rt2 running address-family# ..
rt2 running bgp# neighbor 10.125.0.1
rt2 running neighbor 10.125.0.1#! remote-as 65500
rt2 running neighbor 10.125.0.1# address-family
rt2 running address-family# l2vpn-evpn
rt2 running l2vpn-evpn# ..
rt2 running address-family# ..
rt2 running neighbor 10.125.0.1# .. ..
rt2 running routing# bgp
rt2 running bgp# address-family l2vpn-evpn
rt2 running l2vpn-evpn# export route-distinguisher 65500:100
rt2 running l2vpn-evpn# .. ..
rt2 running bgp# .. ..
rt2 running vrf main#
A summary of the discovered VXLAN interfaces can be seen with the following command:
rt1> show evpn vni all
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
100 L2 vxlan1 1 3 0 default
A list of available EVPN entries can be dumped with the following command:
rt1> show bgp l2vpn evpn
BGP table version is 3, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.125.0.1:2
*> [2]:[0]:[48]:[de:ad:de:83:82:c8]:[32]:[10.50.0.100]
10.125.0.1 32768 i
ET:8 RT:65500:268435556 Default Gateway
*> [2]:[0]:[48]:[de:ad:de:83:82:c8]:[128]:[fe80::dcad:deff:fe83:82c8]
10.125.0.1 32768 i
ET:8 RT:65500:268435556 Default Gateway ND:Router Flag
*> [2]:[0]:[48]:[de:ed:01:08:3c:b7]
10.125.0.1 32768 i
ET:8 RT:65500:268435556
*> [2]:[0]:[48]:[de:ed:01:08:3c:b7]:[32]:[10.50.0.50]
10.125.0.1 32768 i
ET:8 RT:65500:268435556
Route Distinguisher: 10.125.0.3:2
*>i[2]:[0]:[48]:[de:ed:01:13:7d:fb]
10.125.0.3 100 0 i
RT:65500:268435556 ET:8
*>i[2]:[0]:[48]:[de:ed:01:13:7d:fb]:[32]:[10.50.0.107]
10.125.0.3 100 0 i
RT:65500:268435556 ET:8
*>i[3]:[0]:[32]:[10.125.0.3]
10.125.0.3 100 0 i
RT:65500:268435556 ET:8
You can note that advertise-default-gw keyword applied to L2 VNI configuration
forced the signalisation of a new RT2 entry for IP address of bridge interfaces.
Those entries are emphasized on the above output.
Consequently, the neighboring table is populated with local entries found locally,
and remote entries learnt from BGP. For instance, 10.50.0.1 has been detected
as a machine in the local network of rt1, and its MAC address and the IP
association has been propagated to the remote BGP speaker.
rt1> show evpn arp-cache vni 100
Number of ARPs (local and remote) known for this VNI: 4
Flags: I=local-inactive, P=peer-active, X=peer-proxy
Neighbor Type Flags State MAC Remote ES/VTEP Seq #'s
fe80::dcad:deff:fe83:82c8 local active de:ad:de:83:82:c8 0/0
10.50.0.100 local active de:ad:de:83:82:c8 0/0
10.50.0.50 local active de:ed:01:08:3c:b7 0/0
10.50.0.107 remote active de:ed:01:13:7d:fb 10.125.0.3 0/0
Also, the MAC table can be seen, with the remote host emphasized.
rt1> show evpn mac vni 100
Number of MACs (local and remote) known for this VNI: 3
Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy
MAC Type Flags Intf/Remote ES/VTEP VLAN Seq #'s
de:ed:01:13:7d:fb remote 10.125.0.3 0/0
de:ad:de:83:82:c8 local bridge1 1 0/0
de:ed:01:08:3c:b7 local eth1 1 0/0
rt1> show bridge fdb
interface link-layer-address link-interface state
========= ================== ============== =====
bridge1 de:ad:de:83:82:c8 bridge1 permanent
bridge1 de:ed:01:a0:5b:cb eth1 permanent
bridge1 7a:87:1e:9b:24:aa vxlan1 permanent
bridge1 de:ed:01:13:7d:fb vxlan1 reachable
bridge1 de:ed:01:08:3c:b7 eth1 reachable