Virtualization has dramatically improved utilization within the datacenter: now, TRILL , FabricPath and VXLAN overlays can do the same for data center networks. This Chalk Talk, by Cisco expert Sanjay K. Hooda, explains how you can use them to distribute data traffic far more effectively, utilizing virtually all of your network links.
Over the last several years, Virtualization and cloud technologies have become increasingly popular. The realization by the Enterprises that the server resources (including CPU, memory) were heavily underutilized led to the move towards virtualized datacenters. In virtualized datacenters every physical server runs one or more virtual server on top of hypervisor.
Network architects are now faced with ever increasing need to provide the connectivity to the virtual machines, which can move from one physical server to another. To address these requirements, various overlay technologies including TRILL, FabricPath, VXLAN, NVGRE, SPBV etc. have been established. In this article, we will go through high-level basics of FabricPath, TRILL and VXLAN.
The trend towards virtualization of physical servers, especially in large data centers, requires both support for distributed applications at a large scale and the flexibility to provision them in different zones of data centers. This necessitated the need to develop a scalable and resilient Layer 2 fabric enabling any-to-any communication. Cisco pioneered the development of FabricPath to meet these new demands. FabricPath provides a highly scalable Layer 2 fabric with a required level of simplicity, resiliency, and flexibility.
While preserving the plug-n-play features of the Classical Ethernet, Cisco FabricPath provides multi-pathing, high availability, forwarding efficiency by forwarding traffic over the shortest path by discovering the shortest path using Layer-2 IS-IS and conversational learning to meet the challenge to work with small MAC address (Layer-2) table sizes in large Layer-2 domains.
To forward the frames, FabricPath employs hierarchical MAC addresses that are locally assigned. FabricPath encapsulates the original Layer 2 frame with a new source and destination MAC address, a FabricPath tag, the original Layer 2 frame, and a new CRC. To forward the frames in the FabricPath network, the outer source and destination MAC addresses contain a 12-bit unique identifier called a SwitchID. The SwitchID is the field used in the FabricPath core network to forward packets to the right destination switch.
Transparent Inter-Connection of Lots of Links (TRILL) is a technology that addresses the same requirements as the Cisco FabricPath and has almost the same benefits as FabricPath. Unlike FabricPath TRILL, is an IETF standard that was proposed to address the various STP challenges including inefficient utilizations of links, long convergence times, and MAC address table scaling in the Datacenter networks.
Like FabricPath, TRILL uses IS-IS as the control protocol with the idea of taking the advantages of a Layer 3 routing protocol and at the same time maintain the simplicity of a Layer 2 network.
To forward frames, TRILL uses a MAC-in-MAC encapsulation format. The ingress RBridge encapsulates the original Layer 2 frame with a new source and destination MAC (the MAC addresses of the source RBridge, and the next-hop RBridge, respectively), a TRILL Header, (which has the Ingress and Egress nicknames that identify the source and destination RBridge, respectively), and the original Layer 2 frame with a new CRC. The incoming 802.1q or q-in-q tag needs to be preserved in the inner header. Egress RBridge removes the headers added by the ingress RBridge and will forward them based on the inner frame.
VXLAN (Virtual Extensible LAN) has become the most popular overlay protocol today. VXLAN’s support from a number of networking vendors, including Cisco, VMWare etc., along with the fact that it runs over IP core, makes VXLAN a popular choice for deployment in massive scale data centers. VXLAN is probably one of the few overlay protocols that has been deployed both as a host-based overlay as well as a network overlay
Today, the primary mode of deployment of VXLAN is with IP multicast. VXLAN uses VXLAN tunnel endpoints (VTEPs) to map the endpoints to VXLAN segments. As we can extrapolate, a VTEP has two interfaces -- one connecting to the IP network and another one to local segment -- which support bridging.
VXLANs use of IP multicast has led to manageability issues that have resulted in exploring multicast-less options. Multicast-less options, which are gaining popularity, should lead to Head-end replication based VXLAN schemes as the SDN controller enabled implementations gain traction.
Various virtual switches natively support VXLAN encapsulation and decapsulation. Datacenter customers have already been able to rapidly bring up virtual applications with integrated services by employing VXLAN as a host-based overlay.
Over the last couple of years there has been an incredible rise in the popularity of VXLAN. The MAC over IP/UDP overlay format, along with the potential to support up to 16 million virtual network segments, makes VXLAN a leading choice for multi-tenant data center deployments.
From interoperability with the existing network devices perspective, VXLAN can interoperate with existing network using VXLAN gateways, and it can be incrementally deployed, thereby allowing continuous communication with existing nodes.
About the Author
Sanjay K. Hooda is currently Principal Engineer in catalyst switch software engineering at Cisco. He has 15+ years of network design and implementation experience in large enterprise environments, and has participated in IETF standards activities. His interests include wireless, multicast, TRILL, FabricPath, High Availability, ISSU (In Service Software Upgrade) and IPv6. Hooda is co-author of IPv6 for Enterprise Networks.