Since a child object or group is linked to the actual interface on a switch, why would one ever create a dependency between a parent node rather than the interface?
What purpose would this serve?
Thanks.
bump. Anyone?
Here's how I see it, and how I'm rolling it out.
Top-Level Container.. in my case, it's a group named for the parent identifier (In my case, a numeric 5-6 digit number).
Under that, one container per device.
Under that, a dynamic query that grabs all interfaces, something along the lines of "select * from interfaces where Nodes.Caption like '$Caption', if you get my drift.
I'm then creating a dependency with the device as a parent and the device-specific group has that single dynamic query..
In a lot of cases, things aren't tied to a physical interface (or channelized VT), but in some they are. Let's take a simple one, single PPP interface.
For single T1, this case might be meaningful, but the physical port status on the edge isn't as relevant. In a lot of cases, it's a pair of physical interfaces, that don't really go down. If one drops, the other picks up. In the case of simple multi-link PPP, the device doesn't go down, so I don't necessarily want to set the group's status to unreachable, it's simply not true.
Back to the single PPP or ethernet switch interface scenario.
I'd set the group up the way I outlined, and create a dependency to make the parent the device, make it's interfaces children.
The next thing I'd do is add a new dependency, making the interface the parent, and the child the previous group's parent.
You may need to make both the previous group and the parent children of the interface, I haven't fully tested this scenario yet, but I expect to in the next week or two.
That way, if the switchport is down, it sets all of the child nodes and interfaces to unreachable, and if you're alerts are configured to ignore the unreachable status, you will only get a single email about the switchport. The group status pages should show the top level group containers, and anything with sub-groups in non-optimal state will report as you have the groups configured.
I believe that groups are going to radically change the way we view the network as a whole, and radically enhance the signal to noise ratio coming from the alerting mechanisms. There is allegedly no limit to the parent-child relationships and groups of groups. The goal, of course, is to logically create a structure based on your topology, which is something only you can really determine. I think the single biggest problems right now (and I'm not just talking about you) is the general lack of understanding of just how far-reaching this new feature is, and how it's going to revolutionize the way people use the product.
My wishlist item is to be able to see related events, syslog, traps, and be able to punch up related graphs from disparate elements on the group status page. I envision a time when the Summary page gets replaced by the Groups page, and it provides a massively refined targeted view of a given customer's topology in a single unified view.
All in all, I'm excited to use this feature to it's maximum benefit, and keep pushing the envelope ( and Product Development) to make it even better.
Peter
