Don’t Forget to Check the New Data Center Labs on dcloud.cisco.com

Design versus deployment. White board versus black screen. Pre-sales versus post-sales.

Do these separations make sense any longer? In my humble opinion, IT companies cannot afford these silos today. A field engineer should be aware of good design practices as much as architects should know how operationally adequate is a said solution. But how can the latter experience these products in an efficient way?

A while ago I’ve published a blog about some data center lab resources and a lot of people thanked me for pointing dCloud in that article. Since then, this website has become the beachhead for Cisco demonstrations solutions and has gathered a respectable set of data center labs, such as:

Cisco Nexus Data Broker 2.0 v1

Cisco Nexus Data Broker (formerly Cisco Monitor Manager) is a software-defined, programmable solution to aggregate copies of network traffic using SPAN or network taps for monitoring and visibility purposes. It is a simple, scalable and cost-effective monitoring solution.

Cisco UCS Director 5.0 v1

This demonstration shows how Cisco UCS Director reduces the complexity of data centers, allowing IT staff to shift from manually managing infrastructure to developing new services for the business

Cisco Nexus 9000: NX-OS Programmability v1

The Nexus 9000 in standalone mode provides APIs for external tools to be able to automatically provision network resources. This demo shows the interaction with NX-API via both, custom made and off-the-shelf applications like Graphite, Splunk and Puppet.

Cisco UCS Invicta with Citrix VDI v1

Show how the UCS Invicta Appliance allows customers to quickly and efficiently configure IT infrastructure to support I/O-intensive applications with real-time analytics.

Cisco UCS Central 1.1.2a v1

Show how the updated Cisco UCS Central 1.1.2a can provide global definition capabilities for policies and resource pools, which can be flexibly allocated across distributed data centers.

Cisco Intelligent Automation for Cloud 4.0 v1

This demo showcases the powerful capabilities of CIAC 4.0, from onboarding tenants and creating organizations to requesting a vDC and creating a VM from a template. It covers all Administration user levels: CPTA, TTA, OTA and End User.

Cisco Extensible Network Controller 1.5 v1

Show how network operations can create powerful, reusable network service abstractions for business applications through northbound APIs, simply by adding Cisco XNC to a network.

Cisco Unified Computing System 2.2 v1

This demonstration shows the ease and flexibility of building, deploying and managing the data center via Cisco UCS 2.2 (El Capitan).

FlexPod with Microsoft Hyper-V v1

Show how the FlexPod architecture can be leveraged for Microsoft Hyper-V virtualized environments to reduce costs, accelerate time to market, and improve IT efficiency.

Cisco Prime Network Services Controller 3.0 v1

Show how Cisco Prime NSC, combined with the Cisco Nexus 1000V switch, Cisco ASA 1000V Cloud Firewall and Cisco VSG, provides a rapid and scalable deployment through dynamic, template-oriented policy management based on security profiles.

FlexPod with VMware v1

Highlight the FlexPod value proposition in the context of a Virtual Desktop deployment. Focus on features that clearly illustrate the business benefits and unique differentiators of the FlexPod architecture.

Impressive, right?

One last observation: you will need your CCO login to access the labs. And be prepared for some pleasant surprises after you log into the website…

Have fun!

Gustavo

VXLAN is Now RFC 7348

In the last August, the Internet Engineering Task Force (IETF) galvanized the work of roughly 3 years in a Request for Comments (RFC) document. Although it can be considered a young virtualization technology, Virtual eXtensible Local Area Networks (VXLANs) are already molding how Cloud networks function and are quickly becoming a fundamental building block of Software-Defined Networking (SDN).

As I have explored in Chapter 15 from my book (“Data Center Virtualization Fundamentals”), VXLANs were at first invented to provide Layer 2 communication between Virtual Machines (VMs) over IP networks. Nevertheless, its flexibility can be used to implement specialized data center fabrics such as Cisco Application Centric Infrastructure (ACI).

The document was written by employees from Cisco Systems, Storvisor, Cumulus Networks, Arista, Broadcom, VMware, Intel and Red Hat and can be downloaded here: https://datatracker.ietf.org/doc/rfc7348/?include_text=1

Here are some of its highlights:

  • The RFC has achieved informational status, meaning that it should not be considered a mandatory standard but simply the publishing of an experience. IETF´s motto in these cases is “rather document than ignore” according to RFC 1796 (“Not All RFCs are Standards”), which funnily is also informational.
  • According to the RFC, VXLAN overcomes the following challenges: STP limitations, VLAN range size, multi-tenant environments in cloud computing environments, and inadequate table sizes at Top-of-Rack switches.
  • The document focuses on data plane learning scheme as control plane for VXLAN, meaning that the association of MAC to VTEP´s IP address is discovered via source MAC address learning.
  • Multicast is used of carrying unknown destination, broadcast, and multicast frames. VTEPs use (*,G) joins for that objective.
  • The RFC does not discard that other control plane options for MAC/VTEP learning may exist, such as Nexus 1000V´s Enhanced VXLAN.
  • To ensure traffic delivery without fragmentation, it is recommended that the MTUs across the physical network are set to a value that accommodates the larger frame size due to the VXLAN encapsulation.
  • The Internet Assigned number Authority (IANA) assigned the value of 4789 for the VXLAN´s destination UDP port. It is recommended that the source port is calculated using a hash of the inner Ethernet frame´s headers to leverage entropy on networks that deploy traffic load-balancing methods such as ECMP. Also, the UDP source port range should be within the dynamic/private port range of 49152-65535).
  • VXLAN gateways are defined as elements that can forward traffic between VXLAN and non-VXLAN environments.

Even under information status, the publishing of VXLAN as a RFC will surely help the convergence of distinct vendor research and development. These are exciting news indeed for network engineers, server virtualization admins, and cloud architects.

Have you already configured your first VXLAN?

Best regards,

Gustavo