This time last year I was poking around with ciena-sds graphs and while I was working on it, librenms got an update for a model that was newer than what I was fiddling with, so I incorporated my changes into those changes and didn’t think much about it after that. Apparently, there is a conflict that I am trying to wrap my head around. If I am understanding the issue properly, it is a bit above my expertise and thought I would ask the community for ideas/approaches.
Now that it’s a year later, I had a user point out some devices were no longer showing port traffic. (Libre couldn’t find ports for the device at all.) In my digging, I have found the file “includes/definitions/ciena-sds.yaml” that ties interfaces to ifName and ignores any that do not have a value. (I’ve included below Firmware and MIB versions if it helps.)
For my initial testing, I didn’t really worry about the ifName of the ports. Their index was usually 10000 + the “port number” as referred to by the OS. (port 1 was 10001, etc.) It had a hardcoded interface description, which I admit was ugly, but it worked and collected the data.
Apparently, before version saos-06.10.02 Ciena used a custom MIB for interface data:
ifIndex: .1.3.6.1.4.1.6141.2.60.3.1.1.4.1.1 (This is also the port number, but not in a string format.)
ifHCInOctets: .1.3.6.1.4.1.6141.2.60.3.1.1.4.1.2
ifHCOutOctets: .1.3.6.1.4.1.6141.2.60.3.1.1.4.1.16
So now I am wondering if there is a way to discover interfaces under “.1.3.6.1.4.1.6141.2.60.3.1.1.4.1” and use that OID instead? Or at least assign ifName for any interfaces with an index above 10000?
I will mention that one option I would like to avoid is disable updates to this system, and just edit the file to use use the descriptions and ignore the name. It’s an option on this system because it’s just for Ciena devices, but I would obviously like to continue getting future features, enhancement, as well as bugfixes and security updates as they become available.
Hello @PipoCanaja,
I actually did comment out those lines while I was poking around and the “ifName: True” line, which took a little more searching to find out that was telling Libre to use the ifName rather than the ifDescr fields. (ifName being empty would not have a value to label the ports while ifName: true is set.) Using ifDescr the name is like " Ciena 3902 GigEthernet X" rather than just “X” (X = port number), which as i noted before is not pretty, but works for the host I am testing on.
My dilemma is the current method of using ifName works for @bakerds, but this way conflicts with that method. So I am not sure what changes to make so they can co-exist. Right now, I think I would be happy with a way to assign an ifName if it can be determined from the ifDescr and then process it normall.
Another concern is for any older devices that use the custom Ciena interface MIB I mentioned. LibreNMS says we should use YAML configs to discover devices, but this is starting to feel to me like there may have to be a php config to make a few custom tests to determine the best way to find ports. But that might just me making my problem bigger than it needs to be, which is why I am mostly wanting to assign the ifName value based on a regex of ifDescr.
If ifName is not always available, the YAML should stick to ifDescr (so remove ifName=true), so that it always works for all Ciena device. That’s more important. Another option would be to keep ifName=true but patch the port discovery code to fallback to ifDescr whenever ifName is empty.
For older devices, we currently have no way in LibreNMS to use “custom” OIDs for interface discovery and polling.
I see 2 options :
Extend current port discovery code and poller in order to accept custom OIDs to replace IFMIB oids
Or completely rewrite interface discovery specifically for older devices.
Both of them are a significant (and comparable) amount of work. Only the 1st one would solve this problem for all possible devices instead of only Ciena.
I see the logic in what you are suggesting, and it is making the most sense from what I know. I’m worried about the things I don’t know.
Running a discovery, I see this:
SQL[UPDATE `ports` set `ifDescr`=?,`ifType`=?,`ifOperStatus`=?,`ifIndex`=?,`ifAlias`=?,`ifName`=? WHERE `port_id` = ? ["lo","softwareLoopback","up",1,"lo","lo",15796] 1.12ms]
Using ifDescr as ifAlias
Using ifDescr as ifName
And I am wondering if there is a way to manipulate the ifName for ciena-sds at this point? something as simple as if IfName = “^$” then ifName = ifIndex - 1000 would be sufficient, assuming it could be done in YAML config.
The problem is I am not seeing a solution better than PipCanaja’s suggestion to stop using the ifName for the interfaces. The two problems are that the Cienas use some rather long/ugly ifDescr’s rather than the short name that is so much easier to read and I am not sure if that will mess up your devices because you are skipping interfaces without a value for ifName.
So I am testing that to see if I can find any functional issues on the 39xx series, which means my Libre won’t get updates, but that is okay until I can figure something out.
I don’t have any 39xx currently, but will be adding some 3924 in the near future.
Current code works properly for all of my 8700, 5170, and 5142 devices.
This happens to be the instance I created just for Cienas, which is why I am ok with not getting updates while I figure it out.
To recap, the problem as I understand it is that our 3902’s (two ports) were showing with zero ports, which get the index 1000x and appear to have an empty ifName that it I don’t see a way to change in the config. I did find an OID for older SAOS that appears to be for Ciena ports that appears to be the wrong way to go.
So I am letting the server build up data using ifDescr and see what the users complain about.
