Leveraging Routing in Fat Trees (RIFT) Zero Touch Provisioning (ZTP) for EVPN-VXLAN fabrics with Auto-EVPN
There’s no question that the go-to in modern data center designs is an IP fabric to provide base connectivity, overlaid with EVPN-VXLAN to provide end-to-end networking. Today, IP fabrics are commoditized just like the x86 hosts that are connected to the fabric.
Provisioning EVPN-VXLAN overlays in data center fabrics without a controller or orchestration is considered a complex task since it requires over 100 lines of configuration per node for a simple scenario. For example, imagine what it would take to configure complex architectures and provision tunnels over a large fabric with tens – or even hundreds – of nodes.
New IETF Draft Addresses EVPN Complexity
In this blog, we’ll examine a new feature the Internet Engineering Task Force (IETF) is developing that helps operators provision an EVPN-VXLAN overlay on top of a RIFT IP fabric with minimal configuration: Auto-EVPN. In the name itself, Auto-EVPN already gives away some of its workings. Currently, the Auto-EVPN feature is in draft status, meaning it isn’t standardized in an RFC or publicly available yet.
Leveraging the Underlay to Provision the Overlay
While the “What is the best data center underlay?” discussion will probably never settle the newest kid on the block, Routing in Fat Trees (RIFT) offers several interesting features that can make network operators’ lives a whole lot easier. Think about minimal configuration leveraging Zero Touch Provisioning (ZTP), unequal load balancing and highly optimized flooding, to name a few.
RIFT ZTP allows a node to disseminate Key-Value information contained in Key-Value Topology Information Elements (KV-TIEs) within the fabric underlay. These KV-TIEs can contain any information and therefore, they can be used for many purposes, including the provisioning of overlays.
Design Considerations
Each EVPN service model has its own set of deployment requirements. For example, a functional BGP overlay is necessary to exchange EVPN Network Layer Reachability Information (NLRI), regardless of the service model. Furthermore, there are many variables, such as each node’s loopback address and AS number for the BGP session. Some of these variables may be coordinated across each node in a network, but are locally significant to a node (e.g. route distinguishers). Similarly, the calculation of some variables is local to each device. In order to fully provision EVPN in an IP fabric, there are a few requirements, including: a perfectly working underlay that offers reachability, IP and ASN plan, IBGP full mesh configuration or route reflectors to advertise EVPN NLRIs to the nodes, a MAC-VRF and VLANS defined, etc. It’s easy to see where those hundreds of lines of configuration we’ve previously mentioned come from.
Deploying RIFT with Auto-EVPN Enabled
A RIFT underlay contains enough topology information in each node to calculate the necessary variables automatically. In a greenfield fabric deployment, the nodes are only required to have IPv6 address configured on each interface and enable RIFT protocol with the Auto-EVPN feature.
Once RIFT is activated with the Auto-EVPN feature, it automatically provisions the nodes that take part in the EVPN overlay with fabric/edge interfaces, node roles and address plans. It also configures Top of Fabric nodes as BGP route reflectors, establishes IBGP sessions with nodes in the fabric and uses those sessions to exchange the MAC/IP information that EVPN needs, including MAC-VRF and pre-defined VLANS.
Now that our IP fabric is running RIFT in the underlay and EVPN in the overlay, we can leverage that overlay to tunnel Layer 2 packets with VXLAN by simply configuring the leaf nodes (or servers, in case they are participating in RIFT) with the correct VLANs that are defined in the MAC-VRF.
What About Controllers?
In this case, the fabric operator still must provide and configure MAC-VRFs and define VLANs on the edge nodes. That’s where a controller is still of huge value. Additionally, a controller can configure and manage ports and VLANs on the end-nodes or hosts, further simplifying and easing the network operator’s life. A controller also brings additional value by providing monitoring and analytics capabilities to further streamline operations.
Conclusion
In smaller or less-dynamic fabrics, Auto-EVPN helps save time and provides a consistent and reliable method to provisioning EVPN-VXLAN overlay networks. Auto-EVPN also gives the operator additional tools and possibilities, including the extension of Auto-EVPN to the host through a containerized routing stack.
