Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Apr 2004 12:28:45 -0700 (PDT)
From:      David Yeske <dyeske@yahoo.com>
To:        Nick Sayer <nsayer@kfu.com>
Subject:   Re: netgraph arp issues vs linux veth
Message-ID:  <20040426192845.4719.qmail@web13507.mail.yahoo.com>
In-Reply-To: <408D55DF.2070902@kfu.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I looks like removing the promisc and autosrc messages to ngeth0 fixed part of
it.  That is the only modification I made from what I have pasted so far.  I
still had to add the upper hooks up of the ngeth0 device to the bridge for it
to work.  When I set this up with more than one virtual interface it appeared
to favor one of the interfaces.  I could keep one virtual interface working for
a bit, but when I wanted to use the other one, I had to stop passing traffic
through the first one.  One interface would start dropping all packets, and
then the other interface would start working.  I did not see anything useful in
dmesg, although I don't know netgraph that well or what sysctl's I should turn
on for debugging.  I'm not sure if this is a bug or a feature.  I'm going to
look at some of the vmware scripts and see how they are different, but what I
have going now is good enough for a temporary solution.  I will need to
simulate thousands of mac addresses when I'm done with this.  Thanks for the
help everyone :)

--- Nick Sayer <nsayer@kfu.com> wrote:
> Don't send promisc and autosrc messages to ngeth0. You only need to do 
> that for the physical interface.
> 
> Hook the lower and upper hooks of the physical interface up to the bridge.
> 
> Hook the lower hook of the virtual interface up to the bridge. Do not 
> mess with its upper hook.
> 
> 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.
> >
> >I ran this on the spoof machine
> >
> ># 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
> >
> ># 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
> >
> ># 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
> >
> >on the remote machine an arp -a lists this
> >? (192.168.10.3) at 00:bd:03:12:12:12 on rl0 [ethernet] 
> >? (192.168.10.1) at 00:00:e8:5b:13:44 on rl0 permanent [ethernet]
> >
> >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]
> >
> >a sniff on the spoof machine listed this while pinging the remote machine
> >
> ># 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
> >
> >a sniff on the remote machine listed this while pinging the spoof machine
> >
> ># 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
> >
> >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
> >
> >  
> >
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040426192845.4719.qmail>