From nobody@FreeBSD.org  Wed May 30 08:21:29 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 3826216A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 30 May 2007 08:21:29 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 0DC3813C448
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 30 May 2007 08:21:29 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l4U8LSc5081493
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 30 May 2007 08:21:28 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l4U8LSP7081492;
	Wed, 30 May 2007 08:21:28 GMT
	(envelope-from nobody)
Message-Id: <200705300821.l4U8LSP7081492@www.freebsd.org>
Date: Wed, 30 May 2007 08:21:28 GMT
From: Leon Kos<leon.kos@lecad.uni-lj.si>
To: freebsd-gnats-submit@FreeBSD.org
Subject: lagg interface fails to work with some unmanaged switches
X-Send-Pr-Version: www-3.0

>Number:         113150
>Category:       kern
>Synopsis:       [lagg] lagg interface fails to work with some unmanaged switches
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    thompsa
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 30 08:30:01 GMT 2007
>Closed-Date:    Thu Aug 02 09:11:20 GMT 2007
>Last-Modified:  Thu Aug 02 09:11:20 GMT 2007
>Originator:     Leon Kos
>Release:        RELENG_6
>Organization:
University of Ljubljana, Slovenia
>Environment:
FreeBSD cad.lecad.uni-lj.si 6.2-STABLE FreeBSD 6.2-STABLE #3: Wed May 23 14:45:31 CEST 2007     ledon@cad.lecad.uni-lj.si:/usr/obj/usr/src/sys/CAD  i386
>Description:
I have trouble with EtherChannel mode FEC and LACP. Packet flow through lagg device does not pass throug some older 1GBIT switches. Creating netgraph FEC does work with older switches! So the problem must be with lagg interface.
 
My setup:
 
FreeBSD-<  EtherChannel  > Cisco WS-3560G-EI -- Unmanaged 1GBIT switch -- PC
 
Replacing Unmanaged 1Gbit switch with some "smart" switch or dumb 100Mbit switch passes ping packets through. If I replace lagg0 with netgraph fec0 device it also works.

Really strange. It looks like layer 2 problem. Ping does not pass though switch. ARP requests on PC are unreplied.

Tested with 5 switches.Two of them, both 1Gbit does not work.

Lowering MTU to 1400 does not help.

Missing forwarding mode for FEC (inet or MAC) on lagg?
>How-To-Repeat:
hardware specific.


Create etherchannel on Cisco switch ports 1&2 on vlan 100 with:

 configure terminal
 interface range gigabitethernet 0/1 - 2
 switchport mode access
 switchport access vlan 100
 channel group 1 mode on
 end

Create lagg0 device with etherchannel dual port card with:

 ifconfig lagg create
 ifconfig em0 up
 ifconfig em1 up
 ifconfig lagg0 laggproto fec laggport em0 laggport em1 192.168.10.1

Configure PC with 
  ifconfig eth0 192.168.10.2

Place "unmanaged 1Gbit switch" between PC and some Cisco port on VLAN 100
and try ping.

The same problem occurs allso if using LACP on lagg0. Without using lagg and using only em0 works.


>Fix:
a) Replace "unmanaged 1Gbit switch" with some smart switch or unmanaged 100Mbit switch.

a1) PC connected directly to Cisco switch also works.

b) Use ng_fec device and configure it with:

 /usr/sbin/ngctl mkpeer fec dummy fec
 /usr/sbin/ngctl msg fec0: add_iface '"em0"'
 /usr/sbin/ngctl msg fec0: add_iface '"em1"'
 /usr/sbin/ngctl msg fec0: set_mode_mac
 ifconfig fec0 192.168.10.1

 This works with all switches. Not so fast as lagg though :(




>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->thompsa 
Responsible-Changed-By: thompsa 
Responsible-Changed-When: Wed May 30 08:40:30 UTC 2007 
Responsible-Changed-Why:  
Thanks for the report, I will look into this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=113150 

From: Andrew Thompson <thompsa@FreeBSD.org>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: lagg interface fails to work with some unmanaged switches
Date: Wed, 30 May 2007 21:14:02 +1200

 Hi,
 
 Can you please give me a bit of debugging info
 
 1. Is the ARP request received by the FreeBSD server and a reply send to
    the PC?  This can be checked by running tcpdump on the lagg0
    interface and please include the output in the reply
 
 2. Can you send the output from 'ifconfig' on the FreeBSD server and
    'show etherchannel summary' on the Cisco for both the lagg and ng_fec
    cases.
 
 thanks,
 Andrew

From: Leon Kos <leon.kos@lecad.uni-lj.si>
To: bug-followup@FreeBSD.org
Cc: Andrew Thompson <thompsa@FreeBSD.org>
Subject: Re: kern/113150: lagg interface fails to work with some unmanaged
 switches
Date: Wed, 30 May 2007 16:01:55 +0200 (CEST)

 Switch#show etherchannel summary
 Flags:  D - down        P - in port-channel
          I - stand-alone s - suspended
          H - Hot-standby (LACP only)
          R - Layer3      S - Layer2
          U - in use      f - failed to allocate aggregator
          u - unsuitable for bundling
          w - waiting to be aggregated
          d - default port
 
 
 Number of channel-groups in use: 1
 Number of aggregators:           1
 
 Group  Port-channel  Protocol    Ports
 ------+-------------+-----------+-----------------------------------------------
 1      Po1(SU)          -        Gi0/1(P)    Gi0/2(P)
 
 
 
 
 root@cad:~# ifconfig lagg0
 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect
          status: active
          lagg: laggproto fec
                  laggport em1 =4<ACTIVE>
                  laggport em0 =4<ACTIVE>
 
 root@cad:~# ifconfig em0
 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          options=b<RXCSUM,TXCSUM,VLAN_MTU>
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect (1000baseTX <full-duplex>)
          status: active
          lagg: laggdev lagg0
 
 root@cad:~# ifconfig em1
 em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          options=b<RXCSUM,TXCSUM,VLAN_MTU>
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect (1000baseTX <full-duplex>)
          status: active
          lagg: laggdev lagg0
 
 
 Another subproblem with lagg interface.
 
 Using wireshark or tcpdump on lagg0 disables ping although it is shown in
 log. For example pinging on one terminal and capturing on other does:
 leon@cad:~$ ping 192.168.10.2
 PING 192.168.10.2 (192.168.10.2): 56 data bytes
 ^C
 --- 192.168.10.2 ping statistics ---
 10 packets transmitted, 0 packets received, 100% packet loss
 
 [root@cad ~]# tcpdump -i lagg0
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on lagg0, link-type EN10MB (Ethernet), capture size 96 bytes
 13:39:07.835994
 13:39:10.101050 CDPv2, ttl: 180s, Device-ID 'Switch'[|cdp]
 13:39:16.140763
 13:39:17.842257
 13:39:20.771584 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 0, length 64
 13:39:20.771815 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 0, length 64
 13:39:21.788823 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 1, length 64
 13:39:21.788954 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 1, length 64
 13:39:22.807802 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 2, length 64
 13:39:22.807984 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 2, length 64
 13:39:23.827174 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 3, length 64
 13:39:23.827386 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 3, length 64
 13:39:24.846298 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 4, length 64
 13:39:24.846414 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 4, length 64
 13:39:25.768249 arp who-has 192.168.10.1 tell 192.168.10.2
 13:39:25.864045 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 5, length 64
 13:39:25.876430 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 5, length 64
 13:39:26.138778
 13:39:26.768288 arp who-has 192.168.10.1 tell 192.168.10.2
 13:39:26.883591 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 6, length 64
 13:39:26.883718 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 6, length 64
 13:39:27.768328 arp who-has 192.168.10.1 tell 192.168.10.2
 13:39:27.843398
 13:39:27.901725 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 7, length 64
 13:39:27.901994 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 7, length 64
 13:39:28.920226 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 8, length 64
 13:39:28.924397 arp who-has 192.168.10.1 tell 192.168.10.2
 13:39:28.924408 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 13:39:28.924520 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 8, length 64
 13:39:29.938631 IP 192.168.10.1 > 192.168.10.2: ICMP echo request, id 28786, 
 seq 9, length 64
 13:39:29.938807 IP 192.168.10.2 > 192.168.10.1: ICMP echo reply, id 28786, 
 seq 9, length 64
 13:39:36.147545
 13:39:37.849167
 ^C
 33 packets captured
 33 packets received by filter
 0 packets dropped by kernel
 
 
 
 When setting "ifconfig lagg0 promisc" lagg0 shows
 lagg0: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> 
 mtu 1500
          inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect
          status: active
          lagg: laggproto fec
                  laggport em1 =4<ACTIVE>
                  laggport em0 =4<ACTIVE>
 
 and ping goes through when capturing with tcpdump.
 
 
 When using "unmanaged switch" in the middle ping still does not go through 
 althoug tcpdump on FreeBSD does show the following:
 # tcpdump -i lagg0
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on lagg0, link-type EN10MB (Ethernet), capture size 96 bytes
 15:00:58.645167
 15:01:00.330766 CDPv2, ttl: 180s, Device-ID 'Switch'[|cdp]
 15:01:00.346625
 15:01:08.642212
 15:01:10.336785 CDPv2, ttl: 180s, Device-ID 'Switch'[|cdp]
 15:01:10.353169
 15:01:16.774063 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:16.774078 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:17.773991 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:17.774004 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:18.649758
 15:01:18.773921 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:18.773949 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:19.781847 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:19.781860 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:20.359718
 15:01:20.781652 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:20.781663 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:21.781584 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:21.781595 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:22.789508 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:22.789520 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:23.789438 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:23.789451 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:24.789253 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:24.789275 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:25.797171 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:25.797183 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:26.797103 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:26.797119 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:27.797032 arp who-has 192.168.10.1 tell 192.168.10.2
 15:01:27.797045 arp reply 192.168.10.1 is-at 00:04:23:df:69:ae (oui Unknown)
 15:01:28.655312
 15:01:30.358028
 15:01:38.661744
 15:01:40.364461
 ^C
 36 packets captured
 36 packets received by filter
 0 packets dropped by kernel
 
 Looks like ARP request are receive and replied, but lost somehow on the way 
 back. Cisco Discovery Protocol is detected on both sides (FreeBSD and PC).
 
 ------------------------------------------------------------------------------
 The following tests are performed with netgraph_fec
 # ifconfig lagg0 -laggport em0 -laggport em1 laggproto none
 # ifconfig lagg0 destroy
 root@cad:~# ngctl mkpeer fec dummy fec
 root@cad:~# ngctl msg fec0: add_iface '"em0"'
 root@cad:~# ngctl msg fec0: add_iface '"em1"'
 root@cad:~# ngctl msg fec0: set_mode_mac
 root@cad:~# ifconfig fec0 192.168.10.1
 root@cad:~# ifconfig fec0
 fec0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
          ether 00:04:23:df:69:ae
          media: Ethernet none
          status: active
 root@cad:~# ifconfig em0
 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          options=b<RXCSUM,TXCSUM,VLAN_MTU>
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect (1000baseTX <full-duplex>)
          status: active
 root@cad:~# ifconfig em1
 em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          options=b<RXCSUM,TXCSUM,VLAN_MTU>
          ether 00:04:23:df:69:ae
          media: Ethernet autoselect (1000baseTX <full-duplex>)
          status: active
 
 
 Pinging from PC to FreeBSD shows the following
 root@cad:~# tcpdump -i fec0
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on fec0, link-type EN10MB (Ethernet), capture size 96 bytes
 15:15:26.207626 IP 192.168.10.2 > 192.168.10.1: ICMP echo request, id 34859, 
 seq 1, length 64
 15:15:26.207649 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id 34859, 
 seq 1, length 64
 15:15:27.206711 IP 192.168.10.2 > 192.168.10.1: ICMP echo request, id 34859, 
 seq 2, length 64
 15:15:27.206734 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id 34859, 
 seq 2, length 64
 15:15:28.206797 IP 192.168.10.2 > 192.168.10.1: ICMP echo request, id 34859, 
 seq 3, length 64
 15:15:28.206817 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id 34859, 
 seq 3, length 64
 15:15:29.206758 IP 192.168.10.2 > 192.168.10.1: ICMP echo request, id 34859, 
 seq 4, length 64
 15:15:29.206776 IP 192.168.10.1 > 192.168.10.2: ICMP echo reply, id 34859, 
 seq 4, length 64
 ^C
 8 packets captured
 8 packets received by filter
 0 packets dropped by kernel
 
 Everything works. No promisc force on fec0 required for tcpdump.
 
 
 PC (Compaq nc8430 laptop with latest linux kernel) has the folowing
 duo:~# ifconfig eth6
 eth6      Link encap:Ethernet  HWaddr 00:17:A4:D0:65:D7
            inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
            inet6 addr: fe80::217:a4ff:fed0:65d7/64 Scope:Link
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:257 errors:0 dropped:0 overruns:0 frame:0
            TX packets:621 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:21638 (21.1 KiB)  TX bytes:62327 (60.8 KiB)
            Interrupt:16
 
 Unknown oui to tcpdump belongs to
 00-17-A4   (hex)		Global Data Services
 
 I have also tested latest "em" drivers from Intel site without any 
 notable difference.
 
 Kind regards,
 
 Leon Kos, CAD lab, Mech.Eng., University of Ljubljana, Slovenia
 (http://www.lecad.uni-lj.si/~leon)
 
 

From: Leon Kos <leon.kos@lecad.uni-lj.si>
To: Andrew Thompson <thompsa@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Subject: Re: kern/113150: lagg interface fails to work with some unmanaged
 switches
Date: Tue, 5 Jun 2007 11:55:16 +0200 (CEST)

 Some performance testings on Intel Server Board SE7520BD2 with two
 different/similar "em" dual NIC server cards. One is with PCI-X and other is 
 PCIe.
 
 
 PCI-X NIC is connected through PXH bridge to MCH bridge that handles
 PCIe bus direcly. Comparison of PCI-X and PCIe showed no notable performance
 difference anthough we anticipated that we will overcome "hardware" limit
 of 1.2Gbit/sec when measuring concurrent transfer from two clients to server.
 Sadly this is not true.
 
 I have also tested performance of ng_fec and lagg device in EtherChannel
 configuration using FEC and LACP protocol. Tests also show no notable
 difference.
 
 Performance tests with configuration to Cicso WS-3560G-E should theoreticly 
 show 2Gbit/sec thougput. But after some testing we concluded that we are 
 somehow limited by hardware/software to max 1.2 Gbit/sec for concurent
 transfer even if EtherChannel was not used at all.
 
 I have also tried Intel drivers for FreeBSD v6.4.1 without notable change. 
 Problem with lagg device and some "unmanaged" switches remain.
 
 The following performance tests are in Mbit/s as reported on two clients 
 with command
 
 iperf -c 192.168.10.1 -t 30
 
 to server.
 
 Label 1. means single computer iperf report, while 2. means concurrent 
 iperf measure from two computers with different MAC address as 
 verified with "test etherchannel load interface port 1 MAC" on Cisco
 
 ng_fec, PCI-X
 1. 903
 2. 621+573=1194
 
 ng_fec, PCI-e
 1. 911
 2. 621+641=1262
 
 ng_fec, PCIe, em6.4.1
 1. 902
 2. 624+599=1223
 
 lagg, PCIe, em6.4.1
 1. 902
 2. 566+526=1092
 
 lagg, LACP, PCI-X
 1. 916
 2. 600+607=1207
 
 lagg, LACP, PCI-X
 1. 926
 2. 570+646=1216
 
 Without EtherChannel, two clients on different subnet direcly.
 em6.4.1
 1. em0 max 916
 1. em1 max 928
 
 stock driver FreeBSD 6.2
 1. em0, em1 max 930
 2. em0+em1=602+630=1232
 
 through Cisco
 em0+em1 649+579=1228
 
 On board card "em2" on PCI32/33 bus handle max 737 Mbit/sec.
 
 Is here any additional info that I can provide to solve "my" lagg problem.
 Any comment to performance tests?
 
 Kind regards,
 
 Leon Kos, CAD lab, Mech.Eng., University of Ljubljana, Slovenia
 (http://www.lecad.uni-lj.si/~leon)
 
 

From: Andrew Thompson <thompsa@FreeBSD.org>
To: Leon Kos <leon.kos@lecad.uni-lj.si>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/113150: lagg interface fails to work with some unmanaged switches
Date: Fri, 8 Jun 2007 13:33:44 +1200

 On Wed, May 30, 2007 at 04:01:55PM +0200, Leon Kos wrote:
 > root@cad:~# ifconfig lagg0
 > lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 >         inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
 >         ether 00:04:23:df:69:ae
 >         media: Ethernet autoselect
 >         status: active
 >         lagg: laggproto fec
 >                 laggport em1 =4<ACTIVE>
 >                 laggport em0 =4<ACTIVE>
 
 Thanks for the information. Can you tell me if it makes a difference if
 the lagg0 interface is put into promisc mode (ifconfig lagg0 promisc),
 em0 and em1 should also go promisc at the same time.
 
 
 
 regards,
 Andrew

From: "Leon Kos" <leon.kos@lecad.uni-lj.si>
To: "Andrew Thompson" <thompsa@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/113150: lagg interface fails to work with some unmanaged 
     switches
Date: Fri, 8 Jun 2007 22:12:01 +0200 (CEST)

 It makes no difference.  Both (em0 and em1) go into PROMISC at the same
 time as lagg0.
 
 root@cad:~# ifconfig lagg0
 lagg0:
 flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> mtu
 1500
         inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
         ether 00:04:23:df:69:ae
         media: Ethernet autoselect
         status: active
         lagg: laggproto fec
                 laggport em1 =4<ACTIVE>
                 laggport em0 =4<ACTIVE>
 root@cad:~# ifconfig em0
 em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
         options=b<RXCSUM,TXCSUM,VLAN_MTU>
         ether 00:04:23:df:69:ae
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 root@cad:~# ifconfig em1
 em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
         options=b<RXCSUM,TXCSUM,VLAN_MTU>
         ether 00:04:23:df:69:ae
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 root@cad:~#
 
 
 It does not help even if I have only one laggport (em0 or em1).
 
 Again; fec0 works like a charm
 root@cad:~# ifconfig fec0
 fec0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
         ether 00:04:23:df:69:ae
         media: Ethernet none
         status: active
 
 Tnx,
 Leon.

From: Andrew Thompson <thompsa@FreeBSD.org>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some unmanaged switches
Date: Fri, 13 Jul 2007 10:13:08 +1200

 --OXfL5xGRrasGEqWY
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Hi,
 
 
 I have found the problem with lagg on RELENG_6, the following patch
 should fix it for you. I will be testing this and committing shortly
 anyway.
 
 
 cheers,
 Andrew
 
 --OXfL5xGRrasGEqWY
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="if.c.diff"
 
 Index: net/if.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/net/if.c,v
 retrieving revision 1.234.2.20
 diff -u -p -r1.234.2.20 if.c
 --- net/if.c	7 Jul 2007 00:54:46 -0000	1.234.2.20
 +++ net/if.c	12 Jul 2007 22:10:39 -0000
 @@ -2202,6 +2202,7 @@ if_setlladdr(struct ifnet *ifp, const u_
  	case IFT_ISO88025:
  	case IFT_L2VLAN:
  	case IFT_BRIDGE:
 +	case IFT_IEEE8023ADLAG:
  		bcopy(lladdr, IFP2ENADDR(ifp), len);
  		/*
  		 * XXX We also need to store the lladdr in LLADDR(sdl),
 @@ -2210,7 +2211,6 @@ if_setlladdr(struct ifnet *ifp, const u_
  		 */
  		/* FALLTHROUGH */
  	case IFT_ARCNET:
 -	case IFT_IEEE8023ADLAG:
  		bcopy(lladdr, LLADDR(sdl), len);
  		break;
  	default:
 
 --OXfL5xGRrasGEqWY--

From: Frank Bartels <freebsd@knarf.de>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some
	unmanaged switches
Date: Mon, 16 Jul 2007 13:04:57 +0200

 Heya,
 
 two days ago I started using lagg(4) and I noticed the same problem.
 The lagg-PC is not able to reach the PCs behind an unmanaged gigabit
 switch (here: Netgear GS116)
 
 I really wondered what's going on, but as my main switch is a Netgear
 GS724Tv2 "smart switch" (being not so smart), I decided to test it
 with a Cisco 2924XL later.
 
 But now I see the problem seems to be a FreeBSD issue.
 
 FreeBSD country.server-king.de 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Jul 14 20:05:31 CEST 2007     knarf@country.server-king.de:/usr/obj/usr/src/sys/COUNTRY  i386
 
 % ident /usr/src/sys/net/if.c
 /usr/src/sys/net/if.c:
      $FreeBSD: src/sys/net/if.c,v 1.234.2.21 2007/07/13 01:26:44 thompsa Exp $
 
 This means Andrew Thompsons patch was already applied.
 
 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=b<RXCSUM,TXCSUM,VLAN_MTU>
         ether 00:07:e9:a0:13:a1
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=b<RXCSUM,TXCSUM,VLAN_MTU>
         ether 00:07:e9:a0:13:a1
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 82.135.106.31 netmask 0xffffffc0 broadcast 82.135.106.63
         ether 00:07:e9:a0:13:a1
         media: Ethernet autoselect
         status: active
         laggproto lacp
         laggport: em1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
         laggport: em0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
 
 Knarf

From: Andrew Thompson <thompsa@freebsd.org>
To: Frank Bartels <freebsd@knarf.de>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some unmanaged switches
Date: Tue, 17 Jul 2007 09:27:12 +1200

 On Mon, Jul 16, 2007 at 11:50:07AM +0000, Frank Bartels wrote:
 >  two days ago I started using lagg(4) and I noticed the same problem.
 >  The lagg-PC is not able to reach the PCs behind an unmanaged gigabit
 >  switch (here: Netgear GS116)
 >  
 >  I really wondered what's going on, but as my main switch is a Netgear
 >  GS724Tv2 "smart switch" (being not so smart), I decided to test it
 >  with a Cisco 2924XL later.
 
 Interesting. Can you please give be a rough outline of the network, such
 as PC -lacp- CiscoXXX -- Netgear -- PC.
 
 Are you able to test this with any hardware running CURRENT? also any
 tcpdump traces showing where the packets are disappearing would be
 helpful. Do the outgoing packets have the correct MAC src and dst
 addresses, you can see this with the -e flag on tcpdump.
 
 Any further info would be helpful. Thank you both for reporting this, I
 _really_ want to get this fixed.
 
 
 cheers,
 Andrew

From: Frank Bartels <freebsd@knarf.de>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some
	unmanaged switches
Date: Tue, 17 Jul 2007 23:39:28 +0200

 --AqsLC8rIMeq19msA
 Content-Type: text/plain; charset=iso-8859-15
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jul 17, 2007 at 09:27:12 +1200, Andrew Thompson wrote:
 > On Mon, Jul 16, 2007 at 11:50:07AM +0000, Frank Bartels wrote:
 > >  two days ago I started using lagg(4) and I noticed the same problem.
 > >  The lagg-PC is not able to reach the PCs behind an unmanaged gigabit
 > >  switch (here: Netgear GS116)
 > > =20
 > >  I really wondered what's going on, but as my main switch is a Netgear
 > >  GS724Tv2 "smart switch" (being not so smart), I decided to test it
 > >  with a Cisco 2924XL later.
 >=20
 > Interesting. Can you please give be a rough outline of the network, such
 > as PC -lacp- CiscoXXX -- Netgear -- PC.
 
 FreeBSD-PC1 -lacp- GS724Tv2 - FreeBSD-PC2 works fine
 FreeBSD-PC1 -lacp- GS724Tv2 -lacp- Cisco2924XL - FreeBSD-PC3 works fine
 
 FreeBSD-PC1 -lacp- GS724Tv2 - GS116 - FreeBSD-PC4 does not work
 
 Netgear GS724Tv2 is running the same type of trunking to the
 Cisco2924XL (which works fast and stable).
 
 > Are you able to test this with any hardware running CURRENT?
 
 Yes, I am. My (very slow) -current-test machine is just building a
 new world and is waiting for two re-cards to get built in. I will
 tell you about the results as soon as possible.
 
 > also any
 > tcpdump traces showing where the packets are disappearing would be
 > helpful. Do the outgoing packets have the correct MAC src and dst
 > addresses, you can see this with the -e flag on tcpdump.
 
 22:53:07.520010 00:00:00:00:00:00 (oui Ethernet) > 00:07:e9:a0:12:d1 (oui U=
 nknown), ethertype IPv4 (0x0800), length 98: country.server-king.de > edgar=
 1.server-king.de: ICMP echo request, id 34144, seq 0, length 64
 22:54:41.085398 00:0e:a6:6e:a2:0e (oui Unknown) > Broadcast, ethertype ARP =
 (0x0806), length 60: arp who-has edgar1.server-king.de tell bkoo1.server-ki=
 ng.de
 22:54:50.949961 00:07:e9:a0:12:d1 (oui Unknown) > Broadcast, ethertype ARP =
 (0x0806), length 60: arp who-has country.server-king.de tell edgar1.server-=
 king.de
 22:54:50.949979 00:00:00:00:00:00 (oui Ethernet) > 00:07:e9:a0:12:d1 (oui U=
 nknown), ethertype ARP (0x0806), length 42: arp reply country.server-king.d=
 e is-at 00:07:e9:a0:13:a1 (oui Unknown)
 
 Thanks for the hint to the -e option. I tried this on lagg0 but
 while running tcpdump -i lagg0 it seems every network operation
 gets impossible. I had to go to the console, ^C the tcpdump (which
 took many seconds) and after that everything was okay again.
 
 So I ran tcpdump on em0 and em1 simultaneously, the log ist just
 sorted by time. em0 was sending the packets and em1 was receiving.
 country is the lagg-host and edgar1 the host behind the unmanaged
 switch (eek, now you know some of my hostnames! :).
 
 The arp entry never arrives on the host behind the unmanaged switch.
 
 country.server-king.de (82.135.106.31) at (incomplete) on em0 [ethernet]
 
 I do not read tcpdump every day, so I cannot answer your next
 questions in advance. :)
 
 > Any further info would be helpful. Thank you both for reporting this, I
 > _really_ want to get this fixed.
 
 I like to hear that as I plan to use lagg everywhere when 6.3 is out. :)
 
 Knarf
 
 --AqsLC8rIMeq19msA
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (FreeBSD)
 
 iD8DBQFGnTcP3N92+OaFVBwRAm5bAJ0W4iSON4Fx4/39wD1SYBkigadBbgCeI1dF
 BoVEszyeri+MwRpEEag5OrU=
 =FzM/
 -----END PGP SIGNATURE-----
 
 --AqsLC8rIMeq19msA--

From: Frank Bartels <knarf@knarf.de>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some
	unmanaged switches
Date: Sun, 22 Jul 2007 13:38:28 +0200

 > > Are you able to test this with any hardware running CURRENT?
 > 
 > Yes, I am. My (very slow) -current-test machine is just building a
 > new world and is waiting for two re-cards to get built in. I will
 > tell you about the results as soon as possible.
 
 FreeBSD sourcream 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Wed Jul 18 13:04:40 CEST 2007     knarf@sourcream:/usr/obj/usr/src/sys/SOURCREAM  i386
 
 re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:18:4d:79:54:11
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:18:4d:79:54:11
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
         lagg: laggdev lagg0
 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         ether 00:18:4d:79:54:11
         inet 82.135.106.19 netmask 0xffffffc0 broadcast 82.135.106.63
         media: Ethernet autoselect
         status: active
         laggproto lacp
         laggport: re1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
         laggport: re0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
 
 And yes: This one is working!
 
 The em0/em1/lagg0 on my 6.2-STABLE (20070720) is not. So it seems
 to be an MFC issue.
 
 Is there any further information I can provide?
 
 Knarf

From: Andrew Thompson <thompsa@FreeBSD.org>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si,
	Frank Bartels <knarf@knarf.de>
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some unmanaged switches
Date: Mon, 23 Jul 2007 11:39:05 +1200

 --zhXaljGHf11kAtnf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Hi,
 
 
 I was indeed a MFC issue, please test this patch.
 
 
 cheers,
 Andrew
 
 --zhXaljGHf11kAtnf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="lagg_lladdr_r6.diff"
 
 Index: if_lagg.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/net/if_lagg.c,v
 retrieving revision 1.11.2.3
 diff -u -p -r1.11.2.3 if_lagg.c
 --- if_lagg.c	12 Jul 2007 20:40:24 -0000	1.11.2.3
 +++ if_lagg.c	22 Jul 2007 23:27:30 -0000
 @@ -17,7 +17,7 @@
   */
  
  #include <sys/cdefs.h>
 -__FBSDID("$FreeBSD$");
 +__FBSDID("$FreeBSD: src/sys/net/if_lagg.c,v 1.3 2007/05/03 08:56:20 thompsa Exp $");
  
  #include "opt_inet.h"
  #include "opt_inet6.h"
 @@ -319,6 +319,7 @@ lagg_lladdr(struct lagg_softc *sc, uint8
  	if (memcmp(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN) == 0)
  		return;
  
 +	bcopy(lladdr, IFP2ENADDR(ifp), ETHER_ADDR_LEN);
  	bcopy(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN);
  	/* Let the protocol know the MAC has changed */
  	if (sc->sc_lladdr != NULL)
 
 --zhXaljGHf11kAtnf--

From: Frank Bartels <freebsd@knarf.de>
To: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some
	unmanaged switches
Date: Sun, 29 Jul 2007 12:30:21 +0200

 --VbJkn9YxBvnuCH5J
 Content-Type: text/plain; charset=iso-8859-15
 Content-Disposition: inline
 
 > I was indeed a MFC issue, please test this patch.
 
 Now it's okay, thank you very much!
 
 Knarf
 
 --VbJkn9YxBvnuCH5J
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (FreeBSD)
 
 iD8DBQFGrGw93N92+OaFVBwRAvxsAJ9jq3Mc5XWwSlubgem5dlxAPJ/QmQCgr3vs
 uYfJfZ8uv3j6Hwm5gwD59Vg=
 =HATO
 -----END PGP SIGNATURE-----
 
 --VbJkn9YxBvnuCH5J--

From: Carlos Fernando Assis Paniago <Carlos.Paniago@cnptia.embrapa.br>
To: bug-followup@FreeBSD.org,  leon.kos@lecad.uni-lj.si
Cc:  
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some unmanaged
 switches
Date: Wed, 01 Aug 2007 19:04:28 -0300

 This is a multi-part message in MIME format.
 --------------080108030906050602040700
 Content-Type: text/plain; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Hi. the patch2.diff is only half applied in the code in a 6.2 STABLE 
 machine:
 
 Index: if_lagg.c
 ==================================================================
 RCS file: /home/ncvs/src/sys/net/if_lagg.c,v
 retrieving revision 1.11.2.3
 diff -u -p -r1.11.2.3 if_lagg.c
 --- if_lagg.c    12 Jul 2007 20:40:24 -0000      1.11.2.3
 +++ if_lagg.c    22 Jul 2007 23:27:30 -0000
 @@ -17,7 +17,7 @@
    */
 
   #include <sys/cdefs.h>
 -__FBSDID("$FreeBSD$");
 +__FBSDID("$FreeBSD: src/sys/net/if_lagg.c,v 1.3 2007/05/03 08:56:20 
 thompsa Exp $");
 
   #include "opt_inet.h"
   #include "opt_inet6.h"
 @@ -319,6 +319,7 @@ lagg_lladdr(struct lagg_softc *sc, uint8
           if (memcmp(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN) == 0)
                   return;
 
 +        bcopy(lladdr, IFP2ENADDR(ifp), ETHER_ADDR_LEN);
           bcopy(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN);
           /* Let the protocol know the MAC has changed */
           if (sc->sc_lladdr != NULL)
 
 The bcopy is there but not the __FBSDID("$FreeBSD: 
 src/sys/net/if_lagg.c,v 1.3 2007/05/03 08:56:20 thompsa Exp $");
 
 Could be this a problem???
 
 Paniago
 
 --------------080108030906050602040700
 Content-Type: text/x-vcard; charset=utf-8;
  name="Carlos.Paniago.vcf"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="Carlos.Paniago.vcf"
 
 YmVnaW46dmNhcmQNCmZuOkNhcmxvcyBGLiBBLiBQYW5pYWdvDQpuOkFzc2lzIFBhbmlhZ287
 Q2FybG9zIEZlcm5hbmRvDQpvcmc7cXVvdGVkLXByaW50YWJsZTpFbWJyYXBhIEluZm9ybT1D
 Mz1BMXRpY2EgQWdyb3BlY3U9QzM9QTFyaWE7U3Vwb3J0ZSBDb21wdXRhY2lvbmFsDQphZHI7
 cXVvdGVkLXByaW50YWJsZTtxdW90ZWQtcHJpbnRhYmxlO3F1b3RlZC1wcmludGFibGU6QmFy
 PUMzPUEzbyBHZXJhbGRvOztBdi4gQW5kcj1DMz1BOSBUb3NlbGxvLCAyMDkgLSBDYW1wdXMg
 VW5pY2FtcDtDYW1waW5hcztTPUMzPUEzbyBQYXVsbzsxMzA4My04ODY7QnJhc2lsDQplbWFp
 bDtpbnRlcm5ldDpDYXJsb3MuUGFuaWFnb0BjbnB0aWEuZW1icmFwYS5icg0KdGl0bGU6QW5h
 bGlzdGEgQQ0KdGVsO3dvcms6NTUgKDE5KSAzNzg5LTU4MTUNCnRlbDtmYXg6NTUgKDE5KSAz
 Mjg5LTk1OTQNCm5vdGU7cXVvdGVkLXByaW50YWJsZTpBdmlzbyBkZSBjb25maWRlbmNpYWxp
 ZGFkZTo9MEQ9MEE9DQoJLSBFc3RhIG1lbnNhZ2VtIGRhIEVtcHJlc2EgQnJhc2lsZWlyYSBk
 ZSBQZXNxdWlzYSBBZ3JvcGVjdT1DMz1BMXJpYSAoRW1icj0NCglhcGEpLCBlbXByZXNhIHA9
 QzM9QkFibGljYSBmZWRlcmFsIHJlZ2lkYSBwZWxvIGRpc3Bvc3RvIG5hIExlaSBGZWRlcmFs
 bj1DMj0NCgk9QkEgNS44NTEsIGRlIDcgZGUgZGV6ZW1icm8gZGUgMTk3MiwgPUMzPUE5IGVu
 dmlhZGEgZXhjbHVzaXZhbWVudGVhIHNldT0NCgkgZGVzdGluYXQ9QzM9QTFyaW8gZSBwb2Rl
 IGNvbnRlciBpbmZvcm1hPUMzPUE3PUMzPUI1ZXMgY29uZmlkZW5jaWFpcywgcHJvPQ0KCXRl
 Z2lkYXMgcG9yIHNpZ2lsbyBwcm9maXNzaW9uYWwuIFN1YSB1dGlsaXphPUMzPUE3PUMzPUEz
 byBkZXNhdXRvcml6YWRhPQ0KCSA9QzM9QTkgaWxlZ2FsIGUgc3VqZWl0YSBvIGluZnJhdG9y
 ID1DMz1BMHMgcGVuYXMgZGEgbGVpLiBTZSB2b2M9QzM9QUFhPQ0KCSByZWNlYmV1IGluZGV2
 aWRhbWVudGUsIHF1ZWlyYSwgcG9yIGdlbnRpbGV6YSwgcmVlbnZpPUMzPUExLWxhIGFvIGVt
 aXRlbnQ9DQoJZSwgZXNjbGFyZWNlbmRvIG8gZXF1PUMzPUFEdm9jby49MEQ9MEE9DQoJPTBE
 PTBBPQ0KCUNvbmZpZGVudGlhbGl0eSBub3RlOj0wRD0wQT0NCgktIFRoaXMgbWVzc2FnZSBm
 cm9tIEVtcHJlc2EgQnJhc2lsZWlyYSBkZSBQZXNxdWlzYSBBZ3JvcGVjdT1DMz1BMXJpYSAo
 RW1iPQ0KCXJhcGEpIGEgZ292ZXJubWVudCBjb21wYW55IGVzdGFibGlzaGVkIHVuZGVyIEJy
 YXppbGlhbiBsYXcgKDUuODUxLzcyKSBpc2Q9DQoJaXJlY3RlZCBleGNsdXNpdmVseSB0byBp
 dHMgYWRkcmVzc2UgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBkYXRhLHBybz0NCgl0
 ZWN0ZWQgdW5kZXIgcHJvZmVzc2lvbmFsIHNlY3JlY3kgcnVsZXMuIEl0cyB1bmF1dGhvcml6
 ZWQgdXNlIGlzIGlsbGVnYWw9DQoJIGFuZCBtYXkgc3ViamVjdCB0aGUgdHJhbnNncmVzc29y
 IHRvIHRoZSBsYXcncyBwZW5hbHRpZXMuIElmIHlvdSdyZW5vdD0NCgkgdGhlIGFkZHJlc3Nl
 LCBwbGVhc2Ugc2VuZCBpdCBiYWNrLCBlbHVjaWRhdGluZyB0aGUgZmFpbHVyZS4gDQp1cmw6
 aHR0cDovL3d3dy5jbnB0aWEuZW1icmFwYS5ici8NCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQN
 Cg0K
 --------------080108030906050602040700--

From: Leon Kos <leon.kos@lecad.uni-lj.si>
To: Andrew Thompson <thompsa@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, leon.kos@lecad.uni-lj.si,
        Frank Bartels <knarf@knarf.de>
Subject: Re: kern/113150: [lagg] lagg interface fails to work with some
 unmanaged switches
Date: Thu, 2 Aug 2007 09:52:56 +0200 (CEST)

 I am also reporting that now it works. I have tested with laggproto FEC and 
 LACP as explained before.
 
 I do not understand what MFC issue means. Could you please explain?
 
 Anyway, I suggest to close the ticket.
 
 Lep pozdrav!
 
 Leon Kos, CAD lab, Mech.Eng., University of Ljubljana, Slovenia
 (http://www.lecad.uni-lj.si/~leon)
 
 
 On Mon, 23 Jul 2007, Andrew Thompson wrote:
 
 > Hi,
 >
 >
 > I was indeed a MFC issue, please test this patch.
 >
 >
 > cheers,
 > Andrew
 >
State-Changed-From-To: open->closed 
State-Changed-By: thompsa 
State-Changed-When: Thu Aug 2 09:10:32 UTC 2007 
State-Changed-Why:  
Problem has been fixed in RELENG_6, thanks to all the testers. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=113150 
>Unformatted:
