Interfaces are already dependent on their parent node by default, but something the timing of polling intervals can cause some to slip through and get alerted if SW happens to notice the interface is down earlier than it polls the node.
For your second scenario it would require both sides of the connection to have their topology monitoring enabled/working and a custom SWQL/SQL alert to join them across. When I've done things like this you have to decide which side to suppress so I just always trigger the alert on the one with the lower NodeID when I find a relationship.
thanks for sharing this input , so you mean to say , the first step would be the rare case and depending on the polling intervals right ?
Secondly , the enabled and working status should joined them across and then to be decide which side to be suppress right ? in this case you mean to say lower node id means ?
In the database the identifier column fo nodes is called nodeid, it just increments as things are added to the system. So for me to decide which side of the connecting I alert on and which side I suppres I would just do a min(nodeid) in my query and whichever one is lowest will alert. You could get more specific but that's quick and works everywhere
thanks for the details Let me validate this.
Do you have any reference SWQL /SQL script to validate this ?
Also , for desiding the side factor which column/field that you are matching ??
This strikes me as a workable problem, but also something where the odds are you'd make a big hole in monitoring by accident
If you are doing these at the point of alerting, i'd do 2) as a Node-level alert not an interface one, so that I could group together parent interfaces WHERE (Connection), at least first
