young-man-wearing-vr-glasses-with-neon-light-futu-2021-12-17-19-01-47-utc

Intent-Based Networking

by Blog

Intent Based Networking

Modern networks are becoming increasingly distributed, dynamic, and software-driven. Applications can span data centres, cloud platforms, branch locations, wireless infrastructure, and multiple security domains. Managing this complexity through individual device configurations and manual operational processes becomes increasingly difficult as the environment grows.

Intent-Based Networking (IBN) is an architectural approach that allows network operators to express desired outcomes or policies at a higher level of abstraction, while the network management and automation systems determine how those requirements should be implemented across the infrastructure.

The important distinction is between intent and configuration. Traditional network management often focuses on the commands required to configure individual devices. IBN focuses first on what the organisation wants the network to achieve and then uses policy, automation, telemetry, and validation to maintain that desired state.

Defining Network Intent

The foundation of IBN is declarative policy. Instead of manually specifying every configuration command, an operator defines an intended outcome.

For example, an organisation might specify that a particular application must be reachable only from authorised users, that certain workloads must remain isolated, or that critical traffic requires a particular quality-of-service policy.

The IBN system can then translate that higher-level requirement into the policies and configurations required across the relevant network components.

Intent Translation and Automation

Intent cannot simply be sent directly to every network device. The platform must interpret the policy, understand the capabilities and topology of the infrastructure, and determine the appropriate implementation.

Automation systems can then provision or modify network configurations across switches, routers, wireless infrastructure, security platforms, and other supported systems.

This abstraction can reduce repetitive manual configuration and improve consistency across large environments.

Telemetry and Network Awareness

IBN depends heavily on accurate network telemetry. The system needs visibility into topology, device state, configuration state, application behaviour, performance, and policy compliance.

Telemetry can include interface statistics, routing information, device health, flow data, application performance indicators, logs, events, and other operational signals.

This information provides the feedback required to determine whether the network is actually behaving as intended.

Closed-Loop Assurance

One of the defining characteristics of an IBN architecture is the feedback loop.

A simplified model is:

Define Intent → Translate Policy → Automate Configuration → Observe Network → Validate Outcome → Remediate

After a policy is implemented, telemetry is used to determine whether the resulting network state matches the intended outcome.

If the network deviates from policy, the system can identify the discrepancy and, where appropriate, initiate corrective automation.

This is more significant than simple configuration automation. Automation executes a defined task; IBN combines automation with policy and continuous assurance.

Network Security and Segmentation

IBN can also support security policies by expressing requirements such as segmentation, access restrictions, application isolation, or communication controls at a higher level.

The resulting policy can then be applied consistently across the infrastructure rather than relying on engineers to manually reproduce equivalent configurations on individual devices.

However, IBN does not replace security architecture. Identity controls, authentication, endpoint security, firewalls, segmentation, vulnerability management, and security monitoring remain important components of the overall design.

Operational Efficiency

One of the main benefits of intent-based approaches is reducing the amount of repetitive configuration work required from network engineers.

Standardised policies can be applied across large environments while automation reduces configuration drift and the risk of inconsistent manual changes.

Engineers can therefore spend more time defining policy, analysing network behaviour, designing architecture, and investigating exceptions rather than repeatedly entering low-level commands.

AI and Machine Learning

AI and machine learning can contribute to IBN by analysing large volumes of telemetry, identifying anomalies, correlating events, predicting capacity requirements, and assisting with operational decisions.

However, AI is not synonymous with IBN. A network can implement intent-based policy and closed-loop automation without using advanced machine learning.

The critical architecture remains the relationship between policy, automation, telemetry, validation, and remediation. AI can enhance these capabilities rather than defining IBN by itself.

Policy Compliance and Configuration Drift

Large networks can gradually diverge from their intended state as engineers make changes, devices are replaced, applications move, or emergency modifications are introduced.

IBN platforms can continuously compare observed network state with the desired policy state. This helps identify configuration drift and provides a mechanism for returning infrastructure to an approved operational state where appropriate.

Challenges and Design Considerations

IBN introduces its own engineering challenges. Intent must be expressed precisely enough to be translated into enforceable policy, while the automation platform must understand the capabilities and limitations of the underlying infrastructure.

Legacy devices, multi-vendor environments, incomplete telemetry, inaccurate inventories, and poorly defined policies can all reduce the effectiveness of an IBN implementation.

There is also an important operational requirement for validation and controlled change. Automatically modifying a production network without adequate testing, safeguards, or rollback mechanisms can turn an automation error into a large-scale outage.

The Future of Network Operations

Intent-Based Networking represents a shift from managing individual configurations toward managing desired network outcomes.

The long-term model is increasingly:

Policy → Automation → Telemetry → Assurance → Adaptation

Rather than treating the network as a collection of independently configured devices, IBN treats it as a system whose behaviour can be described, automated, measured, and continuously validated against organisational requirements.

When implemented with strong policy definitions, reliable telemetry, controlled automation, and effective validation, IBN can improve consistency, operational efficiency, security policy enforcement, and network agility.

The real value of IBN is therefore not simply “AI configuring the network.” It is the creation of a more intelligent operational feedback loop in which engineers define what the network should achieve and automation continuously helps maintain that desired state.

Matt Conran
Interactive Intent-Based Networking Lab

Intent → Policy → Configuration → Assurance

Follow a business requirement through an intent-based networking system. The objective is not to manually configure every device, but to express the desired outcome, translate it into enforceable policy, deploy the resulting configuration, and continuously verify the network state.

Network intent

Protect the Finance application

“Only authorised Finance users should access the Finance application. The application should remain reachable through the approved network path and the policy should remain enforced as the network changes.”

01 · DEFINE

Intent

Describe the desired business or technical outcome.

→
02 · TRANSLATE

Policy

Convert the intent into enforceable network policy.

→
03 · ENFORCE

Configuration

Deploy the required changes across network infrastructure.

→
04 · VERIFY

Assurance

Compare actual network behaviour with the desired state.

Intent: Define the “What”
The administrator describes the desired outcome rather than specifying every individual device command. The intent is the desired state that the system will attempt to achieve.

Generated policy

A simplified representation of how the high-level intent can become enforceable policy.

# Intent
application: finance
source: finance-users
destination: finance-app
access: allow
encryption: required

Continuous assurance

IBN does not stop when configuration is deployed. The system continuously evaluates whether the desired state is still true.

Finance policy deployed PASS
Authorised users can connect PASS
Unauthorised access blocked PASS
Network state matches intent READY
[READY] Intent engine initialized
[INFO] Desired state has not yet been deployed
Engineering takeaway: Intent-Based Networking moves the operational focus from individual device configuration toward desired outcomes. The important loop is Intent → Translation → Enforcement → Assurance. Continuous assurance is what distinguishes a one-time automated configuration change from a system that continuously checks whether the intended state remains true.

Highlights: Intent Based Networking

Understanding Intent-Based Networking

–  Intent-Based Networking is a paradigm shift in network management focusing on translating high-level business objectives into automated network configurations. By leveraging artificial intelligence and machine learning, IBN aims to streamline network operations, enhance security, and improve overall network performance. It truly empowers network administrators to align the network’s behavior with business intent.

– IBN offers many benefits that make it a game-changer in the networking realm. Firstly, it enables faster network provisioning and troubleshooting, reducing human error and minimizing downtime. Secondly, IBN enhances network security through real-time monitoring and automated threat response. Additionally, IBN provides valuable insights and analytics, enabling better decision-making and optimized resource allocation.

– Implementing IBN requires careful planning and execution. It integrates various components, such as a centralized controller, network devices with programmable interfaces, and AI-powered analytics engines. Furthermore, organizations must assess their network infrastructure and determine the automation and intelligence needed. Collaborating with experienced vendors and leveraging their expertise can facilitate implementation.

Defining: Intent-Baed Networking

Intent-Based Networking can only be understood if we understand what Intent is. Purpose makes the definition of intent easier to understand because it is a synonym. Intentions or purposes vary from person to person, department to department, and organization to organization. It is possible for an organization to provide the best in class software to schools or to provide the best phones available. The purpose of a business process can be to fulfill the described task as efficiently as possible. It is, of course, the potential for a person to have multiple intentions or purposes. Generally, intent or purpose describes a goal to be achieved.

Example: Cisco DNA

As a network infrastructure built on Cisco DNA, IBN describes how to manage, operate, and enable a digital business using the network. An intent within the industry is translated into a network configuration that fulfills that intent. This is accomplished by defining the intent utilizing a set of (repetitive) steps. Cisco DNA approaches networks using all aspects of IBN (design principles, concepts, etc.).

**Challenge: The Lack of Agility**

Intent-based networking is not just hype; we see many intent-driven networks already with many SD WAN overlay roll-outs. It is a necessary development; from a technology standpoint, it has arrived. However, cultural acceptance will take a little longer. Organizations are looking to modernize their business processes and their networks.

Yet, traditional vertically integrated monolithic networking solutions prohibit the network from achieving agility. This is why we need intent-based networking systems. So, what is intent-based networking? Intent-based networking is where an end-user describes what the network should do, and the system automatically configures the policy. It uses declarative statements instead of imperative statements. 

**Converts the What into How**

You are telling the network what you want to accomplish, not precisely what to do and how to do it. For example, tell me what you want, not how to do it, all of which gets translated behind the scenes. Essentially, intent-based networking is a piece of open networking software that takes the “what” and converts it into the “how.” The system generates the resulting configuration for design and device implementation.

The system is provided with algorithms that translate business intent into network configurations. Humans can not match the speed of algorithms, and this is key. The system is aware of the network state and can ingest real-time network status from multiple sources in a transport and protocol-agnostic way.

**The Desired State**

It adds the final piece of the puzzle by validating in real time that the intent is being met. The system continuously compares the actual to the desired state of the running network. If the desired state is unmet, corrective actions such as modifying a QoS policy or applying an access control list (ACL) can occur. This allows for a closer alignment between the network infrastructure and business initiatives and maintains the network’s correctness.

Intent‑Based Networking (IBN)

Intent‑Based Networking is a modern approach to designing and operating networks where you define what you want the network to do, and the system automatically figures out how to do it. Instead of configuring individual devices, you express high‑level intent — such as security policies, application requirements, or performance goals — and the network enforces that intent consistently across the entire infrastructure.

It’s the evolution of SDN, automation, analytics, and policy‑driven architectures like Cisco ACI and SD‑WAN.

 

Core Idea

You tell the network your intent (e.g., “Only finance apps can talk to the database”). The system translates that intent into policies, configurations, and continuous verification.

Intent → Automation → Enforcement → Assurance

 

Key Components of Intent‑Based Networking

1. Intent Definition

High‑level business or technical goals:

  • security segmentation

  • application performance requirements

  • compliance rules

  • connectivity policies

This is the “what”.

2. Automated Translation

The system converts intent into:

  • device configurations

  • ACLs

  • routing policies

  • segmentation rules

  • QoS profiles

This is the “how”.

3. Network Automation

The network automatically deploys the translated policies across:

  • switches

  • routers

  • firewalls

  • SD‑WAN fabric

  • cloud edges

No manual CLI needed.

4. Continuous Verification (Assurance)

The system constantly checks:

  • is the intent being met

  • are policies enforced

  • are flows behaving correctly

  • are there anomalies

  • is the network drifting

If something breaks, the system alerts or auto‑remediates.

 

Why Intent‑Based Networking Matters

IBN delivers:

  • Consistency — policies applied everywhere

  • Security — Zero Trust segmentation by intent

  • Automation — fewer manual errors

  • Agility — faster changes and deployments

  • Assurance — continuous verification

  • Scalability — works across data center, WAN, cloud, and SASE

It transforms networks from device‑centric to policy‑centric.

 

Where Intent‑Based Networking Is Used

Data Center (Cisco ACI)

  • EPGs, contracts, tenants

  • application‑centric policies

  • automated fabric configuration

SD‑WAN

  • application‑aware routing

  • intent‑driven path selection

  • automated failover

SASE

  • identity‑based access

  • cloud‑delivered policy enforcement

Cloud Networking

  • policy‑driven VPC/VNet segmentation

  • automated multi‑region consistency

 

Examples of Network Intent

  • “Only HR users can access HR apps.”

  • “Critical apps must use the lowest‑latency path.”

  • “IoT devices cannot reach the internet.”

  • “All traffic between sites must be encrypted.”

  • “Block unknown SaaS applications.”

The system enforces these automatically.

 

Outcome

Intent‑Based Networking delivers:

  • predictable behavior

  • automated configuration

  • strong security segmentation

  • continuous assurance

  • simplified operations

  • faster deployment of changes

  • alignment between business goals and network behavior

It turns the network into a self‑driving, self‑verifying, policy‑driven platform.

 

Interactive IBN Translation Lab

Intent Translation & Network Change Lab

Select a business intent and see how an intent-based system can translate the desired outcome into policy and network changes. The exact implementation depends on the platform, but the abstraction remains the same: define the outcome first.

Choose an intent

What should the network achieve?

Select one of the scenarios below. Then run the translation engine to see the policy model and resulting network actions.

Policy translation

The intent is represented as policy objects and constraints.

# Select an intent
# Translation waiting...

Network change plan

The automation layer determines the implementation required.

POLICY Model
TRANSLATE Platform
ENFORCE Network
VERIFY Telemetry
No network change has been generated yet.
[READY] Translation engine waiting for intent
Engineering takeaway: IBN separates the desired outcome from the device-level implementation. The system may generate ACLs, segmentation policies, QoS rules, routing preferences or other platform-specific changes. The key idea is that the operator expresses what the network should achieve while the automation layer determines how that outcome is implemented.

Intent Based Networking

Learning more about intent-based networking is essential to understanding it. An intent is a brief description of the purpose and a concrete, predetermined set of steps that must be executed to (successfully) achieve the Intent. This principle can also be applied to the operation of a network infrastructure. The Intent and its steps precisely describe what needs to be done on the network to accomplish a specific task. 

For example, the application is migrating to the cloud. In this case, the Intent or steps may include the following. First, take the existing access policy for that application from the data center policy, transform the policy into an application policy for Internet access, deploy the procedure on all perimeter firewalls, and change the routing for that application to the cloud.

Critical Principles of Intent-Based Networking:

1. Translation: Intent-based networking automatically translates high-level business objectives into network policies and configurations. By understanding the desired intent, the network infrastructure can autonomously make the necessary adjustments to align with the organization’s goals.

2. Automation: Automation is a fundamental aspect of IBN. By automating routine network tasks, such as provisioning, configuration, and troubleshooting, network administrators can focus on strategic activities that add value to the organization. Automation also reduces the risk of human error, leading to improved network reliability and security.

3. Assurance: IBN provides continuous monitoring and verification of network behavior against the intended state. By constantly comparing the network’s current state with the desired intent, IBN can promptly identify and mitigate any configuration drift or anomalies. This proactive approach enhances network visibility, performance, and compliance.

Benefits of Intent-Based Networking:

1. Simplified Network Management: With IBN, network administrators can easily manage complex networks. By abstracting the complexity of individual devices and focusing on business intent, IBN simplifies network operations, reducing the need for manual configuration and troubleshooting.

2. Enhanced Agility and Scalability: IBN enables organizations to respond quickly to changing business requirements and effortlessly scale their networks. By automating network provisioning and configuration, IBN supports rapid deployment and seamless integration of new services and devices.

3. Improved Network Security: Security is a top concern for modern networks. IBN offers enhanced security by continuously monitoring network behavior and enforcing security policies. This proactive approach reduces the risk of security breaches and enables faster threat detection and response.

4. Optimized Performance: IBN leverages real-time analytics and machine learning to optimize network performance. By dynamically adjusting network configurations based on traffic patterns and user behavior, IBN ensures optimal performance and user experience.

Intent-Based Networking Solution: Cisco SD-Access

The Cisco SD-Access digital network evolution transforms traditional campus LANs into intent-driven, programmable networks. Campus Fabric and DNA Center are Cisco SD-Access’s two main components. The Cisco DNA Center automates and assures the creation and monitoring of the Cisco Campus Fabric.

Cisco Campus Fabric Architecture: In Cisco SD-Access, fabric roles and terminology differ from those in traditional three-tier hierarchical networks. To create a logical topology, Cisco SD-Access implements fabric technology using overlay networks running on a physical (underlay) network.

Underlay networks are traditional physical networks that connect LAN devices such as routers and switches. Their primary function is to provide IP connectivity for traffic to travel from one point to another. Due to the IP-based underlay, any interior gateway protocol (IGP) can be utilized.

Overlay and Underlay Networking

Fabrics are overlay networks. In the IT world, Internet Protocol Security (IPsec), Generic Routing Encapsulation (GRE), Dynamic Multipoint Virtual Private Networks (DMVPN), Multiprotocol Label Switching (MPLS), Location Identifier Separation Protocol (LISP), and others are commonly used with overlay networks to connect devices virtually. An overlay network is a logical topology that connects devices over a topology-independent physical underlay network.

Example Overlay Technology: GRE Point to Point

Data & Control Plane

Forwarding and control planes are separated in overlay networks, resulting in a flexible, programmable, and scalable network. To simplify the underlay, the control plane and data plane are separated. As the control plane becomes the network’s brain, it allows faster forwarding and optimizes packets and network reliability. As an underlay for the centralized controller, Cisco SD-Access supports building a fabric using an existing network.

Underlay networks can be automated with Cisco DNA Center. As a result, it is helpful for new implementations or infrastructure growth since it eliminates the hassle of setting up the underlay. For differentiation, segmentation, and mobility, overlay networks often use alternate forwarding attributes in an additional header.

Cisco SD AccessNetworking Complexity

Networks continue to get more complex as traffic demands increase. While software-defined networking (SDN) can abstract the underlying complexities, we must consider how we orchestrate the policy and intent across multi-vendor, multi-domain elements.

To overcome complexity, you have to abstract. We have been doing this with tunneling for decades. However, different abstractions are used at the business and infrastructure resource levels.

At a business level, you need to be flexible, as rules will change and must be approached differently from how the operating system models resources. We must make new architecture decisions for this, as it’s not just about configuration management and orchestrations. None of these can look at the network state, which we need to do.

For this, we need network intelligence. Networks are built and managed today using a manual approach without algorithmic validation. The manual process of networking will not be viable in the future.  Let’s face it: humans make mistakes.

There are many reasons for network outages, ranging from software bugs and hardware/power failure to security breaches. All of these come from a lack of implementation of network security. However, human error is still the number one cause. Manual configuration inhibits us. Intent-based networking eliminates this inhibition.

The traditional approach to networking

In the traditional network model, there is a gap between the architect’s intent and what’s achieved. Not just for device configuration but also for achieved runtime behavior. Until now, there has not been a way to validate the original intent or to have a continuous verification mechanism.

Once you have achieved this level of assurance, you can focus on business needs and not be constrained by managing a legacy network. For example, Netflix moved its control plane to the cloud and now focuses all its time on its customer base.

We have gone halfway and spent billions of dollars on computing storage and applications, but the network still lags. The architecture and protocols have become more complex, but the management tools have not kept pace. Fortunately, now, this is beginning to change.

Software-defined networking; Slow Deployments

SDN shows great promise that could release networking, but deployments have been slow. Primarily down to large cloud-scale organizations with ample resources and dollars. But what can the rest of the industry do if we do not have that level of business maturity?  Intent-based networking is a natural successor to SDN, as many intent-based vendors have borrowed the same principles and common architectures.

The systems are built on the divide between the application and the network infrastructure. However, SDN operates at the network architecture level, where the control plane instructs the data plane forwarding node. Intent-based systems work higher at the application level to offer true brownfield network automation.

SDN and SD-WAN have made considerable leaps in network programmability, but intent-based networking is a further leap to zero-touch self-healing networks. For additional information on SD-WAN, including the challenges with existing WANs, such as lack of agility with BGP ( what is BGP protocol in networking ) and the core features of SD-WAN, check out this SDWAN tutorial.

Intent-Based Networking Use Case

The wide-area network (WAN) edge consists of several network infrastructure devices, including Layer 3 routers, SD-WAN appliances such as Viptela SD-WAN, and WAN optimization controllers. These devices could send diagnostic information for the intent-based system to ingest. The system can ingest from multiple sources, including a monitoring system and network telemetry.

As a result, the system can track application performance over various links. Suppose there is a performance-related problem, the policies are unmet, and application performance degrades.

In that case, the system can take action, such as rerouting the traffic over a less congested link or notifying a network team member. The intent-based system does not have to take corrective action, similar to how IDS/IPS is deployed. These devices can take disciplinary action if necessary, but many use IDS/IPS to alert.

Looking deeper into intent-based networking systems

The intent-based architecture combines machine learning (ML), cognitive computing, and deep analytics, providing enhanced levels of automation and programmability through an easy-to-use GUI. Combining these technologies allows you to move from a reactive to a proactive system.

ML, a sub-application of artificial intelligence (AI), allows intent-based systems to analyze and learn from data automatically without explicit programming. Therefore, it enables systems to understand and predict the data for autonomous behavior. Intent-based networking represents a radical new approach to network architecture and takes networking to the next level in intelligence.

It is not a technology that will be accepted overnight. Its adoption will be slow as, to some, a fully automated network can sound daunting, placing faith in your business, which for many organizations is the network.

However, deploying intent-based networking systems offers a new way to build and operate networks, which increases agility, availability, and security compared to traditional networking.

Intent-based networking (IBN) is transforming the way networks are managed. By shifting the focus from device-centric configurations to intent-driven outcomes, IBN simplifies network management, enhances agility and scalability, improves security, and optimizes network performance. As organizations strive to meet the demands of the digital age, embracing this innovative approach can pave the way for a more efficient and intelligent network infrastructure.

Interactive IBN Assurance Lab

Continuous Assurance & Drift Investigation

Intent is only useful if the network continues to behave as intended. Introduce a controlled configuration change, inspect the evidence, and decide whether the platform should alert, recommend remediation, or apply an authorised corrective action.

Finance application policy
Desired state: authorised Finance users only · encrypted path · approved policy
IN SYNC

Desired vs actual state

Assurance compares observed network behaviour with the intended state.

Identity policy Finance only Finance only
Encryption Required Enabled
Access control Deny others Enforced
Policy version v4 v4

Investigation evidence

Select the evidence you believe explains the observed drift.

INVESTIGATION READY
Simulate drift, inspect the actual state, then select the evidence that explains the mismatch.
[READY] Assurance engine monitoring desired state
Engineering takeaway: Continuous assurance closes the loop between intent and runtime behaviour. A mismatch does not automatically mean the system should make a change: the response may be an alert, recommendation or authorised remediation depending on policy, confidence and operational controls. This distinction is important when designing reliable intent-based automation.
with safety.3D rendering

Brownfield Network Automation

by Blog

Brownfield Network Automation

In today's rapidly advancing technological landscape, the efficient management and automation of networks has become crucial for businesses to thrive. While greenfield networks are often designed with automation in mind, brownfield networks present a unique set of challenges. In this blog post, we will explore the world of brownfield network automation, its benefits, implementation strategies, and the future it holds.

Brownfield networks refer to existing networks that have been established over time, typically with a mix of legacy and modern infrastructure. These networks often lack the built-in automation capabilities of newer networks, making the implementation of automation a complex endeavor.

Automating brownfield networks brings forth numerous advantages. Firstly, it enhances operational efficiency by reducing manual interventions and human errors. Secondly, it enables faster troubleshooting and improves network reliability. Additionally, automation allows for better scalability and prepares networks for future advancements.

Implementing automation in brownfield networks requires a systematic approach. Firstly, a comprehensive network assessment should be conducted to identify existing infrastructure, equipment, and protocols. Next, a phased approach can be taken, starting with low-risk areas and gradually expanding automation to critical components. It is crucial to ensure seamless integration with existing systems and thorough testing before deployment.

Automation in brownfield networks can face challenges such as outdated equipment, incompatible protocols, and lack of standardized documentation. To overcome these obstacles, a combination of hardware and software upgrades, protocol conversions, and meticulous planning is essential. Collaboration among network engineers, IT teams, and vendors is also crucial to address these challenges effectively.

As technologies like Software-Defined Networking (SDN) and Network Function Virtualization (NFV) continue to evolve, brownfield network automation is poised for significant advancements. The integration of artificial intelligence and machine learning will further streamline network operations, predictive maintenance, and intelligent decision-making.

Brownfield network automation opens up a world of possibilities for businesses seeking to optimize their existing networks. Despite the challenges, the benefits are substantial, ranging from increased efficiency and reliability to future-proofing the infrastructure. By embracing automation, organizations can unlock the full potential of their brownfield networks and stay ahead in the ever-evolving digital landscape.

Matt Conran
Network Automation • Interactive Lab 01

Brownfield Network Automation Assessment

Assess an existing network before automation. Examine legacy infrastructure, management interfaces, documentation and standardization to determine how ready the environment is for automation.

Learning Objective: Identify the major constraints that make brownfield automation difficult and determine whether a network should be automated immediately, modernized first, or migrated through a phased approach.

01 • Configure Network Profile

02 • Brownfield Environment

▣
Infrastructure Unassessed
⌘
Management Unassessed
▤
Documentation Unassessed
◇
Standardization Unassessed
⚙
Automation Unassessed
!
Operational Risk Unassessed
Infrastructure Mostly Legacy Devices
Management Model Traditional CLI
Documentation Limited / Outdated
Automation Readiness Awaiting Assessment

03 • Engineering Assessment

Automation Path Assess Environment
Primary Constraint Unknown
Recommended Approach Assessment Required
Risk Level Unknown

04 • Assessment Console

[READY] Brownfield assessment lab initialized.
[INFO] Configure the environment and assess automation readiness.
Engineering Takeaway: Brownfield automation starts with understanding the existing network. Legacy hardware, CLI-only management, inconsistent configurations and poor documentation increase automation risk. A structured assessment helps determine where automation can begin safely and where modernization is required first.

Highlights: Brownfield Network Automation

### The Challenges of Automation

Automating brownfield networks presents unique challenges. Unlike greenfield projects, where you start from scratch, brownfield automation must work within the constraints of existing systems. This includes dealing with legacy hardware that may not support modern protocols, software that lacks API integration, and a complex web of dependencies that have built up over time. Identifying these challenges early is crucial for any successful automation project.

### Strategies for Successful Automation

To tackle these challenges, businesses need a strategic approach. This often involves conducting a thorough audit of the existing network to understand its current state and dependencies. Once this is completed, companies can start by implementing automation in less critical areas, gradually expanding as they refine their processes. This incremental approach helps in mitigating risks and allows for testing and optimization before full-scale deployment. Leveraging modern tools such as network controllers and orchestration platforms can simplify this process.

### The Role of Artificial Intelligence

Artificial Intelligence (AI) is playing a significant role in the automation of brownfield networks. By utilizing AI, businesses can predict network issues before they occur, optimize resource allocation, and enhance overall network performance. AI-driven analytics provide insights that were previously inaccessible, allowing for more informed decision-making. As AI technology continues to evolve, its integration into brownfield automation strategies becomes not only beneficial but essential.

Understanding Brownfield Networks

Brownfield networks refer to existing network infrastructures that have been operating for some time. These networks often consist of legacy and modern components, making automation complex. However, the right approach can transform brownfield networks into agile and automated environments.

Automating brownfield networks offers numerous advantages. Firstly, it streamlines network management processes, reducing human errors and increasing operational efficiency. Secondly, automation enables quicker troubleshooting and problem resolution, minimizing downtime and enhancing network reliability. Additionally, brownfield network automation allows easier compliance with security and regulatory requirements.

While the benefits are substantial, implementing brownfield network automation does come with its fair share of challenges. One major hurdle is integrating legacy systems with modern automation tools. Legacy systems often lack the necessary APIs and standardization required for seamless automation. Overcoming this challenge necessitates careful planning, testing, and potentially using intermediary solutions.

Strategies for Successful Implementation:

A systematic approach is crucial to successfully implementing brownfield network automation. Thoroughly assess the existing network infrastructure, identifying areas that can benefit the most from automation. Prioritizing automation tasks and starting with smaller, manageable projects can help build momentum and demonstrate the value of automation to stakeholders. Collaboration between network engineers, automation experts, and stakeholders is critical to ensuring a smooth transition.

Implementing brownfield network automation may face resistance from stakeholders comfortable with the status quo. Clear communication about automation’s benefits and long-term vision is vital to overcome this. Demonstrating tangible results through pilot projects and showcasing success stories from early adopters can help build trust and gain buy-in from decision-makers.

Challenges of Brownfield Automation:

Implementing network automation in a brownfield environment poses unique challenges. Legacy systems, diverse hardware, and complex configurations often hinder the seamless integration of automation tools. Additionally, inadequate documentation and a lack of standardized processes can make it challenging to streamline the automation process. However, with careful planning and a systematic approach, these challenges can be overcome, leading to significant improvements in network efficiency.

Benefits of Brownfield Network Automation:

1. Enhanced Efficiency: Brownfield Network Automation enables organizations to automate repetitive manual tasks, reducing the risk of human errors and increasing operational efficiency. Network engineers can focus on more strategic initiatives by eliminating the need for manual configuration changes.

2. Improved Agility: Automating an existing network allows businesses to respond quickly to changing requirements. With automation, network changes can be made swiftly, enabling organizations to adapt to evolving business needs and market demands.

3. Cost Savings: By automating existing networks, organizations can optimize resource utilization, reduce downtime, and improve troubleshooting capabilities. This leads to substantial operational expense savings and increased return on investment.

4. Seamless Integration: Brownfield Network Automation allows for integrating new technologies and services with existing network infrastructure. Businesses can seamlessly introduce new applications, services, and security measures by leveraging automation without disrupting existing operations.

5. Enhanced Network Security: Automation enables consistent enforcement of security policies, ensuring compliance and reducing the risk of human error. Organizations can strengthen their network defenses and safeguard critical data by automating security configurations.

Role of automation

As a result, network devices are still configured like snowflakes (having many one-off, nonstandard configurations), and network engineers take pride in solving transport and application problems by making one-time network changes that ultimately make the network harder to maintain, manage, and automate.

Automation and management of network infrastructure should not be treated as add-ons or secondary projects. Budgeting for personnel and tools is crucial. It is common for tooling to be cut first during budget shortages.

**Deterministic outcomes**

An enterprise organization’s change review meeting examines upcoming network changes, their impacts on external systems, and rollback plans. Typing the wrong command can have catastrophic consequences in a world where humans use the CLI. Many different teams can work together, whether they are three-person teams, four-person teams, or fifty-person teams. Every engineer can implement that upcoming change differently. A CLI and GUI do not eliminate or reduce the possibility of error during a change control window.

The executive team will be able to achieve deterministic outcomes by automating the network, which increases the chances that the task will be completed correctly the first time by making changes manually rather than automating the network. Changing VLANs to onboard a new customer may be necessary, which requires several network changes.

**The Traditional CLI**

Software companies that build automation for network components have an assumption that traditional management platforms don’t apply to what is considered to be the modern network. Networks are complex and contain many moving parts and ways to be configured. So, what does it mean to automate the contemporary network when considering brownfield network automation? Innovation in this area has been lacking for so long until now with ansible automation.

If you have multi-vendor equipment and can’t connect to all those devices, breaking into the automation space is complex, and the command line interface (CLI) will live a long life. This has been a natural barrier to entry for innovation in the automation domain.

**Automation with Ansible**

But now we have the Ansible architecture using Ansible variables, NETCONF, and many other standard modeling structures that allow automation vendors to communicate to all types of networks, such as brownfield networks, greenfield networks, multi-vendor networks, etc. These data modeling tools and techniques enable an agnostic programmable viewpoint into the network.

The network elements still need to move to a NETCONF-type infrastructure, but we see all major vendors, such as Cisco, moving in this direction. Moving off the CLI and building programmable interfaces is a massive move for network programmability and open networking.

 

Brownfield Automation • Interactive Lab 02

Brownfield Automation Migration Planner

Build a phased automation strategy for an existing network. Select the task, management method and migration approach, then evaluate whether the proposed automation path is appropriate for the environment.

Learning Objective: Learn why brownfield automation should normally begin with controlled, low-risk tasks and progress toward standardized programmable interfaces, orchestration and broader network automation.

01 • Design the Migration

02 • Automation Journey

◉
Assess Understand state
◇
Standardize Normalize data
⚙
Pilot Low-risk change
⌘
Automate Repeatable workflow
↗
Scale Operationalize
Automation Target Configuration Backup
Management Method CLI Automation
Migration Strategy Pilot First
Plan Status Awaiting Plan

03 • Engineering Decision

Recommended Path Not Evaluated
Risk Unknown
Operational Model Manual
Scale Potential Unknown

04 • Migration Console

[READY] Brownfield migration planner initialized.
[INFO] Select an automation target and build a migration plan.
Engineering Takeaway: Successful brownfield automation is usually evolutionary rather than revolutionary. Assess the environment, standardize what can be standardized, begin with low-risk tasks, validate the workflow and then expand automation toward broader orchestration and programmable network control.

Brownfield Network Automation

Network devices have massive static and transient data buried inside, and using open-source tools or building your own gets you access to this data. Examples of this type of data include active entries in the BGP table, OSPF adjacencies, active neighbors, interface statistics, specific counters and resets, and even counters from application-specific integrated circuits (ASICs) themselves on newer platforms. So, how do we get the best of this data, and how can automation help you here?

A key point: Ansible Tower

To operationalize your environment and drive automation to production, you need everything centrally managed and better role-based access. For this, you could use Ansible Tower, which has several Ansible features, such as scheduling, job templates, and a project, that help you safely enable automation in the enterprise at scale.

Best Practices for Brownfield Network Automation:

1. Comprehensive Network Assessment: Conduct a thorough assessment of the existing network infrastructure, identifying areas that can benefit from automation and potential obstacles.

2. Standardization and Documentation: Establish standardized processes and documentation to ensure consistency across the network. This will help streamline the automation process and simplify troubleshooting.

3. Gradual Implementation: Adopt a phased approach to brownfield automation, starting with low-risk tasks and gradually expanding to more critical areas. This minimizes disruption and allows for easy troubleshooting.

4. Collaboration and Training: Foster collaboration between network engineers and automation specialists. Training the network team on automation tools and techniques is crucial to ensure successful implementation and ongoing maintenance.

5. Continuous Monitoring and Optimization: Regularly monitor and fine-tune automated processes to optimize network performance. This includes identifying and addressing any bottlenecks or issues

Brownfield Network Automation; DevOps Tools

Generally, you have to use DevOps tools, orchestrators, and controllers to do the jobs you have always done yourself. However, customers are struggling with the adoption of these tools. How do I do the jobs I used to do on the network with these new tools? That’s basically what some software companies are focused on. From a technical perspective, some vendors don’t talk to network elements directly.

This is because you could have over 15 tools touching the network, and part of the problem is that everyone is talking to the network with their CLI. As a result, inventory is out of date, network errors are common, and CMD is entirely off, so the ability to automate is restricted based on all these prebuilt silo legacy applications. For automation to work, a limited number of elements should be talking to the network. With the advent of controllers and orchestrators, we will see a market transition.

DevOps vs. Traditional

If you look back, when we went from time-division multiplexing (TDM) to Internet Protocol (IP) address, the belief is that network automation will eventually have the same impact. The ability to go from non-programmability to programmability will represent the most significant shift we will see in the networking domain.

Occasionally, architects design something complicated when it can be done in a less complex manner with a more straightforward handover. The architectural approach is never modeled or in a database. The design process is uncontrolled, yet the network is an essential centerpiece.

There is a significant use case for automating and controlling the design process. Automation is an actual use case that needs to be filled, and vendors have approached this in various ways. It’s not a fuzzy buzzword coming out of Silicon Valley. Intent-based networking? I’m sometimes falling victim to this myself. Is intent-based networking a new concept?

OpenDaylight (ODL)

I spoke to one vendor building an intent-based API on top of OpenDaylight (ODL). An intent-based interface has existed for five years, so it’s not a new concept to some. However, there are some core requirements for this to work: It has to be federated, programmable, and modeled.

Some have hijacked intent-based to a very restricted definition, and an intent-based network has to consist of highly complex mathematical algorithms. Depending on who you talk to, these mathematical algorithms are potentially secondary for intent-based networking.

One example of an architectural automation design is connecting to the northbound interface like Ansible. These act as trustworthy sources for the components under their management. You can then federate the application programming interface (API) and speak NETCONF, JSON, and YAML types. This information is then federated into a centralized platform that can provide a single set of APIs into the IT infrastructure.

So if you are using ServiceNow, you can request a through a catalog task. That task will then be patched down into the different subsystems that tie together that service management or device configuration. It’s a combination of API federation data modeling and performing automation.

The number one competitor of these automation companies is users who still want to use the CLI or vendors offering an adapter into a system. Yet, these are built on the foundation of CLIs. These adapters can call a representational state transfer (REST) interface but can’t federate it.

This will eventually break. You need to make an API call to the subsystem in real-time. As networking becomes increasingly dynamic and programmable, federated API is a suitable automation solution.

Brownfield Network Automation offers organizations a powerful opportunity to unlock the full potential of existing network infrastructure. By embracing automation, businesses can enhance operational efficiency, improve agility, and achieve cost savings. While challenges may exist, implementing best practices and taking a systematic approach can pave the way for a successful brownfield automation journey. Embrace the power of automation and revolutionize your network for a brighter future.

Network Operations • Interactive Lab 03

Deterministic Network Change Lab

Explore how automation changes the operational model of network changes. Compare manual CLI execution with a controlled workflow that validates the intended state, performs the change, verifies the result and provides a rollback path when validation fails.

Learning Objective: Understand how automation can produce more deterministic outcomes by separating intent, validation, execution, verification and rollback instead of relying on one-off manual CLI changes.

01 • Configure Change

02 • Controlled Change Workflow

◎
Intent Desired state
✓
Pre-Check Validate state
⚙
Change Apply update
◉
Verify Confirm result
↶
Rollback Recover safely
Change Onboard Customer VLAN
Execution Manual CLI
Validation Pre-Check + Post-Check
Outcome Ready to Execute

03 • Operational Assessment

Determinism Unknown
Error Risk Unknown
Rollback Unknown
Operational Model Manual Change

04 • Change Console

[READY] Deterministic change lab initialized.
[INFO] Configure the change and execute the workflow.
Engineering Takeaway: Automation is not simply about replacing CLI commands with scripts. The operational advantage comes from creating a repeatable workflow: define intent, validate the current state, apply the change, verify the outcome and provide a controlled recovery mechanism when something fails.

Tech Brief Video Series – Enterprise Networking

by Blog

Hello,

I have created an “Enterprise Networking Tech Brief” Series. Kindly click on the link to view the video. I’m trying out a few videos styles.

Enterprise Networking A –  LISP Components & DEMO – > https://youtu.be/PBYvIhxwrSc

Enterprise Networking B – SD-Access & Intent-based networking – > https://youtu.be/WKoGSBw5_tc

” In campus networking, there are a number of different trends that are impacting the way networks will be built in the future. Mobility, pretty much every user that is getting onto the campus is a mobile device. It used to be only company-owned devices, nows it is about BYOD and wearables. It is believed that the average user will bring about 2.7 devices to the workplace – a watch, and intelligent wearables. This aspect access to printers or collaboration systems. They also expect the same type of access to cloud workloads and application workloads in private DC. 

All this to be seamless across all devices. Iot – the corporate IoT within a campus network-connected light, card readers, all the things you would like to find in an office building. How do you make sure these cannot compromise your networks. Every attack we have seen in 12 – 19 has involved an insecure IoT device that is not managed or produced by I.T., In some cases, this IoT Device has access to the Internet, and the company network cause issues with malware and hacks. The source from Matt Conran Network World

Enterprise Networking C – Hands-on configuration for LISP introduction – > https://youtu.be/T1AZKK5p9PY

Enterprise Networking D – Introducing load balancing – > https://youtu.be/znhdUOFzEoM

” Load balancers operate at different Open Systems Interconnection ( OSI ) Layers from one data center to another; common operation is between Layer 4 and Layer 7. This is because each data centers hosts-unique applications with different requirements. Every application is unique with respect to the number of sockets, TCP connections ( short-lived or long-lived ), idle time-out, and activities in each session in terms of packets per second. One of the most important elements of designing a load-balancing solution is to understand fully the application structure and protocols”

Enterprise Networking E –  Hand-on configuration for LISP Debugging – > https://youtu.be/h7axIhyu1Bs

Enterprise Networking F – Types of load balancing – > https://youtu.be/ThCX03JYoL8

“Application-Level Load Balancing: Load balancing is implemented between tiers in the applications stack and is carried out within the application. Used in scenarios where applications are coded correctly making it possible to configure load balancing in the application. Designers can use open source tools with DNS or some other method to track flows between tiers of the application stack. Network-Level Load Balancing: Network-level load balancing includes DNS round-robin, Anycast, and L4 – L7 load balancers. Web browser clients do not usually have built-in application layer redundancy, which pushes designers to look at the network layer for load balancing services. If applications were designed correctly, load balancing would not be a network-layer function.”

Enterprise Networking H – Introducing application performance and buffer sizes – > https://youtu.be/d36fPso1rZg

“Today’s data centers have a mixture of applications and workloads all with different consistency requirements. Some applications require predictable latency while others sustained throughput. It’s usually the case that the slowest flow is the ultimate determining factor affecting the end-to-end performance. So to try to satisfy varied conditions and achieve predictable application performance we must focus on consistent bandwidth and unified latency for ALL flows types and workloads.”

Enterprise Networking I – Application performance: small vs large buffer sizes – > https://youtu.be/JJxjlWTJbQU

“Both small and large buffer sizes have different effects on application flow types. Some sources claim that small buffers sizes optimize performance, while other claims that larger buffers are better. Many of the web giants including Facebook, Amazon, and Microsoft use small buffer switches. It depends on your environment. Understanding your application traffic pattern and testing optimizations techniques are essential to finding the sweet spot. Most out-of-the-box applications are not going to be fine-tuned for your environment, and the only rule of thumb is to lab test.

Complications arise when the congestion control behavior of TCP interacts with the network device buffer. The two have different purposes. TCP congestion control continuously monitors available network bandwidth by using packet drops as the metric. On the other hand buffering is used to avoid packet loss. In a congestion scenario, the TCP is buffered, but the sender and receiver have no way of knowing that there is congestion and the TCP congestion behavior is never initiated. So the two mechanisms that are used to improve application performance don’t compliment each other and require careful testing for your environment.”

Enterprise Networking J – TCP Congestion Control – > https://youtu.be/ycPTlTksszs

“The discrepancy and uneven bandwidth allocation for flow boil down to the natural behavior of how TCP reacts and interacts with insufficient packet buffers and the resulting packet drops. The behavior is known as the TCP/IP bandwidth capture effect. The TCP/IP bandwidth capture effect does not affect the overall bandwidth but more individual Query Completion Times and Flow Completion Times (FCT) for applications. The QCT and FCT are prime metrics for measuring TCP-based application performance. A TCP stream’s pace of transmission is based on a built-in feedback mechanism. The ACK packets from the receiver adjust the sender’s bandwidth to match the available network bandwidth. With each ACK received, the sender’s TCP starts to incrementally increase the pace of sending packets to use all available bandwidth. On the other hand, it takes 3 duplicate ACK messages for TCP to conclude packet loss on the connection and start the process of retransmission.”

Enterprise Networking K – Mice and Elephant flows – > https://youtu.be/vCB_JH2o1nk

” There are two types of flows in data center environments. We have a large, elephant and smaller mice flow. Elephant flows might only represent a low proportion of the number of flows but consume most of the total data volume. Mice flows are, for example, control and alarm/control messages and usually pretty significant. As a result, they should be given priority over larger elephant flows, but this is sometimes not the case with simple buffer types that don’t distinguish between flow types. Priority can be given by somehow regulating the elephant flows with intelligent switch buffers. Mice flows are often bursty flows where one query is sent to many servers. This results in many small queries getting sent back to the single originating host. These messages are often small only requiring 3 to 5 TCP packets. As a result, the TCP congestion control mechanism may not even be evoked as the congestion mechanisms take 3 duplicate ACK messages. Due to the size of elephant flows they will invoke the TCP congestion control mechanism (mice flows don’t as they are too small).

Enterprise Networking L – Multipath TCP – > https://youtu.be/Dfykc40oWzI

“Transmission Control Protocol (TCP) applications offer reliable byte stream with congestion control mechanisms adjusting flows to current network load. Designed in the 70s, TCP is the most widely used protocol and remains largely unchanged, unlike the networks it operates within. Back in those days the designers understood there could be link failure and decided to decouple the network layer (IP) from the transport layer (TCP). This enables the routing with IP around link failures without breaking the end-to-end TCP connection. Dynamic routing protocols do this automatically without the need for transport layer knowledge. Even Though it has wide adoption, it does not fully align with the multipath characteristics of today’s networks. TCP’s main drawback is that it’s a single path per connection protocol. A single path means once the stream is placed on a path ( endpoints of the connection) it can not be moved to another path even though multiple paths may exist between peers. This characteristic is suboptimal as the majority of today’s networks, and end hosts have multipath characteristics for better performance and robustness.”

Enterprise Networking M – Multipath TCP use cases – > https://youtu.be/KkL_yLNhK_E

“Multipath TCP is particularly useful in the multipath data center and mobile phone environments. All mobiles allow you to connect via WiFi and a 3G network. MPTCP enables either the combined throughput and the switching of interfaces ( Wifi / 3G ) without disrupting the end-to-end TCP connection. For example, if you are currently on a 3G network with an active TCP stream, the TCP stream is bound to that interface. If you want to move to the Wifi network you need to reset the connection and all ongoing TCP connections will, therefore, get reset. With MPTCP the swapping of interfaces is transparent. Next-generation leaf and spine data center networks are built with Equal-Cost Multipath (ECMP). Within the data center, any two endpoints are equidistant. For one endpoint to communicate to another, a TCP flow is placed on a single link, not spread over multiple links. As a result, single-path TCP collisions may occur, reducing the throughput available to that flow. This is commonly seen for large flows and not small mice flow.”

Enterprise Networking N – > Multipath TCP connection setup – > https://youtu.be/ALAPKcOouAA

“The aim of the connection is to have a single TCP connection with many subflows. The two endpoints using MPTCP are synchronized and have connection identifiers for each of the subflows. MPTCP starts the same as regular TCP. If additional paths are available additional TCP subflow sessions are combined into the existing TCP session. The original TCP session and other subflow sessions appear as one to the application, and the main Multipath TCP connection seems like a regular TCP connection. The identification of additional paths boils down to the number of IP addresses on the hosts. The TCP handshake starts as normal, but within the first SYN, there is a new MP_CAPABLE option ( value 0x0 ) and a unique connection identifier. This allows the client to indicate they want to do MPTCP. At this stage, the application layer just creates a standard TCP socket with additional variables indicating that it wants to do MPTCP. If the receiving server end is MP_CAPABLE it will reply with the SYN/ACK MP_CAPABLE along with its connection identifier. Once the connection is agreed the client and server will set upstate. Inside the kernel, this creates a Meta socket acting as the layer between the application and all the TCP subflows.”

More Videos to come!

Additional Enterprise Networking information can be found at the following: