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.
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 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”.
The Bragg Regional Hub Node (RHN) is one of five RHNs in the world. The RHN is a critical component in the Warfighter Information Network Tactical (WIN-T) architecture and has significantly evolved over the past three to four years, meeting the ‘needs and requirements’ of the ever growing and developing WIN-T program. Regional Hub Nodes are an integral part of the network architecture and provide critical support for all three Army components and the Marines.
Who is responsible for managing your unit’s IP space? Is it you? Is it the 255A or 53? Do you actually have someone who is responsible for issuing and controlling the IP space for the unit? There was a recent discussion in the 255N Facebook group about things we can do to secure the network. One of the things brought up was knowing every device that was on the network. While that is important (and one I will get too shortly), today I want to talk about something a little simpler, knowing where all of your IP space is.
The standard BCT is issued two JNNs normally designated to support the BDE Main and the TAC however many units have found that this may not be the best way to actually employ these systems. One sign of a true Net Tech in my opinion is someone who is able to examine their assets and design a network that makes sense, not one that the Army prescribed.
Many Net Techs have heard of a STIG (Security Technical Implementation Guide) but most have never actually looked at them before. The STIG, combined with NSA guides are considered the “best practices” for information assurance within DOD systems. While there is nothing that says that your systems MUST be configured to their standards it is important to realize that by not configuring them in the recommended way means that you are accepting risk.