in reply to Re: Net::SNMP get_request() caching results?
in thread Net::SNMP get_request() caching results?

Thanks for the reply c and I understand your confusion. It's not easy to explain without giving the entire code and having a go at it and there's a lot more code than that.

The whole jist of it is I'm running snmp commands on routers on our network. So, I define a session for a router by it's ip and then I run the snmp commands. (On the same $session that was defined.) So, if I have 4 snmp commands to run on that same ip, I run them in a loop using the same SNMP session that was defined. Well, when I get a response that is an error like not being able to resolve the name or some kind of other error, the error never seems to clear. Even though I set $response as undef, the get_request() seems to not reset for that particular ip on the next go around, until I kill the script and re-run it.

Thanks again for your reply.
  • Comment on Re: Re: Net::SNMP get_request() caching results?

Replies are listed 'Best First'.
Re: Re: Re: Net::SNMP get_request() caching results?
by c (Hermit) on Nov 08, 2001 at 18:26 UTC
    Everything you're saying sounds *really* familiar to me. I've written a utility that runs against routers using net::snmp. The script that is in the code section of the website isnt the most up to date, so I've gone through a few revisions since I posted. The most current one is here. Not sure if it could be of any insight, but I would imagine that I've faced some of your hurdles as well.

    I think I have a bit clearer view of what you're doing now with the loop. Does it just fail for this one remote node? And is the failure the result of the script not being able to resolve the node name to an ip address or is it a timeout general?

    humbly -c

[reply]
      On a side note, in looking at this utility, it looks pretty cool except that SNMP v3 still isnt completely baked into Net::SNMP and therefore using your utility with SNMP v1 or SNMP v2 would be *very* hazardous, as read/write community strings would be passed in plain-text over the network.
[reply]
        yeah, you're right on about that. RW strings can post a threat in an unsecured network. luckily cisco provides some pretty good methods for locking down snmp access to its devices to allow access to only certain nodes.

        humbly -c

[reply]
      You're exactly right, the error happens on one remote node. So, say node 100 with ip 192.168.1.101 has 10 snmp commands run against it, well if there is one error on all snmp commands, the error will stay. Even though I'm destroying the snmp session and starting a new one, for the node will fail no matter how many commands I have to run.

      Here's the error from the snmp object that I usually receive...

      No response from remote host '192.168.1.101'

      This has happened using a URL or a straight ip like above. So, it doesn't seem to be a timeout, it looks like it *thinks* it can't hit it, when I try telnetting into the router and everything is fine, it just got stuck again. hmmm.....
[reply]
        That error response is one that I constantly see, however its usually comes up when either something is blocking the actual packets from getting through to the remote host. I would ask if it were possibly caused by sending an oid to the remote device that required a RW string and only a RO was configured, but I *think* that would produce a different error response.

        Have you tried running each of the snmp commands individually against the remote host to see if you can find one in particular that times out against it, or if its the host in general?

        humbly -c

[reply]

In Section Seekers of Perl Wisdom