Date: Mon, 03 May 2004 17:07:42 +0100 From: Robin Breathe <robin@isometry.net> To: David Yeske <dyeske@yahoo.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: netgraph arp issues vs linux veth Message-ID: <40966E4E.9020603@isometry.net> In-Reply-To: <20040426182243.59597.qmail__9737.87545594878$1083067025@web13506.mail.yahoo.com> References: <20040426182243.59597.qmail__9737.87545594878$1083067025@web13506.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------010000020201040808020203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 would > prefer to use netgraph if possible. Here is some more detailed config > information. *SNIP* > Any clues or pointers are greatly appreciated and will mean I get to deploy > FreeBSD with netgraph rather than linux with veth. > > Regards, > David Yeske Reading this and your other post, it seems that you're trying to emulate multiple distinct physical network interfaces on one physical interface with netgraph(4). This is something I've played with myself. I wrote the attached script, mkbridge.sh, to create an ng_bridge(4) attached to the ng_ether(4) node of a particular "real" interface, with an arbitrary number of additional ng_eiface(4), each with it's own MAC address. You've got this far already, but you (or someone else) might find the script useful with some polish. Now, the part you're getting stuck on is the system spitting response packets out of the interface associated with the route to the remote host. So, what you need is some policy routing. A minimal ipf(4) config to achieve this might be: pass out quick on rl0 to ngeth0 from 192.168.10.3/32 to any Works here on -CURRENT, YMMV. Something similar with ipfw(4) should be equally simple. I warn you that the mkbridge.sh script *may* panic 5.2.x-RELEASE if you try the "stop" target (not happy shutting down an ng_eiface(4) node which has had its MAC address changed)... this has been fixed in -CURRENT; I don't know about -STABLE. Regards, - Robin -- Robin Breathe / robin@isometry.net / +44-1865-741800 --------------010000020201040808020203 Content-Type: text/plain; name="mkbridge.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mkbridge.sh" #!/bin/sh -x # Robin Breathe, 2004 # external interface bridge_iface="em0" # the name of our ng_bridge(4) bridge="bridge0" # number of ng_eiface(4) virtual ethernet interfaces to create nvif="2" case $1 in start) # ensure all necessary modules are loaded for module in ng_ether ng_bridge ng_eiface; do kldstat -v | grep -qw ${module} || kldload ${module}.ko || exit 1 done # attach the external interface to the new bridge ngctl mkpeer ${bridge_iface}: bridge lower link0 ngctl name ${bridge_iface}:lower ${bridge} ngctl connect ${bridge_iface}: ${bridge}: upper link1 # stop external interface modifying IEEE 802.3 source address on outbound frames ngctl msg ${bridge_iface}: setautosrc 0 ngctl msg ${bridge_iface}: setpromisc 1 # setup and attach each tap(4) virtual ethernet device for i in $(jot ${nvif:-1} 0); do # create and attach the ng_eiface(4) to the ng_bridge(4) ngctl mkpeer ${bridge}: eiface link$((i+2)) ether # name it vif# ngctl name ${bridge}:link$((i+2)) vif$i # give it a MAC address: 00:be:YY:MM:DD:## link_addr=$(printf "00:be:%s:%02x" $(date +%y:%m:%d) $((i+1))) ifconfig ngeth$i ether ${link_addr} done ;; stop) ngctl shutdown ${bridge}: for i in $(jot ${nvif:-1} 0); do ngctl shutdown vif$((i)): done ngctl msg ${bridge_iface}: setautosrc 1 ngctl msg ${bridge_iface}: setpromisc 0 ;; *) echo "USAGE: `basename $0` {start|stop}" >&2 exit 64 ;; esac --------------010000020201040808020203--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40966E4E.9020603>