Hi all,
So, I've deployed Tinc in a non normal manor to which has been working
just fine for days up until recent. Here is a description of the network.
There are two VPN host controllers, A and B. All nodes have a separate
connection to A and B. Tinc has been configured to be in 'switch' mode
for both the A cloud and B cloud. On the back end, I have OSPF running
on all nodes and the host controllers which are populated the routes in
the various clouds so that A is the primary route and B is the secondary
route.
The OSPF routes are populating just fine, and tcpdump on all nodes shows
this. The problem is ARP. From the host controller A, I can ping all the
nodes and all the nodes can ping the host controller. Same as B. NONE of
the nodes can ping each other. When I packet dump the Tinc interfaces
across the nodes I see them sending ARP requests ("who has"). No one
sends a response. Sometimes, and now very rarely, a response is sent. If
I static the ARP entries, everything works.
I know Tinc keeps its own ARP tables, and I dabbled with ifconfig
>interfacename< -arp just to see what happens, and of course that
doesn't help.
Does anyone have any ideas as to why ARP isnt working?
Thanks!
On Wed, Apr 26, 2006 at 12:09:42AM -0400, Russell Handorf wrote:> The OSPF routes are populating just fine, and tcpdump on all nodes shows > this. The problem is ARP. From the host controller A, I can ping all the > nodes and all the nodes can ping the host controller. Same as B. NONE of > the nodes can ping each other. When I packet dump the Tinc interfaces > across the nodes I see them sending ARP requests ("who has"). No one > sends a response. Sometimes, and now very rarely, a response is sent. If > I static the ARP entries, everything works.Which version of tinc do you use? Version 1.0.3 has a bug in switch mode that was fixed in 1.0.4. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20060426/9b140c2c/attachment.pgp
On Wed, Apr 26, 2006 at 09:24:25AM -0400, Russell Handorf wrote:> >Which version of tinc do you use? Version 1.0.3 has a bug in switch mode > >that was fixed in 1.0.4. > > > tinc version 1.0.4 (built Feb 24 2006 21:55:39, protocol 17) > Copyright (C) 1998-2005 Ivo Timmermans, Guus Sliepen and others. > See the AUTHORS file for a complete list. > > tinc comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to redistribute it under certain conditions; > see the file COPYING for details. > > Confirmed on every node and cluster end point.In that case, I need more information. Please read section 5.4 and 5.6 of the manual: http://www.tinc-vpn.org/documentation/tinc_5.html#SEC54 -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20060426/617c8d6f/attachment.pgp
On Wed, Apr 26, 2006 at 10:03:46AM -0400, Russell Handorf wrote:> Trying to ping from haldi1 to handorf1 > > Read packet of 42 bytes from haldi (<snip> port 655) > Writing packet of 42 bytes to Linux tun/tap device (tap mode) > Sending packet of 42 bytes to krenoria1 (<snip> port 655) > Sending packet of 46 bytes to eressa1 (<snip> port 655) > Sending packet of 50 bytes to handorf1 (<snip> port 655)Hm, I see something strange there, the packet seems to get bigger and bigger when it is being broadcasted to all clients. Perhaps that causes the problems. I'll look into it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20060426/501ef049/attachment.pgp