From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 10:18:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07DEF106564A for ; Wed, 28 Mar 2012 10:18:04 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 757818FC0C for ; Wed, 28 Mar 2012 10:18:03 +0000 (UTC) Received: by lagv3 with SMTP id v3so1464313lag.13 for ; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=arvVfoPR8j6mH7ZFMbMfuxHTA65C1YmnjjWTW3RhrVQ=; b=fFKJfKomQ9R7mGxbb3CuKS4gqVtuda2ZP707aGCPMslGLD+GFmWCkFLfbZb5/kQCRh AKNIh1c+6SoI5qPeC2vz7hjjZ9ZNIB4yJGz+Qh3OoFKyzKfI1OyzqsM7UQotPmvSrRjt 52g2BHhI60Kmt1xO66AfZxThxDvjLV2wJkcys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=arvVfoPR8j6mH7ZFMbMfuxHTA65C1YmnjjWTW3RhrVQ=; b=S4lNF73S2y5Tzumwwr1vHePUwxrpO45p19ipHxgucpqgveqoejG5bYo1GrHkC8FaCy ZqTgUg+0xefGy0JryrOb1siCbvRlR8WrdxRUQzebKGO5o1jmLbrhhrQXdXJ9zGQ+s3EW kXASM1n8nwvlDUGAy5skS0QxaY8iqZj2El3bpFpH2BVio1nv56vi5ifSembRnq8T3XoK 8D4yG6y0TPpWeEyF+bamXDzvAoaZYIx0PEYtOdIn3ySMCnOGxvAsFMjtDj2ho8dWQ4/z akXCCXwJAnLOIXmo3IeFQ+buT15+378SXe6wT/xymZ99i6arQ3shbeY8fH1Sj9EOfPnY r8uA== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr24616428lab.21.1332929882376; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) X-Originating-IP: [85.110.15.53] Date: Wed, 28 Mar 2012 13:18:02 +0300 X-Google-Sender-Auth: ps44Xww_FuLlK7-qy9hmi11cHJs Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlo17UXLucJB08b4J3b3VlD1klygw44UfzrHe6kAbeD9t0v/H4Qhs1jYXyQj/XW1FwpAkHj Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:18:04 -0000 I have some problems implementing lagg(4) on dual NIC's on the diskless client side. It may be because my switch is a cheap, un-managed Gbit switch or hopefully some other reason. I would like to either get lagg working properly or find an alternative method of solving the problem. HARDWARE DESCRIPTION: I have mobo's with embedded 10/100 NIC's used as diskless cleints. For better performance I have added PCIe Gbit NIC's and Gbit switch. Since PXE cannot boot off an added PCIe NIC, I'm stuck with booting from embedded 10/100, then having to switch the traffic to the GBit NIC. In order to preserve port space on the GBit switch, I also have an old 10/100 hub plugged into one of the ports. Structure is: 10/100 NIC's --> 10/100 hub --> GBit switch --> server GBit NIC's --> GBit switch I concede that under this structure lagg's loadbalance or LACP are probably not going to work. I'll accept failover mode if I'm stuck with that - meaning, after the diskless client is done booting from the BIOS-recognized 10/100 NIC, it should switch traffic to the Gbit NIC and 10/100 should go "down". Unfortunately that does not work either. I have done as much testing as I can think of with: In general, as soon as lagg is brought up, NIC pool no longer responds to pings and gives an "I'm busy now" message. 1. On the server system, after lagg0 gets created as loadbalance, server stops responding to pings. However, tcpdump on server shows that ping requests are being received - it just does not respond. (No firewall running). Does this mean/indicate that my switch cannot handle lagg? 2. On a diskless node, lagg setup as failover behaves as other modes and results in system freeze (no ping response also). In below example, re1 is the Gbit-NIC and is set as primary NIC. > > ifconfig_lagg0="laggproto failover laggport re1 laggport re0 192.168.2.2 netmask 255.255.255.0" Curiously, under this setup tcpdump shows nfs response during frozen status. The second code snippet shows up when I un-plug the ethernet cable on re1 and lagg0 needs to fall back on re0. Server IP is 192.168.2.1, node is 2.2. > > 12:49:12.237477 IP 192.168.2.1.nfs > node2.76575838: reply ok 112 > > 12:59:54.323462 IP 192.168.2.1.nfsd > node2.740: Flags [R.], seq 4209474782, ack 2247908211, win 29127, options [nop,nop,TS val 2033479589 ecr 11647], length 0 Regards.