[Olsr-users] olsrd 0.6.6.1 (and earlier) ipv6 problems
Russell Senior
(spam-protected)
Wed Mar 26 19:41:49 CET 2014
>>>>> "Russell" == Russell Senior <(spam-protected)> writes:
>>>>> "Russell" == Russell Senior <(spam-protected)> writes:
Russell> However, something else is causing an ipv6 routing table
Russell> collapse, and that's rebooting one of the nodes. And I do
Russell> have a packet capture of that:
Russell> https://personaltelco.net/~russell/vpn-capture3-ipv6.pcap
Russell> ::407 is the server in the middle. This is filtering for
Russell> only ipv6 olsrd traffic on the openvpn interface as seen from
Russell> the central server. All the other hosts are nodes. The trace
Russell> starts and ends with 186 routes in ::407's ipv6 routing table
Russell> (as counted by "ip -6 r | wc -l"). Shortly after the start,
Russell> I rebooted one of my test nodes, ::1201. After maybe 30
Russell> seconds or maybe a bit less the route count on ::407 was down
Russell> to about 20, then it gradually built back up, getting back to
Russell> 186 a few seconds before then end of the trace.
Russell> Here is an bzip2'd strace from a reboot event (not the same
Russell> one as above). Again, this attaching to the ipv6 olsrd
Russell> process on the server at ::407.
Russell> https://personaltelco.net/~russell/strace-olsr6d.log.bz2
Russell> The reboot occurs at 02:13:00. By 02:13:22, the route count
Russell> has begun to decline, it bottoms out around 02:13:30, and
Russell> starts back up at around 02:13:42.
Anybody get a chance to look at the strace? I see a:
17798 02:13:19.127877 write(1, "TC: del edge entry 2001:470:e962::407 > 2001:470:e962:1201::1, cost (0.553/1.000) 1.808\n", 88) = 88
followed a short time later by instances like this:
17798 02:13:19.641377 write(1, "TC: del edge entry 2001:470:e962:1001::1 > 2001:470:e962::407, cost (1.000/1.000) 1.000\n", 88) = 88
17798 02:13:19.641420 write(1, "RIB: del prefix 2001:470:e962::1001/128 from 2001:470:e962:1001::1\n", 67) = 67
17798 02:13:19.641461 write(1, "RIB: del prefix 2001:470:e962:1001::/64 from 2001:470:e962:1001::1\n", 67) = 67
17798 02:13:19.641501 write(1, "RIB: del prefix 2001:470:e962:1001::1/128 from 2001:470:e962:1001::1\n", 69) = 69
17798 02:13:19.641543 write(1, "TC: add entry 2001:470:e962:1001::1\n", 36) = 36
17798 02:13:19.641575 write(1, "RIB: add prefix 2001:470:e962:1001::1/128 from 2001:470:e962:1001::1\n", 69) = 69
17798 02:13:19.641614 write(1, "RIB: add prefix 2001:470:e962:1001::/64 from 2001:470:e962:1001::1\n", 67) = 67
17798 02:13:19.641657 write(1, "Inserting alias 2001:470:e962::1001 for ", 40) = 40
17798 02:13:19.641687 write(1, "2001:470:e962:1001::1\n", 22) = 22
17798 02:13:19.641717 write(1, "RIB: add prefix 2001:470:e962::1001/128 from 2001:470:e962:1001::1\n", 67) = 67
17798 02:13:19.641758 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9c3928) = -1 ENOTTY (Inappropriate ioctl for device)
17798 02:13:19.641782 gettimeofday({1395738799, 641789}, NULL) = 0
which coincide with the routing table collapse. Around the time the
routing table begins recovering, I see instances like this:
17798 02:13:39.289467 write(1, "Processing TC from 2001:470:e962:1281::1, seq 0x3dd3\n", 53) = 53
17798 02:13:39.289503 write(1, "TC: found neighbor tc_entry 2001:470:e962::407\n", 49) = 49
17798 02:13:39.289536 write(1, "TC: found inverse edge for 2001:470:e962:1281::1\n", 51) = 51
17798 02:13:39.289572 write(1, "TC: add edge entry 2001:470:e962:1281::1 > 2001:470:e962::407, cost (0.000/0.000) INFINITE\n", 91) = 91
17798 02:13:39.289622 write(1, "Inserting alias 2001:470:e962::1281 for ", 40) = 40
17798 02:13:39.289652 write(1, "2001:470:e962:1281::1\n", 22) = 22
17798 02:13:39.289681 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9c3928) = -1 ENOTTY (Inappropriate ioctl for device)
17798 02:13:39.289705 gettimeofday({1395738819, 289712}, NULL) = 0
Is that illuminating at all?
Oh, and I'm seeing the persistent routing table collapse again. It is
cured by turning off the ipv6 version of olsrd on a particular node.
--
Russell Senior, President
(spam-protected)
More information about the Olsr-users
mailing list