Today’s Challenge: Increased Complexity in the Network
From an end user’s perspective, it is standard practice to consider the enterprise network as a single entity. When a user is not able to connect to an application, it is common to hear phrases like, “The Network is Down” or “Someone Broke the Network.” However, to the enterprise networking team, their network is a complex mix of routers, switches, and many more devices that must be individually deployed, configured, upgraded, and optimized in order for the entire network to operate as a single entity, faithfully passing packets around exactly as intended and generally staying out of the user’s way.
Networks grow and evolve over time, which means devices that comprise the network are never static and the initial configuration they start with will also change over time out of necessity. As the number of network devices grows, the difficulty of managing every device’s configuration becomes increasingly more challenging. Recently, enterprise network infrastructure has experienced rapid expansion to include both on-prem and cloud-based elements, which means that network devices are dispersed across the Internet and can be physical, virtual, or even cloud-native. This has increased the complexity of the network and poses additional challenges to the networking teams who are responsible for managing the configuration of all of these devices, regardless of location.
The Phases of Network Configuration
Historically, network engineers have followed a framework of managing the lifecycle of a network device, like a router or switch, by classifying the device into a particular phase based on time and the configuration that is deployed on the device. This is a solid practice, and generally breaks down into a number of “Day” categorization, as follows:
Day 0
A new network device is installed and connected to the network, referred to as onboarding. A very basic configuration is created manually via CLI (Command Line Interface) or pushed to the device from a controller or server using a standard set of protocols supported by the vendor, referred to as ZTP (Zero Touch Protocol). This basic configuration provides the initial Layer 3 IP connectivity, normally applied to a management interface, and security settings so that the device can be remotely reached by end users and network management systems. At this early stage of device deployment, the Day 0 phase may require the use of several external sources of truth to provide the required configuration elements, like correct VLAN ID and IP address information matching a MAC address and the correct authentication credentials and settings for each device. The Day 0 configuration will then finally need to be validated to ensure that it can be reached over the network and the networking team can successfully gain administrative access to the device for further phases.
If the Day 0 process is done manually by a human using the CLI, it may take days or weeks to deploy all of the devices, depending on the total number of devices, the complexity of the network, and the number of systems that hold required information (sources of truth).
Day 1
Once the initial Day 0 configuration is complete and validated, the device is considered onboarded and a Day 1 configuration can be applied. Day 0 has onboarded the device on the network and made it available, and Day 1 builds upon this and applies a set of common, baseline configurations to groups of devices. These device groups can be defined by many factors like model, location, function, or geography and have a shared set of configurations between them. Some typical examples include configurations for the local NTP server, Syslog export settings to a regional server, SNMP credentials for global and local teams, or security rules for access services.
The information for what defines a group, which devices belong to a group, and what Day 1 configurations should be applied to the group must be clearly defined, consistent, and easily referenced. Ideally this information is stored in a system and can be accessed by networking teams through human interfaces (CLI, HTTP) and through machine interfaces (API).
As with Day 0 operations, this phase could also take days or weeks to be completed, especially if the entire process is disjointed, or completed through human intervention. A validation process should also take place at the completion of the Day 1 phase to ensure that all configurations are functional.
Day 2 to Day N
The Day 2 configurations are implemented to enable all the necessary features for day-to-day operations and bring the device into the intended functioning state. Over the course of time as the network grows and evolves, the configuration will change in stages, signified by Day N, until the device is decommissioned and removed from operations. For instance, a device may start with an initial set of routing rules based on the network at Day 2, but as the network changes in the future it may need the addition or removal of routing configurations. Similarly, a network device may start off Day 2 with a standard set of security ACLs (Access Control Lists), but as network vulnerabilities are uncovered, it will be necessary to update this ACL list to reflect new security measures.
As a network device enters into the Day 2 to Day N lifecycle phase, it is critical that the networking team has an efficient and reliable solution to manage the configuration of all of their network elements. This solution should include the ability to:
- Federate the network device inventory and categorize them into different groups.
- Quickly define, update, and reference Golden Configurations for devices.
- Consistently run compliance checks across all network devices.
- Provide reliable and intelligent remediation when configuration drift is detected.
- Automate as much as possible, engaging the network team only when necessary.
- Logging and displaying detail on devices, configuration drift, and any remediation done.
- Support for modern, non-CLI network elements, and cloud-native services (VPCs, VNet).
Challenges with Traditional Approaches to Configuration Management
It was challenging enough to keep existing on-prem network devices in compliance. Now, with the expansion of network infrastructure into multiple cloud platforms, the challenge of managing all of these new virtual devices in tandem with your existing on-prem devices will increase substantially. This will inevitably lead to non-compliance as the norm.
Some of the big challenges teams now face with this expansion of devices include:
Disjointed Management Tools
Networking teams have a diverse set of tools and systems they use to manage their network. Within the network domain, they may have a controller or orchestrator for the data center underlay and another for the overlay, one or more controllers for the wireless domain, a controller for the SD-WAN network, and perhaps another for the campus network. If there are networking assets deployed in different cloud platforms, there are controllers for those instances and for cloud-native services like VPCs and VNets with each cloud provider having their own dashboard to manage their proprietary services. In addition to all the network controllers, they may have various systems that they utilize in their day-to-day operations such as IT ticketing, change management, logging, and network monitoring.
These tools do not function in coordination with one another, and they require a person to “swivel chair” between each system in order to make a configuration change on a particular network device. All of this human interaction causes delay.
Multiple Sources of Truth
The evolution of the enterprise network has created multiple network and cloud domains with specific controllers, orchestrators, and dashboards that serve as an independent source of truth for that part of the network. If a change needs to be made to a remote branch office, you must refer to the SD-WAN controller. If a VLAN needs to be propagated in the data center, you need to work with the data center orchestration system. If you need to determine why an VPC is not passing traffic, you must query the AWS dashboard for the answers. An enterprise may have multiple IPAM and inventory systems that exist and have authoritative data for devices across multiple domains.
The reality is that multiple sources of truth already exist and will continue to exist, and this poses a real problem for device management, especially if it is done in a human-centric, manual process. A single source of truth would be helpful but maintaining a single source of truth synchronized with a growing list of other systems is not a tenable solution. inefficiency, and the potential for errors to occur in the process.
Configuration File Management
Manually maintaining configuration files for all network devices is not scalable and opens up the opportunity to misconfigurations and errors, especially across a group with multiple team members. If different network teams are responsible for separate networking domains, they may not even have visibility into the configurations, which makes validating common Day N compliance difficult. Answering a common question like, “Do the campus and data center devices reflect the most recent common security policies in their ACLs?” becomes difficult to answer, but the implication of non-compliance is a tremendous threat to the company.
Networking teams have attempted to create Golden Configurations for device groups, which identifies shared and common configurations and creates a template to apply to devices. Initially, this works well, but as the nature of the network is to change and evolve, the initial Golden Configurations also change and multiply into many Golden Configuration files, each becoming more and more specific to a single device and not a group of them. These configurations are no longer universally applicable, and become nothing more that unique, device configurations.
Human Intervention
For a variety of reasons, today’s network practitioner has been conditioned to rely on human intervention as the default action when managing the network. Managing network devices through CLI has always been the norm in the network world, and it’s still instinct to many network engineers. However, there has been a lack of intelligent automation tools that can be trusted to make changes to the network, and in some cases, tools that blindly inflict changes on critical areas of the network like the core can cause massive outages. Building intelligent automation scripts by themselves requires a significant amount of time, patience, and the will to essentially become a developer. Unfortunately, this is an investment that many cannot make due to the existing backlog, ironically due to the need to manually manage the network. Finally, even with the broad use of network controller and systems that have been deployed, there’s still a large element of human intervention required to “swivel chair” from the various systems in order to make changes, because these systems do not integrate with one another.
Moving from Control to Governance
In the past, networking teams had complete control over their entire network because they were built using physical routers and switches, which made it straightforward to create boundaries around the network. These boundaries resembled walls built to separate the border of countries, and it was simple to control the flow of traffic inside and outside of these network boundaries. In today’s exploded network environment across the Internet and multiple cloud platforms, these boundaries are no longer clear and well defined. Due to this, control over the entire infrastructure is no longer solely owned by the networking team. Network users are dispersed at home, in an office, or in a public area and applications are similarly dispersed across on-prem and multiple cloud infrastructures. Networking teams need new tools to help them move from purely controlling a bounded network, into a world where they provide governance over the dispersed infrastructure.
Multi-Cloud & the Network Service Adoption
The network has exploded on to the Internet, and the networking team must now expand their domain and require a new set of tools and skills to embrace this future. Enterprise networks used to be neatly defined by location or geography, and boundaries between “inside” the network and “outside” the network were well understood. With the rapid pace of moving applications into multiple cloud platforms, adopting more cloud-based SaaS offerings, and integrating with cloud-native networking services, the idea of cleanly defined network boundaries is no longer applicable. This changes the nature of how to build networks, how to secure networks and applications, and how to manage and troubleshoot networks in the future.
The networking team is capable of taking on these challenges, but they need help to bridge the gap with managing network infrastructure, whether it is physical, virtual, or cloud-native and on-prem or in any number of cloud platforms.
A Modern Approach to Network Configuration & Compliance Management Through Intelligent Automation
Networking teams require a new, modern solution to successfully address the challenges of Day 0 to Day N network device configuration deployments of existing on-prem infrastructure, and this solution must scale and adapt to include future infrastructure that is cloud-native and SaaS-based networking services.
Itential simplifies and streamlines the task of Day 0 to Day N configuration management for networking teams by solving the problems that they face today.
Easily Manage All Types of Network Configurations
Physical, Virtual, & Cloud-Native
Managing cloud-native network infrastructure requires Networking teams to navigate across multiple Cloud dashboards in order to make a very simple change in something as common as a VPC or VNet. As the amount of VPCs, VNets, and other cloud-native infrastructure grows across multiple cloud platforms, networking teams need a way to normalize configurations across all types of infrastructure. Itential’s Configuration Manager leverages a simplified approach to Configuration Management and Compliance into Cloud infrastructure, allowing networking teams to discover and manage cloud-native network services like VPCs or VNets and treat them as if they were traditional network devices and translate their complex configurations into easily understood JSON objects.
Integrate Configuration Management with IT Systems
ITSM, DevOps Tools, Pipelines & More
The Itential Automation Platform was designed with an API-first approach in order to integrate with the wide variety of systems that exist in enterprise networks. Many modern networking solutions are moving away from managing individual network devices through CLI and toward a network controller that manages all network devices in that domain. The human interface to these systems is typically a web front-end, but there is almost always a defined API that is available for machine-centric integration. Itential’s API-first approach makes it simple for network engineers to automate changes across multiple controllers and multiple domains. These system integrations can be automatically generated by the networking team so that as new systems are deployed, integrations can be quickly created by the end user.
Collect & Federate Data
Designed for Multiple Sources of Truth
With the adoption of new network solutions, the reality is that multiple sources of truth exist within the networking domain. Add to that the sources of truth that may exist in IPAM, inventory and monitoring systems, and you have a tremendous amount of human effort required to reference all of these systems to make a simple change to a single device. Itential’s API-first philosophy is why our solution allows for fast integration into all of your systems.
This means that the information contained within any of these systems can be made available the moment it is needed, without consuming time with a “swivel chair” approach, and a configuration change can take place with the highest quality of information regarding that device and its state in the network. When networking teams use Itential’s platform, they build confidence and trust in the automations they create, and free up valuable time for higher level work on the network.
Simplify Your Configuration Tree
Golden Configuration Templates
Many attempts at configuration file management result in a large and ever-growing list of configuration files based on device types, location, function, and a dozen other ways of categorizing and grouping devices. Even attempts at producing Golden Configuration ultimately produces the same sprawl. Itential implements a single Golden Configuration tree that represents your universal baseline configuration.
Shared configurations that are truly universal can be assigned to a base node, and new child nodes can be created with configurations that are applied to subsets of devices. As network device groups are defined, additional child nodes and sub-nodes can quickly be created in the Golden Configuration and configurations that are applicable to this group can be applied. This produces a single, concise, and easily consumed view of device configuration, what’s inherited between them, and what is unique to them. Teams can easily add, modify, and remove configuration lines and the changes will be inherited to child nodes based on location in the config tree. Advanced features like variables and regular expression matches are available within any configuration statement.
Workflow-Driven Compliance
Automated Configuration Management, Compliance, Validation, & Remediation
A critical element of configuration management is the ability automate configuration back up, compliance checking, configuration validation, and executing intelligent remediation. A network device or group of devices can be backed up and compared against the existing device configuration or previously saved configurations.
Based on our Golden Configuration, networking teams can schedule compliance checks or run them as needed on any part of the configuration tree and get immediate reporting, showing any configuration drift detected, provide a score based on the amount of drift, and offer the opportunity to remediate the drift with the proposed configuration statements. Automated remediation workflows can be created by the networking team in a low-code environment so they can define the precise terms and metrics required before any change to a network device is implemented. This provides a measure of trust and confidence that any changes being made are done according to their expertise and guidance, without the need for human intervention.
Network Governance & Team Collaboration
Ensure Compliance Across All Your Infrastructure
As organizations continue to leverage different cloud platforms and SaaS-enabled services, networking teams will need to invest in the right tools to assist them with governance over this expanded infrastructure. They will collaborate with existing CloudOps and DevOps teams, who already have experience in using cloud infrastructure, and work closely with them to allow infrastructure to be deployed quickly and securely. Itential’s Configuration Manager provides a simplified, streamlined approach to configuration management for traditional networking devices, and these same features can be applied to cloud-native network services like AWS VPCs, or Azure VNets. A Golden Configuration can be created for VPCs or VNets, and compliance reporting can be run across any device in the tree. This enables networking teams to leverage the same powerful tools across any area of their network infrastructure to ensure all network elements, whether physical routers or virtual VPCs, are in compliance.
End-to-End Network Configuration & Automation with Itential
Solving the challenge of configuration management is a vital part of deploying and maintaining a secure and stable enterprise network, but this challenge is only one part of a greater puzzle that must be solved. Over the course of time, network devices will always need to be changed, and any solution that automates configuration changes must also have a solution for the end-to-end network automation challenges. The network configuration change itself may only take up 8%-10% of the total amount of time it takes from start to finish. For example, consider the amount of time it may take to open an IT ticket, wait for approvals, reference different sources of truth (IPAM, Inventory, etc.), notify various groups, and run a pre-check sequence all before a change is actually made. There’s a tremendous amount of work done after the change is made as well, and the real potential of network automation can only be realized if it is all automated, not just the change itself.
Ultimately, the entire process of configuration management can be easily automated by leveraging the Itential Automation Platform, with Configuration Management as the first step in this journey. Itential is purpose-built to help networking teams, with little or no background in DevOps and CloudOps, deploy, manage, and maintain network infrastructure across their expanded network domains, and help them confidently build automations they can trust to reduce their manual workload and provide a higher level of service to the organization.
