Date: Fri, 17 Mar 2017 18:59:17 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Vincenzo Maffione <v.maffione@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: [panic] netmap(4) and if_lagg(4) Message-ID: <58CC23F5.7060507@omnilan.de> In-Reply-To: <CA%2B_eA9iCT7evWUcZMA_ViKfrZnSHp3OpBTS5c4iJ9=ZjO-Pfgw@mail.gmail.com> References: <58CBCD7A.8060301@omnilan.de> <CA%2B_eA9iCT7evWUcZMA_ViKfrZnSHp3OpBTS5c4iJ9=ZjO-Pfgw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:29 (localtime):
> Hi,
> This is supposed to work because of the emulated netmap adapter.
> By means of that, Netmap works on tap(4) interfaces if_bridge
> interfaces, epairs, etc. Have you tried those to see if that works?
Hello Vincenzo,
thanks a lot for your attention!
Yes, I tried various epair/tap setups.
Description followes.
> Maybe here the problem is that if_lagg is a "metadriver", which
> interacts in a bad way with the emulated adapter, which needs to
> intercept all the packets received from the driver.
It seems it's a more generic problem to cloned interfaces, since I get
the same panic when trying to add a em0.vlanN to vale.
There are a lot of component's in my desired setup:
2 igb interfaces build one (LACP) lagg cloned if.
Several cloned vlan children of that lagg interface shall handle IPs for
jails without vnet.
Then there are byhve guests, which are not that bandwidth and latency
critical for frames leaving the host, but for guest-to-host and
guest-to-guest connections, thus vale looks promising to me.
Attaching the 2nd-gen-cloned vlan children of lagg(4) to vale, doesn't
lead to panics, but I couldn't pass any frame. I see arp-who-has and
also the answhers on the vlanIF, but it seems frames don't traverse vale.
Attaching a 1st-gen cloned vlan(4) children of another em(4) interface,
I get the same panic when trying lagg(4) to vale.
The only working setup was:
igb0 --|
lagg0 - bridge0
igb1 --| | | |
|-> lagg0.101 ---| |epair0a|epair0b--vale0port1
| |epair0b^-vale0port2
|-> lagg0.102 vif0-vale0port3
| |
|-> lagg0.103 |
… bhyve -s 5,virtio-net,vif0
Attaching lagg0 to vale0 = panic
Attaching lagg0.101 to vale0 = silence
Attaching em0.101 to vale0 = same panic as with lagg0
Attaching em0 to vale0 = silence with tagged frames
ifconfig em0 -vlanhwtag solves the latter, but this doesn't really
help, because VID filtering inside the guest is no option, was just for
testing.
I'm running stable/11 as of today.
Is it by design that the physical vale interface must be set to promisc
mode?
Thanks,
-harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58CC23F5.7060507>