#1308 ipRouteEntry - Missing routes with same network adress
Hi
I found a bug in the presentation of routes. The mib
uses the network adress as a mib entry, ex
ipRouteDest.10.0.0.0 for network 10.0.0.0. If there is
two different routes with the same network adress with
different netmasks only one is shown.
Easiest way to check this is to do the following.
# ip route add 10.0.0.0/8 via 127.0.0.1
# ip route add 10.0.0.0/16 via 127.0.0.1
# ip route add 10.0.0.0/24 via 127.0.0.1
# ip route
10.0.0.0/24 via 127.0.0.1 dev lo
X.X.X.0/23 dev eth0 proto kernel scope link src X.X.X.X
10.0.0.0/16 via 127.0.0.1 dev lo
10.0.0.0/8 via 127.0.0.1 dev lo
default via X.X.X.X dev eth0
# snmpwalk -c public localhost ipRouteDest
RFC1213-MIB::ipRouteDest.0.0.0.0 0.0.0.0
RFC1213-MIB::ipRouteDest.10.0.0.0 10.0.0.0
RFC1213-MIB::ipRouteDest.X.X.X.0 X.X.X.0
# snmpwalk -c public localhost ipRouteMask
RFC1213-MIB::ipRouteMask.0.0.0.0 0.0.0.0
RFC1213-MIB::ipRouteMask.10.0.0.0 255.255.255.0
RFC1213-MIB::ipRouteMask.X.X.X.0 255.255.254.0
As you can see in the example i can't use snmp to poll
the current routing table. If you wounder it there
would be a different response from the snmpd if there
were different gateway addresse then NO it won't.
The same problem exists if you add a route and then
delete the route and later add a new route with the
same network address but with a different subnet mask.
I think it is the same bug since the kernel keep the
old route but marks is as invalid.
Logged In: YES
user_id=88647
Yes, this is one of the shortcomings of the old
ipRouteTable, and one of the reasons for the newer
ipCidrRouteTable which is currently being implemented. At
the moment it is available with version 5.2.1 for Linux if
you configure with --enable-mfd-rewrites
Logged In: YES
user_id=1210365
Is there any plan to fix this using the current mib instead
of using the new ipCidrRouteTable? I don't see any reason to
keep the old ipRouteTable if it has a bug in it that no one
will fix.
Logged In: YES
user_id=88647
It is notpossible to fix this using the old mib, as it uses
only the forwarding address as the index. On the other hand
there is no reason to remove this, as it works for most
people. Maybe when the new mib has been implemented for most
platforms.
Logged In: YES
user_id=1210365
Ok, i understand that there will not be any fixes for the
current ipRouteTable but i don't understand why the
ipRouteTable shouldn't be removed. You say that it works for
most people but how can anyone trust that it will? As soon
as they use two networks with the same network adress it
won't work and that is hard to know in advance. At some
point it just doesn't work anymore. If the solution is to
use the new ipCidrRouteTable everyone will move to that one
anyway and there will not be any reason to keep the old one
since it doesn't work.
The problem that i have here is that i will poll a lot more
boxes that just linux and i won't administrate them all so i
won't have the possibility to tell everyone to download the
source and compile it with --enable-mfd-rewrites. This has
to be working 'out of the box' so to say or i can't depend
on it.
Logged In: YES
user_id=88647
This is the very first release to to support the new mib,
and only does so for Linux, so we are certainly not prepared
to retire the old mib now. We need to get more confidence
that it works, and there certainly are users out there that
use the old ipRouteTable.
We need implementations for the ipCidrRouteTable for
Solaris, NetBSD, OpenBSD, FreeBSD, at least, before we can
think about retiring ipRouteTable