From owner-freebsd-questions@FreeBSD.ORG Fri Jun 24 13:40:27 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08D8916A41C for ; Fri, 24 Jun 2005 13:40:27 +0000 (GMT) (envelope-from lists@immuneit.com) Received: from web1.nidhog.com (web1.nidhog.com [66.207.132.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E9243D55 for ; Fri, 24 Jun 2005 13:40:26 +0000 (GMT) (envelope-from lists@immuneit.com) Received: from blacksea.nedyah.org (semcheski.squirrelhill.nidhog.net [66.207.143.104]) (authenticated bits=0) by web1.nidhog.com (8.13.1/8.13.1) with ESMTP id j5ODeHrU031071 for ; Fri, 24 Jun 2005 09:40:24 -0400 (EDT) (envelope-from lists@immuneit.com) From: "Michael H. Semcheski" To: freebsd-questions@freebsd.org Date: Fri, 24 Jun 2005 09:31:18 -0400 User-Agent: KMail/1.8 References: <5675255661ae.5661ae567525@liu.se> In-Reply-To: <5675255661ae.5661ae567525@liu.se> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506240931.18594.lists@immuneit.com> X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.6 (web1.nidhog.com [66.207.132.2]); Fri, 24 Jun 2005 09:40:24 -0400 (EDT) Subject: Re: NAT router confusion X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2005 13:40:27 -0000 On Friday 24 June 2005 06:25 am, Ulf Magnusson wrote: > Thanks, I think I understand how it works now. I guess it's basically > like an ordinary router that pretends it's a switch for all addresses > that appear on the same local network. It looks at the destination > address in IP packets and the address of the sending system and goes > into switch mode if they both appear on the same subnet (which is pretty > much verbatim what you said, when I think about it). Its my understanding, and it is somewhat limited, that the host that is generating the traffic is really the one that determines whether the traffic needs to leave the network or not. The router functionality only kicks in if a packet is sent to the gateway (think of the gateway as another host on the network) and the destination is outside of the network. > Do switches gain anything by having full-duplex connections to hubs? I > understand there must be a performance benefit when you connect a host > directly to a switch, but won't the half-duplex connections of the hosts > to the hub become a bottleneck? By this question I'm a little confused. Switches are devices that allow a bunch of connections, and packets are routed from one interface to another within the switch. A hub is a device that allows a bunch of connections, and packets are more or less broadcast to every other interface on the hub. If you go to your local computer store, you will not be able to buy a hub. Maybe there are hubs sold for specific legacy applications I don't know about, but in the consumer market, they have not sold hubs in at least 5 years. I personally have never setup a hub, so I don't know whether there is something special about them that makes them half-duplex only. I do know that many ethernet flavors do not autonegotiate as well as we would hope. If you have a 100Mb half-duplex connection from a FreeBSD host to another host, try "ifconfig fxp0 media 100baseTX media-opt full-duplex", which, assuming your NIC is fxp0 and my syntax isn't too rusty, will force the device into full-duplex mode. To connect to switches that do not autonegotiate correctly, one thing you can do is setup a FreeBSD host with two NIC's. Plug one switch into each NIC, and force each NIC to the right media type. Set up a bridge on the FreeBSD host, and voila, you have solved the duplex problem. We have this problem at work in some places. A switch we want to use does not autonegotiate full-duplex with the switch computing services provides. So, put a bridge in between and remove autonegotiation. Mike