As a follow-on to my previous article on onePK – Cisco onePK: Now I Get It – I recorded a screencast in which I talk about what a onePK-enabled network is capable of. I also demonstrate two applications which make use of onePK to gather telemetry from the network and also program the network.
MTU Checker – Verifies that when the MTU of an interface is changed on the CLI, that the adjoining interface MTU matches
Routing For Dollars – Programs the forwarding table of the routers in the network based on the cost – in terms of dollars – of the various links in the network
Please leave a comment below with any questions or feedback.
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.
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. Read More >>
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.
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.
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.
In this article, I’m going to put all that soft stuff aside and get down into some technical methods for achieving a shared Layer 2 domain (ie, same IP subnet in both sites) while managing risk and putting a design in place that is resilient to Layer 2 failures. Namely, I’m going to talk about a protocol called Overlay Transport Virtualization (OTV). Read More >>
In the previous article in this DCI series (Why is there a “Wrong Way” to Interconnect Datacenters?) I explained the business case for having multiple data centers and then closed by warning that extending Layer 2 domains was a path to disaster and undermined the resiliency of having two data centers.
Why then is stretching Layer 2 a) needed and b) a go-to maneuver for DCI.
Let’s look at it from two points of view: technology and business.
There’s certainly a lot of focus on data center interconnection (DCI) right now. And understandably so since there are many trends in the industry that are making IT organizations look at data center redundancy. Among these trends are:
The business is saying to IT that they require their IT services to be available at all times. In effect the business is saying that they want to be shielded from technology issues, maintenance windows, and unplanned downtime because the IT services they consume (not all of them mind you, but certainly some of them) are so critical to running the business that they cannot be without them (or, they cannot be without them for whatever period of time it would take IT to recover the service).
The technical ability to move workloads between sites thanks to the near ubiquity of features like vMotion and Live Migration. The ability to pick up an application and swing it over to another location makes item #1 above far less daunting to IT shops and lowers the barrier to adoption.
In this post I’m going to talk about how IT can address item #1 above – the business need – in a manner that does not introduce hidden risk into the environment. This is a common conversation that a lot of IT organizations are having right now but unfortunately the easiest and most obvious outcome from those conversations is not always the one with the least risk.
In the second post of this DCI mini series, I’ll talk more about item #2 since that’s the one that drives a lot of the technical requirements that have to be met when delivering the overall solution to address #1. Read More >>
As I wrote about before (Creating a CCNA Voice Lab) I’ve been studying for another Cisco certification. As I was studying for the exam, I started thinking about the tools I was using to prepare. It wasn’t that long ago that my tools were limited to pen and paper (does that make me sound old?? Uhhg). Now, I have a tablet, smart phone, and of course the venerable “cloud” for storing PDFs, notes, etc.
Anyway, I thought it would be neat to document the tools I’m using today. It’ll be interesting to read this in a couple of years to see how things have changed again and maybe it’ll give a fellow cert-chaser some ideas for today. Read More >>
Joel Knight is a Systems Engineer with Cisco Systems and is responsible for working with enterprise customers to help them understand Cisco products and solutions through technical briefings, architecture and design sessions, and competitive analysis.