Software Defined Networks: Present and Future
As a famous writer once said, "... once upon a time a light bulb was also considered a miracle, but for ordinary glasses on the nose they could easily burn at the stake ...". Humanity is largely inert and conservative in its views. People do not immediately perceive the new, as you know, the first two manufacturers of zippers for clothes went broke. And now familiar things sometimes pass several turns in a spiral before turning into our usual part of life. The same can be said about technology.
Let's talk about the fashionable topic today, about the so-called software defined networks (SDN), which, it seems to me, has already passed all the preliminary stages and is ready in the near future to turn into a real main stream of network development. I'll start with a few points as a short introduction:
To summarize: SDN is the ideology of building networks in which all the intelligence of the network is placed on a separate hardware / software base, and all traffic control is based on special protocols (for example, OpenFlow), which operate on the concept of “flow” and can perform various actions with it (allow, deny, redirect, rewrite fields in packages, etc.). In fact, the network policy is determined on the controller based on the specified rules, as well as the operation of specialized applications (for example, emulating the operation of STP or routing protocols). Then the final result is transmitted to the switches using the OpenFlow protocol in the form of flow tables containing information about where, how and what traffic to transmit. On the one hand, this approach gives great flexibility in network management, on the other hand, it greatly simplifies administration (and,
A separate topic is building a network security system based on OpenFlow. The controller actually centralizes this function too (in the form of a specialized application) and, potentially, takes over all the intelligence of firewalls, IPSs and other traditional network protection systems.
HP was one of the first to launch a commercial product that supports the OpenFlow protocol. At the same time, HP switches that support OpenFlow are hybrid, i.e. support work simultaneously in two modes - OpenFlow plus traditional switching. Consider a simple example where there are three HP 3800 series switches in a ring. Here so: As controllers several options are collected - Floodlight, SNAC and NOX. In this example, two controllers are configured on the switches - SNAC and Floodlight, like this:
Two instances are configured in OpenFlow, each of which is connected to a separate controller that controls traffic in a separate VLAN. In this example, the SNAC controller is configured to control traffic in VLAN 3, the Floodlight controller is configured to control traffic in VLAN 4, like this:
Certain ports are enabled in the VLANs controlled via OpenFlow, like this:
And, in fact, on this, the OpenFlow configuration on the switches is over. Further, we see that the controller defined the switches and can register them, this is how it looks in the SNAC web interface: Then, as soon as real traffic appears on the ports controlled through OpenFlow, the controller will see the sources from which the traffic is coming: And, based on the settings made, it will send to the switch information about the traffic flows that the switch should process. You can see the flows (flows) to the switch in the switch CLI like this: Next, you can apply various rules to the traffic. So, for example, in the SNAC controller there is a tab where you can apply access policies for different parameters (src / dst MAC, src / dst IP, TCP ports, etc.):
You can look at the network topology, in Floodlight it looks like this: You can look at different statistics on flows, the history of events (who registered on the network, etc.), in SNAC this tab looks like this: In a word, all the intelligence of a network controlled through OpenFlow is now hosted on controllers, where the entire network policy is decided. An important point on which I want to focus: both controllers used in the laboratory are controllers assembled from open source projects. And with both controllers, HP hardware works honestly.
It is said that when Bertrand Russell was asked, “Are you ready to die for your beliefs?”, He answered: “Of course not! I could be wrong. ” I, too, may be mistaken, but, in my opinion, when the SDN from a major trend turns into a main stream (and this will happen very soon, given Moore’s law and looking at how quickly the technologies recognized as “right” are developing), which is familiar to us today the world of networks will change beyond recognition.
Let's talk about the fashionable topic today, about the so-called software defined networks (SDN), which, it seems to me, has already passed all the preliminary stages and is ready in the near future to turn into a real main stream of network development. I'll start with a few points as a short introduction:
- “All news is usually well-known things that happen only to new people every time.”": The very idea of centralizing the intelligence of the network is not new, and the network has partially passed along this path. You can recall how the Internet was arranged in his childhood, how the first gateway-to-gateway protocols worked, what were (and even now, probably, somewhere else) in the hubs that worked through bridges that actually accumulate intelligence, remember also about Configuration Automation & Provisioning systems. There are many examples. But - the concept of SDN is unique in that its main idea is not just to centralize the intelligence of the network on a dedicated device - the controller, but to directly control the data plane from a single center common to the entire network based on special protocols. In fact, this means moving the control plane of the entire network to a centralized, external hardware base,
- “The first thing that any dictator does is simplify all concepts” : in this regard, the ideology of SDN, from the point of view of network devices, is completely “dictatorial”. They “think” for the switches and decide which packets the SDN controllers should send to. The switch is assigned the role of a simple executor. Complex network tasks (such as loop protection or security) are handled by specialized applications in a centralized control plane on controllers.
- “All weak people tend to think that it would be great if no one controlled them; at the same time, they do not realize that they themselves cannot control themselves or others .. ” : SDN ideology allows us to simplify the network devices themselves to the limit (in fact, to support a control protocol for communication with the controller and basic switching functions), make them weak, and therefore cheap. This, ultimately, can drastically reduce OPEX, which prevents all holders of IT budgets from sleeping peacefully.
- “You need to go against the wind to unfurl the flag” : HP was a pioneer in the development of SDN technologies and one of the first to enter the market with a working solution (see below). When there was no OpenFlow yet and the network industry was focusing on other technologies, HP already participated in the development of the predecessor OpenFlow (Ethane, in 2007), and then became one of the active participants in the OpenFlow Network Foundation (ONF) and, in 2011, InCENTRE (Center for testing OpenFlow).
To summarize: SDN is the ideology of building networks in which all the intelligence of the network is placed on a separate hardware / software base, and all traffic control is based on special protocols (for example, OpenFlow), which operate on the concept of “flow” and can perform various actions with it (allow, deny, redirect, rewrite fields in packages, etc.). In fact, the network policy is determined on the controller based on the specified rules, as well as the operation of specialized applications (for example, emulating the operation of STP or routing protocols). Then the final result is transmitted to the switches using the OpenFlow protocol in the form of flow tables containing information about where, how and what traffic to transmit. On the one hand, this approach gives great flexibility in network management, on the other hand, it greatly simplifies administration (and,
A separate topic is building a network security system based on OpenFlow. The controller actually centralizes this function too (in the form of a specialized application) and, potentially, takes over all the intelligence of firewalls, IPSs and other traditional network protection systems.
HP was one of the first to launch a commercial product that supports the OpenFlow protocol. At the same time, HP switches that support OpenFlow are hybrid, i.e. support work simultaneously in two modes - OpenFlow plus traditional switching. Consider a simple example where there are three HP 3800 series switches in a ring. Here so: As controllers several options are collected - Floodlight, SNAC and NOX. In this example, two controllers are configured on the switches - SNAC and Floodlight, like this:
openflow
enable
controller-id 1 ip 192.168.2.10 controller-interface oobm
controller-id 2 ip 192.168.2.11 controller-interface oobm
Two instances are configured in OpenFlow, each of which is connected to a separate controller that controls traffic in a separate VLAN. In this example, the SNAC controller is configured to control traffic in VLAN 3, the Floodlight controller is configured to control traffic in VLAN 4, like this:
instance "snac"
member vlan 3
controller-id 1
limit software-rate 10000
connection-interruption-mode fail-standalone
max-backoff-interval 10
enable
exit
instance "floodlight"
member vlan 4
controller-id 2
limit software-rate 10000
connection-interruption-mode fail-standalone
enable
exit
hardware-statistics refresh-rate 10
Certain ports are enabled in the VLANs controlled via OpenFlow, like this:
vlan 3
name "SNAC"
untagged 1/3,1/13
tagged 1/1,1/23-1/24
no ip address
exit
vlan 4
name "FLOODLIGHT"
untagged 1/4,1/14
tagged 1/1,1/23-1/24
no ip address
exit
And, in fact, on this, the OpenFlow configuration on the switches is over. Further, we see that the controller defined the switches and can register them, this is how it looks in the SNAC web interface: Then, as soon as real traffic appears on the ports controlled through OpenFlow, the controller will see the sources from which the traffic is coming: And, based on the settings made, it will send to the switch information about the traffic flows that the switch should process. You can see the flows (flows) to the switch in the switch CLI like this: Next, you can apply various rules to the traffic. So, for example, in the SNAC controller there is a tab where you can apply access policies for different parameters (src / dst MAC, src / dst IP, TCP ports, etc.):
You can look at the network topology, in Floodlight it looks like this: You can look at different statistics on flows, the history of events (who registered on the network, etc.), in SNAC this tab looks like this: In a word, all the intelligence of a network controlled through OpenFlow is now hosted on controllers, where the entire network policy is decided. An important point on which I want to focus: both controllers used in the laboratory are controllers assembled from open source projects. And with both controllers, HP hardware works honestly.
It is said that when Bertrand Russell was asked, “Are you ready to die for your beliefs?”, He answered: “Of course not! I could be wrong. ” I, too, may be mistaken, but, in my opinion, when the SDN from a major trend turns into a main stream (and this will happen very soon, given Moore’s law and looking at how quickly the technologies recognized as “right” are developing), which is familiar to us today the world of networks will change beyond recognition.