Date: Fri, 15 Jun 2007 22:34:01 +0300 (EEST) From: "Cristian KLEIN" <cristi@net.utcluj.ro> To: freebsd-net@freebsd.org Subject: Re: VLANs and routing Message-ID: <57520.193.226.6.226.1181936041.squirrel@intranet.utcluj.ro> In-Reply-To: <20070615162738.GA21747@verio.net> References: <f4q05k$f68$1@sea.gmane.org> <20070615104329.GF1173@turion.vk2pj.dyndns.org> <20070615162738.GA21747@verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Vin, Iunie 15, 2007 7:27 pm, David DeSimone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Peter Jeremy <peterjeremy@optushome.com.au> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57520.193.226.6.226.1181936041.squirrel>