On 5/1/07, Calvin Hendryx-Parker <[EMAIL PROTECTED]> wrote:
Hi Chet,
Thanks for your persistence on this issue. I have found out a few more
things and noted them below...
Chet Luther wrote:
> I dug into this, and now understand what the problem is. Unfortunately
> I can't come up with an easy solution for it. FreeBSD has a concept of
> "cloned" routes that are automatically generated by the kernel. In
> your netstat output you can see that your 10.200/24 route has the UC
> flags. The C stands for clone. This means that anytime your system
> looks up a route in that network, a cloned route will be generated.
> NetSNMP is reporting these cloned routes thus causing Zenoss not to be
> able to model your routing table properly.
I don't think that is the exact issue here since the other interfaces
that are links are also flagged with the same flags, but show up as
direct routes in the zenoss OS screen.
The main problem here is that 10.200.0.0/32 route. If you look at the
ipRouteTable SNMP MIB, you'll see that each ipRouteEntry is actually
indexed by the network ID. The network ID for 10.200.0.0/24 and
10.200.0.0/32 is the same thing, 10.200.0.0. So the ipRouteTable can
only contain one of these entries. Unfortunately it will always pick
the more specific of the two. So you end up with 10.200.0.0/32 in your
MIB instead of 10.200.0.0/24.
This issue only occurs on boxes that are allowed to route packets
between interfaces by using the gateway_enable flag in rc.conf.
Aparently once you do this it chooses one of the interfaces and adds a
route that represents the broadcast address into the table. This is the
entry flagged with a "b".
As far as I know the only thing the gateway_enable setting does is
enable ip_forwarding. I'd like to understand why it would create this
broadcast (b = broadcast flag) route when gateway_enable is enabled.
I have 3 servers setup this way and all three of them have this same
behavior. The interface flagged with a "b" won't show on the zenoss
routes. It doesn't matter if it is an internal private IP or a public
routeable IP as I have boxes doing it for either one.
It seems like a bug in the zenoss discovery phase and modeling to ignore
these routes. What do you think?
Bear with me while I play the blame game here for informational
purposes only. :)
* Zenoss can't model the 10.200.0.0/24 network because NetSNMP simply
doesn't expose it.
* NetSNMP can't expose the 10.200.0.0/24 network because RFC1213
states that the ipRouteTable must be indexed by the network ID.
FreeBSD is creating routes with overlapping network IDs.
* FreeBSD is creating routes with overlapping network IDs because ...
I'm sure there's a reason, but I don't know what it is.
--
Chet Luther
[EMAIL PROTECTED]
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
