From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 01:15:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F19616A4CE for ; Tue, 27 Apr 2004 01:15:02 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1357A43D67 for ; Tue, 27 Apr 2004 01:15:01 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3R8K8Gu094674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2004 11:20:10 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3R8EqCb043472; Tue, 27 Apr 2004 11:14:52 +0300 (EEST) (envelope-from ru) Date: Tue, 27 Apr 2004 11:14:52 +0300 From: Ruslan Ermilov To: David Yeske Message-ID: <20040427081452.GA43360@ip.net.ua> References: <20040426182243.59597.qmail@web13506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20040426182243.59597.qmail@web13506.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: netgraph arp issues vs linux veth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2004 08:15:02 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 11:22:43AM -0700, David Yeske wrote: > I made another attempt with netgraph and I think I'm almost there, but I'm > still having some issues. I found a linux solution called veth > http://www.geocities.com/nestorjpg/veth/ which might do the job, but I wo= uld > prefer to use netgraph if possible. Here is some more detailed config > information. >=20 > I ran this on the spoof machine >=20 > # ngctl mkpeer . eiface hook ether > # ifconfig ngeth0 link 00:bd:03:12:12:12 > # ifconfig ngeth0 192.168.10.3 netmask 255.255.255.0 >=20 > # ngctl mkpeer ngeth0: bridge lower link0 > # ngctl name ngeth0:lower broken > # ngctl connect fxp0: broken: lower link1 > # ngctl connect fxp0: broken: upper link2 > # ngctl connect ngeth0: broken: upper link3 > # ngctl msg ngeth0: setpromisc 1 > # ngctl msg ngeth0: setautosrc 0 > # ngctl msg fxp0: setpromisc 1 > # ngctl msg fxp0: setautosrc 0 >=20 > # ngctl show broken: > Name: broken Type: bridge ID: 00000046 Num hooks: 4 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > link3 ngeth0 ether 00000005 upper > link2 fxp0 ether 00000004 upper > link1 fxp0 ether 00000004 lower > link0 ngeth0 ether 00000005 lower >=20 I experminted a bit more here, and it turns out that this can be further simplified. Instead of attaching both "lower" and "upper' of ngeth0: ("ether" node type) to the bridge, you can only attach "eiface" node's "ether" hook to the bridge (i.e., the corresponding "ether" node type will be left unconnected). So bridge will be with three links: fxp0:lower, fxp0:upper, and [eiface]:ether. > on the remote machine an arp -a lists this > ? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet]=20 > ? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet] >=20 > on the spoof machine an arp -a lists this > ? (192.168.10.1) at (incomplete) on ngeth0 [ethernet] > ? (192.168.10.3) at 00:bd:03:12:12:12 on ngeth0 permanent [ethernet] >=20 > a sniff on the spoof machine listed this while pinging the remote machine >=20 > # tcpdump -i ngeth0 'ether host 00:00:e8:5b:13:44' > tcpdump: listening on ngeth0 > 14:03:30.519263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:33.416568 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:40.530562 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:43.427175 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:50.540805 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:53.437845 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:04:00.550960 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:04:03.448383 192.168.10.1 > 192.168.10.3: icmp: echo request >=20 > a sniff on the remote machine listed this while pinging the spoof machine >=20 > # tcpdump -i rl0 'ether host 00:bd:03:12:12:12' > tcpdump: listening on rl0 > 14:02:24.918804 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:29.179263 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:34.929051 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:44.939136 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:02:52.052260 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:02:54.949402 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:02.063079 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 > 14:03:04.959534 192.168.10.1 > 192.168.10.3: icmp: echo request > 14:03:12.072830 arp reply 192.168.10.1 is-at 0:0:e8:5b:13:44 >=20 > Any clues or pointers are greatly appreciated and will mean I get to depl= oy > FreeBSD with netgraph rather than linux with veth. >=20 It seems that you use the same 192.168.10/24 network on both fxp0 and ngeth0 interfaces -- this is troublesome, as ARP in FreeBSD (this is about to change soon) is the global, non per-interface property, and is stored in a single routing table. So when you ping 192.168.10.3 from the remote box, it sends ARP request, the bridge correctly forwards it to ngeth0, that correctly replies with ARP reply, and ICMP ECHO REQUEST gets delivered to ngeth0. Then FreeBSD box with ngeth0 tries to send ICMP ECHO REPLY. For this, it looks up its routing table, and finds out that 192.168.10.1 is on fxp0 (not on ngeth0!), so the reply will be from the fxp0's MAC and with 192.168.10.3 source IP address -- I've verified this locally. Generally, it's not possible to have two broadcast type interfaces in the same subnetwork on one (FreeBSD) box. Put it in other way: suppose it works somehow. So when you ping 192.168.10.1 from the box with fxp0 and ngeth0, and both have addresses from the same IP subnetwork, which interface (i.e., which MAC) should get used? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAjhZ8Ukv4P6juNwoRAv7OAJ9qWItzheLQT4DdULr8ArucwuVbhACeMf0G 1ALCFj5OSU0grmZdwWrglw8= =UOA7 -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v--