11 Replies Latest reply: Nov 29, 2010 8:45 AM by Karlo.Zatylny RSS

Nested Dependency Clarification

Greetings All!!

So the feature I've been looking forward to the most has finally arrived.  However, I must admit to being a little confused on how nesting is going to work.  For example.  Lets say I have 3 sites:

<Site A> --- <Site B> --- <Site C>

In this example, I really need to be able to create a one-to-many type of Parent/Child dependency.  Lets say I have 5 devices at Site B, a router and 4 switches.  And I have 5 devices at Site C, a router and 4 switches.  SiteBRouter needs to be the parent for SiteBSwitches as well as the parent for SiteCRouter.  And then SiteCRouter needs to be the parent for SiteCSwitches.  And obviously, if SiteA router goes down, I don't want to get alerts from any of the other devices.

So I think the only way I can pull this off is by create a parent/child from SiteARouter to SiteBRouter (nodes). Create a group named SiteBDevices and make SiteBRouter the parent of SiteBDevices.  Then a node-node between SiteBRouter and SiteCRouter.  And lastly create another group called SiteCDevices and make it a child of SiteCRouter.

Am I understanding this correctly?  Is there a better way to do this?

 
  • Re: Nested Dependency Clarification
    Karlo.Zatylny

    Hi,

    Let me see if I understand your network topology and suggest a way to do this.  See my picture below.

     

    I have shown what I think your network topology is.  The lines are direct network connections.  To create dependencies in the fewest relationships possible I would create three Groups in Orion based on the colored rectangles.

    Then I would have the following Dependencies:

    Parent                                         Child

    Site A Router Node                 Green Node Group

    Site B Router Node                 Yellow Node Group

    Site C Router Node                 Blue Node Group

    With these dependencies, if Router A goes Down, then all nodes in the green, yellow and blue groups will become Unreachable.

    If Router B goes Down, all the nodes in the yellow and blue groups become Unreachable.

    If Router C goes Down, all the nodes in the blue group become Unreachable.

    You can, of course, accomplish this same functionality in other ways by creating different groups and dependencies. You could also make more specific dependencies based on interfaces a nodes so that if a specific interface goes down on Router A then Router B is Unreachable, etc.

    Note you don't want to nest these groups (see my conversation Groups Error when nesting Node Groups)

    Let me know if this looks right.  I think what you described would work, too.

    • Re: Nested Dependency Clarification

      I liked the demonstration of Karlo up there a lot, and i have a question myself.

      I will ask my question as if it was on the topology demonstrated above. Now if i have advanced alerts set to alert me whenever a node goes down, any node. And i configured dependencies as shown above. If Site B router goes down, will that make that group down? I suppose it will if i chose the 'Show Worst Status" Option.

      Okay, if i did that, and then I have Router B down and that group is down, Site B switches went down, and i didn't change anything in my alerts configuration, will it automatically understand that since the site B switches are a member of a group that is a child of a group that is down, and it won't send the alerts? Or do i have to configure the alerts based as the groups as well?

      • Re: Nested Dependency Clarification
        Karlo.Zatylny

        Hi,

        Group alerts are separate from Node alerts.  A down group will not fire the advanced alert for down nodes.  In your first scenario, you would get an alert for the Site B Router.  Your group would also show down as well if configured to show worst status.  However, the nodes in that group will still be up and you would just need to react to the one down node.

        If Router B goes down and consequently site B switches (and Site C Router and site C switches) will go to unreachable.  In this case, you will only receive one alert for the Site B Router.  If you create a new advanced alert to let you know when a group is down then and only then would you receive an alert that the Green Group is down (assuming Worst Status roll up).  So you would then receive two alerts when the Site B Router is down as all the other nodes would be unreachable downstream and would not trigger the alerts.  Likewise, the yellow and blue groups would be in the unreachable status and not trigger the alerts.

        Does that make sense?

        • Re: Nested Dependency Clarification

           

          Okay, i just want to make sure i got it all right here. I do not want to receive an alert to tell me that the group went down. I have an alert set up from before the upgrade to tell me when any node goes down. I want to when router B goes down, receive an alert for it, and not for all the other nodes dependent on it.

          So does configuring groups and dependencies as shown above work enough as a suppression on the already existing alerts, and i will only receive an alert for router B?

          I mean does NPM detect the group settings and dependencies before triggering the node (not group) alerts?

          Also, this means that the way i configure the status roll up of the group will affect the alerts. I mean if i have a group for the green part and i did not choose the 'show worst status' option and router B went down but site A switches were still up so i will still receive alerts on the dependent nodes of the yellow and blue groups. Am I right?

           

          • Re: Nested Dependency Clarification
            Karlo.Zatylny


             

            So does configuring groups and dependencies as shown above work enough as a suppression on the already existing alerts, and i will only receive an alert for router B?

            I mean does NPM detect the group settings and dependencies before triggering the node (not group) alerts?

            Also, this means that the way i configure the status roll up of the group will affect the alerts. I mean if i have a group for the green part and i did not choose the 'show worst status' option and router B went down but site A switches were still up so i will still receive alerts on the dependent nodes of the yellow and blue groups. Am I right?

             



            1. Yes.  With the default down node alert, unreachable nodes will not trigger that alert and you will receive only the router B alert.

            2. Yes and no.  NPM in real time will check the dependencies and set a down node to unreachable such that the down status will never hit the database and neither an advanced nor basic alert will trigger on that node.  The group settings like status roll up are only considered if the parent in a dependency is a group, not if the parent in a dependency is in a group or groups.  The nodes in the Yellow group at run time will check if Router B is down and do not care that Router B is in the Green group as that is not important in their relationship.

            3.  No.  Look at my post above again.  The parent of the Yellow Group is only Router B not the Green Group.  Thus the roll up status setting of the Green Group does not affect the way the dependency between the Yellow Group and their parent, Router B.  With the dependencies set as outlined you will only receive one down node alert when Router B goes down.

            Hopefully this clarifies things a little.  If not, I can answer more questions :)

  • Re: Nested Dependency Clarification
    dclick

    I have a very similar config, and would be interested in seeing how this plays out.

  • Re: Nested Dependency Clarification

    Karlo's understanding is correct.  And I think I'm going to set my environment up this way and it will work fine.

    Just a suggestion from my perspective.  I come from a nagios background, and this was so simple in nagios.  All I had to do was go to the child node, there was a field labeled parent, and I would simply type the name of the parent node there.

    What Karlo suggests will definitely work for me.  It just isn't quite as intuitive as I think it could be.

    Thanks,

    Russ