In June this year, Cisco launched their Software Defined Access (SDA), which is a solution in the intent-based networking space. There are also other players in this space, such as Apstra. What is intent-based networking, though?
Traditionally we have built networks with a imperative approach, meaning that we must precisely specify all of the components to end up with our desired state. To demonstrate this, let’s start with a simple example where we have traditional network architecture.
This network is a fairly simple network which is typical for a smaller office. We have two users, Bob and Alice, who belong to different departments. Bob is in the HR department, and Alice is in the Sales department. Our end goal for Alice to be able to reach the file server but not Bob. They both should be able to access the Internet, though.
If we are starting from scratch and configuring this scenario, here are some of the steps we would have to take to configure this scenario:
- Assign a VLAN for HR users
- Assign a VLAN for Sales users
- Assign a VLAN for servers
- Assign a subnet for HR users
- Assign a subnet for Sales users
- Assign a subnet for servers
- Configure Bob’s and Alice’s ports to be in the correct VLAN (access port)
- Configure the trunk from the access layer to the distribution layer to allow these VLANs
- Configure the trunk between the distribution switches to allow these VLANs
- Configure two SVIs in the distribution switches
- Configure HSRP on the distribution switches
- Configure an ACL on the FW to deny traffic from Bob (HR) but allow traffic from Alice (Sales) towards the server
- The ACL should allow traffic from both departments towards the Internet
There are a lot of drawbacks to this approach, some of which I have listed below:
- Assigning VLANs and subnets is a manual approach
- User identity is based on IP address
- Security is bypassed if a user can get an IP in the “right” subnet
- Underlying topology has to be updated for every change
- Adding or removing configuration may affect all users
- Many devices need to be touched to update configuration
Some of these can be addressed by using network automation, but here are some of the things we want to accomplish:
- Move away from manually having to provision VLANs and subnets
- Have policy based on something other than IP address
- Achieve better security with authentication
- Create a more stable foundation that is always in place
- Minimize the number of devices that need to be touched in order to configure devices
With an declarative approach, we want to be able to define a policy and have the network figure out all of the details. Our intent is to:
- Allow Bob to access all internal resources except the server, and the Internet
- Allow Alice to access all internal resources and the Internet
- Provide gateway redundancy for the users
We don’t care about what VLAN gets assigned or the subnet. We don’t care about access layer ports or trunks or configuring firewall policies. We just want a network that instantiates the policy above. This is the whole idea behind intent-based networking.
According to Gartner Research VP, Andrew Lerner, an Intent Based Networking System (IBNS) should have the following four components(1):
- Translation and validation: One of the key tenets of IBNS is its ability to translate commands from network administrators into actions the software performs. The idea is that network managers define a high-level business policy they want enforced in the network. The IBNS verifies that the policy can be executed.
- Automated implementation: After a network manager defines the desired state of the network, the IBNS software manipulates network resources to create the desired state and enforce policies.
- Awareness of state: Another key component of IBNS is its gathering of data to constantly monitor the state of the network.
- Assurance and dynamic optimization/remediation: The IBNS constantly ensures the desired state of the network is maintained. It uses machine learning to choose the best way to implement the desired state and can take automated corrective action to maintain state.
To be able to build a network like this, we will need a few components, and I will describe these as based on Cisco’s SDA network.
Fabric – The fabric is built with Catalyst 9k (UADP 2.0) or Catalyst 3850/3650 (UADP 1.1) switches where the operator does not care about the individual switches, but rather it’s seen as an entity, hence a fabric.
Underlay – The underlay is what provides IP reachability so that the overlay can build its tunnels and find the destination of the tunnel endpoints. Often the underlay is built using Intermediate System to Intermediate System (ISIS), which is also the case in Application Centric Infrastructure (ACI) in DC environments.
Overlay – The overlay is what allows users to connect to any switch that is part of the fabric and belong to a certain subnet and still be able to communicate at L2 with other users present on other switches. Often Virtual eXtensible LAN (VXLAN) is used as the overlay.
Orchestration engine – There needs to be an engine responsible for orchestrating the configuration of the individual devices. In SDA it is the Application Policy Infrastructure Controller Enterprise Module (APIC-EM) that is responsible for this.
Policy engine – Something is needed to instantiate the policy and provide authentication of users. In SDA, this is Identity Services Engine (ISE) that is used in this role.
Management – Management for SDA is done through Cisco Digital Network Architecture Center (Cisco DNA Center) where the design, provisioning, and management of the solution is done.
Assurance – The operator needs to know how the network is performing. Are there any errors? How many wireless users are active? Are there enough IP addresses in the DHCP pools? Network Data Platform (NDP) is what Cisco uses to give the operator insight into the network.
Is intent-based networking really a new concept? In networking, a technology is really never entirely new and based on something else already existing. From my point of view, the new thing is that the future network engineer will have less focus on VLANs, subnets, and ACLs, and more focus on user identity, policy, and providing a good user experience. This does not mean that engineers don’t need knowledge; remember in the back end, this is all provisioned using tools and technologies we have manually configured previously. There will be situations where the operator needs to troubleshoot or collect information for a TAC case, etc. What it means, though, is that less experienced engineers can get more work done, faster. It also means that engineers can focus on more important things than provisioning VLANs.
I hope this blog has given you some insight into what an IBNS is and that it’s not that scary. I look forward to reading your comments and discussing with you.