[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