Network Management
NETOPS is responsible for the management of their entire network, to include attached enablers:
When in the field and when deployed, NETOPS is responsible for the entire BCT network to include attached enablers (engineers, aviation, etc.). This means that NETOPS must prepare the required configurations to integrate them into the network, allow themselves to access theses systems, and monitor/manage these systems. An attached unit is no different than an assigned unit, NETOPS owns the configuration for it and does not have to ask permission to make changes. The attached node should have a backup copy of their configs prior to any changes being made so they can easily revert back to baseline at the end of the mission.
RTU “pings” routers/switches instead of looking for the status of specific OSPF relationships:
NETOPS primary purpose is to manage the network. In order to do that, it must be aware of the status of all nodes and their links (fiber, satellite, HCLOS, etc.). Units will often do nothing more than ping (using SNMP or ICMP) a remote router to ensure that it is operational. This does nothing if there are multiple paths to that node other then tell you that the ping is getting there “some way”. Units should monitor the OSPF status of specific links between specific neighbors to ensure that the network is functioning as desired. In addition to this, it is important to periodically ensure that data is routing the way you think it is using trace route and other similar commands.
RTU attempts to actively monitor all devices at remote nodes instead of specific critical devices wasting extensive bandwidth :
NETOPS does not need to actively monitor the status of every single device in a remote node. It is the local operators responsibility to ensure that their call manager, access switches, and other similar devices are functional, not NETOPS. If they require assistance, they should contact NETOPS. NETOPS is only responsible for the WAN (and possibly the LAN at the BCT Main/TAC). Monitoring extra devices uses up limited bandwidth (one recent rotation used nearly 4 GB of data on the SIPR side in 24 hours just polling network devices from the NETOPS WAN Manager).
RTU does not start off of baseline configs at the beginning of each exercise causing duplicate configurations:
Each piece of equipment should have a baseline configuration (this may or may not be the same that was issued by General Dynamics). Prior to each exercise, these devices should be put back to baseline and then have mission/exercise specific configuration changes made as required. One recent unit had severe routing issues because spare networks had been placed on a node during the previous exercise and then placed on a different node for their NTC rotation without being removed.
RTU does not maintain backup copies of current configs for all network devices:
Backup copies of all configurations should be kept and updated as configurations are changed. CPN/JNN teams should backup all of their configs every time a change is made. NETOPS should use Orion Configuration Manager to backup all configs across the network periodically (possibly as often as every 24 hours).
RTU does not implement QOS for critical services:
Quality of Service (QOS) plays a vital role in ensuring that critical services operate as required when bandwidth is limited. WIN-T baseline configs come with the framework for QOS build, but units are required to identify critical services/systems through the use of access-lists. We see two things normally. Either the access-lists are empty, in which case, almost all traffic is considered default priority by the network, or the access-list has the entire server range, in which case all server traffic is prioritized evenly. Both options are good, and the second one can potentially have very bad effects on the network. Specific services and servers need to be identified individually and placed into the appropriate access-lists.