When Pluribus announced BGP EVPN support almost a year ago as part of our thousand-node fabric architecture, we emphasized the benefits of deploying BGP EVPN at the edge of a Pluribus Adaptive Cloud Fabric for fabric extension and interoperability.
Since then, some customers have asked whether Pluribus can create an overlay using BGP EVPN throughout the fabric, like other vendors do, and not just at the edge. The answer is “yes” we absolutely can do that, but unlike other vendors, we can apply the power of SDN automation to make it simpler.
I asked Pluribus VP of Product Management Alessandro Barbieri to explain.
JG: First, let’s review. Why are customers interested in BGP EVPN for data center fabrics?
AB: Network architects are trying to build scalable, agile data center fabrics that can meet the challenges of private clouds. BGP EVPN is simply one tool that may help achieve that goal.
There is widespread agreement that the right way to build private cloud infrastructure is with “Layer 3 + VXLAN” fabrics. These combine scale-out, modular leaf-spine architecture built with high-performance fixed-form factor switches in a resilient underlay based on layer 3 protocols, and an overlay network based on VXLAN to provide network virtualization with layer 2 and layer 3 service plus multi-tenant segmentation.
BGP EVPN is one way to create those VXLAN overlays. It’s a protocol-based approach that is popular because it provides a standards-based, multi-vendor and highly scalable control plane for the overlay. BGP EVPN helps scalability by doing several things well, including creating a mesh of VXLAN tunnels, discovering Virtual Tunnel End Points (VTEPs) without any external controller or provisioning system, leveraging BGP capabilities for multi-tenancy, and implementing broadcast suppression techniques.
JG: What’s the biggest challenge with BGP EVPN?
AB: Because it is protocol-based, BGP EVPN requires a lot of complex configuration in every switch in the network. Without some kind of automation tools or frameworks, users have to go through the network, box-by-box, to create the fabric and to provision every new service. Consider a simple requirement to provision a layer 3 VPN across a fabric of 128 nodes. Every single node needs around 20 lines of config code, which adds up to around 2500 lines of code. From an operational perspective, BGP EVPN is actually not a simple proposition for most customers. It really needs help.
JG: How does Pluribus help customers who want a BGP EVPN fabric?
Some operators are building their own automation frameworks, based on Python scripting or Ansible or other tools because they understand how to do it and they want full control. For those customers, we are happy to deliver our Netvisor ONE network operating system (NOS) on the customer’s open network switching hardware of choice and let them program and automate BGP EVPN the same way that they could do it with other NOS’s such as Arista EOS or Cumulus Linux.
However, that’s not the end of the story. Unlike most vendors, we can apply the power of SDN automation built into the Adaptive Cloud Fabric to deliver BGP EVPN overlays with an order-of-magnitude simplification. Remember that layer 3 VPN that required around 20 lines of code per switch? Instead of entering 20 lines per switch, you can enter 3 lines in the Pluribus ACF and it takes care of programming the full BGP EVPN configuration. It’s the exact same BGP EVPN configuration in the switch but created with about one tenth the effort.
JG: So that makes life simpler for DIY customers who want to use BGP EVPN. What about everyone else?
AB: A lot of network operators don’t have the time or skills to create a DIY automation capability for BGP EVPN. They may look to 3rd party automation software, but those products also require a fair amount of work to integrate and may not be a fit for everyone.
For these customers, maybe the best answer is not to use BGP EVPN at all.
Remember how I said BGP EVPN is only one way to create a VXLAN overlay fabric? Another way is to use a protocol-free SDN-driven approach, which is exactly what we have in the Adaptive Cloud Fabric. The distributed SDN control plane not only automates VXLAN infrastructure discovery and provisioning, it allows the user to program the entire fabric as a single logical switch with a declarative object model.
JG: What does that mean in practice?
AB: Going back to that example of configuring a service across a 128 node fabric, which requires almost 3000 lines of code in a BGP EVPN box-by-box configuration, the same service can be configured across the entire fabric with just three lines of configuration in the Adaptive Cloud Fabric. That’s three orders of magnitude simpler.
Provisioning L3 VPN service across 128 node fabric
Then, if a Pluribus fabric needs to interoperate with another vendor’s BGP EVPN fabric, we create a BGP EVPN border gateway on a leaf switch or cluster, so just one or two switches in the fabric are configured with BGP EVPN instead of every switch. That EVPN border gateway extends services to other fabrics by translating the Pluribus SDN protocol-free control plane to the standard BGP EVPN protocol-based control plane and stitching together the VXLAN tunnels that carry the overlay service traffic.
That’s what we call the best of both worlds: the SDN automation and operational simplicity of the Pluribus fabric plus the ability to interoperate and extend services to other fabrics using BGP EVPN.
- Blog: BGP EVPN for Scaling Data Center Fabrics: Pros and Cons, Deployment Options and Trade-offs
- Demo Series Webinar: BGP EVPN or SDN for Building Data Center Fabrics?
Join the experts!