AppNeta | The Path

Author Archive

I count myself lucky that I had a professor  in college who took the time to brainwash us all in the ways of network troubleshooting.OSI Model

To this day, I still jolt awake in a cold sweat hearing his voice chant “physical layer! physical layer!”  As many of you know, the Physical layer is  the first layer of the OSI model, the interconnecting medium upon which telecommunications is built.

What he meant was: “Always start at the beginning” or for the more Zen: “If a tree falls in a forest on a box of cat6 cabling, is the contractor still going to use it?”

So now I am finding myself chanting this mantra at anyone who will listen. Why am I reliving my old college days?  Ive found that my professor was right  – when troubleshooting your network, you must always start at the beginning.

We have customers who are ready to tear their hair out  – not to mention their  expensive network equipment – when they call us.  It can be overwhelming to review an Assessment with hundreds of targets, but you can make your life easier if you start at the beginning:


1) Ensure your Assessment contains a healthy number of targets that represent the entire deployment (targets on various  subnets, switches, etc)

2) Test to targets from within the same segment and towards other segments

3) Test WAN links and key network locations in EACH DIRECTION

Interpreting Results:

1) Don’t Panic

2) You may find many targets that perform badly, answer these two questions:

a) What are they? (handsets, printers, switches may have variable response to heavy diagnostic testing)
b) where are they? (try to find commonality by subnet and if possible by switch – PHYSICAL LAYER!)

3) Step 2 may answer about 75% of your questions when it comes to finding bad cables, duplex conflicts, bad switch trunks,  etc, but don’t stop there!  Take a deeper dive with outstanding issues to get further diagnostics.  If single tests do not bring an issue to light, consider using real-time monitoring to find help pinpoint transient issues.

Remember, if you didn’t build the network it is that much more important that you completely understand it. By running diagnostics to dozens of targets from various locations and gathering results into one cohesive report, it becomes much easier to quickly identify key performance problems.



We get it, traditional telephony is perfect. Nobody ever dropped a call, nobody ever heard echo, and it only cost about as much as a small island in the south pacific per month to run.

“I’m just an old phone guy; I don’t get these network issues.” This is a common line I hear when working through a VoIP deployment issue where the telephony vendor/MSP has become suspect and needs some help in the network arena.

Well, hold on to your MOS scores, because we are on the case.

Our Partner was in the midst of a VoIP deployment at a multi-site financial institution. Three sites out of 27 were known to be experiencing call quality issues and so they enlisted PathView to help solve the problem.  In about 20 minutes worth of monitoring data those same suspect sites were identified and another three that were experiencing the same issue.

Diagnostics were run, providers called, problem solved?? Keep dreaming.

The providers ensured nothing was different about these six sites (except for the fact that the route happened to change for all six shortly thereafter, eliminating the loss found on the path – did I mention we track route history?)

Seemed like we were winning – but then the phone rang with tales of rolling waves of destruction from the central site out to ALL remote offices.  The client of our MSP was outraged.  He swore that this VoIP deployment was a nightmare, and our Partner had their back up against the wall once again.

“Now there is loss everywhere!” Our partner exclaimed.  “What do all these results mean?!”  – I wasn’t scared.

I took a stroll back through the monitoring data collected and found the beginning traces of the loss. I calmly stated, “Looks like something changed on August 25th at around 1:00 in the morning.” (This was clear to me from the spike in loss and a change in route at the core of the network).

Indeed, something did happen on August 25th around 1:00 in the morning. The client was responsible for a swap in network gear that had caused the issue in the first place.  Apparently the client and MSP shared a good laugh about it after the client realized the MSP clearly had all the facts even before the boss did.

But something bigger happened on the follow-up call I had with our Partner – he realized that the “voice guy” in him had just become data-dangerous.  Armed now with enough to diffuse issues from both providers and the end clients alike.

Follow us on Twitter!

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

%d bloggers like this: