What is Software-Defined Networking and Virtual Networks in Physical Networks

Network virtualization and Software-Defined Networking (SDN) stem from a common pursuit - The goal of greater network agility and the ability to share certain traits:

• Both use software to recreate key components of networking infrastructure
• Both separate the control plane (the part of the network that manages and controls it- a network's brains) from the data plane (the part where data traffic flows- a network's muscles) This means that with both network virtualization and SDN, network control can be programmed directly for applications and network services, without the need for manual configuration.
• Both use a controller that runs specialized software to centralize network management.
• Both (to varying degrees) fulfill the primary goal of increased agility by allowing administrators to quickly and precisely adjust the flow of data traffic across a network.

 

Over time, however, SDN has become more broadly-defined than network virtualization, meaning different things depending on who you speak to and how they are using SDN. The thread that links these different definitions is SDN's use of software to control networks and their physical devices. With SDN, software controls network switches and routers, but the network is not fully virtualized, as it is with network virtualization (components, configurations, functions, and all). Hardware often still plays a major role in an SDN network.

Network virtualization allows you to look at your current physical network from a fresh perspective, one in which you're no longer restricted to the capabilities of your hardware. Software vastly extends your range of possibilities, recreating your hardware as a virtualized pool that can then be used as needed, on-demand.

Imagine your physical network doubled in scope: your physical network is there doing the job it's always done, but in parallel with it, you now have an identical virtual version running independently, alongside or on top of it. Once that virtual network has been created, it can be saved, closed, and restored later, possibly at another site. Or it can be deleted altogether.

 

Now imagine the scope of your physical network tripled, quadrupled, or more, Since virtualization separates networking from the underlying hardware, you can create as many virtual networks (copies of the physical network) as you need. Each of these virtual networks runs in splendid isolation, unaffected by events in other virtual networks or in the data center.

 

Bridging Between Virtualized Networks and Traditional VLANs

As we mentioned in section 2.1, creating a virtual network on top of a physical network is known as overlay networking. The underlying infrastructure becomes the underlay - also known as the physical (Layer 3) network. Several overlay methodologies exist. Two of the most widely-used are Virtual Extensible Local Area Network (VXLAN) and Generic Network Virtualization Encapsulation (GENEVE). It is important to note that VXLAN is vendor-neutral and has been recognized as RFC (Request for Comments) 7348, which is a formal document from the Internet Engineering Task Force (IETF).

 

VXLAN works on hardware (e.g., on routers or switches), on software (e.g., on a hypervisor) or on both (hybrid). It uses 24-bit binary identifiers (from 00000000000000000000 to 111111111111111111111111 and everything in between) meaning that a maximum 16,777,215 VXLANs are possible. Compare that to the maximum 4096 VLANs permitted by their 12-bit identifiers! A VXLAN ID is called a VXLAN Network Identifier (VNI). Each VNI is a separate virtual network that runs in the overlay network which is also known as bridge domains.

 

VXLAN Tunnel Endpoints (VTEPs) connect the physical network to the overlay network. Every VTEP has an IP address in the physical network and one or more VNIs in the overlay network. Encapsulated traffic (traffic that’s had certain information added to it at key stages of its journey - see section 4) is transferred between hosts via a stateless tunnel that is created between a source VTEP and a destination VTEP. By the time data from a host reaches a VXLAN switch, it’s in the form of frames, specifically “inner MAC frames” which include MAC (i.e., hardware) address information and data. The switches add a “VXLAN header” containing the 24-bit VNI.

 

The source VTEP then adds the IP address of the destination VTEP in an IP header, as well as its own IP address. It adds a User Data Protocol (UDP) header (UDP being the transport protocol that VXLAN uses). The MAC address of the next physical device that the frame will be delivered to on its journey is added in an Ethernet header. The physical network (the underlay) forwards the encapsulated frame on to the destination VTEP, which removes the headers in a process called decapsulation (mentioned again in section 4). The frame is then delivered to the destination host.

 

GENEVE is a relatively new entrant to the tunnel protocol field. It was jointly developed and drafted as an IETF proposal by Intel, Microsoft, Red Hat, and VMware and released in 2014. At the time this micro-course was written, GENEVE is currently going through the IETF process to become an RFC itself and so GENEVE is equally vendor-neutral. It works almost identically to VXLAN but is more flexible because it offers control plane independence between tunnel endpoints. And there’s a slight difference in terminology: GENEVE does not have VTEPs (VXLAN tunnel endpoints), just tunnel endpoints (TEPs).

 

It is important to note that NSX-V utilizes VXLAN overlay encapsulation, and NSX-T uses GENEVE.