From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 20:01:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0EFD516A469 for ; Fri, 15 Jun 2007 20:01:52 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id BA57513C4C5 for ; Fri, 15 Jun 2007 20:01:51 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 91CDE5083D for ; Fri, 15 Jun 2007 22:34:05 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCSS+AW+XJeR for ; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Received: from intranet.utcluj.ro (localhost [IPv6:::1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 9433F50821 for ; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Received: from c7.campus.utcluj.ro ([193.226.6.226]) (SquirrelMail authenticated user cristiklein) by intranet.utcluj.ro with HTTP; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Message-ID: <57520.193.226.6.226.1181936041.squirrel@intranet.utcluj.ro> In-Reply-To: <20070615162738.GA21747@verio.net> References: <20070615104329.GF1173@turion.vk2pj.dyndns.org> <20070615162738.GA21747@verio.net> Date: Fri, 15 Jun 2007 22:34:01 +0300 (EEST) From: "Cristian KLEIN" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit Subject: Re: VLANs and routing 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: Fri, 15 Jun 2007 20:01:52 -0000 On Vin, Iunie 15, 2007 7:27 pm, David DeSimone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Peter Jeremy wrote: > >> >>> But the (somewhat weird) requirements are that the vlan interface on >>> machine1 shouldn't have assigned IP address, but the second one should. >>> >> [...] >> >>> Is this kind of setup even supported? >>> >> >> I don't see how it could be if machine1 is an IP endpoint: In order >> to transmit a packet, it needs to put a source IP address into the packet >> - which virtually always comes from the interface. >> > > When originating a packet, that is the case. But a forwarded packet > already has a source address, which can be left unchanged. As long as > routing is working (ARP is not needed, destination is clear, etc), the > intermediate interface need not have an IP. I completely agree with you. Theoretically speaking, you could inject something like (lladdr is not for real): side1# route add 192.168.2.0/24 -interface em0 -lladdr 00:10:ab:cd:ef:gh side2# route add 192.168.1.0/24 -interface em0 -lladdr 00:20:ab:cd:ef:gh And then you wouldn't require IPs on any interface. However, I haven't seen the ability to do something like this on any network stack, most probably, because in a layered approach (as networking is supposed to be) you shouldn't know, nor care what layer 2 does. Still, you could obtain something similar, by doing like this: side1# route add 192.168.2.0/24 -interface em0 side1# sysctl net.link.ether.inet.proxyall=1 side2# route add 192.168.1.0/24 -interface em0 side2# sysctl net.link.ether.inet.proxyall=1 This would tell both sides, that link-layer information for the destination network should be collected by using ARP. The other side will answer to this ARP request through the proxy-arp mechanism. If you don't want to enable proxy-arp, for reasons that you might discover in time, you may do the following: side1# route add 192.168.2.0/24 -interface em0 side1# arp -s 192.168.2.0 00:10:ab:cd:ef:gh side1# arp -s 192.168.2.1 00:10:ab:cd:ef:gh ... side1# arp -s 192.168.2.255 00:10:ab:cd:ef:gh Or, if you can afford using fake IPs: side1# route add 192.168.0.1/32 -interface em0 side1# arp -s 192.168.0.1 00:10:ab:cd:ef:gh side1# route add 192.168.2.0/24 192.168.0.1 In this setup, ping-ing 192.168.1.1 from 192.168.2.1 (assuming these are some IPs configured on some interface of the two routers) should work. Note that, in the configuration I suggested, network debugging (such as traceroute) might break. Make sure that you set net.inet.icmp.reply_src on both sides.