A large electric utility had two alarm monitoring problems: their aging Badger system was failing, and they needed a new monitoring solution for their Harris microwave radios. DPS Telecom installation engineer Chris Hower helped integrate both the legacy remotes and the new microwaves into a single integrated network alarm monitoring system.
Through product demonstrations, training classes, database conversion, and creating several custom network designs, Chris went above and beyond to ensure that DPS Telecom provided a network monitoring system that met client's technical-and budgetary-needs.
The client, a large electric utility, had hundreds of sites, some of which were a three-hour drive away from the primary NOC. The client was installing new Harris microwave radios that reported alarms as SNMP traps, and their existing network monitoring system was a Badger master polling Badger remotes.
Chris said that the client needed to upgrade to a more up-to-date system. "Their biggest fear was 'What if something dies?' If a remote dies, sure, they have a couple of spares. But if the master dies, what are they going to do?" said Chris.
After consulting with DPS Telecom's sales engineers, the client had decided to replace their master with two T/MonXM WorkStations (one as a primary master and the second as a cold standby backup) and install NetGuardian remote units at their new microwave sites. The NetGuardians receive and forward traps from the Harris microwave radios, and the T/MonXM WorkStation receives the traps through the optional SNMP Trap Processor software module.
The T/MonXMs can easily poll both the new NetGuardians and the existing Badger remotes, so the client did not need to maintain two types of master. With this solution in place, they could then gradually replace the Badger remotes with NetGuardians at all their sites, at a pace that would stay within their budget.
Chris' first job was to demonstrate the new system to the client. "They really liked the features of our system. They liked T/MonXM's protocol analyzer. Before, they had to get out this huge box and hook it up to the lines to see any kind of protocol-it's a simple keystroke on T/MonXM. They also liked the visual display on the NetGuardian. You can watch it and see that it's being polled, you can see the alarms. You can see everything that's happening, and you don't have to have much experience to know what's going on."
"They were impressed with it, but they didn't want to change. They liked the display they had and they knew how to use it. So I showed them T/GrafX. I made a simple map in an hour that matched almost exactly what the Badger system looked like."
Then Chris showed the T/MonXM to the technicians who would work with the system. "They were impressed with it, but they didn't want to change. They liked the display they had and they knew how to use it. So I showed them T/GrafX. I made a simple map in an hour that matched almost exactly what the Badger system looked like."
But Chris' responsibilities didn't stop with showing the product. He also made it work for the client's specific needs, helping through all kinds of technical difficulties.
The first was the sheer amount of SNMP traps that the Harris radios sent through the network. "The radios were sending insane amounts of traps, constantly barraging the T/MonXM with traps. So the client brought the Harris guys online and asked them 'What can we do about this? There's a lot of stuff in here that we don't really need to know.' These were a lot of unimportant status alarms. Harris put a front end on OpenView to filter the traps from OpenView and forward them to T/MonXM."
Chris continued, "It turned out that their forwarding method was much different than a regular SNMP trap. It ran over a TCP channel rather than a UDP trap. So we changed T/MonXM to accept that kind of trap."
Implementing the NetGuardians also required some creative engineering. "Their NetGuardian integration was a little bit different because they didn't have network access at the sites. So we found that the Harris radio had a service channel we could hop onto. It's a 232-type service channel, so we plugged the NetGuardian into the service channel through the RS232 port, and started polling them that way. It worked great, extremely great."
The client had another specialized issue. They had used an ASCII-based system to monitor system events after regular working hours. But this required no workarounds at all, since T/MonXM's alarm forwarding feature forwards all system activity as ASCII text.
Chris said this installation was "fairly difficult. On a one-to-ten scale is was a seven. There was a lot of conversion, bringing the Badger database into T/MonXM. But we went with a standard. I told the technicians, if you wire all the NetGuardians the same, on T/MonXM you only have to database once, and you can use the site templates feature to apply that database to all the sites."
Chris said that his goal in the implementation was to change the system over without adversely affecting the client's network monitoring. "We stepped in the place of the Badger master and tried not to make a big footprint. As much as possible, we utilized the equipment that they already had to make it happen, so they're getting money out of all their investments now, not just shooting them over the side."
And, Chris added, he takes a personal pleasure in how well the transition went for the client. "I like seeing results. I think it's awesome to have a huge company count on me to make this thing happen. They're all under the gun and it's pretty cool to be able to see the smile on people's faces when they are glad they trusted you."
A legacy support solution will improve your network visibility without killing your budget. To learn more about legacy support, check the Legacy Support Applications Knowledge Base or contact a DPS Telecom Applications Engineer.