Forum Discussion
Yes, it is truly annoying and really got my clients mad until I devised a solution using policy-driven API script. The policy is defined by a few properties that indicate which ports should be monitored and which should have alerts set (we base this on the interface description). I run it hourly, but it could be run as frequently as desired. I find more and more that LM is not really awesome at real-life monitoring requirements out of the box (e.g., stuff like this or the fact that ACKs are permanent, etc.), but thankfully the API is flexible enough to make it do the right thing! Here are my internal notes on the interface monitoring script:
Device Properties
The device properties leveraged to define which interfaces have monitoring or alerting active are as follows:
Property | Value | Purpose |
wm.intf.desc.alert | regular expression | enable alerting if desc matches RE |
wm.intf.desc.noalert | regular expression | disable alerting if desc matches RE |
wm.intf.desc.monitor | regular expression | enable monitoring if desc matches RE |
wm.intf.desc.nomonitor | regular expression | disable monitoring if desc matches RE |
wm.intf.email.label | email addresses (comma-separated) | send change notice to all in-scope email addresses |
The logic applied to matching the interface description is alert then noalert and monitor then nomonitor. Any in-scope property can be set to the word null to cause the property to be ignored at that inheritance level.
For email, the idea is that each level can introduce a new and additive set of targets, hence the label. If only a single 'default' label is used, then each layer defines the overall set of email targets to be notified about port changes.
The default values for these properties (defined in the root of the device tree) are:
Property | Value |
wm.intf.desc.alert | .+ |
wm.intf.desc.noalert | ^# |
wm.intf.desc.monitor | .* |
In English, this means:
- monitor all ports
- alert on any port that has a label, except if that port's label begins with a '#' symbol
Regards,
Mark
Related Content
- 2 years ago