Paul Goyette a écrit :
On Thu, 8 Dec 2016, BERTRAND Joël wrote:Gert Doering a écrit :Hi, On Wed, Dec 07, 2016 at 11:27:29PM +0100, BERTRAND Joël wrote:Even with interfaces up on both sides, tunnel is unusable.What does "unusable" mean, exactly? Is the agr interface down, are packets not being sent to tap0/tap1, are they not passed to openvpn, are they not being received, etc.?No connection. Both OpenVPN links run as expected. But even if agr0 is up (and configured of course with an IP address), no data is received from aggregated interface. I suppose that NetBSD try to send data, but Linux host doesn't receive any packets.You'll need to do some tcpdumping on all interfaces involved to see how far the packets get...Of course, I have tried to check link with tcpdump. WHen I try to ping Linux host from NetBSD, I obtain on agr0 : 10:34:46.034686 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:47.034689 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:48.034682 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:49.034679 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:50.034666 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:51.034655 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:52.034655 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:53.034647 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:54.034642 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:55.034639 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:56.034624 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:57.034635 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:58.034615 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:34:59.034613 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28 10:35:00.034612 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28Great. You should also run tcpdump on both member links to determine whether or not the agr driver is properly putting packets into those queues.
I run tcpdump of both members. When NetBSD sends an arp request, Linux doesn't receive this request. And when linux sends request, NetBSD doesn't receive it.
And if that succeeds, you should then use tcpdump to watch for packets being sent on the "real" interfaces... (I think this is what the previous responder meant when he said "run tcpdump on all of the involved interfaces...)If I try to ping NetBSD from Linux, I obtain the same message.Hopefully, the addresses are reversed! If NetBSD --> Linux says Request who-has 192.168.100.1 tell 192.168.100.2 then Linux --> NetBSD should say Request who-has 192.168.100.2 tell 192.168.100.1
Of course. I have tried to directly run tcpdump on tap interfaces : Root rayleigh:[~] > tcpdump -i tap3 -p (linux) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap3, link-type EN10MB (Ethernet), capture size 262144 bytes 11:00:31.834796 LACPv1, length 11011:00:53.322376 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:54.318759 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:55.318748 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:56.321787 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:57.318751 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:58.318767 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:01:01.850763 LACPv1, length 110 11:01:31.854744 LACPv1, length 110 einstein# tcpdump -i tap0 -p (netbsd) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes11:00:53.324275 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:54.320839 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:55.320676 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:56.323695 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:57.320671 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28 11:00:58.320727 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:01:01.852714 LACPv1, length 110 11:01:31.856649 LACPv1, length 110 Root rayleigh:[~] > tcpdump -i tap4 -p tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap4, link-type EN10MB (Ethernet), capture size 262144 bytes 11:03:01.874744 LACPv1, length 110 ... einstein# tcpdump -i tap1 -p tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:03:01.876694 LACPv1, length 110 ...Thus tap3(linux) and tap0(netbsd) are connected. Same constatation for tap4(linux) and tap1(netbsd).
JKB