From owner-freebsd-net@freebsd.org Fri Mar 15 10:22:08 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0A1315450EC for ; Fri, 15 Mar 2019 10:22:07 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6046F91954 for ; Fri, 15 Mar 2019 10:22:07 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: by mailman.ysv.freebsd.org (Postfix) id 20EAF15450EB; Fri, 15 Mar 2019 10:22:07 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8C5815450EA for ; Fri, 15 Mar 2019 10:22:06 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B172E91941 for ; Fri, 15 Mar 2019 10:22:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id x2FALvOs023436; Fri, 15 Mar 2019 11:21:57 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id E6DC1BAD; Fri, 15 Mar 2019 11:21:56 +0100 (CET) Subject: Re: Bridges on VLAN-tagged interfaces. To: Eric Bautsch , net@freebsd.org References: From: Harry Schmalzbauer Organization: OmniLAN Message-ID: <716a2edd-96f5-c263-2bd4-38a30808f241@omnilan.de> Date: Fri, 15 Mar 2019 11:21:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: ACL 130 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 15 Mar 2019 11:21:57 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-Rspamd-Queue-Id: B172E91941 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-6.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[omnilan.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mx0.gentlemail.de]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.952,0]; IP_SCORE(-3.53)[ip: (-9.23), ipnet: 2a00:e10:2800::/64(-4.71), asn: 25074(-3.69), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25074, ipnet:2a00:e10:2800::/64, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 10:22:08 -0000 Am 11.03.2019 um 11:48 schrieb Eric Bautsch: … > |ifconfig bridge create ifconfig bridge1 addm re0.33| > > If I now put an IP on that bridge instead of re0.33, it does not ping. > > If I do a broadcast ping from another host on that network thus > (Solaris system issuing the ping): > ping -sn 192.168.33.255 > > I can see packets arriving if I |tcpdump -i re0.33| and if I |tcpdump > -i bridge1| > However, on neither interface do I see any pings coming in when I ping > it's own address (in this case 192.168.33.20). IP stack processes them without passing it to the interface(s), so that's not unusual. > The Solaris system issuing the pings has learned the arp address of > the bridge though: > Code: > > |root@gaspra # arp -an | grep 192.168.33.20 net1 192.168.33.20 > 255.255.255.255 02:a7:91:b6:3a:01| > > If I |tcpdump -i bridge1|, I do get some packets, but not any echo > requests: > Code: > > |root@bianca # tcpdump -i bridge1 tcpdump: verbose output suppressed, > use -v or -vv for full protocol decode listening on bridge1, link-type > EN10MB (Ethernet), capture size 262144 bytes 11:05:26.081185 ARP, > Request who-has 192.168.33.20 (Broadcast) tell > juliet-punchin.swangage.co.uk, length 46 11:05:26.081197 ARP, Reply > 192.168.33.20 is-at 02:a7:91:b6:3a:01 (oui Unknown), length 28 > 11:05:38.201079 IP6 fe80::7285:c2ff:fea6:583c > ff02::2: ICMP6, router > solicitation, length 16 11:06:04.079441 ARP, Request who-has > 192.168.33.20 (Broadcast) tell juliet-punchin.swangage.co.uk, length > 46 11:06:04.079464 ARP, Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 > (oui Unknown), length 28 11:06:17.588644 ARP, Request who-has > 192.168.33.20 (Broadcast) tell gaspra-punchin.swangage.co.uk, length > 46 11:06:17.588665 ARP, Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 > (oui Unknown), length 28| If I read it corretcly, all you get are ethernet broadcast frames. (Hard) Reading next: … > |root@bianca # ifconfig -a re0: > flags=8943 metric 0 > mtu 1500 > options=8209b > ether 80🇪🇪73:63:5c:48 media: Ethernet autoselect (1000baseT > ) status: active nd6 > options=29 lo0: > flags=8049 metric 0 mtu 16384 > options=680003 inet6 > ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet > 127.0.0.1 netmask 0xff000000 groups: lo nd6 > options=21 bridge0: > flags=8843 metric 0 mtu 1500 > ether 02:a7:91:b6:3a:00 inet 192.168.140.85 netmask 0xffffff00 > broadcast 192.168.140.255 id 00:00:00:00:00:00 priority 32768 > hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 > timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: re0 flags=143 ifmaxaddr 0 > port 1 priority 128 path cost 55 groups: bridge nd6 > options=9 re0.33: > flags=8943 metric 0 > mtu 1500 options=80003 ether > 80🇪🇪73:63:5c:48 inet6 fe80::82ee:73ff:fe63:5c48%re0.33 prefixlen 64 > scopeid 0x4 groups: vlan vlan: 33 vlanpcp: 0 parent interface: re0 > media: Ethernet autoselect (1000baseT ) status: > active nd6 options=21 bridge1: > flags=8843 metric 0 mtu 1500 > ether 02:a7:91:b6:3a:01 inet 192.168.33.20 netmask 0xffffff00 > broadcast 192.168.33.255 id 00:00:00:00:00:00 priority 32768 hellotime > 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: > re0.33 flags=143 ifmaxaddr 0 port > 4 priority 128 path cost 20000 groups: bridge nd6 > options=9 root@bianca #| Here you have a universally administered addresses (UAA) on the parent interface re0, which is the same for the vlan clone re0.33, and a locally administered addresses (LAA) on if_bridge(4), which was verified to be announced. In order to get through the MAC filter of the ethernet interface, re0.33 must be in PROMISC mode. I remember having seen two different PROMISC interface status – never tracked it down.  But issuing 'ifconfig re0.33 promisc' might result in a second PROMISC status report on re0.33 and a working setup... If so, one has to discover the mystery of the 1st PROMISC status report, and file a bug reports probably. Best, -harry