By and large I personally think that most of us are much more comfortable with layer three than any other layer in the OSI model. We deal with it each and every day. We have a number of tools at our disposal which make it very easy for us to see if/when it’s working and just how the data is traveling. To start with though, we have to know just how things are supposed to work.
When there is a problem with the network, time matters. We need to be able to quickly move from device to device in order to identify and rectify the problem. In order for this to occur, we have to know where to go to next, and how to get there.
Let me give you a scenario. You are having some problems on the network that are spread across several devices. You go into the log file of each device and see a bunch of messages with a mix-match of various times that mean absolutely nothing to you. In short, you have no idea what is going on with your network.
As I’ve stated in previous posts, an accurate network diagram can be really important when it comes to troubleshooting and managing the network. In order for a diagram to be of use to us, we have to maintain it which means that we update it every time the network changes. Another important part of a network diagram, is that it uses recognized symbols to depict what it is trying to show. ADRP 1-02 (Terms and Military Symbols) does a great job of providing us with standardized symbols for units of various sizes, terrain features, and even many pieces of equipment, but almost nothing to symbolize current day military communications equipment.
We have all learned an important lesson in life the hard way. When it comes to working on the router or switch, there is often a couple of commands that you discovered after beating your head against the wall for a while that if you had known about them earlier, would have made your life so much easier. These are those commands for me.
There are a few things that are in WIN-T that are not explained in school. You either find yourself figuring it out or being told by another Warrant. How many of you have noticed that there are configurations available for all your equipment in TXT format? How many of you use them to blow in configurations when replacing gear from your spares? How many of you have read all the comments?
A couple of weeks ago we talked about what affect changes to our network can have when we add HCLOS and other links between nodes. In that article, we talked exclusively about NIPR traffic going across the network and didn’t mention anything about SIPR. So what happens with our SIPR traffic if we install a HCLOS link?
A quick story for everyone today. A year or two ago a unit was coming through here on rotation. One of their CPNs was setup very close to the Brigade Main so the Net Tech made the decision to give himself some redundancy in his network and ran a piece of fiber between the two nodes. Life was good until one day he had to stow his dishes and all of a sudden, SIPR stopped working. Why?
As a general rule, all WIN-T nodes route traffic in pretty much the same way using pretty much the same configuration. We all know that at a CPN, both SIPR and NIPR traffic goes out the nodes TDMA link because, well, it has no other way to go. For a JNN, if the traffic is going to one of our subordinate units it goes out our TDMA, and if it is going somewhere else, it likely goes out our FDMA. We understand what it does, but most people have stopped thinking about why it does that. This is fine and dandy until we start making changes to the network.
Do you know what your baseline configuration is? Is it the same thing that you received on a CD from General Dynamics years ago or have you updated it over time as you have worked to refine and secure your network? If you do have a baseline, is it something that routinely roll-back to after each mission or do we just keep try to update the configurations each time we get a new message?