[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Link aggregation between NetBSD agr and Linux bond interfaces
On Thu, Dec 08, 2016 at 10:41:10AM +0100, BERTRAND Joël wrote:
> > You'll need to do some tcpdumping on all interfaces involved to see
> > how far the packets get...
On *all* interfaces...
> 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
Now you need to do the tcpdump on tap0 and tap1 to see where the problem
happens - is "agr -> (tap0,tap1)" not working, or is there something
between tap0->openvpn->tap1->bond0 on the other end.
If you see the packets on tap0 or tap1, the NetBSD "agr" part is working,
so then you need to tcpdump on tap1/tap2 on the linux side and the
bond interface there to see who is eating them.
> > Looking at the man page, agr seems to default to use LACP, which might
> > or might not be the problem - so I'd start by turning it off ("link1")
> > to see if a static tunnel works. If that works, check that the linux
> > side is also speaking LACP and whether that part comes up.
> I have turned of link1. And on linux side, I suppose bond0 is
> configured to use LACP :
Turn link1 *on*. As per the man page, that turns *off* LACP.
Ditto on Linux. LACP is good (because it can notice if one of the taps
isn't working), but it is an extra complication on the step towards
"where is it not working", so initial troubleshooting should be without
(Note: if talking to a switch, leave LACP on, of course, to avoid bridge
USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany gert%greenie.muc.de@localhost
fax: +49-89-35655025 gert%net.informatik.tu-muenchen.de@localhost
Main Index |
Thread Index |