• Post Reply Bookmark Topic Watch Topic
  • New Topic

Can SNMP manager poll multiple agents concurrently?  RSS feed

 
Simon Reeves
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I require to send get requests to several snmp agents from a client process.

I have implemented client/agent based on below urls
http://www.jitendrazaa.com/blog/java/snmp/create-snmp-client-in-java-using-snmp4j/
http://www.jitendrazaa.com/blog/java/snmp/creating-snmp-agent-server-in-java-using-snmp4j/

I would like to know whether the client/manager can send requests to the agents concurrently? (e.g. using background threads within the process)
or whether it would be necessary to poll each agent individually?

From the samples,
CommunityTarget has address set as udp:127.0.0.1/161 - which is then used in the snmp 'get' request.
The agent has address set as 0.0.0.0/2001 - which is used when creating TransportMappings.

I don't understand how the addressing is working / how I would configure to handle agents at other/non local IP addresses?
 
Henry Wong
author
Sheriff
Posts: 23282
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simon Reeves wrote:
I don't understand how the addressing is working / how I would configure to handle agents at other/non local IP addresses?


I don't know the innards of SNMP to answer the main question, but I can answer the IP address one...

The address "127.0.0.1" should be your loopback address. All machines have a NIC (network interface card) for the loopback at this address (or slight variant of the last octet). Obviously, this card is a virtual "card". A receiver can listen to this address like it would listen on any NIC. Likewise, a sender can send to this address like it can to any address..... and finally, of course, the sender and receiver has to be on the same machine to work, as this is a loopback network.

The address "0.0.0.0" is ... well, is interesting. On the receive side, it is basically listening on *all* of the NICs. Any UDP packet on that port, coming from any NIC will be received.  And on the send side, basically, the OS is choosing which NIC to send to. In general, the OS will likely choose the NIC to get to the default gateway.  Regardless, I don't like this networking feature. The OS may choose the correct NIC, and may do so for years, then something changes (that is not related to your program), and it no longer works.  I highly recommend to never let the OS choose your NIC for any configuration.


So... to answer your "non local IP" question; On the receive side, you need to choose the IP address for the NIC that you want to use. This may not be as easy as it sounds, as there may be multiple NICs on the box. On the send side, you also need to choose the IP address for the NIC that you want to use. Again, possible multiple NICs, and you need to choose the correct one.

Additionally, on the send side, you need to choose the IP address that you want to connect to (to get to the receive side) ... and if there is a route from sender to receiver, it will work.

I know this sounds a bit vague, but we don't know your configuration -- so we don't know which NICs are correct, and whether there is actually a route between the two machines.

Henry
 
Tim Holloway
Bartender
Posts: 18663
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fortunately, I do know SNMP. I've a client in Romania who periodically taps me to do SNMP stuff for him, although I'm using C, not Java. It runs on the Raspberry Pi.

The master agent on a machine (whether real or virtual) is generally set up to listen on one or more NICs at UDP port 161. Servers like net-snmp can talk via an internal channel to additional (possibly user-defined) sub-agents, so that everything appears to come from the same place - your remote client doesn't need to query a separate port and/or IP address for each user-defined agent.

I'm thinking that net-snmp can now support other protocols besides UDP, but I'd have to go back and check. At any rate, the traditional approach is that a client polls the SNMP server to get one or more MIBs back. Like HTTP, it's a request/response operation, but since it's UDP, no connection is established - they just blast packets back and forth.

You can certainly poll more than one agent host at a time, since the request doesn't wait for a response and the responses all have source IP/port information in them. So no problem there, as long as you pay attention to what came from where.

You can also set up SNMP traps, which blast packets out to listener hosts without being solicited first. That's lower overhead for monitoring-by exception, but at last count, it wasn't possible to register listeners on the fly. You had to put the address and port information of each listener into the net-snmp config file and restart before a listener could be notified.
 
Simon Reeves
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thank you for helpful response.
I am using snmp4j.
would you be able to answer the following.
I've submitted a couple of other posts.

i.e.
How should an snmp client receive responses from multiple snmp agents?
How poll multiple devices using synchronous requests at a periodic interval?

Would you be able to clarify:
Is it possible to send requests using different CommunityTargets (am not fully sure meaning of CommunityTarget) from same client process / using same TransportMapping
and listen() call?
I am using the synchronous snmp requests (e.g. send, get) - Are there any problems if I send requests/receive responses for each device from separate threads? 
(I believe the threads would listen on the same port (listen() method) and was wondering if there might be issues relating to this, for example).
I assume this would be quicker than polling devices sequentially.

Thank you
Simon
 
Tim Holloway
Bartender
Posts: 18663
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It has been a long time since anyone paid me to work with snmp in Java and the snmp4j package is a complex one, so I cannot give detailed information, but I think I can give some general advice.

First, a community ID is assigned to each individual SNMP server. I think that it was originally intended as a low-grade security mechanism, since you have to provide the right ID to get a response, but usually the community ID is "public", In SNMPv2 and later, better security mechanisms were devised.

You can set up a listener that can be used asynchronously with multiple concurrent requests to multiple remote agents. When an agent response is received, the listener dispatches an event to its handler. That event contains the request and its corresponding response.

The listener runs on its own internal thread. You do not have to spawn individual threads for each separate request.
 
Simon Reeves
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Many thanks for reply.
May I ask one more qn?
There is synchronous and asynchronous snmp managers. I am using the synchronous api (since it's already being used)
and was going to place the send/get requests in to separate threads, using a timer, so that I didn't have
to synchronously loop round polling the 20 or so devices, since it would take longer to receive responses from devices etc.
Am I right in thinking that sending a snmp synchronous request from 1 thread shall not block the synchronous request from
another thread? i.e. they can be sent concurrently?
Thank you
 
Tim Holloway
Bartender
Posts: 18663
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Threads are blocked when they explicitly request to wait on something or when higher-priority threads consume resources necessary for that thread to run. In the case of multiple request threads, that would not normally be an issue.

The asynchronous protocol is a lot more efficient, however. Threads have overhead and the more threads, the more overhead. A single asynchronous listener has very little overhead.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!