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.
The Army, and the world in general, has been slow to accept the fact that anything on a network can present a risk to that network. Routinely, we’ll place a device on the network without properly configuring it, patching it, or securing it without a second thought. Even on the occasion that we do think about the security of that device, we look at the device as being unimportant and it doesn’t really matter if it is compromised. Today we’ll talk about the threat sitting in the corner of the TOC….the printer
You just rolled onto your new site after a 5 hour convoy which was delayed 2 hours already. You haven’t been able to see the network for nearly 9 hours and it will be a couple more before you have minimal connectivity in the Main. So, what does your network look like?
Do you have everyone that you need (or would like) to complete your mission? If you are like pretty much everyone in the Army, the answer to that question is no. Rarely does a unit have everyone assigned to it that they are authorized and even in the case that they do, you still have people pulling guard, on profile, or whatever. The short answer is that we never have enough people to take care of all of the tasks that need to be completed which is why it is critical that we effectively manage how we use our personnel.
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?
I am a huge advocate of using HCLOS within out networks. It increases bandwidth, adds redundancy, and reduces delay between nodes. As I’ve said before, when using HCLOS in a DA environment, it is often easiest and most practical to deploy these links with non-maneuver units (BSB, aviation, etc.). In several recent rotations though we have seen units experience an additional challenge in employing their HCLOS assets; HCLOS v1s being permanently placed with maneuver battalions.
Usually about half way through each rotation I will try to find the Brigade XO and spend a few minutes talking to him about communications. By this time, the network is well-established, the unit has conducted a couple of CUBs, and by and large everyone should have a pretty good idea of how well we can (or can’t) communicate across the unit. One of the comments I frequently hear is that they “need more bandwidth”.