Skip to content

Category: Army

Getting FDMA Working on a CPN

As per my last post, I will show here the basic configuration of how to get FDMA working on a Lot 10 CPN. All CECOM documentation only shows how to get a JNN working, but (as CPNs don’t have a GPS to provide timing) we have to do things differently.

Cabling

  • TFOCA-2 runs from Port 1 on the LOS case to J1 on the STT. In our LOS case, we had to use the spare fiber pair to connect to the CTM-100/C.
  • Serial cable connects from NT2R Serial0/0/0 to the LOS case’s Channel 1 Red.
  • Serial patch from Port 1 NRZ to Channel 1 Black (all on the LOS case).
  • FDMA modem and CTM-100/C installed as labeled in the STT.
  • KIV-7M installed as labeled in the LOS case, COMSEC loaded, and strappings matching the HUB.

CTM-100/C Configurations

The following setup will allow your CTMs to pull timing through your FDMA modem.

SETTINGS LOS CASE STT
Mode Fiber Fiber
Input NRZ NRZ
Rate <Provided in SAA> <Provided in SAA>
NRZ Mode EIA530A EIA530A
NRZ Config DCE/EXT DTE/EXT
NRZ Clock ——- TXC
Clock Source Fiber Input
Status (when complete) <Rate> nF_ P_ L_ <Rate> Nf_ P_ L_

NT2R Configuration

  • Remove “passive-interface Loopback0” from the OSPF configuration.
  • Add a network statement to include the Hub’s NT2R (e.g. “network 144.104.201.224 0.0.0.0 area 0”). The IP of the Hub’s NT2R should be visible in your routing table, as it is a directly connected network via Serial0/0/0 (shown in the yellow box below).
#show ip route
NT2R Routing Table

Conclusion

That should be it. If any additional configuration is required, it is Hub-specific and not something we came across. If additional help is required, I can be contacted via this blog (must use a .mil email address).

Next Post: Getting FDMA Working on a CPN

Normally, a WIN-T Battalion Command Post Node (referred to as either BnCPN or CPN) is configured to connect to the WAN via a TDMA satellite link. This is the way things are normally done and the way we are trained to make it work. However, the powers that be have decided to make certain CPNs “Super CPNs” by providing them with an FDMA modem, which is normally reserved for the JNN. This has been done for a while: another CPN at FOB Wolverine (where I was working in Afghanistan) had an FDMA link back in 2010. The only problem is that no one, or very few people, know how to make it work.

Well, we figured it out this morning. I have copious notes and will be posting a write-up for the benefit of fellow CPN operators and the CECOM FSRs who support us.

Team Chief’s Toolkit, Part II: Hacking Your Equipment

Okay, “hacking” may be a bit overboard for what I’m talking about here, but between the recent policies from General Dynamics and the ineptitude of the team you may be replacing, I might not be that far off.

In Part II of the Team Chief’s Toolkit, I’ll give a few recommendations for modifying your equipment and provide a few useful tips for dealing with TPE equipment.

Modify Your Switches

Any remote switch you may have (that is, a switch not mounted inside your stacks) should be locked down and hardened.

  • Enable service password-encryption. This will prevent your VTY and console passwords from being displayed in clear text inside your config.
  • Enable SSH version 2 and disable telnet. Cisco has a nice article on how this is done.
  • Enable port security. For each non-trunk port, there should only be two MAC addresses: the IP phone and the computer attached to it. Port security is not needed on trunk ports, but ensure that nonnegotiate is set to prevent VLAN hijacking and only allow the voice, data, and management VLANs across.
  • Avoid using SNMP version 2c or earlier. Use 3 if your NETOPS will allow it.

Open Letter to SPAWAR

To Whom It May Concern,

As a service-member who has been in the Southwest Asia theater of operations for 24 of the last 48 months, I have been well exposed to the services offered by your organization. While it is nice to have free (albiet low-speed) Internet access and low-cost calling options, the reliability and quality of your network is questionable.

My first issue is regarding the lack of Quality of Service (QoS) policies on your routers. At least at the distribution/access level, QoS policies do not exist. While I have not seen your routers’ configurations, this is obvious for a number of reasons:

  • When the MWR is empty, the Internet speeds are manageable and could even be considered good for a satellite-based link.
  • During the afternoons, when the majority of traffic appears to be data (web pages, instant messaging, etc.), access speeds are still usable, even when all of the computers are in use.
  • In the evenings, at least fifty percent of users are using voice and video applications, such as Skype, with little to no degradation of video quality. Attempting to use data services, however, is nearly impossible, as pages (even quickly loading ones such as Google’s home page) will time-out before being displayed.

Quality of Service policies prevent any one type of service from dominating the available bandwidth and preventing others from working. While the telephone services you provide are Voice-over-IP (VoIP) and QoS policies may be in place segregating VoIP from other traffic, no restrictions are being placed on computer-generated VoIP and video services (i.e. Skype, Yahoo! Video Messenging, etc.).

These policies could be easily created and implemented, as they are in use throughout the IT world (including the Army’s WIN-T architecture). At bare minimum, ensure that each station is allotted a dedicated portion of the cafe’s overall bandwidth, so that it is usable.

Second, the images placed on the cafes’ computers are bloated, outdated, and just plain awful. While I applaud the wide-array of Instant Messaging clients (on this machine, there is Google Talk, Skype, Windows Live Messenger, Yahoo! Messenger, AIM, and MySpace IM), no one uses MySpace IM. Also, the version of Google Talk installed doesn’t support Google Voice, which would be the only reason to use that over Yahoo!, AIM, or Windows Live.

The Start Menu is littered with items like Creative Product Registration, two versions of OpenOffice.org, two icons for Internet Explorer, and a number of other applications that your cafes’ users should not be using or seeing. If the cafes’ techs are installing software onto your baseline, then my statement regarding your image should be withdrawn and my comments be redirected at your techs. Windows XP (the OS used in your cafes) is too easy to keep tidy, especially when users only have access to one account.

Lastly, your network is owned by the Department of Defense. As such, access should be limited to ID Card-holders only. Third country nationals should not be permitted access to such systems. I do understand that the network is not directly tied into NIPR net (the Department of Defense’s Unclassified network), but the use of MWR facilities outside of SWA is limited to ID Card-holders. It should be no different here.

The people working the front desk (TCNs) give priority to their “friends” with regards to time limits on the phones and computers. Soldiers, sailors, airmen, and marines should not have to wait in line behind TCN contractors that should not even be allowed MWR access.

Please do not take my criticism as an attack. I am grateful for the free Internet and appreciate its availability. My hope is to bring a few glaring issues to your attention, so that future deployers can experience even better services with little effort on your part.

Respectfully,

Sean Callaway
United States Army


SPAWAR, or the Department of the Navy’s Space and Naval Warfare Systems Command, provides Internet and voice services in Iraq and Afghanistan. You can visit the SPAWAR homepage here.

The Signal Team Chief’s Toolkit, Part I

Backstory

I took over as my CPN’s Team Chief toward the end of our deployment, as our original Team Chief took leave late and it didn’t make sense to push him back out to our site with only a couple months remaining. Unfortunately, I fell in on a mess. Our Theater Property and Organizational Equipment was spread out to our customers and, aside from a hand receipts, I had little idea what was where.

So, with 20/20 hindsight, I am writing a series of best practices called The Signal Team Chief’s Toolkit. Hopefully, this will be of use to my fellow Army Signal soldiers who are either new to the Team Chief position or are looking for a better way to do things.

Dealing With Equipment

First, it goes without saying that everything not in your shop should be either hand receipted if in use or locked securely in your ISU-90/quad-con. This should be done without exception. Even if you trust the person using your equipment implicitly, a hand receipt will not only cover your ass in the event that something goes wrong, but will aid in the accountability of your equipment during inventories. Remember, do a hand receipt every time.

Get the DA 2062 form in PureEdge or PDF format.

Second, create a tracker of all your equipment, where it is, and to whom it is hand-receipted. You should actually do this before your team validates in country. Once your team begins installing remote switches and loaning (and hand-receipting!) equipment to your customers, the tracker should be modified to identify the location of the equipment and who signed for it. It should look something like this:

DEVICE SERIAL # LOCATION HAND RECEIPTED TO
Cisco IP Phone 7941 FCH1338AWKM Task Force LT Black
Cisco IP Phone 7941 FHK1330A06C Task Force LT Black
Cisco IP Phone 7941 FCH1338AVQC Post Office SSG Blue
Cisco IP Phone 7965 FCH141187RD KAF SSG White
Dell Laptop 6400 1CXS0L1 Task Force LT Black

Keeping this up-to-date will save major headaches during cyclic inventories and especially during your RIP.

I’ve gone ahead and created a Excel worksheet that includes the proper headings and filters to get you started.

Next, as each device (phone, computer, or printer) is added to the network, you should create a document identifying the device and its pertinent information, like IP address configuration, location, and whether or not it was added to active directory. These should go into a binder where they can be easily referenced. When a device is removed from the network for one reason or another, write ‘REMOVED’ in marker across the page, but keep it around for reference purposes, possibly in a different section of your binder.

My device information sheets are available in Word and PDF formats.

Finally, create and maintain a tracker for your statically-assigned IP addresses. Printed copies of this tracker is very useful to the IMOs who are actually assigning the IPs to the end-users’ computers.

My tracker is available in Excel format.

If you have any suggestions or tips of your own, please leave a comment or email me at seancallaway@gmail.com.


EDIT: Links fixed. – 13 NOV 11