• Blending intent-based networking with traditional network management paradigms, while a necessary transitional requirement, is fraught with peril.
• Committing fully to intent-based networking will drive all subsequent workflow and product changes and will result in overall better IT.
I recently wrote about the nascent developments around intent-based networking (IBN), specifically, that a system can automate the provisioning of a network based on a very high-level state of what the result should look like. It’s a laudable goal and, I think, still a few years and a few iterations away from reality, but getting there – even any widespread adoption of automation and orchestration – starts with your company’s unwavering commitment to IBN and automation.
One of the reasons IBN is attractive is because it automates and orchestrates all of the menial tasks network professionals spend time doing by pounding a CLI or clicking through myriad steps in a GUI to implement configurations in the network – a scenario fraught with peril. The fear is that invalid changes can take effect network-wide, which would be difficult to recover from – the equivalent of changing the management IP on a switch without first making it reachable (we’ve all done it or something like it). Now a reliable IBN will have a way to stop invalid changes or a way to quickly back out of changes; I’ll get into some of those in a later post, but the critical point is IT will have to radically change workflows and embrace automation.
There is no value in having a person manually configuring a network. None. This means that either via technology or policy, network IT needs to be banned from CLI configuration access. If you flip Cisco Nexus 9000 switches to ACI mode, configuration access via CLI is not available. That’s how it should be, because nearly everything IT needs to do is managed by the APIC controller. Automating network changes is complex enough. Adding facilities to detect and reconcile to changes made by a controller and by a CLI is infinitely more difficult and, similar to having admins pound a CLI, entirely unnecessary.
On the other hand, Cisco’s new DNA Center currently requires both controller and CLI access since a number of element management features for networking devices are not yet managed by DNA Center. This dual management mode presents opportunities for configuration collision – something DNA Center, I am told, detects. It also means IT will have to establish processes where network administrators have to build workflows to avoid configuration collision, and as Cisco develops DNA Center features, those workflows will have to be updated.
I’m not just picking on Cisco, but its two approaches to IBN and network automation manifested in ACI and DNA are relevant examples of how automation changes IT. But we’ve been here before. The push/pull between using a GUI-driven network management system and CLI simultaneously manifests similar problems which are addressed by configuration management products, change control processes, and other costly IT workflows to ensure conflicts don’t arise and to establish recovery plans when needed, all because IT couldn’t (or wouldn’t) commit to a single management paradigm. Let’s not repeat those lessons.
For an enterprise to be successful with intent-based networking, it needs to fully embrace automation in the data center, the campus, the wide area, and in the branch. Partial commitment will only end in tears as you spend time needlessly resolving problems of your own making. Put in place a plan that will take you from manual configuration to IBN or extensive automation. Specify your technical requirements and goals and perform a GAP analysis. Then, work to close the gaps.