Service-provider NMS / Overlapping IP addresses with Zenoss Core 1

An elegant solution to use Zenoss Core in a service-provider context with overlapping IP addresses.Zenoss Core cannot be used properly to manage overlapping IP addresses. The commercial version of Zenoss can do it, but the design they used to piggyback this feature is the usage of realms to segregate conflicting IPs, so if you have custA and custB both using 10.1.2.3, they end up being stored as custA:10.1.2.3 and custB:10.1.2.3. Because you then need one remote collector per customer, this solution does not scale if you have many customers, you end up with many collectors.

To allow for overlapping IP addresses with Zenoss Core, I followed this path:

• implement a proper NAT concept, eg 10.1.0.0 -> custA, 10.2.0.0 -> custB, etc
• poll 10.1.2.3 and 10.2.2.3, the NATting router forwards the requests to custA:10.1.2.3 and custB:10.1.2.3

The remaining problem is the default behaviour of Zenoss Core when it finds overlapping IP addresses on discovered nodes: the last found IP is assigned to the last modelled node. This problem can easily be solved by telling Zenoss Core to store the interface IP addresses as being local. This way, Zenoss Core stores them as attributes of the interface, instead as storing them as linked objects. This is done by editing the zLocalIpAddresses value:

zLocalIpAddresses: ^127|^0\.0|^169\.254|^224|^192\.168|^172\.1[6-9]\.|^172\.2[0-9]\.|^172\.3[0-1]\.|^10\.

The setup above would specify that all RFC1918 private IP addresses are to be considered local.

This workaround has a few consequences, eg /Networks and the network-map are empty, and some correlation functionality disappear. These are not an issue in my usage of Zenoss Core, but must be considered for every implementation. I would be interested to read your thoughts / get your experimentation feedback, so feel free to ask and/or comment. I have tested this on Zenoss 3.2.1, but this would most probably work the same way on Zenoss 4.x.