Common Config Sources vs Legacy LM Config Sources

We use LM Config and have since day 1.

I’m wondering if any of you have migrated off the legacy LM Config sources and onto the “Common Config” method?

What sort of gaps in data did you have?

I’m sort of stuck on the idea of having to dump one for another or potentially have some that work only with legacy vs Common methods? Seems like it could be hard to manage.

Do you have any challenges today using the new way?

Shack

Posted 2 years ago·Last reply 2 years ago

1 comment

LM User

·2 years ago

It is hard to manage, but I’ve made some headway. There are still issues for me; I’ve got a long running ticket open with support about most of these issues:

Dynamic vs. Standard - it appears that the main difference between these two is that Dynamic configs are expected to change often, so they’re only for collecting the config, not alerting on it. Standard configs are expected never to change, so there is a difference test alert configured on them. In my experience I’ve had quite a few devices where the dynamic CS picked up a config and the standard didn’t. I don’t know why this would be.
SSH Exec vs. Interactive - I have no real answer what the difference is here. I think it has to do with how the device presents logon. With mine, it seems that only one of them works on a particular device and the other never works on that device.
How do all these modules work together? It seems that in order to simplify things, things got way more complex. There are property sources per device type (Cisco, HP, Juniper, etc.) that check the devices to see which method of login should be used (see #2), which commands result in success, and how to regex the output of those commands. These properties all end up on the device and drive the configsources, which are now simplified down to a small set. So, where we had individual configsources per type before, now we have individual propertysources with a single set of configsources everything goes through.
Duplicate configs - the devs don’t seem to know anything about the majority of network devices out there. The default list of commands to run (each successful element in the list becomes an instance) contains commands that in many cases are guaranteed to return the same value. For example, the Config_Cisco_Generic propertysource attempts to create instances starting with this list:

def standard = ["show version": "Version",<br/>  "show inventory": "Inventory",<br/>  "show running-config": "Running-Config",<br/>  "show startup-config": "Startup-Config",<br/>  "show running-configuration": "Running-Configuration",<br/>  "show startup-configuration": "Startup-Configuration",<br/>  "show configuration": "Configuration"<br/>]

Notice how they have “show running-config”, “show running-configuration”, and “show configuration” in there? Guess what returns the same thing on most Cisco devices? That’s because of command completion. However, it’s not the case for every Cisco device. Some devices don’t support command completion, so “show running-config” would fail while “show running-configuration” would succeed. The devs appear to have taken a shotgun approach method, attempting to capture every possible config in every possible situation without putting any “logic” in place (it’s not as if the company is called LogicMonitor” after all).

To rectify this, their solution is to have you put a property on the device that overrides this list. Their answer to the creation of duplicate instances is to have you override the work they built into the PropertySource. Instead, I just fixed the property source:

def standard = ["show version": "Version",<br/>  "show inventory": "Inventory",<br/>  "show running-config": "Running-Config",<br/>  "show startup-config": "Startup-Config",<br/>  // "show running-configuration": "Running-Configuration",<br/>  // "show startup-configuration": "Startup-Configuration",<br/>  // "show configuration": "Configuration"<br/>]

I did this after looking at the instances for all my devices and determining that the “show configuration” instance was never needed and that in every case that the “show running-configuration” and “show startup-configuration” instances were working, the shorter ones were also working. I could have added the property that overrode the values, but I would have then needed to make sure that the group where I applied the property contained the right devices, essentially duplicating the work that the AppliesTo on the PS was already doing.

I still have a ticket open to work out the rest of the bugs, the main one being that one a set of devices, i get the running-config showing up through the “interactive” CS, but not the other instances. Since the old CS did detect the other configs just fine, I want LM to figure out why the new one isn’t doing as well as the old one.

1	SUYASH GAIKWAD
2	RR Robin Ratcliffe
3	AH Alejandra Herrera
4	HS Hunter Sparks
5	LT Lily Trbovic
6	AG Asher Guinzy