John Harrington

Author Archives: John Harrington

Solarwinds Geek Speak

I’m sharing some articles I wrote on the Solarwinds Geek Speak blog.  I recommend you start with the 80/20 rule below post below before reading through the rest.

A disclaimer: Solarwinds didn’t ask me to promote these posts –  I’m sharing them because they’re posts I would have otherwise published on this blog.

Add a comment below if anything strikes a chord, or if you want to disagree, correct me, etc.

The post Solarwinds Geek Speak appeared first on NetworkSherpa.

Reserved Internal Address Ranges

The
I’ve added a new question to my own network integration checklist, specifically when integrating chassis-based or integrated solutions:

Does the system use any reserved internal address ranges?


Some chassis-based systems reserve private IP address ranges for inter-card communication. This is a perfectly fine setup as long as you, the network integrator, know what ranges are in use. However, you’ll have a frustrating case of ‘disappearing packets’, if you’re not aware that these ranges are in use. 
I first saw this issue  on an IXIA XM12 chassis a few years back. As I later discovered, each line card received a /24 from an RFC1918 address range. The supervisor used an IP address in each range to communicate with each line card. When I used a conflicting range in my testing the chassis would swallow my packets, and I was left scratching my head until I figured this out.
I thought this was a one-off, but I hit it again recently on an Ericsson Call Control Node. Same problem, but a little easier to detect this time. Nevertheless, I’ve been stung twice now on this issue, so I’ve added to my checklist and brought it to your attention.
If an appliance uses a reserved Continue reading

Strain relief

I’ve got a problem with sagging cables, and I’ve got a simple solution. Examine the side-by-side images below which show the same fiber connection between a switch and a firewall. The image on the left shows a sagging cable which crosses in front of the switch in the rack unit just below it.
As you may know, this cabling install is a violation of the 167th rule of networking:

Thou shalt contain your cables to your own rack unit and shalt not, under any circumstances, impede access to other rack units or blades.


SnipImageThe image on the right ticks the box for me. There’s no room for a dedicated 1RU horizontal cable manager, but there is room for a zero-RU strain relief bar (as seen below). The result is a relatively neat cabling job. It’s no work of art, but it’s functional.
strain relief barA strain-relief bar is a cheap metal bar that you can bolt on when you rack-mount your switch. It allows you to velcro your fiber patches to the bar, taking the strain to help prevent breaks and preventing the dreaded cable droop. You should, of course, take care to ensure you don’t block access to any field-replaceable units, cards or ports on your network device.
The strain-relief bar Continue reading

Effectiveness – Network Truths, Principles and Fallacies

I gave a 13-minute talk to the Irish Network Operators Group (INOG) recently. In this 13-minute video I argue that you can become more effective, and happier, by standing back and reflecting on how you work, leveraging existing truths, fallacies and principles. I introduce The twelve … Continue reading

The post Effectiveness – Network Truths, Principles and Fallacies appeared first on The Network Sherpa.

Effectiveness – Network Truths, Principles and Fallacies

I recently gave a 13-minute talk to the Irish Network Operators Group (INOG).  In this talk I argue that you can become more effective, and a happier engineer by standing back and reflecting. The talk discusses how you work –  with reference to some great truths, principles and fallacies.

I introduce The twelve networking truths and the 8 Fallacies of Distributed Computing. I then describe a handful of my own learnings and fancy terms like Chesterton’s Fence and the Gordian Knot.

Check out the video folks, I’d love your feedback.


I was quite nervous preparing for the talk, but I know myself well enough by now to recognise these small fears as opportunities. This is the same fear I faced when I started this blog.

This isn’t false modesty, I’ve done talks before in Amazon and survived, but I was still very nervous. Still, it took me hours of consideration, planning and preparation in addition to a fair bit of anxiety.

I got a real buzz from doing the talk and overcoming the fear. Upon reviewing the video, I know I’ve got a few things to work on. But, by facing a small fear, I’m now slighter better at public Continue reading

Clear Pricing for Network Services

I had to buy some switches recently and needed to gather a second quote from another vendor. I went to the Dell website and was pleasantly surprised to quickly find a clear price and a buy-now button for each device on their website.
Normally you’d need an account of the vendors portal to get this information, so it is refreshing to have straightforward access to clear hardware pricing. However it was the list of professional services options shown in the attached image that caught my eye.
Dell_ProServices_MenuYou can choose options for ‘rack and cable’ basic deployment or more comprehensive ProDeploy solution. The out-of-hours cut-over and other on-site planning options are a lot more expensive, but I’d imagine those tasks require more polished and experienced engineers to be engaged, and a lot more time-risk. Lastly you have the more tightly defined remote consulting options, with a 1-hour or a higher-priced 1-case options of the course of a single year.
You could quibble with some of the prices but I was really surprised to see fixed pricing for professional services, presented in an easy-to-consume and transparent manner.  I’ve always had an interest in business. Now that I’m more focused on network consulting I’m paying very close attention to how consulting effort is estimated Continue reading

Writing elsewhere on the net

Hi Folks,
I write for a few other publications, so I’ve made this handy page to link to external articles. I’ll update this page as new articles are released.

Human Infrastructure Magazine

Issue 23 – How To Unblock Your Project
Issue 27 – Email Stinks For Process Documentation

Network Computing

Demystifying The 10x Network Engineer
The Broken Window Theory of Network Configuration

Packet Pushers

All my posts on the PacketPushers Blog
Enjoy.

The post Writing elsewhere on the net appeared first on NetworkSherpa.

Include the why

whyI recently stumbled upon an interesting speech from 1984 by Charlie Munger of Bershire Hathaway fame. Charlie is Warren Buffet’s right-hand-man, and a straight talking genius in his own right. It’s a fairly long speech and Charlie has a few very interesting things to say, but one particular section on ‘explaining the why’ really struck home.
Here’s a brief quote:

….if you always tell people why, they’ll understand it better, they’ll consider it more important, and they’ll be more likely to comply. Even if they don’t understand your reason, they’ll be more likely to comply.
So there’s an iron rule that just as you want to start getting worldly wisdom by asking why, why, why, in communicating with other people about everything, you want to include why, why, why. Even if it’s obvious, it’s wise to stick in the why.

The ‘why’ is notably absent from most conversations in our high-tech sphere. I’ve wasted countless hours interpreting solutions to ill-defined or undefined problems. I’m guilty of writing many ‘why-less’ documents and emails also. Upon reflection, I can recognise the folly of not explaining the problem at hand before launching into the solution.
When I drop the reasoning and background and Continue reading

Getting started with Network Packet Generators

bit blaster
A friend of mine has just ordered a shiny new packet generator for his network lab. I’ve spent some time working as a QA engineer in a network lab and wanted to share some advice.
You can purchase stateful and stateless packet generators from major vendors like Spirent, IXIA or Agilent. If you just need to test throughput, latency or loss, a stateless packet generator will do the trick. The test hardware will use an ASIC to produce line-rate 10G traffic or higher. The Cisco Enterprise Testing Book calls this a ‘bit-blaster’ which I love. In the wrong hands it can also be a ‘network-melter’. 
You need a stateful packet generator if you want to test your routing protocols in conjunction with traffic load. A stateful packet generator such as Ixia’s IxNetwork, will use dedicated CPUs to form and maintain adjacencies, inject routing protocol packets, etc. You can use the stateful feature to inject prefixes which are then used as test targets by high-rate stateless traffic.
Licensing is a major source of pain when operating a stateful packet generators. There are often licenses required per protocol and even per-combination of protocols. For example, I had to buy a license for Continue reading

5 ways to fail – WAN link acceptance

Ethernet WAN linkI’ve had an interesting few months doing WAN circuit turn-ups for a new Data Centre. I dealt with three major carriers, and each experience was worse than the next. I’m not sure why I held such high expectations but I was surprised by their hopeless inefficiency in delivering what should have been a standard product. In this post I’ll examine the problems I saw and their root causes.
In all three situations, 1Gbps Layer-2 ethernet circuit was ordered with a copper ethernet handoff from a rack-installed NID/NTU/whatever-you-call-it-yourself. Lets look at the five issues I hit whilst troubleshooting.

Link up at both ends – No CDP received

There was a lot of blaming the end-customer on this one. “Are you sure that CDP is enabled?”. There was a huge amount of frustration here. The carrier would send an email to confirm that ‘they had tested’, provide no actionable details of their troubleshooting, then close the ticket. This went on for days bouncing between the annoyingly named ‘deliver’ and ‘assure’ teams. The ‘deliver’ team felt they had delivered the circuit and the  ‘assure’ team assured us that the circuit wasn’t live and they couldn’t help us.

The ‘deliver’ team felt they had delivered the circuit and the  ‘assure’ Continue reading

1 2 3