EVPN-VXLAN Explainer 2 - The BGP Session

In this second post I will look at Ethernet VPN (EVPN), what is it and how to configure a BGP EVPN session on Aruba devices.

Please note, this post will focus on the establishment of the BGP EVPN session between peers, and thus will not present a fully functioning EVPN network. I aim to build the configuration up in stages to enable the reader to confidently understand the different pieces of EVPN-VXLAN as a technology.

Ethernet VPN - the VPLS successor seen about campus

Reading through EVPN RFCs one gets an impression of its convoluted development, or rather, the evolving area of focus for its application.
To summarize, it started life as a service-provider focused VPLS successor, then jumped over to the control plane for virtualized data centres, now gaining a foothold in campus networks.
I put together an overview of the various RFCs here.

EVPN - what is it used for?

In the first post in this series, I explained the VXLAN forwarding process, that relies upon flood and learn.

• VXLAN is a data plane technology, concerned with the forwarding of packets and what headers to add to data.
• EVPN is a control plane technology, concerned with building a view of the network by exchanging information about local MAC addresses that an EVPN speaker knows about.

Without a control plan, VXLAN VTEPs must wait until they receive traffic from end client devices locally and from the VXLAN network via other VTEPs, in the data plane (data plane learning).
In contrast, when EVPN devices hear from a local client, they share this information with their remote EVPN peers using control plane learning. Thus EVPN devices can build a view of the network, both local and remote clients, without the need for traffic from the clients hitting them. This can reduce the inefficient flooding of unknown unicast packets.
In addition, EVPN speakers share information about their local configuration, and tell others what VXLAN VNIs they have configured, essentially what VPNs they are a part of. That helps reduce the manual configure on each device, now there is no need to configure all those static VTEP peers under each VNI (see post 1 for more information on this static configuration).
In summary, EVPN works at the control plane to exchange client MACs, while VXLAN works at the data plane to encapsulate customer traffic and allow Layer 2 frames to traverse Layer 3 boundaries.

EVPN - what is it?

EVPN is an extension to BGP, also known as a BGP address-family. The way EVPN is configured, forms adjacencies between speakers, and exchanges information, is all based upon BGP. If you want to learn EVPN, make sure you understand BGP in depth first.

Example Underlay Network

Before we get into the details and packet captures, here is my example network.
I'm going to focus on just two EVPN devices, both Aruba 6300s. This is a subset of the network from the first blog post in this series.
I'm using loopbacks as the BGP connection source interface and running OSPF as the IGP to advertise these loopbacks.

Establishing an EVPN adjacency

To exchange EVPN information between peers, devices in a network must form adjacencies. As a BGP address-family, the connections use the BGP finite state machine to make the initial connection (TCP, port 179) and exchange BGP specific information.
The process is as follows:

1. Idle - A BGP speaker is actively listening for connections on TCP port 179, and initiating such connections.
2. Connect - If the TCP connection is successful, a BGP OPEN message is sent to the peer. The BGP OPEN contains 'Optional Parameters' data, which contains the address-families that the device is configured to support, including EVPN. See the section on 'BGP OPEN' below for further details.
3. Active - if TCP fails at the Connect stage, the device moves to Active, during which is continues to actively form a TCP connection with its BGP peer.
4. OpenSent - The BGP speaker, having sent a BGP OPEN message, listens for an OPEN from its peer. Once received, details are compared against local configuration, such as IP address and AS number. If there are no errors, the device sends a BGP KEEPALIVE and moves to OpenConfirm.
5. OpenConfirm - the BGP speaker waits for a BGP KEEPALIVE from its peer to confirm that it also detected no errors in its OpenSent phase. If a KEEPALIVE is received, the local device moves to the Established state.
6. Established - The BGP speakers exchange BGP UPDATE messages, these contain information about any routes they know.

Example BGP session packet capture

BGP OPEN

The BGP OPEN message contains various information about the sending BGP speaker, and includes 'Optional Parameters' that lists the 'Capabilities' of the device.
It is here that devices advertise that they are configured for Multiprotocol extensions, such as EVPN.
There are defined codes that devices must use to signal such support, these are named the Address Family Indicator (AFI) and Sub-Address Family Indicator (SAFI).

• To indicate EVPN support, the device must send an AFI of 25, for Layer-2 VPN, and a SAFI of 70, which is the code for EVPN itself.
• See RFC 7432 Section 20 for details.

You can see this data, including the AFI/SAFI in a wireshark capture of a BGP OPEN, as in Figure 3 below.

BGP EVPN Session Configuration Example

For this example, I am using the 'Example Network' in Figure 1 above, focusing on just two EVPN peers.
Please note that I am building the configuration up in stages in order to focus on each part in turn. This is just to build the BGP EVPN session, it is not a complete EVPN config, which will be shown in the next blog post.

Config Notes

• This config snippet effectively builds the underlay network.
• VLAN 2010 is configured as a transit VLAN between 6300-1 & 6300-2.
• Port 1/1/10 connects to an L2 only transit switch in my lab (not shown), and is configured as a trunk.
• An SVI interface acts as the Layer 3 interface forming a point-to-point network between 6300-1 and 6300-2.
• OSPF is used as the IGP to advertise loopbacks
• All OSPF interfaces are in Area 0.
• BGP sessions are built using said loopbacks as their source.
• Internal BGP is used here, both devices are in AS 65001.
• Global BGP configuration designates basic parameters for peering, such as AS, peer IPv4 address, and source interface.
• Address-families, such as IPv4, IPv6, and L2VPN EVPN, are activated separately.
• EVPN can be configured as the only active address-family, IPv4 is not required.
• Note that the name of the address-family in the CLI follows the AFI/SAFI naming; 'l2vpn evpn'.

Verification

#show bgp l2vpn evpn summary

#show bgp l2vpn evpn neighbor

Summary

At this stage the BGP peers have established a BGP session and are both aware that the EVPN address-family is active.
However, neither device has been configured to learn, and thus advertise, any routes. Nor have we configured VXLAN. So there is much to do!
I will cover those steps in my next post as I build up the configuration in stages.

🐦 @joeneville_