EVPN VxLAN has become the de facto solution for multi-tenant overlay networks in the datacenter in recent years and has been deployed by numerous customers spanning many different verticals. Even though the IETF has been at work with EVPN standards for over a decade, it has become mainstream in the Data Centers only for a few years now (and still evolving), primarily because of the varied scale, migration, interoperability, services, operational and management requirements and challenges across different customers. This makes it imperative for any new vendor solution in this space to provide the required flexibility and simplicity for ease of adoption.
In this blog, I will review how ArcOS, a modern network operating system, exactly addresses these challenges, making it the operating system of choice for EVPN deployments.
When I think of flexibility, I typically lead with the following questions –
- Can it support my specific deployment model?
- Can I test it easily before I deploy?
- Do I have choice of hardware SKUs on which to deploy?
- Is it interoperable with vendor X and Y?
- Does it scale to my deployment needs?
- Can I manage it with the tools I am comfortable with?
In the context of EVPN this falls under 2 categories
- Deployment – underlay & overlay choices, dual stack, services, route reflection
- Operational – test before prod (VM), hardware, scale, interoperability with other nodes in the network
Underlay & Overlay choices
With EVPN adoption across so many verticals, different customers have different preferences and experiences with routing protocols and different restrictions with existing topologies. For example, enterprise customers tend to prefer interior gateway protocols (IGPs) such as OSPF or ISIS over multi-protocol Border Gateway Protocol (MP-BGP). Therefore, their IP underlay networks exclusively run an IGP even in their existing datacenters. Whereas, if you take a cloud datacenter, it is very likely using BGP exclusively following the MSDC RFC 7938.
As such, there will always be debates on what is the “best” design, however it’s really dependent on the customer variables outlined and therefore what is vital is that the product offering supports any flavor of underlay and overlay routing options. ArcOS provides maximum flexibility to customers by supporting any of these combinations – an IGP in the underlay with iBGP EVPN peering in the overlay using route-reflectors, eBGP in the underlay and eBGP EVPN in the overlay, eBGP in the underlay and iBGP EVPN in the overlay and vice versa.
With reference to underlay and overlay flexibility; many EVPN VxLAN deployments run over an IP CLOS underlay, and thus the software itself must support high scale ECMP, consistent hashing and fast convergence. ArcOS excels in this case.
The figures below illustrate some of these supported overlays and underlay routing options using ArcOS and ArcRR.
Figure 1. ISIS Underlay
Figure 2. eBGP Underlay
Figure 3. iBGP EVPN IPv4 Overlay
Figure 4. iBGP EVPN IPv6 Overlay
Figure 5. eBGP EVPN IPv4 Overlay
Figure 6. eBGP EVPN IPv6 Overlay
It is worth noting that although ArcOS running on switches can provide inline EVPN route reflection services, in the figures above ArcRR, our high performance, route reflector, based on ArcOS is shown providing this function. ArcRR affords another level of deployment flexibility for customers, separating overlay route reflection functions and allowing customers to run ArcRR just for control plane functions, thus taking advantage of the massive scale and performance that ArcRR can provide. This also allows the IP CLOS network to be free of overlay state. For most customers, placement of route reflection with EVPN is an operational decision that is tied to their preferences, restrictions and resources and ArcOS EVPN solution offers that. Furthermore, deploying ArcRR as Docker instances for EVPN deployments also enables possibilities for centralized policy control points and “visibility hubs” when paired with telemetry capabilities of ArcOS.
Customers often deploy a mix of service types, from Layer 2 stretch only, to distributed gateway deployments often referred to symmetric and asymmetric IRB (integrated routing and switching), or Layer 3 only deployments akin to Layer 3 VPNs. Furthermore, there is often the need for resilient service attachments either using Layer 2 or Layer 3 multi-homing. ArcOS supports any combination of these services, and importantly supports both IPv4 and IPv6 at scale in the EVPN overlay for dual stack deployments with ARP/ND suppression capabilities. Finally, ArcOS supports EVPN all-Active multi-homing, providing customers the option to deploy a standards-based resilient service attachment.
ArcOS can be deployed as a VM for EVPN lab testing or network simulation tasks and of course on various hardware switches and routers.
Finally, the fundamental reason customers are adopting EVPN, particularly in the datacenter, after several iterations of proprietary, closed fabric technologies, is because it’s an open, standards-based architecture supported by several vendors on several products. Please checkout https://www.arrcus.com/resource/eantc-2020/ to learn more about Arrcus participation in the EANTC 2020 multi-vendor interoperability testing for EVPN and other areas.
Simplicity is a multifarious term. For some customers, simple means simple to configure, simple to manage, operate and troubleshoot. For other customers, it is more important that the product is simple to integrate into existing automation and management tools. ArcOS is built on the architectural principles of scalability, security and simplicity. Let us review this in the context of EVPN.
Simple Configuration and Operation
Many customers still use command line interface (CLI) as the primary method to interact with the system, as such it is imperative to have a simple and intuitive CLI. ArcOS delivers this intuitively with a stanza based CLI with common operations grouped and indented, making reading the CLI very easy.
Figure 7. ArcOS CLI BGP EVPN Configuration
A core principle ArcOS employs is to reduce the knobs for minimal viable deployment and employ sensible and relevant defaults to assist those customers configuring using the CLI. For EVPN, as an example, ArcOS implements Auto-RD/Auto-RT (RD – Route-Distinguishers, RT-Route-Targets) making EVPN Layer 2 VRF configuration extremely simple. However, while the config may be minimalist the show command outputs for troubleshooting are quite extensive as shown below.
Figure 8. Show Command Output for MAC VRF VLAN10
EVPN networks are critical infrastructure for customers to deliver multi-tenancy as a service. Automating change management and making it less prone to human errors is critical tenet of operating such an infrastructure. The ability to easily integrate a product into this framework is important.
ArcOS provides configuration commit, confirm, check and rollback on-box capabilities for device-level management. Furthermore, in ArcOS all configuration and operational state is natively stored in open, vendor neutral, YANG-based OpenConfig models. Support for these models and the standard programmatic interfaces of NETCONF, RESTCONF and gRPC, allows ArcOS to be integrated into any management systems via open, standards-based RPCs using structured data-encoding of XML, JSON and Protocol buffers respectively. Furthermore, there is a Python-based API (ArcAPI) providing another simple, yet programmatic interface into ArcOS. ArcOS also allows easy integration of DevOps tools like Ansible for customers to adopt a CI/CD pipeline to deploy EVPN VxLAN fabrics.
It cannot be overstated enough, all of the above system integration capabilities greatly de-risk operational changes and management of critical networks.
In summary, we have seen how ArcOS EVPN solution offers flexible deployment options with various attributes of simplicity and ease of management and operations. Check out the video below for a closer look.
Have an EVPN deployment? Looking for a modern OS with an easy to adopt EVPN solution? Reach out to us and checkout www.arrcus.com for more information.