Open Networking — From Disaggregated Hardware to Programmable Fabrics
Open networking is not a single product or protocol. It is an architectural approach that separates hardware, network software, control, telemetry and automation so infrastructure can become more programmable, interoperable and adaptable.
Separate Hardware
Treat switching hardware and network software as independently selectable components.
Expose Control
Use protocols, APIs and software interfaces to make network behaviour programmable.
Operate at Fabric Scale
Move from box-by-box configuration toward repeatable desired-state workflows.
Measure Network State
Use telemetry and analytics to understand actual network behaviour continuously.
Can the network change without requiring every layer to be redesigned or every device to be configured independently?
Open networking moves intelligence toward software, automation and common interfaces.Open Networking Architecture Explorer
Open networking separates the physical switching platform from the software controlling it, allowing organizations greater freedom in hardware selection.
Why disaggregation matters
Traditional networking commonly couples hardware, operating system and features into a single vendor stack. Open networking separates these functions so each layer can evolve independently.
What Does “Open” Actually Mean?
Open networking begins by separating the components that traditionally arrive as one integrated platform: hardware, network operating system, control protocols and operational tooling. The engineering objective is reduced coupling, greater choice and programmable interfaces.
Open Networking Starts With Separation
Open networking begins by separating the functions that traditional networking often bundles together. Hardware provides forwarding capability, network software provides operating and routing functions, control protocols build network state, and automation and telemetry provide the operational feedback loop.
Hardware can become a replaceable platform rather than defining the entire software stack.
Network operating systems and routing software can be selected according to operational requirements.
Standards, APIs and models allow systems to exchange state and participate in common workflows.
Configuration and lifecycle operations can move from individual devices toward repeatable fabric-wide processes.
Open networking is not simply “using open source.” The architectural objective is to reduce unnecessary coupling between hardware, software, control and operations so that each layer can evolve without forcing the entire network to change with it.
The forwarding infrastructure moves traffic according to the state programmed into the network.
Routing protocols and control systems determine reachability and distribute network information.
APIs, automation and telemetry provide the mechanisms for configuring, observing and validating the network.
Separate the Platform From the Network Software
Disaggregation separates the physical switching platform from the network software that controls it. White-box hardware, open network operating systems and routing software can therefore become independent architectural choices rather than a single fixed product.
Open Networking Architecture Explorer
Explore the four architectural layers that turn a traditional integrated network platform into a more modular and programmable system. Select a layer or use the architecture tabs to inspect what becomes separated and why that separation matters.
Hardware
Open networking separates the physical switching platform from the software that operates it. This creates greater freedom in choosing the underlying hardware platform, but also introduces responsibility for validating compatibility and lifecycle support.
The hardware platform no longer has to dictate which network software is used.
Separate the Platform From the Network Software
Disaggregation separates the physical switching platform from the network operating system and the control protocols running above it. This creates greater architectural choice, but it also makes lifecycle, integration, compatibility and operational ownership more important.
Exchanges reachability information between routing peers and is widely used for data-centre and service-provider fabrics.
Link-state routing protocol commonly used to build internal IP reachability within an autonomous system.
Link-state protocol used extensively in large-scale provider and data-centre network designs.
A BGP-based control-plane technology commonly used to distribute MAC and IP reachability information for modern overlays.
ASICs and interfaces determine what the platform can physically forward at line rate.
The network OS provides the software environment that connects the platform to routing and operational functions.
Routing protocols exchange information and construct the state used to make forwarding decisions.
APIs, models and automation turn individual device configuration into repeatable operational workflows.
Disaggregation increases choice, but choice introduces responsibility. Hardware compatibility, NOS support, routing features, lifecycle management, observability and operational skills must all be considered as part of the architecture.
Disaggregation Decision Lab
Build an open networking platform by selecting the hardware, network operating system and control model. The objective is not simply to choose “open” components — it is to understand the engineering trade-offs created when the layers are separated.
Disaggregation increases architectural choice, but the responsibility for validating hardware, software, interoperability and lifecycle support also increases.
Build the Fabric With a Routed Underlay
Once the hardware and software layers are separated, the network can be designed as a programmable fabric. A routed IP underlay provides predictable transport while BGP EVPN and VXLAN can provide the control and overlay mechanisms required for scalable workload connectivity.
Build the Fabric With a Routed Underlay and Programmable Overlay
Open networking becomes especially powerful when disaggregated components are assembled into a fabric. A routed leaf-spine underlay provides predictable IP connectivity, while BGP and EVPN can distribute the control-plane information required for scalable workload and overlay connectivity.
Provides simple routed reachability between the devices that make up the fabric.
Can provide scalable routing between leaf and spine devices and establish the fabric's IP reachability.
Uses BGP to distribute MAC and IP reachability information for modern Ethernet VPN designs.
Encapsulates tenant traffic across the IP underlay and identifies virtual networks using a VNI.
The underlay answers a fundamental question: can the fabric devices reach one another reliably?
Routing protocols exchange information so devices can calculate paths through the fabric.
VXLAN separates logical networks from the physical topology and provides scalable segmentation.
EVPN distributes endpoint reachability through the control plane, reducing reliance on traditional flood-and-learn behaviour.
Keep the underlay simple and predictable. Put the complexity required for tenant connectivity, segmentation and endpoint distribution into the overlay and its control plane. This separation makes the fabric easier to reason about, troubleshoot and automate.
Open Fabric Path Lab
Follow a packet through a modern open networking fabric. Select each stage to expose the engineering evidence behind the underlay, BGP control plane, EVPN and VXLAN overlay.
Turn Network Operations Into a Programmable System
Open interfaces become valuable when they can be used consistently by automation. Models such as OpenConfig, interfaces such as gNMI, and tools such as Ansible and Terraform allow network intent to become repeatable change rather than a sequence of manual device commands.
Turn Network Operations Into a Programmable System
Once hardware and network software are separated, the next engineering challenge is operating the infrastructure consistently. APIs, configuration models and automation allow engineers to describe, deploy and validate network state without relying on repetitive device-by-device configuration.
Define what the network should provide.
Represent configuration using structured data and models.
Apply repeatable changes across the infrastructure.
Push validated state into network devices and services.
Compare the resulting state with the intended state.
Treat network change as an operational lifecycle.
Open, vendor-neutral data models commonly used to represent network configuration and operational state.
A management interface commonly used to retrieve and modify structured configuration and operational data.
Automation and configuration-management tooling suited to repeatable network changes and operational workflows.
Infrastructure-as-code tooling commonly used to provision and manage infrastructure through declarative configuration.
Automation should not simply make configuration faster. The stronger objective is repeatability: the same intent should produce a predictable result, and the resulting network state should be measurable and verifiable.
APIs provide a programmable interface instead of forcing every operation through manual CLI interaction.
Models provide a consistent representation of configuration and operational information.
Automation turns individual operations into repeatable workflows that can be applied across the fabric.
Desired-State Automation Lab
Define the network you want, generate the intended configuration, deploy the change, then verify that the fabric actually reached the desired state.
You Cannot Automate What You Cannot Observe
Programmable infrastructure needs equally strong visibility. Interface state, routing information, traffic flows and system health provide the evidence required to understand what the network is actually doing. Telemetry turns network state into operational data.
Expose the State of the Network
Programmability is only useful when engineers can also observe the resulting network state. Open networking therefore depends on telemetry that exposes interfaces, routing state, traffic behaviour and system health so that automation can be validated against what the network is actually doing.
Counters, errors, link state and utilisation reveal the health of physical and logical interfaces.
BGP, OSPF, IS-IS and EVPN state shows whether the control plane is building the expected reachability.
Flow records and sampled telemetry provide visibility into communication patterns and traffic volumes.
CPU, memory, buffers, process state and platform health provide additional operational context.
Streaming telemetry can deliver operational state continuously rather than relying entirely on periodic polling.
OpenConfig and interfaces such as gNMI help expose structured configuration and operational information.
Technologies such as sFlow provide sampled visibility into traffic patterns without requiring full packet capture.
Automation without telemetry creates blind change. Telemetry without automation creates visibility without scale. The stronger architecture connects both: change the network, observe the result, compare it with the intended state, and investigate any deviation.
Telemetry Investigation Console
Select the signals you would use to investigate a fabric event, correlate them against the timeline, and build enough evidence to distinguish a control-plane problem from a forwarding or workload problem.
Separate Logical Networks From the Physical Fabric
Modern fabrics often carry many logical networks across the same physical infrastructure. VXLAN provides the encapsulation mechanism, while EVPN can provide the control-plane information required to distribute endpoint and reachability state across the fabric.
Separate Logical Networks From the Physical Fabric
Network virtualisation allows logical connectivity to span a physical fabric without requiring every physical link to represent a separate tenant or broadcast domain. VXLAN provides the encapsulation mechanism, while EVPN can provide the control-plane information needed to discover and distribute endpoint reachability.
Switches, links and interfaces provide the physical transport between fabric nodes.
Routed connectivity provides the transport path between VTEPs across the fabric.
Tenant Ethernet frames can be encapsulated inside IP packets for transport across the underlay.
BGP EVPN distributes endpoint information so VTEPs can make informed forwarding decisions.
| FUNCTION | ROLE |
|---|---|
| UNDERLAY | Provides IP reachability between the physical fabric devices. |
| VTEP | Encapsulates and decapsulates VXLAN traffic at the edge of the overlay. |
| VNI | Identifies a VXLAN virtual network and separates logical connectivity within the overlay. |
| EVPN | Distributes MAC and IP reachability information through the control plane. |
| VXLAN | Carries the overlay traffic across the IP underlay using encapsulation. |
VXLAN uses a 24-bit VNI, providing a large identifier space for logical networks.
VTEPs connect local workloads to the VXLAN overlay and perform encapsulation and decapsulation.
EVPN provides control-plane distribution of endpoint information rather than relying entirely on flood-and-learn behaviour.
Logical networks can span different physical locations and paths without changing the underlying fabric topology.
The underlay should answer “How do I reach the VTEP?” while the overlay answers “Which logical network and endpoint am I trying to reach?” Keeping those responsibilities separate makes large fabrics easier to scale, troubleshoot and automate.
VXLAN Overlay Packet Trace
Trace an Ethernet frame across a shared IP fabric and see where the logical network, VNI, VTEPs and VXLAN encapsulation fit into the forwarding path.
Ethernet frame
Encapsulation
ECMP
Decapsulation
Ethernet frame
Extend Open Networking Into the Host
The network does not end at the top-of-rack switch. Linux networking, virtual switching and container networking extend connectivity into servers and workloads. This creates another programmable layer that must be automated, observed and secured alongside the physical fabric.
Extend Open Networking Into the Workload Layer
Open networking does not stop at the physical switch. Linux networking, virtual switches and container networking extend the same programmable principles into the systems and workloads connected to the fabric. The result is a network model that spans physical interfaces, virtual interfaces, workloads and applications.
Provides interfaces, routing, namespaces, bridges, firewalling and other host-level networking capabilities.
A software switch designed for programmable virtual networking and integration with physical and virtual infrastructure.
Provide isolated network views that can separate interfaces, routing tables and network resources.
Connects containers to host and external networks through bridges, virtual interfaces or additional networking systems.
Server connects to the fabric.
Linux provides the local network stack.
Software switching connects logical interfaces.
Containers or VMs consume network connectivity.
Traffic exits through the physical network.
Linux provides a powerful networking environment that can be automated alongside the physical fabric.
OVS provides software-based switching between virtual and physical network interfaces.
Containers consume network connectivity through host and container networking mechanisms rather than directly owning the physical fabric.
The physical fabric and workload network should be treated as connected layers rather than one giant control plane. The fabric provides transport, while Linux, virtual switching and workload networking provide connectivity closer to the application.
Host Networking Stack Inspector
Follow connectivity from an application workload through the Linux network namespace, virtual switch, physical NIC and finally into the upstream fabric.
The Network Becomes a Continuous Feedback System
The final step is connecting intent, automation and telemetry into a controlled feedback loop. The network should not simply accept changes; it should provide evidence that the resulting state matches the design, detect meaningful drift and support controlled remediation.
Turn Open Networking Into a Closed-Loop System
The real advantage of an open network appears when programmability, automation and telemetry operate as one system. Desired state defines the intended configuration, automation applies it, the fabric delivers connectivity, telemetry exposes the resulting state and validation determines whether the network still matches the design.
Define what the network should look like.
Translate intent into repeatable configuration.
The physical and virtual network delivers connectivity.
Collect evidence about the resulting network state.
Compare observed state with intended state.
Correct validated deviations and verify again.
Automation should operate against an explicit desired state rather than an undocumented collection of commands.
Telemetry and state data provide the evidence required to determine whether a deviation is real.
Not every difference should trigger an automatic change. Context and policy must determine the response.
A successful configuration deployment is not the final result. The resulting network state must also be verified.
Does the deployed configuration match the intended model?
Are routing adjacencies and learned paths behaving as expected?
Is traffic actually following the expected forwarding path?
Does telemetry confirm that the network remains healthy over time?
Open networking becomes strategically valuable when openness is combined with automation and evidence. The goal is not simply to make individual devices programmable, but to create a network that can be defined, changed, observed, validated and safely corrected as a system.
Closed-Loop Network Validation
Introduce configuration drift into a network, collect evidence, identify the affected state and safely drive the system back toward the intended design.
