Cisco Logo


Data Center and Cloud

From my perspective, Cisco continues to be a fun place to work for a couple of reasons.  First of all, we have a company full of really smart geeks with networking chops second to none.  Second, we have the freedom to push boundaries and find ways to make our customers’ lives easier.

Bring those two together and you get some interesting results, like the new VXLAN technology we announced at VMworld today. Working with industry notables, Cisco contributed our networking smarts to help develop a technology that will make a big difference for our customers who want to build clouds.  VXLAN is the basis of a scalable cloud network where lots of logical networks (over 16M, courtesy of a 24 bit of logical network identifier) can be created instantly to meet the needs of the even the most complex and dynamic cloud.  Indeed, the technology even pushes the boundary of virtual machine migration beyond a layer 2 domain.  A group of networking and server virtualization companies have submitted a joint proposal to the IETF to have the VXLAN technology standardized.

To read the IETF submittal, click here.  To learn more about why VXLAN should be part of you cloud plans, read this white paper.  If you are at VMworld, by all means, swing by the Cisco or VMware booth to see a demo and get your questions answered.

If you are interested in putting VXLAN to test, stay tuned for the upcoming 1.5 release of Nexus 1000V (entering beta in September 2011).

Look for more posts on the topic, but, in the interim, if you have questions, post them here and we’ll get them answered.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

11 Comments.


  1. Thanks for the pointer to the IETF draft and the new whitepaper. VXLAN is obviously getting a lot of buzz this morning based on the mention in Steve Herrod’s keynote at VMworld 2011.

    As with any new technology, there seem to be lots of questions floating around the InterTubes. Some of them include:

    - If FabricPath, OTV and LISP already exist and are shipping, why introduce VXLAN into the equation? Doesn’t that create confusion?

    - Does this solve new problems that other “overlay” technologies could not solve?

    - Will Cisco continue to support other technologies?

    Hopefully this blog (and others in the community) will spark some healthy discussion about what this means for our industry and how it relates to virtualization and cloud computing. I’ll throw in my initial 2cents:

    - VXLAN is not a vendor-specific technology (co-authored by many companies in both the virtualization and networking space), but it’s still an IETF draft (not a finalized standard) and product implementations by vendors will vary. This is potentially another tool in the toolbox.

    - The IT world is going through a significant shift around roles within the Data Center. Many challenges can now be solved by different functional areas (servers, network, compute, virtualization), and businesses are still working through how to best leverage these new technologies within their organization – based on skill-sets, pricing, business needs, etc.

    As Omar said above, Cisco has always embraced and lead in new technologies that had the ability to give customers choices in how their solve their business problems. VXLAN is another way for Cisco to embrace the broader ecosystem within virtualization and cloud computing, and give our customers choice in how they want to deploy technology to solve their business problems.

       2 likes

  2. Omar, great article. It is fantastic to see the industry acknowledge that legacy network model for data centers no longer meet the requirements for enterprises and providers. This will improve opportunities for everyone in the industry.

       0 likes

  3. This is from: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html

    VXLAN is intended for creating more logical networks in a cloud environment. Overlay Transport Virtualization (OTV) while using similar frame format as VXLAN, is a data center interconnect technology extending Layer 2 domains to different data centers over Layer-3. Unlike VXLAN, OTV has simpler deployment requirements since it does not mandate multicast-enabled transport network. Locator ID Separation Protocol (LISP) goes a step further by providing IP address mobility between data centers with dynamic routing updates. While VXLAN, OTV, and LISP may share similar frame format, they serve very different networking purposes and are hence complimentary to each other.

       0 likes

  4. Hi Omar,

    Interesting technology. Maybe you can answer a couple of quick question that have been bugging me since I read the white paper:

    1. What is the benefit of VxLAN over the older MAC in MAC tunneling that Vmware already has? (presumably, I can use OTV to extend that over the WAN, so what does this buy me?)

    2. It appears that the MAC encapsulation/de-encapsulation happens in the 1000V. Are there other switches or devices that will also perform the encapsulation or de-encapsulation….such as the Nexus 5000/7000….or is this just a VM to VM protocol (like the MAC in MAC stuff)

    3. If this is truly an open standard intended for multi-vendor solutions, is the Vswitch API that Cisco gets from Vmware open to everyone? Last I heard it was not, in which case this is specifically a Vmware/Cisco proprietary solution for the foreseable future.

    4. Does Cisco have products that will support me tunneling to bare metal servers or other hypervisors such as HyperV, Xen, or KVM? If so, when will we see those?

    Thanks a ton for clearly articulating why traditional networking equipment and approaches are no longer valid for Virtualized Datacenter. We at Xsigo have been saying that for a long time.

    Looking forward to your answers.

    Regards

       2 likes

  5. I am glad to see that the demands of virtualization and cloud computing are pushing the boundaries of legacy networks and companies like Cisco and VMware continue to innovate and evolve the network.

       0 likes

  6. How does adding in a 24-bit header via software impact the server’s CPU & memory utilization? Nexus 1000V already consumes 15-25% of available resources just for switching, so how does adding in the network ID impact these resources?

       0 likes

  7. Omar
    Interesting piece. How does another protocol hack fix the virtualization issue. Don’t we already have GRE Tunnels?
    Why not just go with OpenFlow?

       0 likes

Trackbacks and Pingbacks:

  1. Return to Countries/Regions
  2. Return to Home
  1. All Data Center and Cloud
  2. Return to Home