From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 09:50:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AC5A5C8 for ; Fri, 17 Jan 2014 09:50:33 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF5C1145 for ; Fri, 17 Jan 2014 09:50:32 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 89DA03A82CA; Fri, 17 Jan 2014 10:50:23 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 11.6024] X-CRM114-CacheID: sfid-20140117_10501_8A60406E X-CRM114-Status: Good ( pR: 11.6024 ) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Jan 17 10:50:23 2014 X-DSPAM-Confidence: 0.9923 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d8fcdf486711946516935 X-DSPAM-Factors: 27, the+port, 0.00406, the+port, 0.00406, fixes, 0.00439, inet, 0.00439, From*"Nagy, Attila" , 0.00527, Received*online.co.hu+[195.228.243.99]), 0.00657, Received*[195.228.243.99]), 0.00657, Received*online.co.hu, 0.00657, the+host, 0.00657, Received*(japan.t, 0.00657, Received*(japan.t+online.co.hu, 0.00657, at+09, 0.00751, 17+08, 0.00875, Received*from+japan.t, 0.00875, but+I'm, 0.00875, Received*online.private+(japan.t, 0.00875, 17+09, 0.00875, 17+09, 0.00875, Received*japan.t+online.private, 0.00875, Received*japan.t, 0.00875, the+machine, 0.00953, 9a, 0.01000, 9a, 0.01000, fe80, 0.01000, mtu, 0.01000, mtu, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id AA7E13A82BD for ; Fri, 17 Jan 2014 10:50:16 +0100 (CET) Message-ID: <52D8FCD4.2040900@fsn.hu> Date: Fri, 17 Jan 2014 10:50:12 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: FreeBSD Net Subject: lagg member interfaces don't come back after cable pull Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 09:50:33 -0000 Hi, Running stable/9@r260621, multiple (currently two) igb's connected to multiple Cisco Nexus 2ks, forming an LACP port channel. If I pull one of the cables from the switch, the port immediately goes down, and removed from the port channel. Everything works nicely. When I reconnect the cable, the member interface (igb1) remains down. On the host side, I see: igb1: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd nd6 options=29 media: Ethernet autoselect status: no carrier igb2: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active admin: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd inet6 fe80::ae16:2dff:fe9a:18cd%admin prefixlen 64 tentative scopeid 0x9 inet 172.27.79.74 netmask 0xffffff00 broadcast 172.27.79.255 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb2 flags=1c laggport: igb1 flags=0<> Issuing an ifconfig down and up on igb1 fixes the problem, it gets back into the port channel. On the switch side I can see the following: 2014 Jan 17 08:58:11 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_UP: port-channel6: Ethernet109/1/47 is up 2014 Jan 17 09:20:42 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel6: Ethernet109/1/47 is down 2014 Jan 17 09:31:52 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_UP: port-channel6: Ethernet109/1/47 is up The cable was pulled at 09:20:42 and was reconnected in some seconds. ifconfig down and up was issued around 09:31:52, which fixed the access. From what I see it may be just the igb and not really connected to lagg, but I'm not sure and the machine is far away, so testing is not so easy.