Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayWhen one of our long-standing telco clients began transitioning from Megasys Telenium to SolarWinds, they encountered unexpected monitoring headaches. Their move from Telenium (which polls DPS NetGuardian RTUs via DCP protocol) to SNMP under SolarWinds introduced new complexities, especially around configuring and polling NetGuardian RTUs.
The feedback they shared was candid - and invaluable. It showed us which SNMP implementations worked well already (hello, NetGuardian 420!) and which areas needed refining (the G6 and its MIB files).
Here's how we're collaborating with this telco to simplify their monitoring setup and cut down on extra labor.
The client's shift from Telenium to SolarWinds meant changing how they monitor their NetGuardian RTUs. With Telenium, they used DCP - a very compact protocol that required minimal configuration. In SolarWinds, however, they rely on SNMP, so everything hinges on properly configured MIB files.
"I love the 420 because it's so simple," one engineer told me. "But with (SNMP on) the G6, I feel like I've taken a step backward."
This was a key frustration. The NetGuardian 420's SNMP MIB structure made it easy to create just four custom pollers for all 20 ports. In contrast, the G6 demanded individual poller setups for each input. That extra work was bogging them down.
On top of the MIB differences, our client had found polling compatibility issues:
"Alarms only worked correctly with SNMPv1. Versions 2 and 3 threw errors," the engineer explained.
SNMP traps functioned, but polling the G6 for open/close alarms in higher SNMP versions wasn't reliable. As soon as I heard this, I made a note to review the G6 firmware and MIB with our engineering team.
"The G6 was not supposed to be a step backward," I reassured them. "It's built on a newer chipset with advanced capabilities, so we need to see what's causing these problems for you."
As we dug into the SNMP issues, this client also shared the practical realities of day-to-day fieldwork.
During our call, their techs brought up fiber rollouts and SFP glitches they'd encountered when first deploying NetGuardian RTUs. Sometimes, the SFP modules they used weren't immediately compatible with certain site configurations, causing momentary confusion.
"We had an SFP issue on our side," one engineer explained. "Once we realized it was our own module mismatch, everything worked like a charm. We really appreciate you guys helping us get that sorted."
It turned out to be a quick fix: once the right SFPs were in place, their RTUs successfully integrated into the overall monitoring system.
This story should remind you of how even a well-planned rollout can stumble over small details - especially when multiple teams, hardware generations, and new protocols converge. At DPS, we like to catch these issues early by consulting with you on recommended part numbers and site-readiness steps.
In the middle of these technical challenges, the client was also dealing with organizational transitions. Multiple employees had shifted roles or retired, while entire regions in multiple US states were divested to another company. That new owner was asking about DPS Telecom's offerings:
"They use SolarWinds Orion, so they wanted to see how we do things," the client told us.
As a result, we spent extra time helping them craft a "post-transition" approach that would fit both organizations.
We guided them on best practices for remote monitoring, whether they chose T/Mon, an SNMP-based manager, or a hybrid. This conversation also shows how internal reorganizations can drive large-scale changes in network monitoring - providing both new challenges and fresh opportunities for optimization.
Navigating SFP swaps and reassigning local teams might sound mundane, but these everyday realities shape how smoothly a major monitoring transition goes.
By addressing every "piece of the puzzle" - hardware modules, staff turnovers, and new corporate structures - we keep our clients' networks on track, even in the face of significant corporate reorganization.
The DCP protocol had previously kept everything straightforward for the client. But in an SNMP-based environment like SolarWinds, the MIB files are the backbone of your monitoring:
"The G6 interface immediately reminded me of the TempDefender," the client noted. "I tried to SNMP-walk it, but I kept running into errors."
To address these challenges, we're making several changes:
A big part of our conversation revolved around why the 420 is so popular among telco professionals. It's straightforward, reliable, and requires minimal configuration overhead. As one engineer put it:
"The 420 lets me configure everything I need without a hassle. I can add pollers for all 20 ports with just four entries. It's perfect for our workflow."
This is why the 420 is still going strong in many networks. It's the model of simplicity - a trait we're determined to preserve as we evolve our hardware. While the G6 includes advanced capabilities, we recognize that the 420's ease of setup remains a top priority for many clients.
Our conversation with the client also highlighted how password management can become a real headache when networks span hundreds of remote sites and multiple states. Until recently, this telco had used local logins for each RTU. That works fine at smaller scales, but it quickly becomes unmanageable when you're juggling new sites, new staff, and sensitive password policies.
"If we give these passwords to another entity," one team member said, "they'd have access to our entire system. We'd need to change passwords on 900 devices."
That's where centralized authentication methods like RADIUS step in. While not everyone uses it, most newer NetGuardian models - including the 420 and the G6 - support RADIUS. This protocol lets you manage logins and permissions centrally, so you don't have to visit each RTU to make an update.
"If you have a RADIUS library file, we'd love to test it," their engineer told us.
We're now sending them our RADIUS library file. Once configured, this approach could allow them to unify their login policies across multiple devices and business units. That's a huge time savings, especially with all the reorganization they're undergoing. We're also open to exploring other authentication protocols (like Active Directory) if they prove to be a better fit.
Embracing centralized login management is one of those subtle but powerful wins that can transform your daily workflows.
Feedback isn't just helpful. It's essential.
We refine our products based on real-world experiences, which is why these calls are so important:
"With the G6, I have to create individual points for each input - it's a lot more work," the client said.
That type of insight goes straight to our engineering team. We don't want to release hardware and then walk away. We constantly improve it to address actual field challenges. Whether it's tweaking MIB structures or adding an entirely new feature, feedback is our most reliable roadmap.
Switching NMS platforms is never trivial. Moving from Telenium (DCP polling of NetGuardians) to SolarWinds (SNMP) introduces new protocols, different setup processes, and fresh learning curves.
To help, I offered to set up a screen-share meeting with our engineering team. A quick walkthrough can save hours of frustration by pinpointing exact configuration pitfalls.
Despite some initial speed bumps, the client emphasized how much they value DPS support. Their goal is to make the NetGuardian 832A G6 just as user-friendly as their beloved NetGuardian 420. We're dedicated to making that happen:
"If engineering needs more context, we can set up a meeting to dive into your setup," I offered. "We want to ensure you're just as happy with the G6 as you are with the 420."
By refining the G6's MIB structure, fixing any SNMP version issues, and supplying clear documentation, we aim to streamline the entire setup process. Our client - and any telco making a similar transition - will save time and headaches down the road.
At DPS Telecom, we don't just ship a product and call it a day. We listen, improve, and support you during big transitions. Whether you're moving from one monitoring system to another or looking to upgrade to new hardware, we'll guide you every step of the way.
Let's discuss your monitoring challenges. What do you need to monitor? What specifics will make your life easier?
Call us today at 1-800-622-3314 or email sales@dpstele.com. We'll figure out the fastest path to simplified, reliable monitoring. You'll keep your network running smoothly while saving time and energy in the process.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 18 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
