Tuesday, February 4, 2014

Tab Completion on Cumulus Linux

This film could have ended much differently

if Jerry were running Cumulus Linux 

The TAB key on my keyboard gets a lot of use. Whether I'm looking at a bash prompt on a *NIX system or logged into a router's CLI, I almost never type whole commands.

In the bash shell, tab completion capabilities are usually limited to helping complete:

  • shell built-in commands
  • external executables found in $PATH
  • file names
  • directory names
Completion in bash doesn't help with things like command line arguments to various commands, but it is (sometimes) smart enough to not offer filenames as completion options to the 'cd' command, choosing instead to only offer directories.

Network devices, on the other hand, tend to have really rich inline help / command completion stuff, and I live by it.

Rather than typing abbreviated commands, I prefer to let the system help me type the whole thing, partly because it eliminates errors, and partly because I usually can't remember the exact syntax for a given platform. Cisco's godawful platform-dependent mac-address-table vs. mac address-table comes immediately to mind as something that always seems to take more than one attempt.

So, rather than typing this:
ROUTER#sh ip bg vpnv4 vr GREEN nei A.B.C.D received-    

I tend to do this:
ROUTER#show ip bg<TAB>
ROUTER#show ip bgp vp<TAB>
ROUTER#show ip bgp vpnv4<TAB>
ROUTER#show ip bgp vpnv4 vr<TAB>
ROUTER#show ip bgp vpnv4 vrf GREEN nei<TAB>
ROUTER#show ip bgp vpnv4 vrf GREEN neighbors A.B.C.D re<TAB>
ROUTER#show ip bgp vpnv4 vrf GREEN neighbors A.B.C.D received-<TAB>
ROUTER#show ip bgp vpnv4 vrf GREEN neighbors A.B.C.D received-routes
This is pretty helpful, and an improvement over the bash shell where you often must abandon the command line for man pages in order to figure out the options for a given command.

Imagine my surprise when I found myself using pretty-full-featured tab completion in Cumulus Linux!

For example, when I started up the routing services for the first time, I instinctively did this:
#service qu<TAB>
#service quagga sta<TAB>
#service quagga start
Checking the CDP/LLDP neighbors table also supports completion:
#lldpcli nei<TAB>
#lldpcli neighbor sh<TAB>
#lldpcli neighbor show
If I wasn't sure about an argument, or if more than one argument matched, a second press of <TAB> offered the whole list of possibilities in the way you'd expect from bash, similar to the '?' on Cisco IOS.

This is really nice, and so seamlessly integrated that I didn't even notice I was using it at first. Then I noticed, and was mystified: What is this wizardry?

Well, here's how it works.

Suppose we've got an executable mycommand, which understands two arguments "-A" and "-B".

In order to get bash completion for mycommand, we need to drop a bash completion script in /etc/bash_completion.d/ (a directory I'd never even noticed before.) The script should get sourced by your shell at startup time, and it does two things:
  1. It loads a module into the shell.
  2. It associates the module with the command in question for completion purposes.
So, here's a simple example, for mycommand.
[chris@poetaster]$ cat /etc/bash_completion.d/mycommand.bash
    COMPREPLY=( $(compgen -W "-A -B" -- ${cur}) )
    return 0
complete -F _mycommand mycommand
Now, we're rewarded with the following:
[chris@poetaster]$ myc<TAB>
[chris@poetaster]$ mycommand <TAB>
[chris@poetaster]$ mycommand -<TAB>
<audible bell>
[chris@poetaster]$ mycommand -<TAB>
-A  -B 
[chris@poetaster]$ mycommand -A
Unlike Cisco IOS, the bash prompt in Cumulus Linux executes completion without printing extraneous lines, which I appreciate.

Of course, the completion routines baked into CumulusLinux are much more complicated than my simple "-A -B" example here. They understand the context of the command, where files are required vs. switches, when one option makes another obsolete, interface names, ip addresses, etc...

The completion feature wasn't mentioned in any of the documentation I read. It's a small thing, and they just did it without making a big deal. But it's really helpful, and I think it will help make lots of network folks much more comfortable in the Linux shell than they might otherwise have been.

Also, I'm glad they did it because I had no idea this existed, and I'm already thinking about ways to bake it into stuff I work on every day. Particularly virsh. I want command completion to help me type the names of VMs.

Monday, February 3, 2014

SDN Themes from ONUG - Let the ASIC go

Edit: I banged this out on the flight home from ONUG four months ago. Just found it in the drafts folder. ONUG's spring 2014 conference in New York is just 3 months away.

I was privileged to attend the Open Networking User Group (ONUG) Conference, ONUG Academy and mini Tech Field Day event hosted by JP Morgan Chase on October 29 and 30.
I attended at someone else's expense. Disclaimer.

ASICs came up a lot during these couple of days. Following are some ASIC-related things I heard and overheard at ONUG.

Sun Microsystems was overly attached to their SPARC processor (and so was I!) Folks inside Sun made efforts to derail Solaris x86, in order to protect their favorite server platform, and contributed to killing the company altogether. Sad story.

As good as your ASIC is, you'll never keep up with the performance of commodity chipsets. If the whitebox stuff is faster and still good enough to do the job, then it's probably going to win. It's certainly going to cost less. The proprietary ASIC may be better and have more features, but better is the enemy of good enough.

People used to route packets using general-purpose servers with multiple NICs. Cisco invented the networking market by introducing purpose-built equipment for moving packets between networks. The pendulum is swinging the other way now, as network functions become virtualized into general purpose servers, commodity network hardware and whitebox switching.

Lately (starting with the Nexus 3K) even Cisco is shipping switches with non-Cisco switching ASICs. This really says something about the state of the industry.

Assuming (as I do) that SDN overlays are the way of the future, they need to run on an physical underlay which don't require most of the features we're accustomed to seeing from major vendors data center offerings.

My friend Brent Salisbury is fond of saying that "OVSDB is the forwarding plane of SDN."

If Brent is right, then commodity switching ASICs are the underlay of SDN, because it would be ridiculous to pay for fancy feature support twice. Right now, that means everyone is talking about Broadcom's Trident II but Mellanox, Intel or others could launch a chip that changes the discussion that at any time.

All we need from the underlay is a simple IP fabric, and I can't see any reason to care where it comes from. More interesting features are the price and the interface to configuring the switch / programming the ASIC.