Category: network management

On the very same day that I published the CLI is Not the Problem post I stumbled upon an interesting discussion on the v6ops mailing list. It all started with a crazy idea to modify BGP to use 128-bit router ID to help operators that think they can manually configure large IPv6-only networks without any centralized configuration/management authority that would assign 32 bit identifiers to their routers.

The discussion quickly deteriorated into you really need a provisioning system and in one of the responses Jared Mauch provided a link to a NANOG presentation by Shawn Morris from NTT.

The “Is CLI In My Way … or a Symptom of a Bigger Problem” post generated some interesting discussions on Twitter, including this one:

One would hope that we wouldn’t have to bring up this point in 2014 … but unfortunately some $vendors still don’t get it.

Every time I plug a new device into my Windows laptop and it automatically discovers the device type, installs the driver, configures the devices, and tells me it’s ready for use, I wonder why we can’t have get the same level of automation in networking.

Consider, for example, a well-known vSphere link failover issue: if you forget to enable portfast on server-facing switch ports, some VMs lose connectivity for up to 30 seconds every time a switch reloads.

You know how hard it is to get the network traffic statistics: interface counters are too coarse, Netflow records are too granular, Sflow is sampling… life is hard for network monitoring Goldilocks.

In the Network Monitoring video (part of Real-Life OpenFlow Use Cases webinar) I explained an interesting alternative: you could get (hardware permitting) traffic counters with ever OpenFlow flow entry, resulting in any granularity you need.

Plexxi has an interesting problem. They have a shiny new solution that requires unorthodox approaches to network forwarding and allows them to implement potentially cool concepts like affinities (traffic engineering in disguise). They also need to sell these new concepts to the customers, and the first question I would ask after recovering from a hefty dose of cool-aid is "and how do I configure these affinities?"

If you’ve ever tried to troubleshoot web application performance issues, you’ve probably seen it all – browser waterfall diagrams, visual traceroute tools, network topologies produced by network management systems … but I haven’t seen them packaged in a comprehensive, easy-to-use and visually compelling package before. Welcome to ThousandEyes.

One of the first arguments used by networking engineers living in IPv6 denial and trying to justify their stance is “IPv6 addresses are unreadable. We will never migrate to IPv6; it’s much easier to deal with IPv4 addresses.”

That’s absolutely true. If you use RFC 1918 addresses in a small(ish) network, the first two octets don’t change, and it’s easy to remember the remaining two numbers … but the unreadable IPv6 addresses just might change the way we approach network configuration and monitoring.

I love Greg Ferro’s characterization of CLI:

We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

However, you do know that most devices’ GUI offers nothing more than what CLI does, don’t you? Where’s the catch?

Greg Ferro published a great blog post explaining why he decided to use node.js to build his cloud automation platform. While I agree with most things he wrote, this one prickled me the wrong way:

In my view, an Application Programmable Interface(API) is the fundamental change that makes Software Defined Networking (SDN) a “thing”. We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

While I agree with his view on CLI, keep in mind that API is no different.

One of the most pleasant surprises of the recent Interop show was the Tail-f's Network Control System (NCS). I “knew” Carl Moberg (of the NETCONF and YANG fame) for a long time and had the privilege to meet him in person just before the SDN Buyer's Guide panel that I co-hosted with Kurt Marko (who did an excellent job putting the buyer's guide together). Anyhow, what Carl presented during the panel totally blew me away.

In the last part of Clos Fabrics Explained webinar Brad Hedlund described how you can use Dell Fabric Manager to plan, design, configure and operate leaf-and-spine Clos fabric built with Dell Force10 switches. Should we call Dell Fabric Manager an SDN solution? Who cares, it sure is useful ;)

With all the Puppet buzz I’m hearing and claims that “compute and storage orchestration problems have been solved” I wanted to check the reality of those claims – is it (for example) possible to create a LUN on a storage array using a standard well-defined API.

Stephen Foskett, Simon Gordon and Scott Lowe quickly pointed me in the right direction: SMI-S. Thank you!

Last week I had the privilege of attending RIPE65, meeting a bunch of extremely bright SP engineers, and listening to a few fantastic presentations (full meeting report @ RIPE65 web site).

I knew Geoff Huston would have a great presentation, but his QoS presentation was even better than I expected. I don’t necessarily agree with everything he said, but every vendor peddling QoS should be forced to listen to his explanation of the underlying problems and kludgy solutions first.

Brian Christopher Raaen asked a great question in a comment to my OpenStack/Quantum SDN-Based Virtual Networks post:

Other than some syntax difference what do these new HTTP-based APIs add that SNMP couldn’t already do?

Short answer: In theory nothing, apart from familiarity and convenient programming libraries. In practice, there’s a huge gap between theory and practice. See “Hands-on experience” at the bottom of the article.

Every time I write about a simple use case that could benefit from OpenFlow, I invariably get a comment along the lines of “you can do that with NETCONF”. Repeated often enough, such comments might make an outside observer believe you don’t need OpenFlow for Software Defined Networking (SDN), which is simply not true. Here are at least three fundamental reasons why that’s the case.