Common Config Monitoring

Last updated on 25 March, 2024

Common Config monitoring is an approach that uses a variety of collection types to identify the most reliable method a device supports. Coverage is typically focused on collection types that use variations on SSH style protocols. For example, SCP, SFTP, and SSH EXEC. The Common Config approach uses multiple PropertySources in a sequence and has some characteristics unique to this suite of modules.

  1. A device or brand-specific PropertySource, such as Cisco_Generic_Configs, applies host properties of collection information specific to each device. These provide subsequent steps of the process information specific to the kind of device you are working with.
  2. A number of “check” PropertySources run and attempt various collection types using the host properties applied. Upon the first successful collection a further host property is added, indicating a success. This stops less reliable checks from running and applying.
  3. With the host now containing a list of device-specific collection information – and a property representing what is believed to be the most reliable collection method – the matching “common” ConfigSources apply. Common ConfigSources share code and get their device-specific collection instructions from the host properties that are applied through the vendor-specific config related PropertySources. For more information, see LogicModules in Package.

Requirements for Common Config Monitoring

  • The minimum collector version supported is 28.606. This is due to a requirement on the SSHJ library added in that version.
  • Install the Common Config LogicModules. For more information, see LogicModules in Package.

Common Config Custom Properties

The following custom properties must be set on the device resource within LogicMonitor. For more information on setting properties, see Resource and Instance Properties.

Authentication Properties

PropertyValueRequired
config.user/ssh.user/telnet.userUser that is used for authenticationYes
config.pass/ssh.pass/telnet.passPassword that is used for authenticationYes
ssh.cert/ssh.publickeyPath of the key used in authenticationNo
ssh.enable.passPassword used for privilege escalation during interactive SSHNo
ssh.portPort used for SSH connections (Default : 22)No
config.hostnameAn alternate host used in place of system.hostnameNo

Prompt and Command Properties

PropertyValueRequired
config.promptA user-specified prompt line to search for, rather than finding one automatically No
config.ptyA user-specified PTY type (Default : vt100)No
config.filterRegex used to filter the output.For example, this may be used to filter MOTD messages or personal information.No
config.custom.responseCustom responses to regex lines in a comma-separated Line=>Response format.For example: Please Enter a to Continue=>aNo
config.commands.formattingA comma-separated list of commands sent prior to the main command.For example, you can format the CLI to ignore pagination.
Note: These logs are not automatically deleted and must be deleted manually.
No
config.commands.standardSpecify comma-separated key value pairs for instances that you want to monitor.For example: show config=Config,show inventory=InventoryNo
config.commands.dynamicSpecify comma-separated key value pairs for instances that you want to collect, but not alert on, even if they change.No
config.logs.permanentWhen set to true or 1, this property adds regular permanent logging to common configs collected with pseudo interactive methods (ssh, telnet, etc). These logs can be used for diagnostics. Logs are written to the /logs/ConfigStats/ directory
Note: These logs are not automatically deleted and must be deleted manually.
No

Properties to Control Protocol Used

You can use properties to define a single protocol for a device. This prevents other protocols from being attempted. For Telnet, you must use a property and value, as no other protocols are relevant and should not be attempted.

ProtocolPropertyValueRequired
Telnetconfig.type.telnetIf set to “1” or “true”, forces Interactive Telnet collection for the device, bypassing checks.Yes
SCPconfig.type.scpIf set to “1” or “true”, forces SCP as the collection type for the device, bypassing checks.No
SFTPconfig.type.sftpIf set to “1” or “true”, forces SFTP as the collection type for the device, bypassing checks.No
SSH EXECconfig.type.execIf set to “1” or “true”, forces SSH EXEC as the collection type for the device, bypassing checks.No
SSHconfig.type.interactiveIf set to “1” or “true”, forces Interactive SSH collection for the device, bypassing checks.No

Migration from Legacy LogicModules

The following vendor-specific ConfigSources have been deprecated in favor of Common Configs, which is the supported approach for network device Configuration Monitoring. If you are currently monitoring configs using any of these legacy ConfigSources, you will not experience data loss upon importing the new modules. However, you will collect duplicate data and receive duplicate alerts for as long as both sets of ConfigSources are active. For this reason, LogicMonitor recommends that you disable the legacy ConfigSources after importing the new set of ConfigSources and confirm that they are working as intended in your environment. Common Config monitoring provides a more reliable method for collection of generic or general purpose configs through existing stable collection types. However, LogicMonitor recognizes that there are devices with special circumstances that may require a more traditional approach.

  • Arista_EOS
  • Aruba_WirelessController
  • Cisco_IOS
  • Cisco_NXOS
  • Cisco_Viptela
  • Cisco_WLC_RunningConfig
  • Cisco_WLC_SystemConfigs
  • Citrix_Netscaler
  • Dell_Networking
  • Fortinet_FortiOS
  • HPE_Network_Config
  • Juniper_JUNOS
  • PaloAlto_FW_CLIConfigs

Note: When a ConfigSource is disabled, it stops querying the host and generating alerts, but maintains all historical data. You may delete the legacy DataSources altogether, but consider this carefully as all historical data will be lost. For more information on disabling DataSources, see Disabling Monitoring for a DataSource or Instance.

Common Config Checks and Active Discovery

The Common Config modules use a series of checks to identify the most reliable collection method. The initial application can take up to 48 hours to complete. You can force Active Discovery for a device to speed up this process if faster results are required. For more information, see What is Active Discovery.

Config Metrics DataSource

This suite of modules provides a DataSource (LogicMonitor_ConfigSource_Metrics) to monitor its execution. Once instances have been created, this module can be used to identify and diagnose issues such as collection times close to or exceeding timeout, config sizes larger than configured limits, and sporadic collection. If you experience issues with config monitoring, LogicMonitor recommends that you look at this DataSource during troubleshooting to verify whether the issue relates to any of these metrics monitored.

Troubleshooting

Collection Preference for Common Config Monitoring

The collection preference is indicated by the number included in the ConfigCheck module names, with 1 being the most preferred collection method, displayed in the following:

  • ConfigCheck_1_SFTP
  • ConfigCheck_2_SCP
  • ConfigCheck_3_Exec
  • ConfigCheck_4_Interactive
  • ConfigCheck_5_Telnet

Permission Issues

Collecting configuration differences with a ConfigSource requires that the account used has permission to run all commands that are required to collect uninterrupted config data. Disabling paging on a resource is sometimes required when LogicMonitor cannot automate paging in a standard way.

Note:If configuration difference collection no longer works, the size may have grown and you may be seeing the effects of non standard pagination.

Paging Failures

Interactive SSH, SSH Exec, and Telnet based ConfigSources contain best effort methods to handle paging, but paging failures can occur on some resources preventing collection of configuration differences.

Recommendation: Disable paging if telnet, ssh or ssh exec protocols are used.

If collection does not work, or fails when the resource starts paging to collect configuration differences, then standard paging is not compatible and a custom property is required.

If configuration collection does not work without adding formatting commands to a custom property, do the following to mitigate the failures: 

  • Log in to the resource using the credentials assigned to the resource from the collector monitoring. This ensures there is no communication access issue.
  • Run all the commands needed to collect the config uninterrupted by paging. Then, add all those required commands to a custom property on the resource, adding those commands to the config.commands.formatting resource property.
  • The credentials used must have permissions to run all commands that are in the config.commands.formatting property.

Cisco WLC 9800 Scenario

If SFTP/SCP based collection is not possible then to avoid paging and timeout issues you must enter custom commands into the config.commands.formatting property. To disable paging, complete the following post-login steps after commands are run:

Recommendation: These commands may have security implications that you should consider before proceeding. Use SFTP/SCP collection when possible over SSH, SSH EXEC, or Telnet config difference collection to avoid potential security implications.

  1. Execute a custom formatting command sourced from config.commands.formatting. This command should adjust the user’s permission level to enable them to disable paging. For instance, if the initial command fails, use enable 15.
  2. Execute the following command to disable paging. You can use either terminal length 0 or config paging disable.
  3. Switch the user mode to one with sufficient permissions to view the configuration. For example, Cisco IOS 17.6 or later requires privileged exec mode to disable paging. Ensure the configuration is collected using the command “show running-config” from the privileged exec (#) prompt, not the non-privileged exec (>) prompt.
  4. After collecting the configuration, revert the resource settings to their original state. If necessary, adjust the permission level from 15 to a lower value. If paging needs to be re-enabled due to other account requirements, add a command for this in the custom property. Use a dedicated monitoring account unused by regular users, and leverage the most restrictive yet functional permission settings.

Global Settings

When using SSH, SSH exec, or Telnet, configuring global settings may be necessary (for example, disabling paging from privileged exec mode). If global settings are changed, consider reverting them after collection, especially if other users access the interface. For example, if a user disables “terminal length 0” using SSH or Telnet, collection might fail unless LogicMonitor consistently sets it during each collection using the configured list of commands that are run from the config.commands.formatting resource property.

Recommendation: Some resources such as a Cisco WLC 9800 require global settings to be changed for collection to complete in some cases. Avoid toggling between global settings to complete collections when possible.

LogicModules in Package

LogicMonitor’s package for Common Configs consists of the following LogicModules. For full coverage, please ensure that all of these LogicModules are imported into your LogicMonitor platform. At any given time, only one set of ConfigSources from the below list will apply to a device, calculated automatically via the listed PropertySources (unless overridden). For more information, see Module Installation.

Display NameTypeDescription
Config MetricsDataSourceMetrics on collection success and failure.
ConfigCheck_1_SFTPPropertySourceSets auto.config.type.sftp if collection is possible via SFTP.
ConfigCheck_2_SCPPropertySourceSets auto.config.type.scp if collection is possible via SCP.
ConfigCheck_3_ExecPropertySourceSets auto.config.type.exec if collection is possible via SSH Exec.
ConfigCheck_4_InteractivePropertySourceSets auto.config.type.interactive if collection is possible via Interactive SSH.
ConfigCheck_5_TelnetPropertySourceSets auto.config.type.telnet if collection is possible via Interactive Telnet.
Config_Arista_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Aruba_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Brocade_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Cisco_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful. Currently will only apply to devices where config.beta is set to 1, or previous Cisco common configs have been collected.
Config_Fortinet_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_HPE_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Juniper_GenericPropertySourceChecks for SSH compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Netscaler_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_PaloAlto_GenericPropertySourceChecks for SSHJ compatibility with a device and sets the relevant properties for modules to collect if successful.
Config_Sophos_GenericPropertySourceChecks for SSH compatibility with a device and sets the relevant properties for modules to collect if successful.
Dynamic Configs (SCP)ConfigSourceCommon module for handling generic SCP config collection. Dynamic configs are set to not alert on change by default.
Dynamic Configs (SFTP)ConfigSourceCommon module for handling generic SFTP config collection. Dynamic configs are set to not alert on change by default.
Dynamic Configs (SSH Exec)ConfigSourceCommon module for handling generic SSH EXEC config collection. Dynamic configs are set to not alert on change by default.
Dynamic Configs (SSH Interactive)ConfigSourceCommon module for handling generic SSH Interactive config collection. Dynamic configs are set to not alert on change by default.
Dynamic Configs (Telnet)ConfigSourceCommon module for handling generic Telnet Interactive config collection. Dynamic configs are set to not alert on change by default.
Standard Configs (SCP)ConfigSourceCommon module for handling generic SCP config collection. These configs will alert on a non-filtered change.
Standard Configs (SFTP)ConfigSourceCommon module for handling generic SFTP config collection. These configs will alert on a non-filtered change.
Standard Configs (SSH Exec)ConfigSourceCommon module for handling generic SSH EXEC config collection. These configs will alert on a non-filtered change.
Standard Configs (SSH Interactive)ConfigSourceCommon module for handling generic SSH Interactive config collection. Dynamic configs are set to not alert on change by default.
Standard Configs (Telnet Interactive)ConfigSourceCommon module for handling generic Telnet Interactive config collection. Dynamic configs are set to not alert on change by default.

Note: The ConfigSources in this package are configured to alert based on whether a config is classed as “Standard” or “Dynamic”. Dynamic configs are expected to change frequently and therefore do not alert on change. If necessary, we encourage you to adjust these predefined thresholds to meet the unique needs of your environment. For more information on tuning datapoint thresholds, see Tuning Static Thresholds for Datapoints.

In This Article