Huawei Switch MAC Address Table

Best I can do for now is either an SNMP datasource that has the OID for MAC (relating to MAC in the MAC table) and its corresponding interface index number in the form of Instance/description.

OR

A script datasource that works like a config source that logs in and runs the display mac-address command, however this shows RAW output only and can't be displayed.

It would be neat to have more RBAC over specific datasources/configsources as I could allow a lot more run or show commands (as separate configsources) but obfuscate the running config (which we hide from the client).

What do you want to do with the data? Do you want to have counts? Are you trying to create ERISources and TopologySources so that you can map it out? What's the goal? Is it troubleshooting?

FWIW: When you do a poll now, you can see the entire output of the script. Script output can contain more than what is parsed. So, if you have a datasource that pulls the data and does track some sort of numerical data, but also outputs the MAC table, you could do that and the MAC table would only be displayed when the Poll Now button is used. Technically, it would be included in the output every time the script ran, but only the part of the output that matches the scripted collection output format gets properly parsed. The rest is ignored.  I've used this technique in the past to actually have the exact same script run discovery and collection. Every time it runs, it outputs both the discovery output and the collection output. When running for discovery, the collection output is ignored by LM. When running for collection, the discovery part is ignored by LM.

The goal essentially is to allow a client to run a command on a switch without logging in and of course receive the output as it is. We look after and manage devices for clients and we hold the rights to the configuration and as such clients cannot log into devices. One of the commands that clients would often call up to have the information for is the display mac-address (on Huawei) this allows them to see what connected devices are on what interface. It is somewhat tricky as there is no real appropriate OID to use that would work, the closest I have come (which does work) is this .1.3.6.1.2.1.17.4.3.1.1 (dot1dTpFdbAddress) as the SNMP OID and the interface index as the description .1.3.6.1.2.1.17.4.3.1.2. This works but then you get a lot of instances with a singular number as the interface it is connected to as its description which may look messy but, it is searchable.

The other option is have it as a script datasource and the user can go to it and "Poll Now" and get the raw output infront of them. This looks nice and they can then extrapolate the data somewhere else but it is not searchable.  If the raw output could be displayed on a widget that would be cool but ultimately would start to compete against configsources to some degree. On the topic of configsources I could ultimately just make one that does the aforementioned script and that would work wonders and I could in future make a nice script which grabs a lot more (which would be awesome!) however I run into a RBAC problem where we don't allow them to see the configsource due to config ownership. If I had more granular RBAC over datasources/confgsources (mainly configsources) I could produce some amazing tools for our clients.

A scripted ConfigSource should work. The thing about LM is that it's not really built for interacting with the devices just once in a while. You'd need to build the configsource to log in regularly and issue the show commands. You wouldn't have to set any config checks on it, unless you really wanted to. The configsource would pull back the results of the show commands (using Expect) and store them in LM. Then your users could see the output of the command without ever logging into the device.

Yeah I ended up building both but neither is ideal to present to a client (client in this sense is a client of our Network Services who we give visibility of their network via LM). I'll put through a request for better more granular RBAC over different configsources.