Standardizing the LAN

Managing a tactical network is far different than managing a fixed or civilian network. Fixed and civilian networks are static by and large. When a change needs to be made, it is generally known about well ahead of time and thoroughly reviewed prior to actually making the change. Technicians and engineers review the proposed change, document it, and will often test it out in a test environment to ensure that no unforeseen consequences will occur as a result of the change.

A tactical network, on the other hand, is almost always in a state of change. Links come and go as units are forced to move across the battlefield, equipment fails, and Soldiers forget to fill the generator with gas. New requirements often pop up with little notice forcing the Brigade Net Tech to modify the network on the fly in order to meet these requirements. It is a rare thing to see a unit with an extra router or two let alone a test environment and when changes occur it is not uncommon to see second and third order effects take place.

One way to minimize the chance of this occurring is through the standardization of network connections and configurations. WIN-T is designed to be largely plug and play with its setup. This allows for a fair bit of flexibility in how it is employed, but also makes for lazy operators and lazy Net Techs who are unaware of how the network is physically connected at a point in time. One common example I see during literally every single NTC rotation is the connection of the BDE Main LAN (NOTE: A recent change to doctrine has removed the use of the acronym “TOC” and replaced it with “Main”, I however still like to use TOC and it is still extremely common so expect to see both used interchangeably as I remember and forget to correct myself.). I see two common problems here. 1. The physical layout of the Main itself changes and 2. The physical connection of the LAN changes.

Problem 1 – The Main’s Layout Changes:

There is no doctrinal answer to what is located at a BCT Main, let alone how it is physically configured. The TOC layout plays an important part in how the various sections within the TOC interact and how efficiently they are able to work together. I won’t spend much time on this other than to say that each unit MUST have a standardized TOC layout. All too often I see the unit setup the TOC one way, tear it down, jump and then set it up different way. From an S6 perspective, this is a nightmare scenario because the amount of sheer work it takes to connect all of the devices to the network the first time is immense. To force the S6 to start from scratch each time the TOC is moved just because the layout was changed is a waste of time, labor and resources (I have seen units run out of CAT5 cable because they had to rewire the main 3 times). While there is absolutely a process to “perfecting” the TOC layout and it will take a few iterations to figure it all out, this is something that should be done as part of a TOCEX at home and not out in the field or even better at NTC.

Problem 2 – The physical connection of the LAN changes:

Just like there is no doctrinal answer to how to setup the TOC, there is also no doctrinal (or even TM) answer for how to setup the LAN that supports the TOC. For example, a typical BDE Main (talking on the SIPR side) consists of a JNN with 4 trunk ports, 2 CPPs with 4 trunk ports on each, the Network Management case with 4 trunk ports, a CCS case with a trunk port, 2 SIPR access cases (by default) with 4 trunk ports each (although many units will have additional access cases/switches) and the multitude of other shelters with switches/routers across the main that tie into the network (BCCS stack, ADAM truck, DCGS-A stack, etc.). To say that there is a variety of ways to connect the LAN together would be an understatement.

But if WIN-T is made to be plug and play (including at the LAN level), why do we need to standardize the way that we physically connect the LAN? Well for a couple of reasons. First because it makes troubleshooting a hell of a lot easier. Take for example this classic scenario. A user comes to the help desk (your help desk is talking all user requests and they aren’t coming straight to the Net Tech right?) and says that their system isn’t working. It is quickly discovered that all users connected to that switch aren’t working. The Soldier goes to the switch, it appears to be up and running but for some reason, there is no connectivity to the network at large so they start to investigate the trunk ports. The problem is that the switch is full of cables (both CAT5 and TFOCA) and no one is entirely sure where any of them go. None are marked, all of them are tangled into each other, and the CAT5 cables (and yes there is at least a trunk cable or two in there) are all bundled together. The TFOCA ultimately runs back to one of the CPPs (we think) but when you walk outside you are greeted with this site. Tracking down that trunk line may take you a little while. I have actually seen on more than one occasion the Soldier just gives up and just run a new trunk line (which of course they fail to label).

The other reason, to standardize the LAN, is because just because WIN-T is plug and play by default doesn’t mean that it stays that way. At NTC for example we give the rotational unit a backup link to the Division headquarters for them to failover to in the event that they must stow their STTs due to wind (it actually happens a lot more often than you would think out here). This connection operates off of a nonstandard VLAN which the Net Tech must configure a trunk port to connect from their switch to the division switch, and then trunk that VLAN all the way back to the JNN’s ST2R. That is often hard enough to do the first time because of course, we’re not entirely sure of the path it must take from switch to switch to get to the JNN but then when the main jumps, all of a sudden this VLAN stops working. Many units will call the Division and say that their switch is messed up but 9 times out of 10 we’ll discover that they didn’t setup the LAN in the same way so the trunk port, that allowed the VLAN to go across it at the last location, isn’t the same path it is taking this time.

So How Do We Fix The Problem?

The answer is easy, STANDARDIZATION! But how do we do that? Well, there are a few ways. Start with the Brigade TACSOP (you have one right?) This document is supposed to talk all about how the Brigade Main (and usually TAC too) deploys and operates in the field. While it includes a ton of battle drills, many do (and all should) include a section about how the TOC is actually setup and configured. This includes the arrangement of tents, setting up physical security, etc. It should also include a section about how the TOC is wired up. While we may not want to include all of the nitty-gritty details here, at the very least a basic wire diagram showing the basics of how the LAN is connected (trunk lines). From there another much more detailed document should show exactly where each trunk line is plugged into.

Another step is to label the TFOCA cables and then leave them labeled even when you tear down the TOC. On each end of the cable permanently attach a label that at the very least identifies the switch name and port that it will be plugging into on both ends (example: JNN SIPR SPF2 – JNN SDXS1 SPF2). This means that when the operator arrives on site and is setting up, they can simply grab the cable reel, look at one of the labels, and automatically know exactly where both ends need to plug into. And the best part is, it will be the same every single time.

Finally, update your switch configurations. If you have a trunk port, label it for what it really is. Almost every single time I look at the configuration of an access case the trunks have “(SFP2 1000 LX/LH) Trunk to JNN ST2S or Access Case” in the description. What does that do to help you with anything? Instead once we have standardized the TOC layout, update the description just like we did on the labels (example: Trunk line to JNN ST2S Port 25).

Once this work is done the first time, it is important to keep it all current. SOPs are living documents that need to be updated as changes are identified. Labels (on both cables and switch ports) need to be updated as things change. If it is a one-time change for that specific mission the just note it in your green book. If it is a permanent change than incorporate it into your other documents. Ultimately this will decrease the amount of time needed to establish the TOC when it sets up, decrease errors, and aid significantly in troubleshooting in the future.