The next generation Nexus 5600 family offers VXLAN bridging and routing capability, line rate L2/L3, and 40G uplinks, to deliver high performance in a compact form factor for 10G Top of Rack, 1/10G FEX aggregation deployments.
AND THERE HAS BEEN BROAD CUSTOMER ADOPTION ACROSS THE DATA CENTER!
From Nexus 1000V to the Nexus 9000, Cisco’s holistic approach resonates with customers because it provides increased business agility, operational efficiency, and empowers IT to rapidly evolve as business requirements change.
Here are the latest examples of why our customers chose Nexus:
Cisco’s award winning converged infrastructure management software solution just got even better! In the latest release of Cisco UCS Director, we’ve added broader and deeper infrastructure support across the compute, network, storage and virtualization layers, as well making the product even more scalable. The latest release also comes with new software development kits (SDKs) for partners to provide extensibility and interoperability and a northbound API for integration with Cisco’s Intelligent Automation for Cloud (IAC) as well as other cloud management systems. Let’s take a closer look at these enhancements in detail.
SDKs and APIs
UCS Director’s new SDKs and APIs were recently made available to give our partners the following functionality:
Northbound API which integrates into higher platforms like Cisco IAC. This API enables you to perform operations on Cisco UCS Director resources and to integrate those operations into applications so that they can provide API-supported functionality and features.
SDK available on cisco.com & DevNet (CDN), which provides open automation for partners looking to create new device connector
UCS Manager 2.1 (Delmar); KVM console; SAN zoning through UCS Manager; standalone management of UCS C-SeriesUCS Integration -Local disk provisioning and policies
-Workflow tasks for vNIC templates and service profile
-Assign blade or server pool to group
-Cloning of profile and profile template
Whiptail – application acceleration
Invicta, Acella API Version 1.5 support
CRUD actions, workflows, and reports
Converged and stack views
UCS Central Integration
-Multi-domain Manager concept
-Inventory for UCS-M elements
-Local/global service profile and templates
-Pools and policies for network and storage equivalent to UCS-M
Do you have a need for automated provisioning of your data center? Cisco Prime Data Center Network Manager (DCNM) might just provide that solution.
DCNMis designed to help you efficiently implement, visualize, and manage the Cisco Unified Fabric. The need today in the datacenter is for a comprehensive management platform that delivers visibility as well as control of all elements within the Unified Fabric which in turn significantly simplifies troubleshooting, maintenance and provisioning of the entire fabric in a fast and efficient way.Watch the video below to find out more.
Out with the old and in with the new and honestly I couldn’t be happier with the new that’s coming in. What is the new that I’m talking about? The Nexus 1000V REST API of course.
I just finished writing scripts to manage (create, modify, delete) vlans and port-profiles on a Nexus 1000V using expect. The scripts work fine, I’m using PowerShell as the main script and it calls out to expect and ssh running in a Cygwin environment, however it would be nice to use the REST API, and do everything from PowerShell or the language of your choice.
The customer I did the work for has multiple 1000V deployments and wanted to automate some aspects of the 1000V administration. Vlan provisioning and port-profile creation seemed to be obvious choices.
We’ve been getting a lot of great questions about ACI since our launch as people try and better understand the value of an application-oriented approach. I got the following questions on my blog post about the Application Virtual Switch that probed on some of the thinking behind an application-aware architecture, and why now was the right time to release it (after all, John Chambers called it the most disruptive Cisco innovation in a decade!). Anyway, on to the Q&A:
I’d like to know more about the path that Cisco pursued to evolve towards an “application aware” architecture. This back-story (how Cisco arrived at this juncture) would be very helpful to industry analysts, customers and institutional investors. Here’s some of the key questions on my mind.
- What were the primary roadblocks that inhibited the adoption of this innovative approach in the past?
I would say that the Application Centric Infrastructure (ACI) was a combination of a Eureka! moment, that people just never thought of it before, and that it was also an insightful evolution from early SDN technology. So, it might be fair to say that SDN had to come along, and then we realized, here might be a better way to program the network (with an application-oriented model, rather than a network-centric model).
That might be another way of saying that the lack of SDN as a precursor to ACI was a roadblock. But I think of it as networks were just built on hardware that were optimized to pass packets and other very specific tasks. And the limitations of historical networking protocols and traditional network designs, coupled with very limited ways in which you could manage a network and tell it what to do, all served as roadblocks to implementing anything like ACI. So the roadblocks that had to be cleared included the ability to program switches through software interfaces, and to centrally manage the software applications or controllers to orchestrate the broader network, not an individual device. Those are some of the things SDN brought along.