Monitoring of Remote Networks

[crawleyinc]

crawleyinc [http://community.zenoss.org/people/crawleyinc] created the discussion

"Monitoring of Remote Networks"

To view the discussion, visit: http://community.zenoss.org/message/63473#63473

--------------------------------------------------------------
I have a remote device I am trying to map and have NAT configured to allow zenoss to connect to the remote device.  As it stands, when the device sends SNMP traps it labels the "device" portion of the event as the internal IP address (e.g. 192.168.1.xxx).  I want it to report the public IP as the device name (Just so I can avoid conflicts with other devices with the same internal IP.)

Any thoughts on how to accomplish this?  I'm guessing there is going to have to be some manipulation of OIDs to make the change that I want, I'm just not sure if that should occur at my location or at the remote site.

Thanks!
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/63473#63473]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

[jcurry]

jcurry [http://community.zenoss.org/people/jcurry] created the discussion

"Re: Monitoring of Remote Networks"

To view the discussion, visit: http://community.zenoss.org/message/63485#63485

--------------------------------------------------------------
Hmmm - this is a perennial, difficult one if you are managing overlapping address spaces.  Still not easy if you have NAT that doesn't actually have iverlapping addresses.

Especially for TRAPs, the values of the event fields will be taken directly from the data on the SNMP TRAP which, as you say, will have the private values for ip addresses in them - and this isn't necessarily just the device field; if the TRAP has varbinds with other IP information then that will also be the un-NAT'ed private addresses.

You would need a lookup mechanism to translate private addresses to public addresses.  This should probably be done with a DNS.  Then, for events from that part of your network, you would need an event transform that substituted address fields.

Has anyone done this?  Any other suggestions?

Cheers,
Jane
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/63485#63485]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

[crawleyinc]

crawleyinc [http://community.zenoss.org/people/crawleyinc] created the discussion

"Re: Monitoring of Remote Networks"

To view the discussion, visit: http://community.zenoss.org/message/63515#63515

--------------------------------------------------------------
We were thinking about doing some sort of name translation through a DNS, but I think the problem would still occur if say, we have two clients whose Domain Controllers both have the same internal IP address. Just as a little background, I work for a small IT firm who manages networks for companies that outsource their IT departments. The idea is to monitor these disjoint networks through a single Zenoss instantiation, but as you can see there are issues that are associated with doing something like this.


The alternative would be to avoid traps altogether, and simply have Zenoss poll the remote sites for their snmp information, however this presents another set of challenges as different clients have different configurations and custom-tailoring a monitoring template for each one would be arduous.  The common factor between all of our client sites is that every single one has Dell OpenManage Server Administrator present on every single one of their servers.  The nice thing about OMSA is that it is able to monitor many, many aspects of Dell hardware and has a fairly robust SNMP trap implementation.  Having Dell OMSA throw traps at Zenoss whenever something bad happens, then having Zenoss throw e-mail alerts while simultaneously changing the little location dots from green to red on our google maps portlet so everyone knows in the office knows that something is going on would just be badass and make our lives much easier (It would also blow prospective clients' minds when they come see our operation).

That said, we would love be to able to figure out a way for Zenoss to understand that the trap is coming from the public IP rather than the private one, so we can map it all to their respective locations and have all of the client data centralized and easily navigable.  DNS is certainly an option, but I'm just not sure if it is the 100% solution.

Anyone have any other thoughts?
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/63515#63515]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]