Software-Defined Networking (SDN) and segmentation are often discussed simultaneously because they both prioritize automation. SDN automates a lot of tasks involved in networking, and since most modern security breaches are automated, segmentation tools should follow a similar suit. In addition, trust-boundaries have traditionally been understood as residing in the network layer of any cloud architecture. Because SDN controllers enable large-scale network architectures to be centrally managed and orchestrated, it makes sense to add segmentation to those controllers for better orchestration.
That being said, you should keep in mind that the “N” in SDN stands for networking. Therefore, any segmentation deployed by any SDN controller will be implemented to focus on network challenges, not host challenges. SDN controllers view hosts in the traditional manner, as nodes that attach to the network fabric, and applications running on those hosts are managed using host-centric tools, not network-centric tools. Networking tools rarely manage tasks that are specific to every single host or application. Controllers create network segments to enforce traffic-forwarding decisions in the network fabric, and these decisions are made according to the metrics that are most relevant to routers and switches, including network load, latency, link failures, and dynamic routing protocol costs. These metrics are rarely relevant to host-specific segmentation requirements.
Network segmentation and host-based micro-segmentation
When defining trust-boundaries, deciding where to create relevant segments will result in two parallel conversations: one between the team that manages host workloads and one between the team that manages the network. Both teams will use the same term – “segmentation” or “micro-segmentation” – but they will mean different things. If the two teams use their own tools to deploy and manage each type of segment, instead of working together, the result will be a siloed approach that will lead to operational limits as the scale of the architecture grows.
For example, your networking team may have deployed Cisco ACI as its data center SDN solution. ACI uses its own mechanisms to create segments, such as bridge domains, and endpoint groups (EPGs). Workloads are deployed within EPG’s, and can be split into smaller “micro EPGs” to create more granular network segments.
However, these are still network-centric segmentation concepts. If you have ten hosts in your data center, for example, you can simply create ten EPG segments in Cisco ACI to enforce a trust-boundary at each host. But if you have 100 or 1,000 workloads, it is operationally unrealistic to create 100 or 1,000 EPG segments for each host. Using the SDN controller to create an equal number of network segments and hosts simply will not scale.
SDN solutions will create their own segments to address network segmentation priorities, but in order to segment individual hosts, you should consider a host-based approach.
SDN and overlay networks
One of the benefits of SDN is the fact that network topologies are no longer dependent on the physical topology of routers and switches. Tunneling protocols, such as VXLAN or GENEVE, are used to virtualize the network. Since the network can now be virtualized in much the same way as data center compute and storage resources, these tunneling methods are used to allow network paths and links to be defined in a programmatic way, enabling the controller to quickly re-configure network topologies as required without the need for changes to the physical infrastructure. This allows the network fabric in an on-premise data center to be virtualized, similar to how networks are virtualized in public cloud network fabrics.
Since overlay networks, such as VXLAN, have a large number of unique IDs – over 16 million – it is tempting to want to use these IDs to create micro-segmentation architectures that allow the SDN controller to allocate segments for every host on the network. But SDN controllers don’t terminate VXLAN segments at individual hosts. All of these unique IDs are used by SDN controllers to solve networking challenges, such as encapsulating Layer-2 packets within Layer-3 frames. In order to enable micro-segmentation at every host, the mechanism used needs to be enabled at the host itself, and not by any external SDN controller that is deployed in the network and focused on networking tasks.
How can host-level tools help SDN?
A challenge for most SDN solutions is visibility into the application flows. Being able to determine application behavior from an application perspective is a challenge for networking tools. SDN controllers have deep visibility into network topologies, network segments, IP addresses, and traffic metrics, but getting a clear picture of the behavior and required network resources between your SQL servers and your web servers, for example, is often not easy with SDN controllers. Knowing the dynamic requirements between applications on a network is necessary to design a scalable cloud architecture.
When deploying host-based solutions, like Illumio, into a data center that uses an SDN architecture, you should look for mapping capabilities, like our application dependency map, to aid in the design of network resources that address host-specific requirements. Illumio co-exists with any SDN solution, and while the application dependency map is used to define host-specific segments, this same map enables a clear picture of application requirements when the network is deployed and managed by the SDN controller.
Host-based micro-segmentation and network-level segmentation can and should co-exist, since they each address a different requirement. By implementing a host-based approach, you are afforded the application-level visibility capabilities that allow SDN solutions to guarantee network resources across any cloud architecture.
For more information on Illumio's approach to host-based micro-segmentation, visit https://www.illumio.com/solutions/micro-segmentation