This chapter describes the components of EVPN-VXLAN Layer 2 on SR Linux.
Basic configuration of EVPN-VXLAN L2 on SR Linux consists of the following:
Example:
The following example shows a basic EVPN-VXLAN L2 configuration consisting of a vxlan-interface, MAC-VRF network-instance, and BGP-EVPN configuration:
EVPN Layer 2 (without multi-homing) includes the implementation of the BGP-EVPN address family and support for the following route types:
The MAC/IP route is used to convey the MAC and IP information of hosts connected to subinterfaces in the MAC-VRF. The IMET route is advertised as soon as bgp-evpn is enabled in the MAC-VRF; it has the following purpose:
Advertisement of the MAC/IP and IMET routes is configured on a per-MAC-VRF basis. The following example shows the default setting advertise true, which advertises MAC/IP and IMET routes.
Note that changing the setting of the advertise parameter and committing the change internally flaps the BGP instance.
Example:
The creation of VXLAN destinations of type unicast, unicast ES (Ethernet segment), and multicast for each vxlan-interface is driven by the reception of EVPN routes.
The created unicast, unicast ES, and multicast VXLAN destinations are visible in state. Each destination is allocated a system-wide unique destination index and is an internal NHG-ID (next-hop group ID). The destination indexes for the VXLAN destinations are shown in the following example for destination 10.22.22.4, vni 1
The following is an example of dynamically created multicast destinations for a vxlan-interface:
When a MAC is received from multiple sources, the route is selected based on the priority listed in MAC selection. Learned and EVPN-learned routes have equal priority; the latest received route is selected.
When multiple EVPN-learned MAC/IP routes arrive for the same MAC but with a different key (for example, two routes for MAC M1 with different route-distinguishers), a selection is made based on the following priority:
You can configure the BGP next hop to be used for the EVPN routes advertised for a network-instance. This next hop is by default the IPv4 address configured in interface system 0.0 of the default network-instance. However, the next-hop address can be changed to any IPv4 address.
The system does not check that the configured IP address exists in the default network-instance. Any valid IP address can be used as next hop of the EVPN routes advertised for the network-instance, irrespective of its existence in any subinterface of the system. However, the receiver leaf nodes create their unicast, multicast and ES destinations to this advertised next-hop, so it is important that the configured next-hop is a valid IPv4 address that exists in the default network-instance.
When the system or loopback interface configured for the BGP next-hop is administratively disabled, EVPN still advertises the routes, as long as a valid IP address is available for the next-hop. However, received traffic on that interface is dropped.
Example:
The following example configures a BGP next hop to be used for the EVPN routes advertised for a network-instance.
MAC loop prevention in EVPN broadcast domains is based on the SR Linux MAC duplication feature (see MAC duplication detection and actions), but considers MACs that are learned via EVPN as well. The feature detects MAC duplication for MACs moving among bridge subinterfaces of the same MAC-VRF, as well as MACs moving between bridge subinterfaces and EVPN in the same MAC-VRF, but not for MACs moving from a VTEP to a different VTEP (via EVPN) in the same MAC-VRF.
Also, when a MAC is declared as duplicate, and the blackhole configuration option is added to the interface, then not only incoming frames on bridged subinterfaces are discarded if their MAC SA or DA match the blackhole MAC, but also frames encapsulated in VXLAN packets are discarded if their source MAC or destination MAC match the blackhole MAC in the mac-table.
When a MAC exceeds the allowed num-moves, the MAC is moved to a type duplicate (irrespective of the type of move: EVPN-to-local, local-to-local, local-to-EVPN), the EVPN application receives an update that advertises the MAC with a higher sequence number (which might trigger the duplication in other nodes). The “duplicate” MAC can be overwritten by a higher priority type, or flushed by the tools command (see Deleting entries from the bridge table).
The EVPN multi-homing implementation uses the following SR Linux features:
EVPN relies on three different procedures to handle multi-homing: DF election, split-horizon and aliasing.
To support multi-homing, EVPN-VXLAN supports two additional route types:
Local bias for EVPN multi-homing is based on the following behavior at the ingress and egress leafs:
In SR Linux, the local bias filtering entries on the egress leaf are added or removed based on the ES routes, and they are not modified by the removal of AD per EVI/ES routes. This may cause blackholes in the multi-homed CE for BUM traffic if the local subinterfaces are administratively disabled.
The following is an example of an EVPN multi-homing configuration. In this example, the system network-instance is configured with an Ethernet segment, which is associated to all network-instances of type mac-vrf that contain a specified subinterface.
The system network-instance is configured with Ethernet segment ES-1 as follows:
The following configuration causes Ethernet segment ES-1 to be associated to all network-instances of type mac-vrf that contain a subinterface in ethernet-1/2:
To display information about the ES, use the show system network-instance ethernet-segments command. For example:
The detail option displays additional information about the ES. For example: