tinc - Jun 2017 - Cache of the the unreachable nodes cause un-optimized route?

Hi, All

Here is the case: 

A, B, C, D all configured with "IndirectData = yes”, so connection only
happens when there’s a “ConnectTo” in tinc.conf.
Arrow indicate the “ConnectTo” direction

Everything works fine earlier as below:

1. A connect to C, D connect to C
2. C is the transit node where only forward traffic between A and C
3. D advertise 0.0.0.0/0#2
4. A can access internet from D through C, no problem at all

What I did yesterday:
5. A connect to B
6. B advertise 0.0.0.0/0#1

Then I thought the traffic will go through B directly if B is reachable, but
when B is down, traffic will fallback to D(through C), but interestingly, when
the step 5 and 6 are done, I found the traffic seems goes to B though C(not
directly), which is not under my earlier expectation.

Then I remove the “ConnectTo = B” statement from A, but interestingly, at this
time, the traffic still goes to B through C. From what I know from tinc, if the
“ConnectTo” is removed, and IndirectData = yes every where, this shouldn’t
happen. And from the tcp connection perspective on A at this moment, it indeed
only connect to C, no connection to B at all.

Then I investigate further, I found the advertised route from B still exist on
C, where it shows something like below:

2017-06-01T09:00:29.558712+08:00 C tincd: 0.0.0.0/0#1 owner B (That’s the
reason, why C received the packet from A forward to B even A is not connected to
B, in this case I have to stop the tinc daemon on B in order to make traffic
goes back to D)

After tincd -n myvpn -kWINCH on A/C/D, then all the old unreachable info is
gone.

So questions here:

1. Why in the my case, the traffic will go A>C>B path even A is not
connect to B?
2. Why the unreachable info and the related advertised subnet info still exist
in C even the A remove the ConnectTo statement to B(all IndirectData = yes)?
Should I run a crontab to WINCH all the outdated connection regularly to avoid
this? Sounds not that way…looking for advice.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170601/2f05a0bc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_4631.jpeg
Type: image/jpeg
Size: 66098 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170601/2f05a0bc/attachment-0001.jpeg>

> Then I remove the “ConnectTo = B” statement from A
when you do this, means just the A will not setup a metadata connection to
B on startup.

Please read this email from the archive:
https://www.tinc-vpn.org/pipermail/tinc/2010-April/002288.html

Yes, it was 7 years ago. But if you are using tinc 1.0.x your should find
your answers on that thread.

Cheers

Saverio


2017-06-01 4:21 GMT+02:00 Bright Zhao <startryst at gmail.com>:
> Hi, All
>
> Here is the case:
>
> A, B, C, D all configured with "IndirectData = yes”, so connection
only
> happens when there’s a “ConnectTo” in tinc.conf.
> Arrow indicate the “ConnectTo” direction
>
> Everything works fine earlier as below:
>
> 1. A connect to C, D connect to C
> 2. C is the transit node where only forward traffic between A and C
> 3. D advertise 0.0.0.0/0#2
> 4. A can access internet from D through C, no problem at all
>
> What I did yesterday:
> 5. A connect to B
> 6. B advertise 0.0.0.0/0#1
>
> Then I thought the traffic will go through B directly if B is reachable,
> but when B is down, traffic will fallback to D(through C), but
> interestingly, when the step 5 and 6 are done, I found the traffic seems
> goes to B though C(not directly), which is not under my earlier
expectation.
>
> Then I remove the “ConnectTo = B” statement from A, but interestingly, at
> this time, the traffic still goes to B through C. From what I know from
> tinc, if the “ConnectTo” is removed, and IndirectData = yes every where,
> this shouldn’t happen. And from the tcp connection perspective on A at this
> moment, it indeed only connect to C, no connection to B at all.
>
> Then I investigate further, I found the advertised route from B still
> exist on C, where it shows something like below:
>
> *2017-06-01T09:00:29.558712+08:00 C tincd: 0.0.0.0/0#1
> <http://0.0.0.0/0#1> owner B (That’s the reason, why C received the
packet
> from A forward to B even A is not connected to B, in this case I have to
> stop the tinc daemon on B in order to make traffic goes back to D)*
>
> After tincd -n myvpn -kWINCH on A/C/D, then all the old unreachable info
> is gone.
>
> So questions here:
>
> 1. Why in the my case, the traffic will go A>C>B path even A is not
> connect to B?
> 2. Why the unreachable info and the related advertised subnet info still
> exist in C even the A remove the ConnectTo statement to B(all IndirectData
> = yes)? Should I run a crontab to WINCH all the outdated connection
> regularly to avoid this? Sounds not that way…looking for advice.
>
>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170602/9f7d0c97/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_4631.jpeg
Type: image/jpeg
Size: 66098 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170602/9f7d0c97/attachment-0001.jpeg>