I had an opportunity recently to sit in a Cisco onePK lab and it opened my eyes to exactly what Cisco is doing with onePK, why it's going to be so important as Software Defined Networking (SDN) continues to gain traction, and why onePK is different than what anyone else is doing in the industry.

onePK is a key element within Cisco's announced Open Network Environment SDN strategy. onePK is an easy-to-use toolkit for development, automation, rapid service creation and more. It enables you to access the valuable data inside your network via easy-to-use APIs.

Source: www.cisco.com/go/onepk

Since having my own eyes opened, I've been pondering how to explain my new found understanding in a way that others will grasp. In particular to business decision makers (BDMs) and technical decision makers (TDMs). I'm really, really, struggling to come up with a good analogy for BDMs. I'm still working on that one. Surprisingly, I'm also struggling to come up with a sound analogy that will work with the majority of TDMs that I know. Maybe I shouldn't be so surprised at that since all the TDMs I deal with are on the infrastructure side of things (networks, storage, compute, platform) and really don't deal with software. There's a gap there that I somehow need to bridge. I'm still pondering how to successfully do that.

However, there is a slice of the TDM population that I believe I can reach right now. These folks, like myself, have software and network experience. Maybe through open source projects, previous careers, or just mucking about with LAMP stacks in their own lab/home network, they understand programming semantics, APIs, and extending the functionality of third-party software.

I'm going to use a popular open source software package to draw some parallels with what Cisco onePK will soon allow organizations to do to their networks.

We're halfway through 2013 and we have our second new member of the Nexus family of switches for the year: the Nexus 7700. Here are the highlights:

• Modular, chassis-based system
  • 18 slot (16 IO modules) and 10 slot (8 IO modules)
• True front-to-back airflow
• New fabric modules
  • (6) fabric modules (maximum) per chassis
  • 220G per slot per fabric module
  • 1.32Tbps per IO module slot
• Supports F2E and newly announced F3 IO modules

Here's a topic that comes up more and more now that FabricPath is getting more exposure and people are getting more familiar with the technology: Can FabricPath be used to interconnecting data centers?

FabricPath has some characteristics that make it appealing for DCI. Namely, it extends Layer 2 domains while maintaining Layer 3 — ie, routing — semantics. End host MAC addresses are learned via a control plane, FP frames contain a Time To Live (TTL) field which purge looping packets from the network, and there are no such thing as blocked links — all links are forwarding and Equal Cost Multi-Pathing (ECMP) is used within the fabric. In addition, since FabricPath does not mandate a particular physical network topology, it can be used in spine/leaf architectures within the data center or point-to-point connections between data centers.

Sounds great. Now what are the caveats?

Wow the title of this post is a mouthful.

Similar to my previous post on the Nexus 2000 (Nexus 2000 Model Number Cheat Sheet), this post will explain what the letters and numbers mean in the Nexus 7000 IO module part numbers. This will allow you to quickly identify the characteristics of the card just by looking at the part number which in turn should help you out as you're building BOMs and picking the right card for the job.

Update July 2, 2013: Updated to reflect release of the Nexus 7700 and F3 modules.

This is the third article in my series on Data Center Interconnection (DCI). In the first (Why is there a "Wrong Way" to Interconnect Data Centers?) I wrote about the risks associated with DCI when the method chosen is to stretch Layer 2 domains between the data centers. In the second article (DCI: Why is Stretched Layer 2 Needed?) I wrote about why the need exists for stretching Layer 2 domains between sites and also touched on why it's such a common element in many DCI strategies.

I've been working on something that at this point in my career I never thought I'd be doing: another Cisco Certified Network Associate (CCNA) certification. The CCNA Voice, to be exact. Now that I'm in a job role where I'm expected to be somewhat of a jack-of-all-trades, I can no longer avoid learning voice :-) For a long time I've focused on just the underlying network bits and left the voice "stuff" to others. Since I now need to talk intelligently about Cisco voice solutions, products, and architectures, I decided to go through the CCNA Voice curriculum as a way to establish some foundational knowledge.

This post is about the tools and methods I used to build a small lab to support my studies.

There's a new Nexus in the family, the Nexus 6000. Here are the highlights.

	Nexus 6001	Nexus 6004
Size	1 RU	4 RU
Ports	48 x 10G + 4 x 40G	48 x 40G fixed + 48 x 40G expansion
Interface type	SFP+ / QSFP+	QSFP+
Performance	Line rate Layer 2 and Layer 3
Latency	1μs port to port
Scalability	128K MAC + 128K ARP/ND (flexible config), 32K route table, 1024-way ECMP, 31 SPAN sessions
Features	L2/L3, vPC, FabricPath/TRILL, Adapter FEX, VM-FEX
Storage	FCoE
Visibility	Sampled Netflow, buffer monitoring, latency monitoring, microburst monitoring, SPAN on drop/high latency

I'm not sure why I've taken such an interest in mDNS, service discovery, and the Bonjour protocol, but I have. It probably has something to do with my not being able to use AirPlay at home for such a long time because, like any true network geek, I put my wireless devices on a separate VLAN from my home media devices. I mean, duh. So now I keep an eye out for different methods of enabling mDNS in the network in anticipation of my own experience in my home network becoming one of my customer's experience in their enterprise network.

Do you ever find yourself in a conversation with someone where you attempt to explain a concept in detail and you realize that you don't know that concept at the level of detail that you thought you did? That happened to me recently. I thought I had a better handle on TRILL and FabricPath than I really did. Since I retain things far better when I write them down, I'm going to blog the differences between TRILL and FabricPath when it comes to address learning and what role the control plane plays in building the network topology

Service Profile Renaming Yes, finally, you can rename service profiles. No more struggling to name your profiles perfectly the first time. When a profile is renamed, all the unique attributes including the MACs, WWNs, UUID, etc, are preserved. This can be done when the server is live and online without any impact. VM-FEX for Microsoft Hyper-V and KVM In addition to vSphere, VM-FEX (which I've written about here) is now available when using the Hyper-V or KVM hypervisors on UCS.