One concern in networking is that it might be possible for an attacker to move from one device to another using some type of connection that previously exists. But what if you're able to isolate the devices physically? You might, for instance, have switch A and switch B.
And in this scenario, we've created an air gap between both of those devices. If an attacker does find a way to get access to switch A, they would have no way to gain access also to switch B. If there is a requirement for devices on switch A to talk to devices on switch B, then there would obviously need to be some type of connectivity.
This might be a direct connection, or you might be passing the data through another switch or a router. This air gap can be configured for a number of different scenarios. For example, you might have all web servers in one rack and all database servers in another rack.
And if you have an air gap in place, this physical isolation prevents either of those from communicating with the other. You might also see this in a managed service provider, where there are many customers being managed by that single company. And for highly secure environments, the managed service provider might use this physical isolation to put one customer on one switch and another customer on a completely separate, physically isolated switch.
Here's what this might look like. We have customer A on one switch and customer B on the other switch. Devices plugged into customer A switch can communicate between each other.
And devices plugged into customer B switch can also communicate to each other. But notice, there's no connectivity between customer A and customer B. Of course, with physical isolation, we also need two separate physical switches. And if you have 100 customers, you would need 100 switches. Obviously, this is not going to scale very well.
But there are technologies built into your switches that allow for segmentation, but still have everyone connected to the same physical switch. This is using VLANs, or virtual local area networks. This allows you to configure certain interfaces on your switch as belonging to one VLAN, and other interfaces on the switch as belonging to the other VLAN.
VLANs cannot communicate to each other directly, so this has the same effect as having two separate physical switches. This would obviously simplify the network design, and you would need fewer switches to accomplish the same amount of segmentation. When we think about switching and routing, we often consider the physical aspects of those devices. There's interfaces we would connect to, there's a power connection, and we would send information through those devices to be able to forward traffic from one device to another.
But inside those devices, there are different operations that are occurring all at the same time. We refer to these as planes of operation. And from the perspective of SDN, or software defined networking, there are three separate planes that we'll focus on. One is the data plane, the other is the control plane, and then there is the management plane.
This allows us to break these devices apart into their individual functions. And when you do that, you can begin coding that as software. This is a way to take the physical world, turn it into software that can then be used in in our cloud-based world. The infrastructure layer, or the data plane, is the part of the device doing the hard work. Whenever we think about switching and routing, we're talking about the process of forwarding traffic from one device to another.
And that forwarding process is what's happening in the data plane. This is also where network address translation occurs, any type of encryption, trunking, or anything else relating to the networking part of forwarding data. All of this data that's being transferred from one device to another is being managed by the control plane. For example, if you're using a router to forward traffic between IP subnets, there needs to be some type of routing table inside of the router so that we know where this traffic should go.
And in that scenario, the control plane is responsible for managing the routing tables and then taking action on where this data should go. This also includes any type of dynamic routing updates, network address tables, or anything else that can tell the data plane how to get data from point A to point B. And of course, at some point, you'll need to make configuration changes to this device.
When you're connecting to a switch at the command line through SSH and you're making configuration changes, all of those changes are occurring in the management plane. Those changes would then dictate how the control plane manages its session tables and routing tables, and ultimately, that determines how the data plane is going to forward traffic. If we look at a physical switch, we can almost pull apart where the different planes of operation exist. For example, on the front of the switch, we have a number of interfaces that we're connecting our devices to. This would be the data plane, because this is what's sending information from one device to another.
The control plane handles the lookup tables and address translations that are necessary for the data plane to operate. And obviously, we'll need to connect to this device over a console or management interface, and that all occurs at the management plane. Now we can take these three planes of operation and turn them into more of a block diagram.
Here's exactly the same switch, but now we're only dealing with the data plane, control plane, and management plane in more of a block diagram. We know that our network traffic flows on the data plane of this device. We have a control of that traffic occurring in the control plane, so things like dynamic routing protocols and static routes. And the configuration of this device occurs at the management plane using SSH, SNMP, or application programming interfaces.
This has allowed us to create software versions of these physical devices that we traditionally have used, so that we can now use these devices in the cloud. Here is a common cloud-based configuration. We have an internet connection that's connecting to a load balancer. And that load balancer is connecting to web server A, web server B, and the database server for this application.
With cloud technologies using SDN, we can now immediately build out infrastructure devices we might need. For example, in this scenario, we might want to add some firewalls. So we can add a firewall that would separate the internet from the load balancer.
We might want. but another firewall to separate and control traffic between the web servers and the database server. We're able to click a button and dynamically create this technology in the cloud thanks to our software defined networking.