From nobody Wed Jul 26 15:06:57 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R9y162zNWz4pVKm for ; Wed, 26 Jul 2023 15:07:06 +0000 (UTC) (envelope-from SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R9y144vcFz3rjM for ; Wed, 26 Jul 2023 15:07:04 +0000 (UTC) (envelope-from SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=m2JzpPqk; spf=pass (mx1.freebsd.org: domain of "SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Wed, 26 Jul 2023 17:06:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1690384017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SRF6kosMqM8xwCaIcGvRyOZ4v9+16ogzTwqF2BWMzJI=; b=m2JzpPqkKvaIygZ3STgCCayJZKBvureh5SHecWLjWNw1CR6UNOCMuxGBEHcdmpntReXUsh HC0eYg29HcTe3fmHZkKyyqB+9FWuk3NuoFYv8fPnK5tjfPLczKozzq5aWpUCPXVpUM8W79 U7a5c6vK8HYry17YYsEB31hRGNnjAy7x4TPeABECZpNZBqaOpLbc5Eegx27cMyfpGppsx7 mDhIoiXEIyuxVk8bf6bFU62/rSzGJaIgESbNLW0iCdTzKPV6gjM1WefhPwLTGGUKor231I QWMJIycQq//ISH0J5M0TYQT761SA5ZdzqGwkBKvjYnQx3IoFYOp8AV6DIDVpDw== From: Ronald Klop To: Rudy Cc: freebsd-net@freebsd.org Message-ID: <1098775861.8350.1690384017229@localhost> In-Reply-To: <156f55a9-9a0b-f2e8-f542-1933f6dc229a@monkeybrains.net> References: <156f55a9-9a0b-f2e8-f542-1933f6dc229a@monkeybrains.net> Subject: Re: VLAN not working - jails, bridges, and VLANs List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8349_738894886.1690384016801" X-Mailer: Realworks (663.155) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_HAS_DN(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=OEIo=DM=klop.ws=ronald-lists@realworks.nl] X-Rspamd-Queue-Id: 4R9y144vcFz3rjM X-Spamd-Bar: --- ------=_Part_8349_738894886.1690384016801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Rudy Datum: zondag, 16 juli 2023 05:54 Aan: freebsd-net@freebsd.org Onderwerp: VLAN not working - jails, bridges, and VLANs > > > Kernel: FreeBSD 13.1-RELEASE-p8 GENERIC amd64 > Issue: vlan traffic not in the jail > > Weird issue today... > > I have a bridge with on the host, two jails, and a vlan in the jail. > The jails were networking just fine with their native vlan (1), but the host would not pass 802.1q traffic to the jail. > > If I created the vlan91 on the host, that would 'wake up vlan awareness on the bridge'. I could then destroy the vlan91 on the host, and the jail still passes traffic. > > The Workaround: > host#ifconfig vlan91 create vlan 91 vlandev igb1 10.1.1.1/28; ifconfig vlan91 destroy > > > > Maybe something wrong with the bridge spanning tree implementation? It's like that bridge was created before the vlans, and the non-native vlans are pruned. > > > Rudy > > > > > > > > > host# ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu 1500 > ether 58:9c:fc:00:69:7f > 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: epair1a flags=143 > ifmaxaddr 0 port 12 priority 128 path cost 2000 > member: epair0a flags=143 > ifmaxaddr 0 port 11 priority 128 path cost 2000 > member: igb1 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 20000 > groups: bridge > > > jail0# ifconfig > epair1b: flags=8863 metric 0 mtu 1500 > options=8 > ether 02:eb:91:68:32:0b > inet 10.10.40.112 netmask 0xffffff00 broadcast 10.10.40.255 > groups: epair > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > nd6 options=21 > vlan91: flags=8843 metric 0 mtu 1500 > ether 02:eb:91:68:32:0b > inet 10.8.254.68 netmask 0xfffffff0 broadcast 10.8.254.79 > groups: vlan > vlan: 91 vlanproto: 802.1q vlanpcp: 0 parent interface: epair1b > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > nd6 options=29 > > > host# kldstat > Id Refs Address Size Name > 1 50 0xffffffff80200000 1f30470 kernel > 2 1 0xffffffff82131000 5ec1f8 zfs.ko > 3 1 0xffffffff8271e000 b7d0 opensolaris.ko > 4 1 0xffffffff82ae5000 3378 acpi_wmi.ko > 5 1 0xffffffff82ae9000 3250 ichsmb.ko > 6 1 0xffffffff82aed000 2180 smbus.ko > 7 1 0xffffffff82af0000 8d38 ioat.ko > 8 1 0xffffffff82af9000 2110 pchtherm.ko > 9 1 0xffffffff82afc000 2340 uhid.ko > 10 1 0xffffffff82aff000 4350 ums.ko > 11 1 0xffffffff82b04000 3380 usbhid.ko > 12 1 0xffffffff82b08000 31f8 hidbus.ko > 13 1 0xffffffff82b0c000 2a08 mac_ntpd.ko > 14 1 0xffffffff82b0f000 7638 if_bridge.ko > 15 1 0xffffffff82b17000 50d8 bridgestp.ko > 16 1 0xffffffff82b1d000 3a64 if_epair.ko > > > > > > > > > Hi, What are you trying to accomplish? /--- epair1a --- epair1b --- vlan91 -> Jail1 ibg1 ---- bridge0 ---+ \--- epair0a --- epair0b --- ??? Is ibg1 running in PROMISC mode if you do not do the workaround of setting vlan91 on ibg1? Can you post complete output of ifconfig and the relevant part of your /etc/rc.conf? Regards, Ronald. ------=_Part_8349_738894886.1690384016801 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Rudy <crapsh@monkeybrains.net>
Datum: zondag, 16 juli 2023 05:54
Aan: freebsd-net@freebsd.org
Onderwerp: VLAN not working - jails, bridges, and VLANs



Kernel: FreeBSD 13.1-RELEASE-p8 GENERIC amd64
Issue: vlan traffic not in the jail

Weird issue today...

I have a bridge with on the host, two jails, and a vlan in the jail.
The jails were networking just fine with their native vlan (1), but the host would not pass 802.1q traffic to the jail.

If I created the vlan91 on the host, that would 'wake up vlan awareness on the bridge'.  I could then destroy the vlan91 on the host, and the jail still passes traffic.

The Workaround:
host#ifconfig vlan91 create vlan 91 vlandev igb1 10.1.1.1/28; ifconfig vlan91 destroy



Maybe something wrong with the bridge spanning tree implementation?  It's like that bridge was created before the vlans, and the non-native vlans are pruned.


Rudy








host# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
     ether 58:9c:fc:00:69:7f
     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: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
             ifmaxaddr 0 port 12 priority 128 path cost 2000
     member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
             ifmaxaddr 0 port 11 priority 128 path cost 2000
     member: igb1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
             ifmaxaddr 0 port 4 priority 128 path cost 20000
     groups: bridge


jail0#  ifconfig
epair1b: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
     options=8<VLAN_MTU>
     ether 02:eb:91:68:32:0b
     inet 10.10.40.112 netmask 0xffffff00 broadcast 10.10.40.255
     groups: epair
     media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
     status: active
     nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
vlan91: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
     ether 02:eb:91:68:32:0b
     inet 10.8.254.68 netmask 0xfffffff0 broadcast 10.8.254.79
     groups: vlan
     vlan: 91 vlanproto: 802.1q vlanpcp: 0 parent interface: epair1b
     media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
     status: active
     nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


host# kldstat
Id Refs Address                Size Name
  1   50 0xffffffff80200000  1f30470 kernel
  2    1 0xffffffff82131000   5ec1f8 zfs.ko
  3    1 0xffffffff8271e000     b7d0 opensolaris.ko
  4    1 0xffffffff82ae5000     3378 acpi_wmi.ko
  5    1 0xffffffff82ae9000     3250 ichsmb.ko
  6    1 0xffffffff82aed000     2180 smbus.ko
  7    1 0xffffffff82af0000     8d38 ioat.ko
  8    1 0xffffffff82af9000     2110 pchtherm.ko
  9    1 0xffffffff82afc000     2340 uhid.ko
10    1 0xffffffff82aff000     4350 ums.ko
11    1 0xffffffff82b04000     3380 usbhid.ko
12    1 0xffffffff82b08000     31f8 hidbus.ko
13    1 0xffffffff82b0c000     2a08 mac_ntpd.ko
14    1 0xffffffff82b0f000     7638 if_bridge.ko
15    1 0xffffffff82b17000     50d8 bridgestp.ko
16    1 0xffffffff82b1d000     3a64 if_epair.ko





 


Hi,

What are you trying to accomplish? 
                      /--- epair1a --- epair1b --- vlan91 -> Jail1
ibg1 ---- bridge0 ---+
                      \--- epair0a --- epair0b --- ???
Is ibg1 running in PROMISC mode if you do not do the workaround of setting vlan91 on ibg1?

Can you post complete output of ifconfig and the relevant part of your /etc/rc.conf?

Regards,

Ronald.
  ------=_Part_8349_738894886.1690384016801--