A quick comparison of EoMPLS, VPLS and A-VPLS really reflects the learning curve the network industry has experienced as the technologies are deployed. All three are PW services and use a MPLS infrastructure to build the PWs. EoMPLS is a point to point technology and as such is well suited for point to point applications. Scaling EoMPLS can be a challenge as the number of PWs increments and we begin to consider meshing options. N*(N-1)/2 anyone? VPLS is an adaptation of EoMPLS where the VPLS network behaves as a switch between the sites and facilities easier multi-point implementation. VPLS doesn't forward STP BPDUs and as such allows or better control of the network. A-VPLS is a Cisco innovation that simplifies the VPLS configuration, enhanced load balancing and availability capabilities while still leveraging a VPLS network.
In any EoMPLS and VPLS implementation a lot of configuration needs to be done that reflects the PW nature of the technology and cross connects per VLAN add to the keyboard time. Don't get me wrong, I've worked with a number of customers who have utilized both EoMPLS and VPLS to meet their requirements. Some have been for short term data center migrations while others are parts of a permanent DCI solution and are production class networks. That said, each one of them has had to come to grips with the details of the technology they employ and it hasn't always been without challenges. A-VPLS addresses many of these challenges with some of the simplicity aspects it incorporates and is the current "state of the art" in PW technology.
What do customers who don't want a PW technology look to provide the DCI component they need? Enter Cisco's Overlay Transport Virtualization (OTV). OTV provides the ability to build a DCI solution without PW technologies and can ride(overlay) any IP network. Additionally, OTV brings many advancements customers have been asking for in other DCI solutions, namely simpler configuration, dynamic MAC advertisement rather than traditional flooding, ARP optimizations and transport agnosticism.
Today OTV is available on the Nexus 7000 series switches, as such meaning it is an NX-OS only feature (this is a NX-OS centric blog, BTW). It is being considered for other platforms and you should work with your local sales team for additional details on that aspect. With that out of the way, let's review how OTV operates. First, OTV uses IP multicast to discover neighbors which simplifies the configuration as each OTV edge device joins the multicast group and finds other OTV edge devices through the group membership. Once the OTV edge devices find each other, they form a neighbor relationship, much like a routing protocol, and exchange key attributes such as VLANs extended, MAC address tables for those VLANs, and more.
With a neighbor relationship established OTV can begin to encapsulate and forward frames across the IP network. When the frames are received they are de-encapsulate d and forwarded on as a normal L2 frame, it really is that simple. With the Nexus implementation this all happens in hardware with very little extra latency added providing a high performance solution in a very resilient and scalable platform.
Some key requirements to keep in mind for OTV today are that there must be an IP multicast network between the edge devices for neighbor discovery to work properly. Additionally, jumbo frames, while not strictly required are extremely recommended. Remember this is an encapsulation technology and an 8 byte shim header is added to each frame to help preserve items such as the CoS markings and VLAN ID. If jumbo fames are not possible on the intermediate IP network smaller MTUs and fragmentation may lead to poor performance.
Clearly there are many options available for DCI with varying levels of complexity and trade-offs to be taken into account. As we've watched the technology mature over time enhancements and optimizations have been added and will continue to evolve and mature over time. It is exciting to see the options and work with customers to determine which one best fits for their environment. What DCI technology do you use and or are considering?
I look forward to your comments and discussing how technologies like LISP will fit in to the big picture.
Ron Fuller, CCIE No. 5851 (Routing and Switching/Storage Networking) is a Technical Solutions Architect for Cisco specializing in data center architectures. He has 19 years of experience in the industry and has held certifications from Novell, HP, Microsoft, ISC2, SNIA and Cisco. His focus is working with enterprise customers to address their challenges with comprehensive end-to-end data center architectures.
Ron's latest book, NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures, has been selected as Cisco Subnet's October, 2010, book giveaway.
Read a chapter excerpt.
Enter this month's book giveaway contest.
Buy the book now.