[Olsr-dev] stale routing entries in 0.5.4pre
Sven-Ola Tuecke
(spam-protected)
Tue Sep 18 08:38:08 CEST 2007
Morning,
mmh. Seems that the firmware's olsrd version has some flaw in setting "via"
routes in the correct order or so. The only unusual thing I can spot, is
the broad netmask for the WAN/LAN wired link. We usually use very narrow
netmasks for wired links (e.g. 255.255.255.252 for two or 255.255.255.248
for up to six interconnected routers). Nevertheless, the mentioned config
looks fine for me.
Because the is no direct route to 10.14.1.14, there also should be no
entries using 10.14.1.14 as "via" (or: the "router" with the ancient route
command). You may see some "cannot add / cannot remove" messages in the
router's syslog, e.g. with "logread -f".
Because of recent refactorings in olsrd, the firmware's olsrd version is
special in exactly this scope. I will not maintain this special code any
more, because of the recent rewrite from hannes. So you can do 2 things to
circumvent:
a) use another netmask to reflect the wired interconnections, which seems to
run here in berlin on a couple of similar locations
b) use hannes refactored add/del-route code. Simply "ipkg install olsrd".
Which gives you the full-debug and standard olsrd-0.5.3-cvs version with
rt-refactoring included. Be aware, that this version uses a fixed value
for "metric" which for example breaks "olsr-viz".
P,S, I am working on integrating the newer routing stuff into the firmware's
standard olsrd. But this is IMO not "production-stable" currently. I don't
want to break our 500 node network (needs testing), I want the metrics
back. As well as the "default-route-switch-damping" introduced with
the "NatThreshold" parameter. I personally depend on the latter, because my
inet connection is via Freifunk and the neighbour/router on the other side
is a church with 8 routers and the church admin does not want to
use "LQMult" and there are 5 HNA-gateways with similar ETX in range.
End-of-AND <ggg>
HTH
// Sven-Ola
Axel Neumann wrote:
> Hello,
>
> I observed some stale routing entries with freifunk 1.6.2 running
> olsr-0.5.4pre configured to run olsr on
>
> the wireless interface:
> 10.14.0.2 255.255.252.0
>
> and on the wan interface
> 10.14.1.2 255.255.254.0
>
> (on the lan it offers dhcp on 192.168.11.1)
>
> The node used to have a neighboring olsr node with a similar
> configuration: the wireless interface:
> 10.14.0.14 255.255.252.0
>
> and on the wan interface
> 10.14.1.14 255.255.254.0
>
> The 10.14.1.2 and the 10.14.1.14 interface were connected via the
> integrated switch (the lan ports) of another buffalo configured with
>
> the wireless interface:
> 10.14.0.1 255.255.252.0
>
> and on the lan interface
> 10.14.1.1 255.255.254.0
>
> I disconnected 10.14.1.14 but the direct route from 10.14.1.2 to
> 10.14.1.14 did not dissapear . Not even after an hour.
>
> At 10.14.0.1 the route did dissapear.
>
> route -n | grep ^10.14.0.4 # first showed
> (spam-protected):~# route -n | grep ^10.14.0.4
> 10.14.0.4 10.14.1.14 255.255.255.255 UGH 5 0 0
> vlan1
>
> later on it showed:
> (spam-protected):~# route -n | grep ^10.14.0.4
> 10.14.0.4 10.14.1.14 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.0.4 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
>
> the full table is given below.
>
> ciao,
> axel
>
> (spam-protected):~# route -n | grep ^10.14.
> 10.14.1.17 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.1.17 10.14.1.14 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.1.16 10.14.1.1 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.1.19 10.14.1.1 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.1.18 10.14.1.1 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.1.20 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.0.17 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.0.16 10.14.1.1 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.0.19 10.14.1.1 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.0.18 10.14.1.1 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.0.20 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.1.1 0.0.0.0 255.255.255.255 UH 1 0 0
> vlan1
> 10.14.0.9 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.0.9 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.0.8 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.1.3 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.0.11 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.0.10 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.1.5 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.1.5 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.0.13 10.14.1.14 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.0.13 10.14.1.1 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.1.4 10.14.1.1 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.0.12 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.1.7 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.0.15 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.1.6 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.0.14 10.14.1.1 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.0.1 10.14.1.1 255.255.255.255 UGH 1 0 0
> vlan1
> 10.14.1.9 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.1.9 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.1.8 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.0.3 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.1.11 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.1.10 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.0.5 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.1.13 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.0.4 10.14.1.14 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.1.12 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.0.7 10.14.1.1 255.255.255.255 UGH 2 0 0
> vlan1
> 10.14.1.15 10.14.1.1 255.255.255.255 UGH 6 0 0
> vlan1
> 10.14.1.15 10.14.1.14 255.255.255.255 UGH 7 0 0
> vlan1
> 10.14.1.15 10.14.1.14 255.255.255.255 UGH 8 0 0
> vlan1
> 10.14.0.6 10.14.1.1 255.255.255.255 UGH 3 0 0
> vlan1
> 10.14.1.14 10.14.1.1 255.255.255.255 UGH 5 0 0
> vlan1
> 10.14.0.150 10.14.1.1 255.255.255.255 UGH 4 0 0
> vlan1
> 10.14.0.0 0.0.0.0 255.255.254.0 U 0 0 0
> vlan1
> 10.14.0.0 0.0.0.0 255.255.252.0 U 0 0 0
> eth1 (spam-protected):~#
>
More information about the Olsr-dev
mailing list