[Babel-users] wired linked mesh, need to understand something on a simple topology

[tuna at lyua.org]

Hello,

I have been trying Babel into a tiny mesh vpn on wired link, with only  
3 nodes. To keep it simple as possible, topology is:
A-B-C where A,B and C are my distinct nodes. I have been trying to set  
it up so that
A connects to B and then C connects to B as well (and not the other  
way round, but it doesn't matter
I guess). I am working with IPv6 only. I am encountering some weird  
stuff (or I did not expected to see that, which might be
due to my misunderstandings).

(In next dumps I am going replace the IPs by node's letter)

The way I run Babel on each node is this command line:
babel -s -d 2 -D tun0

Now what happens:

When A and B are connected, everything works nicely. Babel table is at  
first, on A:
A/128 metric 0 (exported)
B/128 metric 65535 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665  
age 0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

and after a second or so:
A/128 metric 0 (exported)
B/128 metric 96 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665 age  
0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

OK

Same things happen on B, we end up with:
B/128 metric 0 (exported)
A/128 metric 96 refmetric 0 id 02:18:f3:ff:fe:63:79:61 seqno 2462 age  
0 via tun0 neigh fe80::42:6b89:f7c8:bc70 (installed)

Now, let's proceed with C connecting to B. Here is what happen on C, at first:
C/128 metric 0 (exported)
A/128 metric 65535 refmetric 96 id 02:18:f3:ff:fe:63:79:61 seqno 2462  
age 0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)
B/128 metric 65535 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665  
age 0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

And then:
C/128 metric 0 (exported)
A/128 metric 192 refmetric 96 id 02:18:f3:ff:fe:63:79:61 seqno 2462  
age 0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)
B/128 metric 96 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665 age  
0 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

Well, perfect then. On B we have, at that point:
B/128 metric 0 (exported)
A/128 metric 96 refmetric 0 id 02:18:f3:ff:fe:63:79:61 seqno 2462 age  
17 via tun0 neigh fe80::42:6b89:f7c8:bc70 (installed)
C/128 metric 96 refmetric 0 id 02:1f:d0:ff:fe:8d:29:3e seqno 65328 age  
0 via tun0 neigh fe80::42:6b89:f7c7:bc6f (installed)

Which is nice too. But, isn'it so that A should also get an entry  
about newly arrived node C?
Because on A, nothing changes: no entry at all which deals with C.

Is that OK?

Now after a while, something happens on B and C. Tables are changed.  
Here it is on B:
B/128 metric 0 (exported)
A/128 metric 65535 refmetric 0 id 02:18:f3:ff:fe:63:79:61 seqno 2462  
age 13 via tun0 neigh fe80::42:6b89:f7c8:bc70 (installed)
C/128 metric 96 refmetric 0 id 02:1f:d0:ff:fe:8d:29:3e seqno 65328 age  
66 via tun0 neigh fe80::42:6b89:f7c7:bc6f (installed)

On C:
C/128 metric 0 (exported)
A/128 metric 65535 refmetric 65535 id 02:18:f3:ff:fe:63:79:61 seqno  
2462 age 66 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)
B/128 metric 96 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51666 age  
4 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

Why this route is unsable anymore? I am missing something here...

And on A:
A/128 metric 0 (exported)
B/128 metric 65535 refmetric 0 id 02:a0:24:ff:fe:cf:7c:47 seqno 51665  
age 72 via tun0 neigh fe80::8c7:3280:8ae3:6882 (installed)

So it is like A is cut from network due to this.
Before each changes I can see the update request/answers on each  
nodes, but it should have kept the same metric, shouldn't it? (Or at  
least giving a higher metric for one of the 2 on B, no? so B would  
have a preffered route)

I am bit confused.
What am I missing here? Could it be that B retracted the route to A  
while preffering C? But then A is not able to access C (the only route  
it has, is unusable). From B's point of view I can understand a bit,  
but from A, not really.

I guess I just did not understood a small thing here.

Thanks

Note: Babel version is 0.95. If needed I can provide more log (even  
from tcpdump).