“No problems I said, I’ll just use SNMP to collect that.” Or so I thought. There are so many different MIBs so at times I just want to believe I can collect everything from SNMP. However once you have a specific need the information just isn’t there.
It started with a simple question. Is there a better way to collect interface information? My client had been using Rancid to collect the output from “show interface”. This worked quite well until some hardware and software upgrades changed the output causing the parser scripts they were using to stop working. So I wrote a small script which collected the ifTable from IF-MIB and created a csv file.
That was easy enough. But since this was so easy there were a few more things my client needed. They wanted to know which mac-domains used which port-channels on their Cisco uBR10012 routers. In this scenario a mac-domain is tied to a bundle interface and policy based routing was used to decide where the traffic from each bundle interface was sent.
“I’ll have to think about that I said, at least the port-channel part is easy.” I said, and the port-channel part should have been easy. I mean Cisco does have a MIB for that. However it’s not supported on the uBR platform.
I drew up a mental picture of what I needed to do. For the mac domain to the bundle interfaces I parsed the output from “show ip int brief”. I hoped that the access-lists used in the route-maps would be available through an SNMP table. No luck. But surely some information about PBR was accessible from SNMP. After googling awhile it turns out that Citrix has some SNMP support for policy based routing, lucky them.
In the end I had to combine information from SNMP, show running, show ip int brief and show route-map. The most challenging part was the destination address in the route-map, since I only had an ip address and not a subnet mask for the destination I had to write in a subnet calculator for the script. That way I could determine which port-channel would be used for a particular bundle interface by mapping the networks found in the PBR access-list to the interface address of the bundles and port-channel interfaces. If it sounds complicated (granted I haven’t tried to explain it that good), that is my point. Why can’t we just have a good interface network API?
In my early years in this industry I worked a lot with Microsoft technologies. Say what you will against them but they have their strengths. When I created my program for server documentation it felt like I could get everything through WMI. Also the same API could be used to collect information from NT 4.0 (with a patch) to Windows Server 2012, basically all of their operating systems. Granted WMI wasn’t perfect and I think it’s being replaced by WS-Management, but it’s still miles ahead of what any kind of API we have on a Cisco device.
On Cisco routers we have SNMP with different MIBs being supported on different platforms. Other than that we only have ssh and https (on some platforms you might be able to do fancy things with XML), my problem with these is that the output is always variable. If I want to parse an access-list the output looks completely different compared to the interface config, or the version information. Also a lot of times I find myself wanting to act upon some output from the device. For ssh you could do this with different Expect scripts, it works but is it’s not very elegant. I think it would be great if everyone in IT learned a scripting language, and it would be much easier for beginners if we had good tools in networking.
There’s have been a lot of talk about SDN lately. Most of what I’ve heard concerns changing the traffic path in some way. Though I’m sure that’s good for all kinds of scenarios, what I’d really like to see from all this SDN heaven that we keep hearing about is to have good APIs to my networking equipment. I guess hoping for a universal API is just a cozy dream. But honestly just getting something better than we have now would be great. So where is my router API?