This section presents configuration examples of basic BGP EVPN neighbor configurations.
device(config)#router bgp device(config-bgp-router)# local-as 62001 device(config-bgp-router)# neighbor 192.168.21.31 remote-as 62000 device(config-bgp-router)# neighbor 2000:10:1::2 remote-as 62002 device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# retain route-target all <---Spine only device(config-bgp-evpn)# neighbor 192.168.21.31 next-hop-unchanged <---Spine only device(config-bgp-evpn)# neighbor 192.168.21.31 activate device(config-bgp-evpn)# neighbor 2000:10:1::2 next-hop-unchanged <---Spine only device(config-bgp-evpn)# neighbor 2000:10:1::2 activate device(config-bgp-evpn)# end
As with any VPN technology, EVPN neighbors must always be in the default VRF. The preceding example shows EVPN address-family being activated for IPv4 and IPv6 BGP neighbors.
BGP neighbor configuration can be simplified by using peer groups, as in the following example.
device(config-bgp-router)# neighbor my-peer-group peer-group device(config-bgp-router)# neighbor my-peer-group remote-as 62001 device(config-bgp-router)# neighbor 192.168.30.2 peer-group my-peer-group device(config-bgp-router)# neighbor 2000:20:1::2 peer-group my-peer-group device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# retain route-target all device(config-bgp-evpn)# neighbor my-peer-group route-reflector-client device(config-bgp-evpn)# neighbor my-peer-group activate
Note
The neighbor route-reflector client command is not required if all devices peer with each other in a full iBGP mesh.BGP EVPN routes carry the encapsulation type as part of the BGP encapsulation extended community. When BGP encapsulation extended community is absent from the route, the default MPLS encapsulation is assumed. On SLX-OS platforms, the default encapsulation for EVPN peers is MPLS, and BGP encapsulation extended community with the MPLS encapsulation type is attached to all EVPN routes.
For spine or specific border leaf cases, routes are not imported into MAC-VRF or IP-VRF tables, but instead are reflected/re-advertised to iBGP/eBGP peers. The following configuration is required to retain all of the routes in the VPN table.
device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# retain route-target all
When BGP advertises routes to an eBGP peer, the next-hop value in the route is modified to carry the local peering IP address. In the case of a BGP EVPN VXLAN IP Fabric, the next-hop value in the route is the VTEP IP address of the advertising router. A BGP EVPN spine distributing the routes to other leaf nodes should not modify the next-hop value. Each EBGP peer activated under EVPN address-family should be configured so that it does not modify the next-hop value, as in the following example.
device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 192.168.21.31 next-hop-unchanged device(config-bgp-evpn)# neighbor my-peer-group next-hop-unchanged device(config-bgp-evpn)# neighbor 192.168.21.31 activate device(config-bgp-evpn)# neighbor my-peer-group activate
In special cases where spine or super-spine routers must accept EVPN routes that have the AS number of a router in the AS path segment, the allowas-in command can be used for a given BGP peer, as in the following example.
device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 192.168.21.31 allowas-in 1 device(config-bgp-evpn)# neighbor my-peer-group allowas-in 1
In a full iBGP mesh of EVPN nodes, a leaf node needs to peer only with all other leaf nodes; it does not need to have a session with any spine node. The configuration of route-reflector client on the spine nodes is not required.
In a non-full iBGP mesh configuration, in order to reflect routes from one iBGP neighbor to another iBGP neighbor, the iBGP neighbors should be configured as route-reflector-clients, as in the following example.
device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 192.168.21.31 route-reflector-client device(config-bgp-evpn)# neighbor my-peer-group route-reflector-client
The '"client-to-client-reflection" feature is by default enabled under EVPN address-family. The route-reflector configuration does not force routes that are not imported to be retained in BGP. The retain route-target all command is required in all cases.
Limited filtering support is available for EVPN routes. However, route maps can be configured on EVPN neighbors, as in the following example.
device(config-bgp-router)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 192.168.21.31 route-map in rmap-in device(config-bgp-evpn)# neighbor 192.168.21.31 route-map out rmap-out
Only AS path and extended-community-based match and set criteria are supported for EVPN routes.
In order to have better resiliency, separate BGP neighbors for overlay and underlay may be desired. This separation allows administrators to manipulate, debug, and maintain EVPN neighbors without affecting underlay connectivity. This separation can be achieved by deactivating underlay address-family for EVPN neighbors.
IPv4 neighbors are automatically activated under IPv4 unicast address-family, and they must be deactivated as in the following example.
device(config-bgp-router)# neighbor 192.168.21.31 remote-as 62000 device(config-bgp-router)# address-family ipv4 unicast device(config-bgp-ipv4u)# no neighbor 192.168.21.31 activate device(config-bgp-ipv4u)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 192.168.21.31 activate
IPv6 neighbors are not by default activated under IPv6 unicast address-family. Therefore, for them to negotiate only EVPN address-family, they must be activated only under EVPN, as in the following example.
device(config-bgp-router)# neighbor 2000:10:1::2 remote-as 62002 device(config-bgp-ipv4u)# address-family l2vpn evpn device(config-bgp-evpn)# neighbor 2000:10:1::2 activate
When a BGP router receives an update message with its own AS number in the AS path attribute, this means that there is an AS path loop and by default such updates are discarded. In many scenarios this AS path check needs to be disabled, and seeing a the AS number of a router in the AS path attribute is fine. On SLX devices, this AS path check is enforced at the receiver and is overridden by means of the neighbor allowas-in command. However, enforcing this AS path check at the sender side can save the amount of RIBout memory used to store the routes that are discarded at the receiver. Furthermore, it avoids sending updates and withdraws those routes, thereby improving the convergence time.
The following example configuration shows how to enforce this check for a neighbor or peer group. This configuration is per address-family.
LeafC_2(config-bgp-router)# address-family ipv4 unicast LeafC_2(config-bgp-ipv4u)# neighbor 163.124.20.10 enable-peer-as-check
A neighbor reset is required for the preceding configuration to take effect. After it is applied, this configuration prevents Network Layer Reachability Information (NLRI) from being added to the RIBout of the peer if the AS path segment of the NLRI has the AS number configured as "remote-as" for the neighbor.