SNMP integration with OCS agents and OCS server

[Guillaume PROTET]

Hi all,

As planned in the OCS Inventory roadmap, we started to integrate SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.

This how we plan to make it work using agents and server:

1) OCS server uses IPDISCOVER datas to determine which IP need to be enhanced using SNMP.

2) OCS server give the IP range to scan directly to the OCS agent using the prolog response (like we already do for package deployment).

3)OCS agent receive the order and start its process for scanning IP with SNMP. Agent will load several SNMP OID and SNMP communities that it knows to remeber it for the next steps.

4)OCS agent try to determine what is the community that use an IP by searching in every communities that it knows.

5)When the SNMP community found, Ocs agent run a standard subroutine (ip_run() for example) to find the OID of the peripheral associated to the IP.

6) If the OID found is specific, the OCS agent run a specific subroutine for this kind of peripheals (for example a specific subroutine for Cisco devices)

7)OCS agent feed the inventory XML by adding new informations about the scanned IP

...h(repeat point 4) to 7) for every IP specified by OCS server)


8)OCS agent send the feeded inventory XML to the server that will store new data in the MySQL database.


For the moment, we plan to integrate it in the Unix unified agent using the new hooks system which permit at the start of the agent run, at PROLOG time, at the PROLOG response time, at the inventory time and at the the end of the agent run.

What are your opinions about it ? All your ideas are welcome :) :).

Kind regards,

--
Guillaume

[Pascal DANEK]

Hi Guillaume.
Personally I would prefer to keep the SNMP data separated from the inventory request.
As the data could be virtually huge, and as the inventory request is already used for ipdiscover and registry capacities, I think that it would be better, with scalability in mind, and also to keep each request as light as possible, to send data through a dedicated request.
You can easily configure module to handle such request. This behaviour is presently used by download capacity and by real time ip updates feature (and probably others that I don't remember at the moment).
About the data model, I think there will be no problem to put it in Map.pm. Thus, feeding the database and export these new data in the web service will be quite simple.
Best regards.

--pascal

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent using the prolog response (like we already do for package deployment).
3)OCS agent receive the order and start its process for scanning IP with SNMP. Agent will load several SNMP OID and SNMP communities that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine (ip_run() for example) to find the OID of the peripheral associated to the IP.
6) If the OID found is specific, the OCS agent run a specific subroutine for this kind of peripheals (for example a specific subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent using the new hooks system which permit at the start of the agent run, at PROLOG time, at the PROLOG response time, at the inventory time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
--
Guillaume

[James Clendenan]

Hi Guillaume et all,

I'm new here, so my apologies initially if this is a silly question/
thought.

I am looking at using this technology as a service for a number of
small business clients, and would have a potential where their
internal IP ranges are non-unique, however they do have a number of
SNMP compatible printers (generally HP) that I would like to have
queried.

Would it be better to have the SNMP scan based on the MAC address of
the network device in question, rather than just the IP address which
won't be entirely unique for all networks?

I was thinking that the MAC address could be sent with the IP address,
and only scanned if the tuple is identical? A bit more work for keys
etc, but it might be safer than scanning random devices on the wrong
network by accident, especially for laptop deployed agents.

Just my 0.02$

James Clenenan

ps. reply on these e-mails doesn't seem to be working to reply to the
list.

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package deployment).
3)OCS agent receive the order and start its process for scanning IP
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine
(ip_run() for example) to find the OID of the peripheral associated
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
--
Guillaume

[Guillaume PROTET]

Hi James,

Yes you are right about using MAC adresses for SNMP scans and we will take a look to see if we can technically do it.

Thanks for your report about developers@ mailing list. We take a look to solve the problem.

Kind regards,

--
Guillaume


----- Mail original -----

Post by James Clendenan
Hi Guillaume et all,
I'm new here, so my apologies initially if this is a silly question/
thought.
I am looking at using this technology as a service for a number of
small business clients, and would have a potential where their
internal IP ranges are non-unique, however they do have a number of
SNMP compatible printers (generally HP) that I would like to have
queried.
Would it be better to have the SNMP scan based on the MAC address of
the network device in question, rather than just the IP address which
won't be entirely unique for all networks?
I was thinking that the MAC address could be sent with the IP address,
and only scanned if the tuple is identical? A bit more work for keys
etc, but it might be safer than scanning random devices on the wrong
network by accident, especially for laptop deployed agents.
Just my 0.02$
James Clenenan
ps. reply on these e-mails doesn't seem to be working to reply to the
list.

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be
enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package
deployment).
3)OCS agent receive the order and start its process for scanning IP
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine
(ip_run() for example) to find the OID of the peripheral associated
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
-- Guillaume

[Francois Mermet]

Hi James,

It's a good idea for the mac adress but there is a problem: the snmp commands acces use only the ip address. I don't know how to resolve this problem. If some one have one, tell me it please.

For the printer, they can be detected with SNMP if only this printer can respond on snmp query.
It depend of the printer capabilitys.

Thanks

Dwizz




________________________________
De : Guillaume PROTET <guillaume.protet-Q/0Kkk6T+***@public.gmane.org>
À : developers en <***@ocsinventory-ng.org>
Envoyé le : Ven 7 mai 2010, 15h 31min 13s
Objet : Re: SNMP integration with OCS agents and OCS server

Hi James,

Yes you are right about using MAC adresses for SNMP scans and we will take a look to see if we can technically do it.

Thanks for your report about developers@ mailing list. We take a look to solve the problem.

Kind regards,

--
Guillaume


----- Mail original -----

Post by James Clendenan
Hi Guillaume et all,
I'm new here, so my apologies initially if this is a silly question/
thought.
I am looking at using this technology as a service for a number of
small business clients, and would have a potential where their
internal IP ranges are non-unique, however they do have a number of
SNMP compatible printers (generally HP) that I would like to have
queried.
Would it be better to have the SNMP scan based on the MAC address of
the network device in question, rather than just the IP address which
won't be entirely unique for all networks?
I was thinking that the MAC address could be sent with the IP address,
and only scanned if the tuple is identical? A bit more work for keys
etc, but it might be safer than scanning random devices on the wrong
network by accident, especially for laptop deployed agents.
Just my 0.02$
James Clenenan
ps. reply on these e-mails doesn't seem to be working to reply to the
list.

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be
enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package
deployment).
3)OCS agent receive the order and start its process for scanning IP
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine
(ip_run() for example) to find the OID of the peripheral associated
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
-- Guillaume

[James Clendenan]

Hi Dwizz,

If you ping the device, the system will send an arp request and then
you can check the ARP table, you should get the MAC address of the
device. Once you have that, check to see that it matches the IP+MAC
for your expected device. If they do, then query with the IP
address. If they don't you're probably sitting on a network with a
duplicate IP range to the network with the device you want to query,
so go to the next device.

Net::ARP should do the trick for reading the arp table, but I'm not
sure how portable to windows it is.

Hope that makes sense. The reason I'm suggesting the MAC verification
is that I have a few devices that get really grumpy when queried, and
send admin's many e-mail alerts (APC power devices mostly) and would
cause a lot of random noise.

As for the printer, most HP's community string is "public" for things
with a jetdirect card in them, so I'm not to concerned about them not
responding, it's more the mixup between 2 identically numbered
networks, that could cause additional headache.

Thanks,

James

Post by Guillaume PROTET
Hi James,
It's a good idea for the mac adress but there is a problem: the snmp
commands acces use only the ip address. I don't know how to resolve
this problem. If some one have one, tell me it please.
For the printer, they can be detected with SNMP if only this printer
can respond on snmp query.
It depend of the printer capabilitys.
Thanks
Dwizz
Envoyé le : Ven 7 mai 2010, 15h 31min 13s
Objet : Re: SNMP integration with OCS agents and OCS server
Hi James,
Yes you are right about using MAC adresses for SNMP scans and we
will take a look to see if we can technically do it.
Kind regards,
--
Guillaume
----- Mail original -----

Post by James Clendenan
Hi Guillaume et all,
I'm new here, so my apologies initially if this is a silly question/
thought.
I am looking at using this technology as a service for a number of
small business clients, and would have a potential where their
internal IP ranges are non-unique, however they do have a number of
SNMP compatible printers (generally HP) that I would like to have
queried.
Would it be better to have the SNMP scan based on the MAC address of
the network device in question, rather than just the IP address

which

Post by James Clendenan
won't be entirely unique for all networks?
I was thinking that the MAC address could be sent with the IP

address,

Post by James Clendenan
and only scanned if the tuple is identical? A bit more work for keys
etc, but it might be safer than scanning random devices on the wrong
network by accident, especially for laptop deployed agents.
Just my 0.02$
James Clenenan
ps. reply on these e-mails doesn't seem to be working to reply to

the

Post by James Clendenan
list.

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER

using

Post by James Clendenan

Post by Guillaume PROTET
SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need

to be

Post by James Clendenan

Post by Guillaume PROTET
enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package
deployment).
3)OCS agent receive the order and start its process for scanning

IP

Post by James Clendenan

Post by Guillaume PROTET
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an

IP by

Post by James Clendenan

Post by Guillaume PROTET
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard

subroutine

Post by James Clendenan

Post by Guillaume PROTET
(ip_run() for example) to find the OID of the peripheral

associated

Post by James Clendenan

Post by Guillaume PROTET
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations

about

Post by James Clendenan

Post by Guillaume PROTET
the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are

welcome :) :).

Post by James Clendenan

Post by Guillaume PROTET
Kind regards,
-- Guillaume

[Pascal DANEK]

Maybe the improvement that will tie a discovered host with the scanner
id wiil help ?

Envoyé de mon mobile

Le 7 mai 2010 à 15:31, Guillaume PROTET

Post by Guillaume PROTET
Hi James,
Yes you are right about using MAC adresses for SNMP scans and we
will take a look to see if we can technically do it.
Kind regards,
--
Guillaume
----- Mail original -----

Post by James Clendenan
Hi Guillaume et all,
I'm new here, so my apologies initially if this is a silly question/
thought.
I am looking at using this technology as a service for a number of
small business clients, and would have a potential where their
internal IP ranges are non-unique, however they do have a number of
SNMP compatible printers (generally HP) that I would like to have
queried.
Would it be better to have the SNMP scan based on the MAC address of
the network device in question, rather than just the IP address which
won't be entirely unique for all networks?
I was thinking that the MAC address could be sent with the IP
address,
and only scanned if the tuple is identical? A bit more work for keys
etc, but it might be safer than scanning random devices on the wrong
network by accident, especially for laptop deployed agents.
Just my 0.02$
James Clenenan
ps. reply on these e-mails doesn't seem to be working to reply to the
list.

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be
enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package
deployment).
3)OCS agent receive the order and start its process for scanning IP
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine
(ip_run() for example) to find the OID of the peripheral associated
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
-- Guillaume

[Guillaume PROTET]

Hi Pascal,

Yes you are right, it will be better if we separate SNMP requests from the inventory process. Your idea about using the same mecanism than download is a good solution. So we could use the "end_handler" hook at the agent side (as we already do with Download.pm) to make SNMP scans and send the results directly to the server side which, as you said, will use a dedicated module to handle this request.

Thanks a lot for your tips.

--
Guillaume

----- Mail original -----

Post by Pascal DANEK
Hi Guillaume.
Personally I would prefer to keep the SNMP data separated from the
inventory request.
As the data could be virtually huge, and as the inventory request is
already used for ipdiscover and registry capacities, I think that it
would be better, with scalability in mind, and also to keep each
request as light as possible, to send data through a dedicated
request. You can easily configure module to handle such request. This
behaviour is presently used by download capacity and by real time ip
updates feature (and probably others that I don't remember at the
moment). About the data model, I think there will be no problem to put
it in Map.pm. Thus, feeding the database and export these new data in
the web service will be quite simple.
Best regards.
--pascal

Post by Guillaume PROTET
Hi all,
As planned in the OCS Inventory roadmap, we started to integrate
SNMP to enhance Ipdiscover datas. SNMP scans will be made by agent
using adresses found by IPDISCOVER.
So, we will be able to have more informations than IPDISCOVER using
SNMP communities.
1) OCS server uses IPDISCOVER datas to determine which IP need to be
enhanced using SNMP.
2) OCS server give the IP range to scan directly to the OCS agent
using the prolog response (like we already do for package
deployment).
3)OCS agent receive the order and start its process for scanning IP
with SNMP. Agent will load several SNMP OID and SNMP communities
that it knows to remeber it for the next steps.
4)OCS agent try to determine what is the community that use an IP by
searching in every communities that it knows.
5)When the SNMP community found, Ocs agent run a standard subroutine
(ip_run() for example) to find the OID of the peripheral associated
to the IP.
6) If the OID found is specific, the OCS agent run a specific
subroutine for this kind of peripheals (for example a specific
subroutine for Cisco devices)
7)OCS agent feed the inventory XML by adding new informations about
the scanned IP
...h(repeat point 4) to 7) for every IP specified by OCS server)
8)OCS agent send the feeded inventory XML to the server that will
store new data in the MySQL database.
For the moment, we plan to integrate it in the Unix unified agent
using the new hooks system which permit at the start of the agent
run, at PROLOG time, at the PROLOG response time, at the inventory
time and at the the end of the agent run.
What are your opinions about it ? All your ideas are welcome :) :).
Kind regards,
-- Guillaume