On MacOS X, the built-in PING application has audible alerts. These alerts have quickly become my favorite options. I like to multitask, so I don't always keep my terminal window in front while doing continuous pings. I've gotten to the point that I almost always use one of these two options.


-a beeps when the remote side responds. Great for rebooting something to know when it is back online.


-A beeps when the remote side doesn't respond. Great for testing network consistency. I also like to use this one when applying updates or patches to a remote device so I know when it the reboot actually starts.


I did a quick check on other platforms, Windows 7 has no audible flags, Centos 6.5 only supports the -a option, -A means something else.



AuthorKelly McDowell

I'm not one to sit around and bash the traditional vendors. I think Greg Ferro has the vendor bashing covered, or at least he has a bigger microphone. and the truth is, I've been a happy consume of many of their products. and I've made a great living with their gear, and truly been excited by much of their equipment.

But I do think the traditional vendors have committed a cardinal sin in the last few years, and it is has the potential to cost them dearly in the long run. Let me explain where I think they went wrong:

In the beginning it was all the vendors could wring the last bit of performance out of existing CPUs. Look at the M40 that Juniper launched with in 1998. It was so revolutionary that it became the foundation for a whole new company, simply because they were able to have exponential speed improvements in their devices over their competitors. At the time they were constrained by hardware and spent enormous energy and talent trying to wring every last watt of performance from their silicon.  But in the last 5-8 years the CPUs have gotten incredibly fast, and that became less important, especially for the Control Plane. Data Plane functions were offloaded to ASICs and dedicated processors, and it became obvious that the control plane had more than enough power to process the CLI, run SPF algorithms, and respond to ICMP packets. So what did the vendors do? Then scaled down the Control Plane CPUs to cut costs. They were performing adequately and nobody really complained, who knew much different? 

Fast forward to today. We are all about virtualization. Whether SDN, or simply virtual appliances, software is eating the world. And what are users discovering with their new virtual gear? The Control Plane doesn't have to be adequate, it can be amazing. What could we do with a faster Control Plane? Certainly we'll get speed improvements, or even better, new functionality that never existed before.

A few examples, we'll pick on Juniper here:

The Juniper SRX, Branch Series. These are great boxes, with full router functionality, and most of the switching feature set. I've been a huge fan of them for 4 years now. But while the Forwarding Plane is adequate, the Control Plane is painfully slow sometimes. Try issuing a commit operation when you have two of them clustered together. You'll definitely want to multi-task while that happens. Now, compare that to the vSRX (Firefly Perimeter). Commit times are exponentially better because they have server class hardware to execute the Control Plane. 

And for a more positive example from Juniper:
The Juniper QFX5100 is a great switch. While we know the real braun comes from the Terabit speed ASIC, one of the neatest features comes from the powerful CPU for the Control Plane. Xeon class CPUs allow you to run multiple instances of the OS. With dual VMs of the Junos Control Plane, you can do single box firmware upgrades with no downtime. That type of upgrade had never been possible without a large chassis device and multiple Supervisors or Routing Engines. Juniper even allows you to host your own VM on the switch. While the market is still innovating with this feature, already there are syslog servers (ELK Stack anyone?) analytics, monitoring VMs, etc deployed. This is a whole new realm of possibility, mostly enabled by server class CPU running the control plane. 

One of the most exciting and useful innovations that will come from powerful control planes will be added visibility and analytics. With legacy servers, storage, and network appliances, we are practically blind to what happens at any detail. We're left to SNMP poll every 5 minutes for a snapshot of the state. This is almost completely ineffective, and often worthless when things go wrong. Have you noticed that once we virtualize a a server we get much better visibility into the CPU usage, memory usage, storage I/O, and network I/O? It is pretty sad state that VMWare is much better at giving us storage and network info than Netapp, EMC, Juniper or Cisco.  With more powerful Control Planes in our hosts (physical or virtual), we can do on-box reporting, more granular statistics, and analyzing the data and pull more relevant info.

I can't wait to see what functions are enabled by our new-found computing power. We've seen the future, and we don't plan on going back. Traditional vendors can either deliver, or we'll buy elsewhere.


Feel free to agree or disagree, you can reach me @ocdune on Twitter.

AuthorKelly McDowell