Intent-based networking in practice
In short: Intent-based networking (IBN) lets you state what the network should achieve, for example "guests must never reach finance systems", and lets software turn that into configuration. It then keeps measuring the real network against the intent and alerts or fixes drift. It builds on SDN and automation, and works best with clean data and careful rollout.
From "how" to "what"
Traditional networking is about how: log in to each device and type the exact commands for VLANs, access lists and routing. Intent-based networking (IBN) is about what: you describe the outcome, and the system works out the device configuration. An intent might be "the point-of-sale segment can reach the payment gateway only on HTTPS" or "video calls get priority on all branch links".
IBN is not a single protocol. It is an approach that combines SDN-style central control, automation, a model of the network and continuous monitoring.
The four stages
- Capture and translate. The intent is entered through a GUI, API or policy file. The system translates it into a policy using its model of users, devices, groups and applications.
- Verify before change. Good systems check the proposed policy against the network model to catch conflicts, for example an intent that would cut off management access.
- Activate. The system generates and pushes configuration to the right devices, often across vendors and domains.
- Assure and remediate. Telemetry, test traffic and state checks confirm that the network really behaves as intended. If something drifts, such as a manual change or a failed link, the system alerts or, if allowed, corrects it automatically.
What it looks like in real products
| Area | Typical intent | Example tooling |
|---|---|---|
| Campus | Group-based access: staff, guests, IoT | Cisco Catalyst Center with identity services; other campus fabric controllers |
| Data centre | Application tiers that may talk to each other | Juniper Apstra, Cisco ACI, Arista CloudVision |
| WAN | Application performance and path policies | SD-WAN controllers (see SD-WAN path selection) |
| Verification | "Can host A reach host B?" across the whole network | Network modelling and verification tools that analyse configs |
You can also build intent-style workflows yourself: a source of truth holds the desired state, templates generate configs, a pipeline tests and pushes them, and compliance checks compare running configs with the intent.
Adopting IBN safely
- Clean data first. Intent is only as good as the model. Wrong inventory, IP plans or group membership produce wrong configuration.
- Start in monitor mode. Use assurance and drift detection before you allow automatic remediation.
- Keep humans approving big changes. Automatic fixes are fine for small, well-understood drift; major policy changes need review.
- Protect the platform. Whoever controls the intent controls the network. Use strong authentication, role-based access, change logs and backups.
- Plan for failure. Know how devices behave if the controller is unavailable and how to make emergency changes.
Tip: in interviews, avoid describing IBN as "the network configures itself". A better answer is "the network is configured from declared intent, and assurance keeps checking that the intent is met".
A common mistake is to buy an IBN product and keep making manual CLI changes. The system then reports constant drift, people learn to ignore it and the benefits disappear.
Practice
What is the main difference between traditional configuration and intent-based networking?
What does the assurance stage do?
Why should you start with monitoring rather than automatic remediation?
Key takeaways
- IBN describes desired outcomes and lets software produce device configuration.
- The loop is translate, verify, activate, assure and remediate.
- Assurance with telemetry and drift detection is what separates IBN from simple automation.
- Good source-of-truth data is essential; wrong data gives wrong configuration.
- Adopt in stages and protect the intent platform as critical infrastructure.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.