I am using Zenoss Core 4.2.4, and I'm seeing similar issues, but not identical. I have a particular PDU that lives on the other side of a router (see nmap traceroute below). When the link between 192.168.4.254 and 10.50.0.2 drops, Zenoss generates events for both the 10.50.0.2 device AND the 10.13.0.2 device (and several others that live behind that router.)
Remodeling the devices seems to have had no effect. On a whim, I deleted and re-added the devices in the order of the traceroute, but to no avail. Based on the tracepath.py tool, it appears that Zenoss is not learning the topology at all.
I'd like to look into the internals a bit to see how the topology works (or doesn't, in this case). Can anyone share a few pointers on how to look under the hood?
====== nmap traceroute ======
[zenoss@zenoss ~]$ nmap -sP --traceroute -n 10.13.0.2
Starting Nmap 5.51.4 ( http://nmap.org ) at 2013-08-21 08:37 CDT
Nmap scan report for 10.13.0.2
Host is up (0.0015s latency).
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 0.29 ms 10.0.10.97
2 0.83 ms 192.168.4.254
3 1.02 ms 10.50.0.2
4 2.41 ms 10.13.0.2
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
====== tracepath.py ======
[zenoss@zenoss ~]$ tracepath.py 10.13.0.2
Getting path from localhost to 10.13.0.2...
zenoss -> 10.13.0.2