Forum Discussion

Santiago_Moneta's avatar
8 years ago

checl cisco devices for error disabled ports

Hi everyone, I'm working on getting my Cisco switches monitored and found that I cannot see, at least by default, to logic monitor to alert me when a port is on "error disabled" mode. I found this KB but I'm not sure how to actually create the event that it mentions, may I ask the community for some help?

This is the KB I found: https://www.logicmonitor.com/support/monitoring/networking-firewalls/cisco-port-errdisabled/

 

Thanks!

  • We have an eventsource for this, originally provided by LM support and tuned a bit since then.  It requires SSH access to devices since Cisco lacks a MIB for detecting errdisabled ports (at least in the general case).  This in turn means you must be very careful about deploying the eventsource since defining ssh.user/ssh.pass would otherwise bring other things into scope you may not want, like LMConfig (we added an alternate name format to control for that). Lastly, since it is an eventsource you cannot practically acknowledge issues.  If you used syslog integration with LM (we do not as it is too limited), you could perhaps feed device logs to the collector and detect them that way without SSH. Another option would be use the same logic as the eventsource and create a datasource, generating datapoint values based on the errdisable cause picked up from the command. 

    I just published what we have now as H4T9GH. Since it is in Groovy, it will need to be reviewed.

  • On 11/29/2017 at 8:48 AM, Santiago Moneta said:

    Hi everyone, I'm working on getting my Cisco switches monitored and found that I cannot see, at least by default, to logic monitor to alert me when a port is on "error disabled" mode. I found this KB but I'm not sure how to actually create the event that it mentions, may I ask the community for some help?

    This is the KB I found: https://www.logicmonitor.com/support/monitoring/networking-firewalls/cisco-port-errdisabled/

     

    Thanks!

     

    I am also looking for the same information. The link you previously provided is no longer working. 

    This was posted in 2017, so hoping someone has an answer now.

    Thanks,

    Josh

  • On 8/31/2020 at 10:42 AM, mnagel said:

    We have an eventsource for this, originally provided by LM support and tuned a bit since then.  It requires SSH access to devices since Cisco lacks a MIB for detecting errdisabled ports (at least in the general case).  This in turn means you must be very careful about deploying the eventsource since defining ssh.user/ssh.pass would otherwise bring other things into scope you may not want, like LMConfig (we added an alternate name format to control for that). Lastly, since it is an eventsource you cannot practically acknowledge issues.  If you used syslog integration with LM (we do not as it is too limited), you could perhaps feed device logs to the collector and detect them that way without SSH. Another option would be use the same logic as the eventsource and create a datasource, generating datapoint values based on the errdisable cause picked up from the command. 

    I just published what we have now as H4T9GH. Since it is in Groovy, it will need to be reviewed.

     

    Thank you for the info. I don't believe I would be comfortable adding the SSH info to our system, just too big of a security issue and the err-disabled status problems we see are few and far between. 

    We do have a syslog upgrade in place, so i'll investigate that option going forward. Appreciate the response.

    Josh B.

  • 18 minutes ago, jbibler said:

     

    Thank you for the info. I don't believe I would be comfortable adding the SSH info to our system, just too big of a security issue and the err-disabled status problems we see are few and far between. 

    We do have a syslog upgrade in place, so i'll investigate that option going forward. Appreciate the response.

    Josh B.

    It is possible via various methods to setup a limited access read-only account, which we generally try to do, but understood completely regardless. To the extent LM relies on SSH it has been problematic on our systems for various reasons (inadvertently enabling LMConfig is one, lack of public key support is another).