Skip to content 
Introduction
In today’s dynamic business landscape, migrating networks and IT resources have become common, particularly for larger enterprises and communication service providers (CSPs). While smaller companies may not experience this to the same extent, migration is considered a regular occurrence for many. In some ways, it signifies progress, expansion and supports the ever-evolving requirements of an organization. However, amidst this transformation, a significant challenge arises—the creation and eventual coexistence of multiple technology stacks that make it challenging to manage, organize and automate the underlying infrastructure.
For example, imagine a company that utilizes customer edge (CE) routers at specific sites, forming part of an L3VPN or a group of L3VPNs on the provider side. Concurrently, assume that this company has embarked on a migration to SD-WAN at selected sites. During the automated migration process, a potential challenge arises about Virtual Routing and Forwarding (VRF) names. On the CE routers, VRF names do not necessarily need to be identical as long as the WAN sub-interfaces are appropriately mapped on the provider edge (PE) end, and essential properties like communities and protocol configurations remain consistent. However, on the SD-WAN side, the “VPN <no>” identifier becomes crucial, serving as a unique identifier for specific departments or network segments. In this context, the VRF names must be uniform across all sites. So, scraping the details from the old CE routers, migrating, and subsequently using them to build SD-WAN configurations could be challenging if something like VRF names differ at every site.
Digging deeper
Different routing and switching technologies
When it comes to switching, STP horror stories abound, but for the right reasons, the industry is moving to technologies like EVPN-VXLAN. These platforms were primarily created for data center environments but they are quickly making inroads into campus networks. However, STP still exists in pockets of sites or parts of isolated network segments.
Similarly, when it comes to routing, MP-BGP with MPLS, LSP, and RSVP-TE have existed for a very long time in CSP clouds, but segment routing is beginning to be deployed in portions of CSP networks too.
Different WAN technologies
Larger enterprises are deploying their own ISP-style clouds to minimize L3VPN service expenses and are also migrating to simple Layer 2 connections from local and global ISPs between their data centers and significant sites.
Equally important is the fact that these organizations are also considering cloud-based or on-premises SD-WAN solutions for flexibility. Besides providing edge devices that require management, these solutions have their own controllers with Northbound APIs, webhooks, and integrations that introduce further complexity.
Different security technologies
Historically, smaller branch sites were protected behind small single-box firewalls, medium-sized sites protected behind medium-sized firewalls, and bigger sites protected behind large firewalls. However, given the nature of security breaches and attacks witnessed nowadays, this approach is no longer tenable.
What is required are next-generation firewalls (NGFWs) with controllers that configure every aspect of Layer 1 to Layer seven security and connectivity across multi-cloud and on-premises. Additionally, emerging solutions such as SASE must be deployed on endpoints, cloud resources, and WAN devices, creating the need for strong automation and orchestration tools.
Different modes of device and controller management
CLI has served as the primary method for managing network and server equipment. When it comes to peripheral IT resources like IPAM and other kinds of inventory databases, it is via Web GUI. However, modern infrastructure provides new interfaces. As an example, routers, switches, firewalls, and related controllers all support CLI, REST, and RPC (NETCONF, GRPC) APIs.
With respect to network data collection, Syslog and SNMP have become de-facto standards. However, devices with telemetry support can now provide data in much more granular, organized, and modern formats like XML and JSON, making it much easier to build actionable logic on top in a vendor-agnostic manner.
The following chart details specific technology categories, associated tools, and the transition scenario:
| Technology Category | Key Legacy and New Technologies | Current Transition Scenario |
|---|---|---|
| Switching | STP | Running in legacy network segments on the campus. |
| EVPN-VXLAN | Campus Environments are starting to look more like Data Center Environments. End-to-end Segmentation. | |
| Routing | MPLS, RSVP-TE | In the core of CSP networks, these were the norm for over two decades and are still widely used. |
| Segment Routing | This is in different stages of deployment in different CSPs | |
| WAN Technologies | L3VPN, Layer 2 connections | Larger Enterprises deploy ISP-style clouds for cost savings on L3VPN services and greater control of routing mainly for DC and Larger sites. |
| Cloud or On-Prem controller based SD-WAN | Smaller/micro sites being moved to internet connections with SDx edges. | |
| Security Technologies | Next-Gen Firewalls and Cloud Security Providers | Legacy FW technology moving to Next Gen FW Tech with controllers for improved config support for L1 to L7 security policies. Cloud Security added to the mix with SASE like upcoming technologies. |
| Device and Controller Management | CLI/SNMP/Web GUI(controllers) | CLI for node management and Web GUI for accessing early controllers was the norm. |
| REST/RPC APIs, Telemetry | Modern device OSes have in-built support for REST, RPC APIs, and Telemetry, which can be used for greater network control and management via XML, and JSON payloads, which are more vendor-agnostic. |
What’s needed?
Given the evolving landscape of information technology and the networking industry, it becomes evident that network operators and security engineers require two essential things:
First is a good raise… 🙂
Second, access to a versatile, flexible, ever-evolving network management and automation platform like Anuta Networks ATOM.
The first one is something that network engineers will have to manage on their own, but Anuta has you covered on the second one for sure. With features like workflow automation and the industry’s most comprehensive integration support, ATOM can automate any use case involving modern controllers, OSS/BSS platforms, and devices.
Each workflow task handles payload creation and API requests/calls to various systems to push/pull state data and actions. Smaller groups of such tasks can be made to handle more minor interactions. These smaller workflows can also act as smaller units of bigger workflows built to cater to more prominent use cases.
These same powerful workflows have been used internally by the Anuta engineering teams to build many features and support a growing list of customer requirements. Other features like service creation, closed loop automation, greenfield and brownfield network discovery, and services onboarding have all been implemented using workflows too.
Anuta continues to develop new integrations rapidly because of tools like the swagger builder, which can quickly take any platform or system’s swagger or Open API documentation and convert it into a library of workflow tasks. This provides Anuta’s users a great starting point for building great automation within custom environments.
ATOM accomplishes all of this while providing a single pane of glass to manage network FCAPS, services, and closed-loop automation needs. What if your company is in a transition phase or initiating migrations? In those scenarios,, ATOM is a go-to tool because it supports and hosts legacy and modern architectures on a single platform allowing for migratory use cases.
Stay tuned for more exciting blogs and other content on use cases that our architects are building for our current and future customers. Also, visit our website for more information on the topics discussed in this blog.
Additional Contributors: Sukirti Bhawna
