From owner-freebsd-net@freebsd.org Wed May 31 22:43:03 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34161BD3282 for ; Wed, 31 May 2017 22:43:03 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6EF46FA67 for ; Wed, 31 May 2017 22:43:02 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id h4so33928277oib.3 for ; Wed, 31 May 2017 15:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IdvqQLmu+9D+GSiKAk1MoEO6HAt4E2Yyp+bHhlMf234=; b=eRTr3vgSR1VS8cq4PT19az9F1+y7TfAf2C0fxbSyfd4ksBlllqs7wm9k1gbyA6Ju2r FjzMnAzYsue+RqsC5b3DkV9yc7zZsqZERSSl6aGHVK0UQ08Y1g5OyrQue3PG0SlBYbWZ 0z0mGRuk0fVboISmU53/5/6C+VLBE06n10lLbLn4TamFAaMHq6u9taY5CfQPnxoDUgN6 BKFpevHVIimqbLWMTo57iIo2ePsWtY/kqHtXUA/zTEwg+Z/YpZPEq/oe5Li0ztwZkipO hatn277SK64UutUSH6IAuk1Xhm872Z5G/BtlATmZeZp1N+0ialGGbFtCi6cJK6HX/3kP FQtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IdvqQLmu+9D+GSiKAk1MoEO6HAt4E2Yyp+bHhlMf234=; b=pkQ4jWH+bKxw5DePvRpVOcBnW6Wc+RHL4K9HaucyVlPbhasVv9YEt/2bH7trGtb1KT FTrkInk5jmsylxq+rkmrsHjbBaxtS/8UpYmI9VV+xLyr9Ezmc9/0SGLt2cDRet45mmZS LiGu9gZIfEaTqmn9OfTu8kLOskUbarQoJF8WWqRA7IyYM7oQveySAcfYBXJkzU6ht5Er BwRCFwDSwV1vExdMMHZKRB0gYNyaGpszenl0TiRQNtgh0lxEq2QGzav3dt0QnMKQ0gy1 DXZ5Hn4qo5xGyYsvmRJ86DZ7BxEtADGhH56VMOcnEX+44+D4bOkIlp2uKbaI79/AMVyW sLlQ== X-Gm-Message-State: AODbwcDeED28Te1ZmpvjAnKwI6UJs3PlNH+xyFIF7X5LliU+356lwhTF xEromwSjI4q+an3yVH3QMuMiYo1lIw== X-Received: by 10.202.50.213 with SMTP id y204mr14155793oiy.164.1496270582175; Wed, 31 May 2017 15:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Wed, 31 May 2017 15:43:01 -0700 (PDT) In-Reply-To: <5926F74A.1000101@omnilan.de> References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> <58CFA606.7090306@omnilan.de> <58D02259.9010101@omnilan.de> <5926F74A.1000101@omnilan.de> From: Vincenzo Maffione Date: Thu, 1 Jun 2017 00:43:01 +0200 Message-ID: Subject: Re: vale uplink via vlan-if [Was: Re: Are ./valte-ctl and ./bridge friends or competitors?] To: Harry Schmalzbauer Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:43:03 -0000 If VLAN interface do not work properly with VALE/netmap that's a bug of the emulated adapter code in FreeBSD. But in any case the approach is not the right one, since using the emulated netmap adapter with VALE will make you lose most of the advantage of using netmap in the first place. (see my previous email). Cheers, Vincenzo 2017-05-25 17:24 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 21.03.2017 19:05 (localt= ime): > > 2017-03-20 19:41 GMT+01:00 Harry Schmalzbauer : > > > >> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 > (localtime): > >> =E2=80=A6 > >>>> So to summarize for newbies exploring netmap(4) world in combination > >>>> with physical uplinks and virtual interfaces, it's important to do t= he > >>>> following uplink NIC configuration (ifconfig(8)): > >>>> -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc > >>>> > >>> > >>> Exactly. This is mentioned at the very end of netmap(4): > >>> > >>> "netmap does not use features such as checksum offloading, TCP > >> segmentation > >>> offloading, encryption, VLAN encapsulation/decapsulation, etc. When > >> using > >>> netmap to exchange packets with the host stack, make sure to disable > >> these > >>> features." > >>> > >>> But it is probably a good idea to add these example ifconfig > instructions > >>> somewhere (man page or at least the README in the netmap repo). > >>> > >>> > >>>> > >>>> I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do > they? > >>>> > >>> > >>> Well, I think they interfere: if you receive a tagged packet and the > NIC > >>> strips the tag and puts it in the packet descriptor, then with netmap > you > >>> will see the untagged packet, and you wouldn't have a way to see the > tag. > > Sorry picking this up again, but I'm stuck getting vale(4) productive :-( > > I took lagg(4) out of the game and configured my desired setup using > if_bridge(4) at first. > > The physical uplink NIC is em0. > The bridge/vale uplink is em0.232. > > hostB --switch-- em0-hostA > | > '- em0.232 > | > bridge5-vmnet0 > | > vtnet0-GUESTa <-tcpdump: > > 17:07:28.423768 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1, > length 28 > 17:07:28.424208 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP > (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 4= 6 > > The same is visable on vmnet0 nad em0 of course. > > Now if I replace bridge5 by vale, leaving everything else unchanged > besides using netmap-vtnet with bhyve, I don't get ARP is-at answer. > I can see the who-has on all interfaces involved, and also the is-at > answer up to em0.232, but not at vtnet0 (the guest, connected via vale). > > To draw the same picture like with bridge: > > hostB --switch-- em0-hostA > | > '- em0.232 > | > vale232:em0.232-' > vale232:GUESTa--vtnet0-GUESTa <-tcpdump: > > 17:16:00.111868 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1, > length 28 > ... no reply > > While tcpdump of em0.232 shows: > 17:16:01.119537 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has 172.21.34.10 tell 172.21.35.1, > length 46 > 17:16:01.119849 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP > (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 4= 6 > > The reply made it up to vale's uplink, but not through vale. Am I > missing something? > Tagging, checksum-disabling etc. seems to be right, since utilizing > if_bridge(4) gives the expected result, but I have no idea why I can't > get packets via vale(4). > > Important note: Using em0.232 parent (vlandev em0) for vale uplink does > work! > So I guess if_em(4)'s native netmap support interferes with the vlan clon= e. > I'm out at this point, far too less knwoledge about the code paths... > Can anybody else help here? > > Thanks, > > -harry > --=20 Vincenzo Maffione