Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-12169

User provisions nodes with SNMP profiles in place

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 25.0.0
    • Fix Version/s: 25.0.0
    • Security Level: Default (Default Security Scheme)
    • Labels:
      None

      Description

      This story references actors and information laid out in NMS-12168 and NMS-12168.

      Werner has configured SNMP access profiles according to the rules he knows for his large IP network. Now it's time for him to provision some nodes. He will do this in two ways: auto-provisioning and requisition-driven provisioning.

      The first batch of nodes will be provisioned via newSuspect events which could result from the use of discovery or from another mechanism such as Trapd's new-suspect-on-trap configuration option being switched on. The source of the events is unimportant, but for this story we assume that they are trap-derived.

      A newSuspect arrives from IP address 10.20.30.40, whose reverse DNS PTR record indicates a hostname of sw01.lab.example.com. Provisiond invokes the SNMP Fitter code, which looks at each configured SNMP access profile in turn, leading to the following decision tree:

      • The first profile, "Copenhagen", has an empty expression field, so we should try the profile against this address.
        • The agent does not respond within the configured timeout / retry to a GET-REQUEST for sysObjectID.0 using the protocol parameters in the "Copenhagen" profile, so the fitter code moves to the next profile.
      • The second profile, "Vienna", also has an empty expression field, so we should try the profile against this address.
        • The second profile, "Vienna", does elicit a timely response to the same request described above, so the fitter code persists the "Vienna" protocol parameters to the SNMP Peer Factory, perhaps by building and sending a configureSNMP event.
          • The persistence is for only the singular IP address 10.20.30.4o for which this profile was found to be a fit. The fitter code does not concern itself with address ranges, only specific addresses. The SNMP Peer Factory has self-optimizing behavior which will take care of ranges as a convenient side effect.
        • The fitter signals to Provisiond the following facts about the IP address 10.20.30.40:
          • SNMP fitting has been performed, and succeeded at identifying a fit
            • I imagine that the OnmsIpInterfaCe record is the best place to store this information, but the implementer has total latitude if the information wants to live elsewhere.
          • This interface's snmp-primary field should have a value of P (primary)
        • Since the fitter has found a match, it stops evaluating SNMP access profiles. Provisiond moves on with whichever lifecycle phase naturally follows.

      Another newSuspect arrives for IP address 192.168.0.1, whose reverse PTR record indicates a hostname of fw03b.dmz.carlsberg.dk. As before, Provisiond activates the SNMP Fitter code, whose decision tree (briefly) goes:

      • The city-name profiles (Copenhagen, Vienna, Princeton, and Chapel Hill) are all tried, because, as before, their expression fields are empty, indicating they should always be tried in their natural order. Each city-name profile's protocol parameters fail to elicit a response to a GET-REQUEST for sysObjectID.0 within its specified timeout / retry parameters.
      • With the four city-name profiles exhausted and no fit found so far, the fitter code moves on to the next profile ("Niels"). That profile's expression field is not empty, so the fitter code evaluates the hostname of the address at hand against the profile's rule. The rule matches, so the fitter knows that it should make an attempt at fitting this profile to the IP address at hand.
      • The fitter performs a GET-REQUEST for sysObjectID.0 using the protocol parameters specified in the "Niels" profile. The agent responds within the profile's timeout / retry parameters.
      • The fitter signals to Provisiond that this IP address has been fitted, that fitting succeeded, and that the IP address should have snmp-primary="P".
      • The fitter persists the "Niels" profile's parameters to the SNMP Peer Factory for the IP address 192.168.0.1. The fitter also signals Provisiond the same set of facts about this interface as about the first interface (fitting done, fitting succeeded, snmp-primary = P)

      A third newSuspect arrives for IP address 172.20.20.32, whose PTR record indicates a hostname of whatever.exampe.com..

      • The fitter tries all four city-name profiles as before, but finds no fit. The fitter evaluates the expressions of all three given-name profiles for the hostname at hand, but none of the rules evaluates true. The fitter has now run out of profiles to try.
      • The fitter code signals to Provisiond that IP address 172.20.20.32 has had SNMP fitting done, and that no SNMP access profile fit was identified. The fitter code conveys no opinions about the interface's snmp-primary attribute.
      • The fitter code  returns control to Provisiond without communicating any information to the SNMP Peer Factory.

      Werner now provisions a node via a requisition. He adds an IP interface to the node with IP address 10.255.0.1, whose PTR record indicates a hostname of lb02.web.unc.edu. Decision tree summary:

      • The Copenhagen, Vienna, and Princeton profiles all fail to find a fit, but the Chapel Hill profile is a fit.
      • The fitter code communicates to Provisiond that this IP address has been fitted, that fitting was successful, and that it thinks the interface should have an snmp-primary value of "P". Doubt: is Provisiond obligated to do anything with the fitter's opinion about the interface's snmp-primary value, in the event it disagrees with the value in the requisition?
      • The fitter persists the parameters from the Chapel Hill profile to the SNMP Peer Factory for 10.255.0.1.
      • The fitter returns control to Provisiond.

      Epilogue: the next day, all the nodes provisioned above come due for a rescan. The fitter is invoked by Provisiond for each of the interfaces on these nodes, and must make a decision about whether to "re-fit" them. Decision tree summary:

      • 10.20.30.40 was successfully fitted before, so the fitter returns control to Provisiond without taking any action.
      • 192.168.0.1 was successfully fitted, so return control without taking any action.
      • 172.20.20.32 was unsuccessfully fitted, so the fitter treats it as it would an IP address it has never encountered before, starting at the top and working through all the profiles.
      • 10.255.0.1 was successfully fitted before, so return control with no action taken.

      Epilogue: three months later, 192.168.0.1 stops responding to SNMP operations, because the group responsible for it decides to change its preferred SNMP parameters. Werner needs a way to have OpenNMS forget that the IP address was ever fitted at all. Given how rare this situation is, providing a Karaf shell command to perform this task seems adequate. Imagined invocation: snmp:fit 192.168.0.1 --reset

       

        Attachments

          Activity

            People

            • Assignee:
              cgorantla Chandra Gorantla
              Reporter:
              jeffg Jeff Gehlbach
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: