Mellanox published a great blog entitled “How to Make Your Leaf/Spine Network Hum.” As I read this blog I realized that the recommendations were aligned incredibly well with features of an Intent-Based Network implementation. In short, an Intent-Based Network implementation enables simple data center automation, rapid deployments, reduced OpEx, and multi-vendor lifecycle management for leaf-spine networks. Next, I’ll highlight the features of an Intent-Based Network implementation in the context of the eight tune-ups mentioned in Mellanox’s blog post.
#1 The first tune-up is about achieving high performance through ECMP that’s inherent in leaf-spine networks (aka Clos or L3 Clos networks). An Intent-Based Network implementation takes care of configuring ECMP (across any switch vendor, of course) but it also monitors that traffic is indeed balanced in real-time. It alerts you to any imbalances using an Intent-Based Analytics (IBA) probe called ‘ECMP Imbalance.’ The net effect is you get anomalies whenever your ECMP fabric is not balanced, perhaps due to elephant-mice flows, link failure, etc. Visibility is a first step toward resolution.
#2 The second tune-up is a non-disruptive failover with the solution being the use of resilient (as opposed to static) hashing. From my research, resilient hashing is enabled by default on switch platforms (e.g. Cisco, Cumulus). I’d like to highlight a few different parts of an Intent-Based Network implementation that are relevant to this problem. One is the ability to have an IBA probe to validate resilient hashing is indeed configured on all switches in the fabric. The second — using an Intent-Based Network implementation, you can configure resilient hashing on platforms where this is not the default. Lastly, the effect of out-of-order packets is typically degraded application performance, so we can use active probing like a pingmesh to have network performance monitoring within an Intent-Based Network implementation.
#3 The third tune-up is hitless upgrades. Doing these upgrades on a fabric managed by an Intent-Based Network implementation gives you a lot more confidence due to real-time, meaningful and deep analytics built into an Intent-Based Network implementation. For example, you can monitor ECMP and ensure it’s still retained, that your server facing LAGs are all up and the performance drop is not abnormal, etc.
#4 The fourth tune-up is automated network provisioning. An open-source multi-vendor ZTP server can take care of automating the switch boot process and startup config. Beyond that, automating the entire network lifecycle is what an Intent-Based Network implementation is purposefully built to solve. To do this, you are not forced to use proprietary features or fancy control planes. An Intent-Based Network implementation is purely at the management plane and makes use of the standards based, widely deployed, well-tested feature sets from switches in the way they are intended to be used.
Delivering turn-key solutions in this regard using battle-tested industry standard reference designs for leaf-spine networks provides confidence with the final design.
#5 The fifth tune-up is stretching VLANs and multi-tenancy. An Intent-Based Network implementation comes with first-class EVPN support which is fully multi-tenant with use of VRFs. EVPN is great because it’s not only controller-free, it also includes a distributed control plane, is standards based and built on the highly scalable and most battle-tested network protocol of all, BGP. An Intent-Based Network implementation with EVPN offers an even more simplified operational model for you, shielding you from switch vendor idiosyncrasies and topping it off with closed-loop telemetry. Given an Intent-Based Network implementation automates configuration management, we make it easy to do the right thing without compromising. For example, the use of a unique ASN per device gives you ease of troubleshooting but is often not done due to the increased cost of managing configuration. Similarly the use of symmetric routing in EVPN is avoided to save on config management complexity at the cost of scalability. When the computer does the configs, you start thinking from a different perspective. Generally speaking, reference designs are sometimes misused to diminish choices for customers. But with an Intent-Based Network implementation a lot of flexibility is available within a reference design with many smart defaults that are overridable. You are still the boss.
#6 The sixth tune-up is about IP mobility without overlays. This could be referred to as L3 to the host and this is one of the first-class patterns in any good reference design and is typically popular with container workloads on Kubernetes, etc. An Intent-Based Network implementation will even automate the provisioning and configuration of dynamic routing protocol stacks on the servers. You can use an Intent-Based Network implementation to extend the scope of monitoring beyond just the leaf-spine switches in the fabric. For example, the ping tests can now be performed from server to server to get a true end-to-end picture.
#7 The seventh tune-up is about being smart in managing costs of optics. Most of this is achieved outside the purview of an Intent-Based Network implementation, but believe it or not, even here an Intent-Based Network implementation can help you look at this problem holistically at the network level instead of switch by switch. You can ask questions such as “Am I using optics from vendor X anywhere in my fabric, or alert me if an optic from a vendor that is not in the approved list shows up in the network, etc.”
#8 The eighth tune-up is about being smart in managing the costs of the switches and switch operating system software. The solution here is having freedom and options. You can always fake that you have freedom with your switch vendor but if you are using their switches, their OS, their management software, their monitoring software and more, the depth and strength of lock-in is sometimes too apparent. Or you have a lot of home-grown automation and monitoring software whose developers are long gone and you know it is impossible to extend (and maintain) this for a brand new OS platform and all associated versions. An Intent-Based Network implementation solves this problem and gives you that leverage, which is real. An Intent-Based Network implementation gives you a single pane of glass and a uniform operational model across any network vendor. A good Intent-Based Network implementation takes care of validating the different combination of switch hardwares, operating systems and routing protocol stacks combination for you.
In summary, leaf-spine networks are the way to go and an Intent-Based Network implementation is your best bet in helping you get there. An Intent-Based Network implementation can also help with discovering your existing brownfield leaf-spine networks so you have a single tool for all your modern data center networks.