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 routing bgp as 65500
vsr running config# / vrf main routing bgp address-family l2vpn-evpn advertise-all-vni true

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 routing bgp as 65500
vsr running config# / vrf main routing bgp neighbor 10.125.0.2 remote-as 65500
vsr running config# / vrf main routing bgp neighbor 10.125.0.2 address-family 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.

../../../../../_images/evpn-bgp-config.svg

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 config# / vrf main interface physical eth2 port pci-b0s5
vsr running config# / vrf main interface physical eth2 ipv4 address 10.125.0.1/24
vsr running config# / vrf main interface vxlan vxlan2 vni 102
vsr running config# / vrf main interface vxlan vxlan2 local 10.125.0.1
vsr running config# / vrf main interface vxlan vxlan2 link-interface eth2
vsr running config# / vrf main l3vrf customer1 table-id 10
vsr running config# / vrf main l3vrf customer1 interface physical eth1 port pci-b0s4
vsr running config# / vrf main l3vrf customer1 interface physical eth1 ipv4 address 10.51.0.100/24
vsr running config# / vrf main l3vrf customer1 interface bridge bridge2
vsr running bridge bridge2# / vrf main l3vrf customer1 interface bridge bridge2 link-interface vxlan2
vsr running bridge bridge2# / vrf main l3vrf customer1 interface bridge bridge2 ipv4 address 10.51.0.100/32
vsr running bridge bridge2# / vrf main l3vrf customer1 routing bgp l3vni 102
vsr running bridge bridge2# / vrf main l3vrf customer1 routing bgp address-family ipv4-unicast redistribute connected
vsr running bridge bridge2# / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn advertise ipv4-unicast

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 l3vrf customer1 routing bgp address-family l2vpn-evpn export route-distinguisher 65500:102

The below configurations shows how to configure RTs for an L3 VNI:

vsr running config# / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn export route-target 65500:102
vsr running config# / vrf main l3vrf customer1 routing bgp address-family 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# del / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn export route-target 65500:102
vsr running config# del / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn import route-target 65500:102
vsr running config# / vrf main l3vrf customer1 routing bgp address-family 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: f2:3f:5c:31:6b:58
  Router-MAC: f2:3f:5c:31:6b:58
  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: f2:3f:5c:31:6b:58
  Router MAC: f2:3f:5c:31:6b:58
  L2 VNIs:

To get information about the BGP information exchanged, the following command dumps the BGP prefixes exchanged. 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 6, 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:f2:3f:5c:31:6b:58
*> [5]:[0]:[32]:[10.51.0.100]
                    10.125.0.1               0         32768 ?
                    ET:8 RT:65500:268435558 Rmac:f2:3f:5c:31:6b:58

Displayed 2 out of 2 total prefixes

EVPN bridged configuration

For bridging services, the bridge VXLAN interface can be on the default L3VRF.

vsr running config# / vrf main interface physical eth2 port pci-b0s5
vsr running config# / vrf main interface physical eth2 ipv4 address 10.125.0.1/24
vsr running config# / vrf main interface physical eth1 port pci-b0s4
vsr running config# / vrf main interface vxlan vxlan1 vni 100
vsr running config# / vrf main interface vxlan vxlan1 local 10.125.0.1
vsr running config# / vrf main interface vxlan vxlan1 learning true
vsr running config# / vrf main interface bridge bridge1 ipv4 address 10.50.0.100/24
vsr running config# / vrf main interface bridge bridge1 link-interface vxlan1
vsr running config# / vrf main interface bridge bridge1 link-interface eth1

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 config# / vrf main routing bgp as 65500
vsr running config# / vrf main routing bgp neighbor 10.125.0.2 remote-as 65500
vsr running config# / vrf main routing bgp neighbor 10.125.0.2 address-family l2vpn-evpn
vsr running l2vpn-evpn# / vrf main routing bgp address-family l2vpn-evpn vni 100
vsr running vni 100# / vrf main routing bgp address-family l2vpn-evpn export route-distinguisher 65500:100
vsr running vni 100# / vrf main routing bgp address-family l2vpn-evpn export route-target 65500:100000
vsr running vni 100# / vrf main routing bgp address-family l2vpn-evpn import route-target 65500:100000

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 routing bgp address-family l2vpn-evpn flooding disabled

It is possible to reenable flooding by using the following command. Consequently, RT3 updates will be propagated.

vsr running config# / vrf main routing bgp address-family l2vpn-evpn flooding head-end-replication

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. A 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. An anycast IP 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 l3vrf customer1 table-id 10
rt1 running config# / vrf main l3vrf customer1 interface physical eth2 port pci-b0s5
rt1 running config# / vrf main l3vrf customer1 interface physical eth2 ipv4 address 10.100.0.1/24
rt1 running config# / vrf main l3vrf customer1 interface bridge bridge2 ipv4 address 10.100.0.1/32
rt1 running config# / vrf main l3vrf customer1 interface bridge bridge2 link-interface vxlan2
rt1 running config# / vrf main l3vrf customer1 routing bgp as 65500
rt1 running config#! / vrf main l3vrf customer1 routing bgp l3vni 102
rt1 running config#! / vrf main l3vrf customer1 routing bgp address-family ipv4-unicast redistribute connected
rt1 running config#! / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn advertise ipv4-unicast
rt1 running config#! / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn auto-route-target rfc8365
rt1 running config#! / vrf main interface physical eth1 port pci-b0s4
rt1 running config#! / vrf main interface physical eth1 ipv4 address 10.125.0.1/24
rt1 running config#! / vrf main interface physical eth1 mtu 1550
rt1 running config#! / vrf main interface vxlan vxlan2 vni 102
rt1 running config#! / vrf main interface vxlan vxlan2 local 10.125.0.1
rt1 running config#! / vrf main interface vxlan vxlan2 link-interface eth1
rt1 running config#! / vrf main routing bgp as 65500
rt1 running config# / vrf main routing bgp router-id 10.125.0.1
rt1 running config# / vrf main routing bgp address-family l2vpn-evpn auto-route-target rfc8365
rt1 running config# / vrf main routing bgp address-family l2vpn-evpn advertise-all-vni true
rt1 running config# / vrf main routing bgp neighbor 10.125.0.3 remote-as 65500
rt1 running config# / vrf main routing bgp neighbor 10.125.0.3 address-family l2vpn-evpn

rt2

rt2 running config# / vrf main l3vrf customer1 table-id 10
rt2 running config# / vrf main l3vrf customer1 interface physical eth2 port pci-b0s5
rt2 running config# / vrf main l3vrf customer1 interface physical eth2 ipv4 address 10.200.0.2/24
rt2 running config# / vrf main l3vrf customer1 interface bridge bridge2 ipv4 address 10.200.0.2/32
rt2 running config# / vrf main l3vrf customer1 interface bridge bridge2 link-interface vxlan2
rt2 running config# / vrf main l3vrf customer1 routing bgp as 65500
rt2 running config#! / vrf main l3vrf customer1 routing bgp l3vni 102
rt2 running config#! / vrf main l3vrf customer1 routing bgp router-id 10.125.0.3
rt2 running config#! / vrf main l3vrf customer1 routing bgp address-family ipv4-unicast redistribute connected
rt2 running config#! / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn advertise ipv4-unicast
rt2 running config#! / vrf main l3vrf customer1 routing bgp address-family l2vpn-evpn auto-route-target rfc8365
rt2 running config#! / vrf main interface physical eth1 port pci-b0s4
rt2 running config#! / vrf main interface physical eth1 ipv4 address 10.125.0.3/24
rt2 running config#! / vrf main interface physical eth1 mtu 1550
rt2 running config#! / vrf main interface vxlan vxlan2 vni 102
rt2 running config#! / vrf main interface vxlan vxlan2 local 10.125.0.3
rt2 running config#! / vrf main interface vxlan vxlan2 link-interface eth1
rt2 running config#! / vrf main routing bgp as 65500
rt2 running config# / vrf main routing bgp router-id 10.125.0.3
rt2 running config# / vrf main routing bgp address-family l2vpn-evpn advertise-all-vni true
rt2 running config# / vrf main routing bgp neighbor 10.125.0.1 remote-as 65500
rt2 running config# / vrf main routing bgp neighbor 10.125.0.1 address-family l2vpn-evpn

hostA

hostA running config# / vrf main interface physical eth2 port pci-b0s5
hostA running config# / vrf main interface physical eth2 ipv4 address 10.200.0.10/24
hostA running config# / vrf main routing static ipv4-route 0.0.0.0/0 next-hop 10.200.0.2

hostB

hostB running config# / vrf main interface physical eth2 port pci-b0s5
hostB running config# / vrf main interface physical eth2 ipv4 address 10.100.0.10/24
hostB running config# / vrf main routing static ipv4-route 0.0.0.0/0 next-hop 10.100.0.1

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                1        1        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:2
*> [5]:[0]:[24]:[10.100.0.0]
                    10.125.0.1               0         32768 ?
                    ET:8 RT:65500:268435558 Rmac:86:65:5b:0c:ec:b1
*> [5]:[0]:[32]:[10.100.0.1]
                    10.125.0.1               0         32768 ?
                    ET:8 RT:65500:268435558 Rmac:86:65:5b:0c:ec:b1
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:1e:bf:20:3a:0a:50
*>i[5]:[0]:[32]:[10.200.0.2]
                    10.125.0.3               0    100      0 ?
                    RT:65500:268435558 ET:8 Rmac:1e:bf:20:3a:0a:50

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, N - NHRP, T - Table
       > - selected route, * - FIB route, r - rejected, b - backup

L3VRF customer1:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:19
C>* 10.100.0.0/24 is directly connected, eth2, 00:00:19
C>* 10.100.0.1/32 is directly connected, bridge2, 00:00:19
B>* 10.200.0.0/24 [200/0] via 10.125.0.3, bridge2 onlink, weight 1, 00:00:11
B>* 10.200.0.2/32 [200/0] via 10.125.0.3, bridge2 onlink, weight 1, 00:00:11

5 routes displayed.

Use case for bridging mode

The below drawing illustrates a bridging EVPN setup with two devices that connect two L2 VPNs together.

../../../../../_images/evpn-l2-config.svg

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