Getting from A to Z

Troubleshooting
Licensed under Creative Commons from Solarbotics

First, let me take a quick second to apologize to all of my readers for having been of the web for the last couple of months.  As I posted a while back, I left NTC at the end of July and headed to Fort Meade, MD.  Since I got here, I have been very busy getting the family settled and doing work on our new home.  On top of that, I have been busy doing pretty constant training for my new job and have had to navigate some potential complications with posting on here.  But the good news is, I think I have just about got this all figured out and will hopefully be posting more regularly now and in the future.  With that being said, I would still love to have other people contribute to the site so if you have something you’d like to put out there, drop me a note.

When I entered the Army in July 1999, I came in as 31F (switch operator).  I PCSed to Korea for my fist duty station and was assigned as a Small Extension Node (SEN) operator/maintainer which made up part of the Army’s Mobile Subscriber Equipment (MSE) network.  Anyone who worked with MSE will remember that it had almost absolutely no data capabilities (until it when through some major upgrades in the later part of its life) but also that it was extremely easy to troubleshoot.  When I went through AIT the instructors spent days pounding into our head just how to troubleshoot the system which revolved almost entirely on understanding the signal flowed through the system.

Signal flow for MSE was pretty darn easy to understand.  If you understood the idea of how the system worked, the signal flow was easy to follow and on top of that, there was really no difference between the physical and logical flow of a signal so if you understood one, you understood the other.  With the introduction of JNN and IP data networks to tactical communications, logical and physical said “It’s been fun” and headed their separate ways leaving our operators and even ourselves busy scratching our heads wondering how the hell it all worked.

Life is Normal

The logical signal flow is what we as operators and net techs deal with on a daily basis; We know when it works, and we know even sooner when it doesn’t.  We are easily able to verify the logical path of our network using things like ping and traceroute or even monitoring tools like SNMPc.  As long as logical is working, life is good but on occasion, logical stops and we have to figure out why.  This is when we run into problems.  What is the problem?  When things stop working, I am often amused to see the very first thing many operators and net techs do is start randomly logging into routers looking for changes to configs, convinced that someone had got into their system and made configuration changes.  While this is definitely possible (and has absolutely happened to me) I think more often than not, the configs that were working 30 minutes ago are probably still working now (unless of course you were actively playing with the configs and then that’s a whole different situation).

So assuming no one was in your routers playing around, how do we figure out what the problem is?  The answer is to follow a straightforward, common sense approach to our troubleshooting that considers both logical and physical problems.  In order for us to be able to do that though, we have to understand how both the logical and physical signal flow works.  This is the first of a few articles (I haven’t decided how many it will actually be in the end) that outlines how the signal flows across the network on both the logical and physical level and how we can use that to figure out why the hell it isn’t working.

To be continued….

2 Responses to “Getting from A to Z”

  1. Sean

    Welcome back… I too was trained as a 31f life was definitely simple then. It’s true things normally don’t just break themselves and it is more than likely a physical break… But when you’re on the other side and dealing with circuit providers they like to change things without informing you