Re: Before sending to bug at openbsd....
Description: Configuring trunk with LACP is broken. Cannot issue ICMP from one trunk to another. This is done is a sandbox network. using to qemu hosted openBSD. Strange FACT the id of the trunk stay Each interface are direclty bridged to each other on the host, the bridge is not shared, theres is one bridge per interface; vio0(bsd1) --- tapXXX --- br0 --- tapYYY --- vio0(bsd2) vio1(bsd1) --- tapXXX --- br0 --- tapYYY --- vio1(bsd2) Oh! I've just thought of something else. You have no switch sending the LACP frames out! So of course it won't work. Maybe you could look at openvswitch or something if you need to model a LACP trunk setup in a VM. (If you don't need to do that, then I don't see all that much point doing this in the first place). Anyway I don't think this is tech@ material so if you'd like to continue the discussion, please move it to misc.
Re: Before sending to bug at openbsd....
On Wed, Mar 12, 2014 at 3:33 PM, sven falempin sven.falem...@gmail.com wrote: On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote: On 2014/03/12 13:47, sven falempin wrote: You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) The sockets just talk directly to each other, you don't need a server. Because i am an idiot and do not listen GOOD advice, i created two ethernet tunnel with almighty SSH. But apparently LACP is not forwarded, (the round robin works just fine), here is the trunk with the two link0 tun and the LACP packet sended to LACP slow protocol tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkproto lacp trunk id: [(,00:00:00:00:00:00,,,), (,00:00:00:00:00:00,,,)] trunkport tun1 collecting,distributing trunkport tun0 collecting,distributing groups: trunk media: Ethernet autoselect status: active inet 172.18.1.2 netmask 0x broadcast 172.18.255.255 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb # tcpdump -tteni tun0 tcpdump: listening on tun0, link-type EN10MB 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 I guess 01:80:c2:00:00:02 is not sent to the other side is this normal , a tun should forward broadcast, should it not ? *go read qemu socket node* Hello again ! Using socket qemu was a bit tricky, trying to get to socketed interface leads to machine hang when doing ifconfig up on the second interface (probably the addr argument is wrong). Anyhow , trunk should work on one interface and it does but once again only with roundrobin, NO LACP :( the qemus is now using : -net nic,model=virtio,macaddr=52:54:00:12:01:01,addr=0x12 -net socket,mcast=230.0.0.1:42421 and -net nic,model=virtio,macaddr=52:54:00:12:01:02,addr=0x12 -net socket,mcast=230.0.0.1:42421 Machine number1: bsd1 # ifconfig vio0 up bsd1 # ifconfig trunk0 trunkport vio0 10.100.42.1/24 bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=20.186 ms 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=10.495 ms 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=9.848 ms --- 10.100.42.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 9.848/13.509/20.186/4.730 ms bsd1 # ifconfig trunk0 trunkproto lacp bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes --- 10.100.42.2 ping statistics --- 28 packets transmitted, 0 packets received, 100.0% packet loss bsd1 # ifconfig trunk0 down bsd1 # ifconfig trunk0 up bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes --- 10.100.42.2 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss bsd1 # ifconfig trunk0 trunkproto roundrobin bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=19.379 ms 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=12.347 ms 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=10.107 ms 64 bytes from 10.100.42.2: icmp_seq=3 ttl=255 time=11.031 ms --- 10.100.42.2 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 10.107/13.216/19.379/3.646 ms bsd1 # ifconfig trunk0 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 52:54:00:12:01:01 priority: 0 trunk: trunkproto roundrobin trunkport vio0 master,active groups: trunk media: Ethernet autoselect status: active inet 10.100.42.1 netmask 0xff00 broadcast 10.100.42.255 inet6 fe80::5054:ff:fe12:101%trunk0 prefixlen 64 duplicated scopeid 0x6 bsd1 # ifconfig trunk0 trunkproto lacp bsd1 # ping
Re: Before sending to bug at openbsd....
Em 13-03-2014 11:32, sven falempin escreveu: On Wed, Mar 12, 2014 at 3:33 PM, sven falempin sven.falem...@gmail.com wrote: On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote: On 2014/03/12 13:47, sven falempin wrote: You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) The sockets just talk directly to each other, you don't need a server. Because i am an idiot and do not listen GOOD advice, i created two ethernet tunnel with almighty SSH. But apparently LACP is not forwarded, (the round robin works just fine), here is the trunk with the two link0 tun and the LACP packet sended to LACP slow protocol tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkproto lacp trunk id: [(,00:00:00:00:00:00,,,), (,00:00:00:00:00:00,,,)] trunkport tun1 collecting,distributing trunkport tun0 collecting,distributing groups: trunk media: Ethernet autoselect status: active inet 172.18.1.2 netmask 0x broadcast 172.18.255.255 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb # tcpdump -tteni tun0 tcpdump: listening on tun0, link-type EN10MB 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 I guess 01:80:c2:00:00:02 is not sent to the other side is this normal , a tun should forward broadcast, should it not ? *go read qemu socket node* Hello again ! Using socket qemu was a bit tricky, trying to get to socketed interface leads to machine hang when doing ifconfig up on the second interface (probably the addr argument is wrong). Anyhow , trunk should work on one interface and it does but once again only with roundrobin, NO LACP :( the qemus is now using : -net nic,model=virtio,macaddr=52:54:00:12:01:01,addr=0x12 -net socket,mcast=230.0.0.1:42421 and -net nic,model=virtio,macaddr=52:54:00:12:01:02,addr=0x12 -net socket,mcast=230.0.0.1:42421 Machine number1: bsd1 # ifconfig vio0 up bsd1 # ifconfig trunk0 trunkport vio0 10.100.42.1/24 bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=20.186 ms 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=10.495 ms 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=9.848 ms --- 10.100.42.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 9.848/13.509/20.186/4.730 ms bsd1 # ifconfig trunk0 trunkproto lacp bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes --- 10.100.42.2 ping statistics --- 28 packets transmitted, 0 packets received, 100.0% packet loss bsd1 # ifconfig trunk0 down bsd1 # ifconfig trunk0 up bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes --- 10.100.42.2 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss bsd1 # ifconfig trunk0 trunkproto roundrobin bsd1 # ping 10.100.42.2 PING 10.100.42.2 (10.100.42.2): 56 data bytes 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=19.379 ms 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=12.347 ms 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=10.107 ms 64 bytes from 10.100.42.2: icmp_seq=3 ttl=255 time=11.031 ms --- 10.100.42.2 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 10.107/13.216/19.379/3.646 ms bsd1 # ifconfig trunk0 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 52:54:00:12:01:01 priority: 0 trunk: trunkproto roundrobin trunkport vio0 master,active groups: trunk media: Ethernet autoselect status: active inet 10.100.42.1 netmask 0xff00 broadcast 10.100.42.255 inet6 fe80::5054:ff:fe12:101%trunk0
Before sending to bug at openbsd....
Hello, does someone knows about this and how to fix it or workaround ? Best Regards, Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED Category: system Environment: System : OpenBSD 5.4 Details : OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Architecture: OpenBSD.i386 Machine : i386 Description: Configuring trunk with LACP is broken. Cannot issue ICMP from one trunk to another. This is done is a sandbox network. using to qemu hosted openBSD. Strange FACT the id of the trunk stay Each interface are direclty bridged to each other on the host, the bridge is not shared, theres is one bridge per interface; vio0(bsd1) --- tapXXX --- br0 --- tapYYY --- vio0(bsd2) vio1(bsd1) --- tapXXX --- br0 --- tapYYY --- vio1(bsd2) Trunk is working in round robin mode. # - # uname -a OpenBSD bsd2.bsd2 5.4 GENERIC#37 i386 # ifconfig vio vio0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 12:74:43:be:49:f0 priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect status: active inet6 fe80::2cb5:6052:6e2e:107c%vio0 prefixlen 64 scopeid 0x1 vio1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 12:74:43:be:49:f0 priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect status: active inet6 fe80::2cb5:6052:6e2e:107c%vio1 prefixlen 64 scopeid 0x2 # - # uname -a OpenBSD bsd1.local 5.4 GENERIC#37 i386 # ifconfig vio vio0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 02:4d:82:04:94:0d priority: 0 trunk: trunkdev trunk0 groups: egress media: Ethernet autoselect status: active inet6 fe80::f044:d4c2:63de:2fc4%vio0 prefixlen 64 scopeid 0x1 vio1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 02:4d:82:04:94:0d priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect status: active inet6 fe80::f044:d4c2:63de:2fc4%vio1 prefixlen 64 scopeid 0x2 How-To-Repeat: test transcript: # # trunk0 lacp is not working # ping 10.142.1.10 PING 10.142.1.10 (10.142.1.10): 56 data bytes ping: sendto: Host is down ping: wrote 10.142.1.10 64 chars, ret=-1 ping: sendto: Host is down ping: wrote 10.142.1.10 64 chars, ret=-1 --- 10.142.1.10 ping statistics --- 8 packets transmitted, 0 packets received, 100.0% packet loss # # # # strange id # ifconfig trunk0 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 12:74:43:be:49:f0 priority: 0 trunk: trunkproto lacp trunk id: [(,00:00:00:00:00:00,,,), (,00:00:00:00:00:00,,,)] trunkport vio1 collecting,distributing trunkport vio0 collecting,distributing groups: trunk media: Ethernet autoselect status: active inet6 fe80::1074:43ff:febe:49f0%trunk0 prefixlen 64 scopeid 0x7 inet 10.142.1.11 netmask 0xff00 broadcast 10.255.255.255 # # # fallback to roundrobin for testing (on both machines of course) # ifconfig trunk0 trunkproto roundrobin # ping 10.142.1.10 PING 10.142.1.10 (10.142.1.10): 56 data bytes 64 bytes from 10.142.1.10: icmp_seq=0 ttl=255 time=22.450 ms 64 bytes from 10.142.1.10: icmp_seq=1 ttl=255 time=9.213 ms [...] 64 bytes from 10.142.1.10: icmp_seq=8 ttl=255 time=9.466 ms 64 bytes from 10.142.1.10: icmp_seq=9 ttl=255 time=9.275 ms --- 10.142.1.10 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 9.089/12.452/22.450/4.720 ms # # # retry LACP for testing (on both machines of course) # # ifconfig trunk0 trunkproto lacp # ping 10.142.1.10 PING 10.142.1.10 (10.142.1.10): 56 data bytes --- 10.142.1.10 ping statistics --- 7 packets transmitted, 0 packets received, 100.0% packet loss
Re: Before sending to bug at openbsd....
On 2014/03/12 10:41, sven falempin wrote: Hello, does someone knows about this and how to fix it or workaround ? Best Regards, Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED Category: system Environment: System : OpenBSD 5.4 Details : OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Architecture: OpenBSD.i386 Machine : i386 Description: Configuring trunk with LACP is broken. Cannot issue ICMP from one trunk to another. This is done is a sandbox network. using to qemu hosted openBSD. Strange FACT the id of the trunk stay Each interface are direclty bridged to each other on the host, the bridge is not shared, theres is one bridge per interface; vio0(bsd1) --- tapXXX --- br0 --- tapYYY --- vio0(bsd2) vio1(bsd1) --- tapXXX --- br0 --- tapYYY --- vio1(bsd2) Your explanation is missing something, tapXXX and br0 don't exist in OpenBSD and you haven't explained where they come from. Are you aware that LACP is a link-local protocol and is only expected to work over a single ethernet hop? From the naming br0 I am suspecting some kind of bridge on some OS that you haven't talked about; if such a bridge *did* forward link-local frames (as would be needed for LACP to work), that would be a bug. You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs.
Re: Before sending to bug at openbsd....
On Wed, Mar 12, 2014 at 11:44 AM, Stuart Henderson st...@openbsd.org wrote: On 2014/03/12 10:41, sven falempin wrote: Hello, does someone knows about this and how to fix it or workaround ? Best Regards, Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED Category: system Environment: System : OpenBSD 5.4 Details : OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Architecture: OpenBSD.i386 Machine : i386 Description: Configuring trunk with LACP is broken. Cannot issue ICMP from one trunk to another. This is done is a sandbox network. using to qemu hosted openBSD. Strange FACT the id of the trunk stay Each interface are direclty bridged to each other on the host, the bridge is not shared, theres is one bridge per interface; vio0(bsd1) --- tapXXX --- br0 --- tapYYY --- vio0(bsd2) vio1(bsd1) --- tapXXX --- br0 --- tapYYY --- vio1(bsd2) Your explanation is missing something, tapXXX and br0 don't exist in OpenBSD and you haven't explained where they come from. vio0(bsd1) --- tapXXX(host) --- bridge 0(host) --- tapYYY(host) --- vio0(bsd2) vio1(bsd1) --- tapAAA(host) --- bridge 1(host) --- tapBBB(host) --- vio1(bsd2) Are you aware that LACP is a link-local protocol and is only expected to work over a single ethernet hop? From the naming br0 I am suspecting some kind of bridge on some OS that you haven't talked about; if such a bridge *did* forward link-local frames (as would be needed for LACP to work), that would be a bug. Thank you, i did saw some LACP data on interfaces but there are indeed not forwarded. You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) Thank you again -- - () ascii ribbon campaign - against html e-mail /\
Re: Before sending to bug at openbsd....
On 2014/03/12 13:47, sven falempin wrote: You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) The sockets just talk directly to each other, you don't need a server.
Re: Before sending to bug at openbsd....
On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote: On 2014/03/12 13:47, sven falempin wrote: You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) The sockets just talk directly to each other, you don't need a server. Because i am an idiot and do not listen GOOD advice, i created two ethernet tunnel with almighty SSH. But apparently LACP is not forwarded, (the round robin works just fine), here is the trunk with the two link0 tun and the LACP packet sended to LACP slow protocol tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkproto lacp trunk id: [(,00:00:00:00:00:00,,,), (,00:00:00:00:00:00,,,)] trunkport tun1 collecting,distributing trunkport tun0 collecting,distributing groups: trunk media: Ethernet autoselect status: active inet 172.18.1.2 netmask 0x broadcast 172.18.255.255 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb # tcpdump -tteni tun0 tcpdump: listening on tun0, link-type EN10MB 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 I guess 01:80:c2:00:00:02 is not sent to the other side is this normal , a tun should forward broadcast, should it not ? *go read qemu socket node* -- - () ascii ribbon campaign - against html e-mail /\
Re: Before sending to bug at openbsd....
Em 12-03-2014 16:33, sven falempin escreveu: On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote: On 2014/03/12 13:47, sven falempin wrote: You might do better with qemu socket network devices (or the L2TPv3 support that was recently added to qemu head), which should allow a direct connection between the virtual interfaces, rather than using a bridge device that exists outside the VMs. qemu is 1.7.0 something like : vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server 127.0.0.1:5000 --- vio0(bsd2) The sockets just talk directly to each other, you don't need a server. Because i am an idiot and do not listen GOOD advice, i created two ethernet tunnel with almighty SSH. But apparently LACP is not forwarded, (the round robin works just fine), here is the trunk with the two link0 tun and the LACP packet sended to LACP slow protocol tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkdev trunk0 groups: tun status: active inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr fe:e1:ba:d1:62:79 priority: 0 trunk: trunkproto lacp trunk id: [(,00:00:00:00:00:00,,,), (,00:00:00:00:00:00,,,)] trunkport tun1 collecting,distributing trunkport tun0 collecting,distributing groups: trunk media: Ethernet autoselect status: active inet 172.18.1.2 netmask 0x broadcast 172.18.255.255 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb # tcpdump -tteni tun0 tcpdump: listening on tun0, link-type EN10MB 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124: LACPv1, length: 110 I guess 01:80:c2:00:00:02 is not sent to the other side is this normal , a tun should forward broadcast, should it not ? *go read qemu socket node* If it is configured with the link0 option, yes. -- Giancarlo Razzolini GPG: 4096R/77B981BC
