eBGP support for EVPN

The BGP session for underlay and overlay can be either iBGP or eBGP. eBGP supported has been added in this release. Dual-AS and Multi-AS eBGP topologies are supported.

In a Dual-AS Topology, all spines share a common AS number and all leafs share another common AS number.

In a Dual-AS topology, since the peer VTEPs (leafs) receive the route from another leaf with the same AS number, the route would be rejected. To avoid this, use the following allowas-in command:

switch(config-bgp-l2vpn-evpn)# neighbor 1.1.1.1 allowas-in 1

A sample Dual-AS configuration is shown below.

Leaf 1 configuration


vlan 1-2
evpn
    vlan 2
        rd 5:5
        route-target export 1:1
        route-target import 1:1
interface 1/1/1
    no shutdown
    ip address 11.1.1.2/24
interface loopback 1
    ip address 2.2.2.2/32
interface vxlan 1
    source ip 2.2.2.2
    no shutdown
    vni 100
        vlan 2
router bgp 2
    neighbor 1.1.1.1 remote-as 1
    neighbor 1.1.1.1 update-source 2.2.2.2
    neighbor 11.1.1.1 remote-as 1
    address-family ipv4 unicast
        neighbor 11.1.1.1 activate
        neighbor 11.1.1.1 allowas-in 1
        network 2.2.2.2/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 1.1.1.1 activate
        neighbor 1.1.1.1 allowas-in 1
        neighbor 1.1.1.1 send-community extended
    exit-address-family

Leaf 2 configuration


vlan 1-2
evpn
    vlan 2
        rd 5:5
        route-target export 1:1
        route-target import 1:1
interface 1/1/24
    no shutdown
    ip address 12.1.1.2/24
interface loopback 1
    ip address 3.3.3.3/32
interface vxlan 1
    source ip 3.3.3.3
    no shutdown
    vni 100
        vlan 2
    !
router bgp 2
    neighbor 1.1.1.1 remote-as 1
    neighbor 1.1.1.1 update-source 3.3.3.3
    neighbor 12.1.1.1 remote-as 1
    address-family ipv4 unicast
        neighbor 12.1.1.1 activate
        network 3.3.3.3/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 1.1.1.1 activate
        neighbor 1.1.1.1 allowas-in 1
        neighbor 1.1.1.1 send-community extended
    exit-address-family

Spine configuration


vlan 1-2

interface 1/1/2
    no shutdown
    ip address 11.1.1.1/24
interface 1/1/5
    no shutdown
    ip address 12.1.1.1/24
interface loopback 1
    ip address 1.1.1.1/32
router bgp 1
    neighbor 2.2.2.2 remote-as 2
    neighbor 2.2.2.2 update-source 1.1.1.1
    neighbor 3.3.3.3 remote-as 2
    neighbor 3.3.3.3 update-source 1.1.1.1
    neighbor 11.1.1.2 remote-as 2
    neighbor 12.1.1.2 remote-as 2
    address-family ipv4 unicast
        neighbor 11.1.1.2 activate
        neighbor 12.1.1.2 activate
        network 1.1.1.1/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 2.2.2.2 activate
        neighbor 2.2.2.2 next-hop-unchanged
        neighbor 2.2.2.2 send-community extended
        neighbor 3.3.3.3 activate
        neighbor 3.3.3.3 next-hop-unchanged
        neighbor 3.3.3.3 send-community extended
    exit-address-family

In a Multi-AS Topology, all spines share a common AS number and all leafs have different AS numbers.

A sample Multi-AS configuration is shown below.

Leaf 1 configuration


vlan 1-2
evpn
    vlan 2
        rd 5:5
        route-target export 1:1
        route-target import 1:1
interface 1/1/1
    no shutdown
    ip address 11.1.1.2/24
interface loopback 1
    ip address 2.2.2.2/32
interface vxlan 1
    source ip 2.2.2.2
    no shutdown
    vni 100
        vlan 2
router bgp 2
    neighbor 1.1.1.1 remote-as 1
    neighbor 1.1.1.1 update-source 2.2.2.2
    neighbor 11.1.1.1 remote-as 1
    address-family ipv4 unicast
        neighbor 11.1.1.1 activate
        network 2.2.2.2/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 1.1.1.1 activate
        neighbor 1.1.1.1 send-community extended
    exit-address-family

Leaf 2 configuration


vlan 1-2
evpn
    vlan 2
        rd 5:5
        route-target export 1:1
        route-target import 1:1
interface 1/1/24
    no shutdown
    ip address 12.1.1.2/24
interface loopback 1
    ip address 3.3.3.3/32
interface vxlan 1
    source ip 3.3.3.3
    no shutdown
    vni 100
        vlan 2
    !
router bgp 3
    neighbor 1.1.1.1 remote-as 1
    neighbor 1.1.1.1 update-source 3.3.3.3
    neighbor 12.1.1.1 remote-as 1
    address-family ipv4 unicast
        neighbor 12.1.1.1 activate
        network 3.3.3.3/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 1.1.1.1 activate
        neighbor 1.1.1.1 send-community extended
    exit-address-family

Spine configuration


vlan 1-2
interface 1/1/2
    no shutdown
    ip address 11.1.1.1/24
interface 1/1/5
    no shutdown
    ip address 12.1.1.1/24
interface loopback 1
    ip address 1.1.1.1/32
router bgp 1
    neighbor 2.2.2.2 remote-as 2
    neighbor 2.2.2.2 update-source 1.1.1.1
    neighbor 3.3.3.3 remote-as 3
    neighbor 3.3.3.3 update-source 1.1.1.1
    neighbor 11.1.1.2 remote-as 2
    neighbor 12.1.1.2 remote-as 3
    address-family ipv4 unicast
        neighbor 11.1.1.2 activate
        neighbor 12.1.1.2 activate
        network 1.1.1.1/32
    exit-address-family
    address-family l2vpn evpn
        neighbor 2.2.2.2 activate
        neighbor 2.2.2.2 next-hop-unchanged
        neighbor 2.2.2.2 send-community extended
        neighbor 3.3.3.3 activate
        neighbor 3.3.3.3 next-hop-unchanged
        neighbor 3.3.3.3 send-community extended
    exit-address-family

The tunnel endpoints are communicated as next-hops in the EVPN routes. By default, the next hop of a route is preserved when advertising the route to an iBGP peer, but is updated when advertising the route to an eBGP peer. Setting this to 'true' over-rides this behavior and preserves the next hop when routes are advertised to eBGP peer. To retain the next-hop (or tunnel endpoint info), an extra configuration is required as shown in the following command:

switch(config-bgp-l2vpn-evpn)# neighbor 2.2.2.2 next-hop-unchanged

NOTE:

When VSX is used with eBGP, the VSX peers must be in same AS.

Route-targets must be manually configured for switches running eBGP since auto generated RT's (route-target auto) would lead to different export/import route-targets (Applicable for both VSX/non-VSX).