I thought that it might provide some further information for anyone's benefit. Things got really messed up by just deleting and modeling networks that were modeled correctly in the past.
While trolling forum posts, I remembered that this problem came up before during an upgrade. (I think from 2.1.3 to 2.2.x.). I remember that I had to modify the /Networks zProperties and add 30 and 29 before 24 in the zDefaultNetworkTree property. Those seem to have disappeared at some point.
I haven't payed too much attention to the network mapping functions of Zenoss, and it appears that it was to my disadvantage. Much of the overhead that my zenhub process was encountering since the 2.3.x upgrade was do to some nasty nested auto-discovered networks. I found some help in two forum posts:
http://forums.zenoss.com/viewtopic.php?t=3758http://forums.zenoss.com/viewtopic.php?t=9217For us we have a relatively few devices that handle routing in our network and the 29 and 30 bit masks all belong to them. However, we had some older network devices that had been modeled properly but a newer device that was added recently had a nested mess of a network map. It is important to make sure that both ends of the route being monitored are modeled properly, not just for pretty maps, but also to reduce the number of unnecessary alerts that occur when an intermediate routing device goes down.
To work around our problem, I did the following:
[*:e7dfa50df0]Add 30 and 29, before the 24 entry in the zDefaultNetworkTree property at the base of the /Networks organizer. [*:e7dfa50df0]Shut down zenmodeler process [*:e7dfa50df0]identify the devices that route 29 and 30 bit traffic. [*:e7dfa50df0]Under the /Network organizer identify any networks that have been improperly nested inside a 24 bit network container and delete the entire tree. [*:e7dfa50df0]Open the routers that have network devices on the removed subnets and remove any interfaces associated with those networks. [*:e7dfa50df0]manually run zenmodeler on each of the routers that were affected: [list:e7dfa50df0] [*:e7dfa50df0]zenmodeler run --collect=InterfaceMap --device=fulldevicenameofrouter
[*:e7dfa50df0]Verify that the network and network devices removed are now modeled correctly.
[/list:o:e7dfa50df0] I expect that the root of this problem occurs to some degree because we have some routing entries that are unnecessarily wide. (I.E. routing the entire 10.0.0.0/8 when only two 16 bit subnets exist on the far end.)
James Roman wrote:
We've recently added an MPLS circuit between two of our sites. We have
two identical Cisco model routers on each side of the MPLS link. The
router serial and fast ethernet interfaces between two sites are either
29 or 30 bit masked. When I run an inventory of the routers, however,
Zenoss places them in a 24 bit subnet (which tramples a number of
existing subnets). If i run snmpwalk on the routers, the IF-MIB entries
show the appropriate interface subnets.
IP-MIB::ipAdEntNetMask.10.xxx.xxx.xxx = IpAddress: 255.255.255.248
IP-MIB::ipAdEntNetMask.10.xxx.xxx.xxx = IpAddress: 255.255.255.248
IP-MIB::ipAdEntNetMask.172.xxx.xxx.xxx = IpAddress: 255.255.255.252
When I inventory the core switches that are now connected by the routers
(which have been in our Zenoss system for years) , the VLAN and
FastEthernet interfaces belong to the appropriate 29 bit subnets.
I don't know if this is a device model related issue, or if it is a flaw
introduced in the 2.3.3 code for new devices.
I am also seeing similar messages to those below in the zenhub log. I am
seeing them for most of my devices (not just the routers in question),
since the upgrade to 2.3.x.
|2009-04-08 11:54:07 INFO zen.ZenHub: Worker reports
WARNING:zen.ZenStatus:device '172.xxxx.xxx.xxx' network
'172.xxx.xxx.xxx/30' not in topology
2009-04-08 11:54:07 INFO zen.ZenHub: Worker reports
WARNING:zen.ZenStatus:device '172.||xxx.xxx.xxx||' network
'172.||xxx.xxx.xxx||/30' not in topology
2009-04-08 11:54:07 INFO zen.ZenHub: Worker reports
WARNING:zen.ZenStatus:device 'hostname.domain.com' network
'10.xxx.xxx.xxx/29' not in topology|
Any help?
_______________________________________________
zenoss-users mailing list
zenoss-users@zenoss.org ([email]zenoss-users@zenoss.org[/email])
http://lists.zenoss.org/mailman/listinfo/zenoss-users