Winding down this year, we only have a couple of topics left: SDNs and SDI. Although SDNs are part of a solid SDI, we want to talk directly about it now.
Many cloud management tools have the ability to create a virtual network. But creating a true VXLAN would require support of the layer 2 to UDP protocol encapsulation. But that raises another question: Is a VXLAN a true SDN?
First, what is a SDN? SDN stands for Software Defined Networking. This means than a very robust network can be created and ran through a software system. That being said, exactly how robust it is, is determined by the package that is either included in your cloud management software, or a third party software that you add to your environment.
So, now that we know what it is, how do we use it? Lets try this example first. You have a basic cloud setup; several tenants (or projects based on your cloud management software (CMS)) are setup. You are using basic network connectivity through your CMS to talk to the physical VLAN that connects your COMPUTE nodes of your cloud.
You can communicate with other systems across your physical network. But now, you would like to add some additional services, such as load balancing (LB), firewalls (FW), and advanced routing (RTR).
Not all SDNs have all of these capabilities, but most that I have worked with do. So here you are, and you want to expand the network first. You would like to have several subnets, with each tenant having its’ own network range of IPs. Firing up your management software, you create a virtual router first. This router makes the connection from the CMS and the SDN to the physical layer of the network. This is at Layer 2 and possibly Layer 3 of the OSI model.
This virtual RTR is now your gateway for all your networks. You can make additional RTRs if you have separate connections to networks below the CMS software. Actually you can have separate RTRs for every network you have, even 20 to 50 of them, but management becomes a nightmare.
You now have at least one network, and you have a RTR attached to it making the connection to the physical VLAN below the CMS. What if you want a LB or a FW on your network? Well, some CMS programs come with the ability to have Security Groups, or filters on your traffic. In the most logical and simple sense, you are using a firewall. It can restrict traffic based on TCP/UDP port, Protocol number (e.g. GRE tunneling uses Protocol number 47, not port 47), sender and receiver and so forth. Truly a firewall in all sense of the word.
But if you want to share policies and centralized management of your FW, you will need to engage an SDN. (In some cases, you can load a major virtual FW, and have it manage all policies).
But what about LBs? That is another great thing of the SDN toolset. Most have the ability to build pools and do SSL off-loading right from within the software. Many LBs and FWs expose an API stack for you to take advantage of, especially if you are functioning in a devops or a CI/CD (Continuous Integration / Continuous Delivery) model.
It is difficult to be vendor agnostic with all the different SDNs available out there. But go slow, do your homework, and you will succeed in nailing it.
By Richard Thayer
