Introduction
Collecting networking data has always been a cat-and-mouse game between the parties that build platforms to collect data and the parties that build network/infra hardware devices. Over the years, we have seen many protocols that enable us to read data from the network:
– SNMP
– SSH
– NetConf
– RestConf
Over time this will probably all become API-based, but until we get there, we still have to find ways to deal with collecting data from traditional devices.
But how do you select the right protocol to do this?
Structured vs Non Structured
When you look at those four protocols, the following give you a structured outcome, so the choice should be quite easy. Let’s pick one of these:
– SNMP
– NetConf
– RestConf
Well… we thought the same.
The problem is that every vendor implemented these protocols in a different way.
For SNMP, we have something called MIBs, which are basically dictionaries that explain how to read data from devices via SNMP. But if a MIB is missing or doesn’t exist, that data becomes unreadable.
For NetConf and RestConf, things differ even more. Vendor implementations vary so much that building a truly multi-vendor solution becomes impossible when relying fully on those protocols. Older devices, and especially most Telco devices, don’t even support them.
So, while the most logical protocols were failing us, we turned to the non-structured approach.
Now, I think someone at Google ran into the exact same problem, and that’s why they built something revolutionary called TextFSM.
Google to the Rescue
With TextFSM, you can turn any non-structured output into a structured JSON file.
This gives us full control over what data we want to extract and also how we want to return the output.
To simplify this, we maintain a database with more than 1,400 templates for existing vendors and commands.
We also provide a service to build the missing templates for you, and we run an open-source project that helps you build your own templates.
Conclusion
Why we prefer SSH + TextFSM
1. SSH works everywhere
SSH is supported by almost every network device: Old, New, Telco, enterprise, you name it.
Where SNMP, NetConf, and RestConf fail due to missing MIBs or inconsistent implementations, SSH simply works.
2. We bypass vendor inconsistencies
Instead of relying on vendors to provide structured data, we take the device’s raw CLI output and structure it ourselves.
TextFSM eliminates the dependency on whatever the vendor decided to implement (or break).
3. We get consistent multi-vendor structured data
Even if 10 different vendors display their interface status in 10 different CLI formats, we can still build 10 TextFSM templates and always output one unified JSON model.
4. Zero waiting for vendors to fix or update anything
New software version breaks SNMP or NetConf?
Doesn’t matter.
We adjust the template, done.
5. Predictable, reliable, future-proof
Even as APIs become more common, SSH won’t disappear anytime soon.
And TextFSM works today, everywhere, right now.