Problem:
Log Analyzer cannot create alerts for each individual "instance". An option to use a varbind as a "discriminator" would allow for unique alerts per instance, and also for resets to apply to that instance only.
Examples of instances that might generate alerts are BGP neighbors, EIGRP neighbors, Cisco FRUs, interfaces, etc.
Problem Example:
A BGP neighbor goes down on a router. The trap below is received. A Log Analyzer rule fires, tags the trap, and sends an Alert to NPM. NPM raises an alert. Two minutes later a second BGP peer goes down. Log Analyzer again tags the trap and sends the alert to NPM. NPM does not raise a new alert because the old alert is already active.
Currently there is no way to generate an alert for each "instance" (in this case, BGP neighbors). If a neighbor comes back up, there is no way to automatically clear the alert for that instance only.
TrapOid
1.3.6.1.4.1.9.9.187.0.1
VARBINDS
sysUpTime (1.3.6.1.2.1.1.3.0)
13 days 16 hours 39 minutes 25.04 seconds
bgpPeerLastError.172.18.0.65 (1.3.6.1.2.1.15.3.1.14.172.18.0.65)
bgpPeerState.172.18.0.65 (1.3.6.1.2.1.15.3.1.2.172.18.0.65)
established(6)
cbgpPeerLastErrorTxt.172.18.0.65 (1.3.6.1.4.1.9.9.187.1.2.1.1.7.172.18.0.65)
empty value
cbgpPeerPrevState.172.18.0.65 (1.3.6.1.4.1.9.9.187.1.2.1.1.8.172.18.0.65)
openconfirm(5)
TrapType
CISCO-BGP4-MIB:cbgpFsmStateChange
Potential Solution:
If we could indicate that each unique value in the varbind "bgpPeerLastError" represented a different bgp peer, that would allow us to get a different alert for each peer going down, as well as clear the alert when the peer came back up.
CA Spectrum is one example of an NMS that has this functionality.
Top Comments