A controller-based network is the new paradigm for SDN: software-defined network. In this article, I will explain what a controller-based network is, why it is different from a traditional network, and how you can transition between the two.
What is SDN?
Maybe you know this already, but since there are many definitions out there read this to ensure we are on the same page. For this article, I define SDN as follows:
A software-defined-network that you can configure by defining how you want the network to be in general, as opposed to configuring individual devices.
We all know a computer network is made up of many different devices: with this definition, there is some sort of system that represents the network as a whole and that you can configure. It will, in turn, set up all the other devices in the network accordingly. If you are curious about this concept, please read our full guide to “What is SDN?”.
Since the network itself is an abstract idea, we need an actual device that you can configure and that will consequently configure the other network devices. That is, my friends, the controller.
What is a Controller?
If you want to know what is a controller-based network, you need to know what is a controller first. Once you understand that, a controller-based network will literally be just a network that relies on a controller to function.
So, based on our definition of SDN, we know what a controller is a system that represents the network as a whole. To be more pragmatic, it is an actual device: a server, most likely a virtual machine. If network devices process user traffic to send it from point A to point B, the controller never processes traffic. Instead, it is just an orchestrator for other devices. You connect to the controller, define your intents, and it will connect to other devices and configure them.
So, a controller has typically two roles. On one side, it is a server, as it is accepts request from the user (the network engineer) via user interface and APIs. On the other hand, it is a client: it calls APIs on all network devices to configure them. Of course, there is much more than just that: it will have a database to keep information about the network, some intelligence to dynamically trigger some configuration on devices, and so on.
What is a Controller-Based Network?
Of course, a controller-based network is an SDN network that it is based on a controller. Note the important thing here: the network is based on the controller. I am not talking about a network that just has a controller, but a network that is based on one.
What is the difference, exactly? If the network is based on the controller, it means it needs the controller to function, at least in part. This means that the network itself, defined as the collection of network devices, will be “dumb” and have limited or no intelligence. They rely on the controller to tell them what to do, and if they have no connectivity with the controller they will be left to their own devices.
In a fully controller-based network, network devices that forward traffic know how to do just one thing: forward traffic. They will allow for configuration of static rules on where the traffic should go, and minimal alternative static paths to pre-configure (like “if you realize A is unreachable, send traffic to B instead”). This allows for minimum functionality and failure-tolerant scenarios in case the controller dies or connectivity between the device and the controller is lost.
A controller-based network has also a consequence that may not be immediately visible: network devices do not need complex routing protocols to communicate with each other. The whole purpose of routing protocols is, in fact, to make each network device aware of the state of the network at any time, and react accordingly. But in this case, since we have a controller-based network, the device can chill out and let the controller to the work. Then, the controller will configure the device only with the bare minimum information that it needs.
More on a Controller-Based Network
With this article so far, you should have a clear understanding of what a controller-based network is. Now, we can dive deeper into the nuances.
Transitioning from Traditional to Controller-Based Network
In a traditional network, we have no controller and instead use routing protocols to have network devices share intelligence. The network engineer needs to configure devices individually, one by one. Picture this against the controller-based network, and you see it is the complete opposite. How do you move from one end of the spectrum to another?
One approach is the “big bang”, but this is unpractical and virtually impossible. With this approach, one day you turn off all your routing protocols and turn on the controller. Yet, if something goes wrong or is not working as expected, you can create significant impact. Of course, the larger the network, the most likely at least something will go wrong. Instead, there are other approaches to use.
Another approach that is easy to execute but that still carries risk is the “segmented big bang”. This is a term I just made up, it is not a technical term. Here, you think about your network as a collection of other networks connected with each other. You will have natural gatekeepers between parts of your network, for example you may have a location with many devices that is then connected through a WAN network to other sites: the two WAN edge devices, such as provider’s routers, are great gatekeepers.
Once you segmented the network, you do a big bang in each segment, which at this point is a smaller portion and is easier to manage. This carries the exact same risks as the fully-fledged big bang, but it limits the blast radius to a part of the network only. The advantage of this approach is that configuring a controller-based network from scratch, without considering integration with traditional protocols, it is much simpler.
Finally, the last approach is the one most companies will need to resort to. This is a phased transition, where traditional and controller-based network coexist for a while. This means you onboard your devices into your controller as they are, with their existing network configuration. The controller must be able to understand and work with that configuration: if there are complex BGP policies and route maps, the controller needs to understand them. Once you have your entire network onboarded, you can work from the controller to start to change how individual devices behave.
Using the controller, you remove complex logic from devices piece by piece. But this time, you tell the controller to remove the complex configuration from the devices, and you are not connecting to them manually anymore.
One disadvantage of this approach is that your controller needs to support many complex features. If you want to build the controller yourself, this can be a showstopper. Instead, if you resort to commercial products such as the ones that Cisco creates (for Cisco devices), they will be expensive.
Costs of a Controller-Based Network
If you go for a controller-based network, you will be faster to deploy changes to your infrastructure, especially for a Datacenter. This benefit offsets the costs of switching to this new paradigm for most companies and in most situations. But what influences the cost of a controller-based network?
Two items influence this cost: the cost of the controller, and the cost of network devices. Ideally, you don’t want to swap all your network devices at once: you want to keep what you have, and replace them with new ones as they go end of life. But the new devices that you buy don’t need to have complex networking features, we just need the basics. Long story short, the cost of network devices will go down over time (as their software components gets smaller).
The other item, of course, is the cost of the controller. This tends to be feature-based, as traditionally hardware companies are trying to move to a more “software as a service” model. So, the fewer the features you need, the cheaper the controller will be. The same is true if you want to implement a custom controller, which is a route worth taking if your company is large enough. The more features you need to develop, the more development hours you will need to spend, and thus the cost will increase.
Controller-Based Network in Summary
In short, a controller-based network is the future of SDN. There, you have a device that acts as the master of the network, you tell it what you want the network to be and it will configure all the network devices on your behalf. Moving to this approach from a traditional network means some form of transition, and this typically involves supporting both the old routing protocols and the newer SDN model.
If you want to learn more on networking, you should start here with our full and free CCNA guide.
