Posts for: ##datacenter

DCI Series: Overlay Transport Virtualization

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.
Read more β†’

DCI: The Need for Stretched Layer 2

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.

Read more β†’

Why is there a "Wrong Way" to Interconnect Datacenters?

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:

  1. 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).
  2. 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 β†’

An Introduction to the Nexus 6000

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
Read more β†’

Address Learning and the TRILL/FabricPath Control Plane

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

Read more β†’

Cisco UCS Manager 2.1 Highlights

Cisco UCS Manager 2.1 Highlights
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.
Read more β†’

Nexus 2000 Model Number Cheat Sheet

A colleague of mine pointed something out the other day: the numbers and letters that make up the Nexus 2000 (FEX) model actually have meaning! No, I haven't been living under a rock. I think it's pretty clear that with a model number like "2248TP-E" the "22" indicates this is the 2200 series FEX and the "48" indicates it's got 48 ports. But what about the letters that follow the numbers?

Read more β†’

Doing Etherchannel Over 3, 5, 6, and 7 Link Bundles

As a follow-up to my previous article on Port Channels titled "4 Types of Port Channels and When They're Used" I wanted to talk a bit about the long-standing rule that says you should always create your Etherchannel (EC) bundles with a number of links that works out to a power of two (ie, 2,4 or 8 links). That rule is less applicable today than it used to be.

Read more β†’

4 Types of Port Channels and When They're Used

The other day I was catching up on recorded content from Cisco Live! and I saw mention of yet another implementation of port channels (this time called Enhanced Virtual Port Channels). I thought it would make a good blog entry to describe the differences of each, where they are used, and what platforms each is supported on.

Read more β†’