Category: data center

I often get questions from engineers wondering whether my webinars or courses would be too tough for them. Here’s a question I got from an engineer who wanted to attend my Building Next-Generation Data Center course: “What specific prior experience do you expect for this workshop?”

Eyvonne Sharp wrote a great blog post describing Cisco’s love of complexity and how SD-WAN vendors proved things don’t have to be that complex.

I know Cisco (and every other vendor) loves making ever-more-complex solutions that lock you into their morass for the rest of your life (long-distance vMotion anyone?).

Last year Cisco launched a new series of Nexus 9000 switches with table sizes that didn’t match any of the known merchant silicon ASICs. It was obvious they had to be using their own silicon – the CloudScale ASIC. Lukas Krattiger was kind enough to describe some of the details last November, resulting in Episode 73 of Software Gone Wild.

For even more details, watch the Cisco Nexus 9000 Architecture Cisco Live presentation.

I managed to get another awesome lineup of guest speakers for the Spring 2017 Building Next-Generation Data Center course (starting in less than a month):

Scott Lowe will open the course with a presentation on the impact of open source software in data center environments.

One of my readers wondered what the difference between fabric extenders and leaf-and-spine fabrics is:

We are building a new data center for DR and we management is wanting me to put in recommendations to either stick with our current Cisco 7k to 2k ToR FEX solution, or prepare for what seems to be the future of DC in that spine leaf architecture.

Let’s start with “what is leaf-and-spine architecture?”

When Facebook announced 6-pack (their first chassis switch) my reaction was “meh” (as well as “I would love to hear what Brad Hedlund has to say about it”). When Facebook announced Backpack I mostly ignored the announcement. After all, when one of the cloud-scale unicorns starts talking about their infrastructure, what they tell you is usually low on detail and used primarily as talent attracting tool.

Imagine you were asked to migrate some of the workloads running in your data center into a public (or managed) cloud. These workloads still have to access the data residing in your data center – a typical hybrid cloud deployment.

Next thing you know you have to deal with your (C)ISO and his/her usual concerns as well as the variety of articles on tech sites stating that "security is the biggest challenge of cloud adoption".

One of my readers sent me a list of questions after watching some of my videos, starting with a generic one:

While working self within large corporations for a long time, I am asking myself how it will be possible to move from messy infrastructure we grew over the years to a modern architecture.

Usually by building a parallel infrastructure and eventually retiring the old one, otherwise you’ll end up with layers of kludges. Obviously, the old infrastructure will lurk around for years (I know people who use this approach and currently run three generations of infrastructure).

Cumulus Linux 3.2 shipped with a rudimentary EVPN implementation and everyone got really excited, including smaller ASIC manufacturers that finally got a control plane for their hardware VTEP functionality.

However, while it’s nice to have EVPN support in Cumulus Linux, the claims of its benefits are sometimes greatly exaggerated.

Running BGP instead of an IGP in your leaf-and-spine fabric sounds interesting (mainly if your fabric is large enough). Configuring a zillion BGP knobs on every box doesn’t.

However, BGP doesn’t have to be complex. In the Simplify BGP Configurations video (part of leaf-and-spine fabric designs webinar) Dinesh Dutt explains how you can make BGP configurations simple and easy-to-understand.

Most networking operating systems include a mechanism to roll back device configuration and/or create configuration snapshots. These mechanisms usually work only for the device configuration, but do not include operating system images or other components (example: crypto keys).

Now imagine using RFC 1925 rule 6a and changing the “configuration rollback” problem into “file system snapshot” problem. That’s exactly what Cumulus Linux does in its newest release. Does it make sense? It depends.

In the last few weeks I’ve seen numerous questions along the lines of “how do I manage VLANs on my switch with Ansible”. You can look at this question from two perspectives: the low-level details (which modules do I use, how do I push commands to the box…) or the high-level challenges (how do I make sure actual device state matches desired device state). Obviously I’m interested in the latter.

I’m positive I’ve answered this question a dozen times in various blog posts and webinars, but it keeps coming back:

You always mention that high speed links are always better than parallel low speed links, for example 2 x 40GE is better than 8 x 10GE. What is the rationale behind this?

Here’s the N+1-th answer (hoping I’m being consistent):

One of the quotes I found in the Mythical Man-Month came from the pre-GPS days: “never go to sea with two chronometers, take one or three”, and it’s amazing the networking industry (and a few others) never got the message.

Running Linux containers on a single host is relatively easy. Building private multi-tenant networks across multiple hosts immediately creates the usual networking mess.

Fortunately the Socketplane team did a pretty good job; for more details watch the video from Docker Networking Fundamentals webinar or listen to the podcast I did with them a year ago.