From nobody Fri Oct 10 09:01:25 2025 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 4cjgjt635nz6BfNV for ; Fri, 10 Oct 2025 09:02:26 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cjgjt4mPmz3k5N; Fri, 10 Oct 2025 09:02:26 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1760086946; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtVz7FmjmZUmlQsuQPmuv+j2KC+sgLwXkomXoChigm4=; b=rTY9gdwXk8L9rtamWi4lo5jpBegyq4AwNA5v76KbOlBvvMqsSTlwkHnyJZYbcgWaO+VwM3 zpqm0tTUBXWpGiLZT2rwaqAHdvulNsRGORK5TF2JXQpTQUmygpN3kDaA3xg5ImA99wYWmx KWsrcIG3LMNHj+kGG5GjJ7DhoquuOciBbgGMAb/kdXdNWGK+H3D8i+KzAMinnJyq/FCZCW DPCU8uhqGWhUvMh3MewNog6Kx8vx+HBP89nA14NnQ20/HLkjqKacWhbUBDoALzlq3D0r4r rfClHghxDVDIWbPfnDtXfv49iY7nFiJE0i8VnYtlumpLf4RfOk8XAw19CDkgVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1760086946; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtVz7FmjmZUmlQsuQPmuv+j2KC+sgLwXkomXoChigm4=; b=pFUHe2B+BIupkcEItBqaU7rS6MDxCUcoovV2C6TxxzstYIJZs6y5p7r7l3r43uzTmY/+Jh O5hVHPWizX1VK/U5F8DRz/HGMsHloEhWkbDpOhVCuMruJVFCHGXPqlIWx7ITj+Lh8ShEwB RobU6OyEURipGZmoV/7wIhTxjR0uK7uGJLFGEc4CaDVjG74j8zBpDYAOG9Le7EElY3f4wU 2V8fGz8xDP3hdRqFBcsVpgedCvRt4PQ+deUGFdB++E6581/ymXgUny+Xjwp2JuD1zYSPkm QpgSV/bMr6yU0dHcPBtmTITUtu+O/dSiSYiI8BYDXgWq0wTTIeFiiaMP5gh3zA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1760086946; a=rsa-sha256; cv=none; b=Au+s91Yqoc6LqI7+QyFB0ON/UmP6XMK9DGpUJLP2WL6H/EQOUjGyRt5xNeVc/04HH4Z9Qb rkd4qELNMlNCP0IftAKkSqkhGXJJYRE5sTwAonLOAw3HdGUjL8FIFV0ip1mVa0DnvyYhPU T6H4X+KMueIu2qU7dFVys/0Cr62+B8L6DkISGXs7fEpym9sbSbiApopfY9dnHEufmj8sIS 7DLWX2+9PCNVvXcsGh8XffEPWd32iZUZzhp0BKpHMFLILzxCMsF8vguhDWVzmJ6a9ADVlR aW0S8GGJCnLhiy8HkTq+VTqLf+v6xRQfdZTF4Jn5U5aaTuMPwiG0MoAB5t57Rw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:1c00:270f:14b0:458e:633b:59a6:ce56] (2001-1c00-270f-14b0-458e-633b-59a6-ce56.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:270f:14b0:458e:633b:59a6:ce56]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cjgjt2KwdztVS; Fri, 10 Oct 2025 09:02:26 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <267e7bcc-66b8-433a-9db0-abab6129cde6@FreeBSD.org> Date: Fri, 10 Oct 2025 11:01:25 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: FBSD 15 :: if_bridge help needed To: Paul Procacci , "freebsd-net@freebsd.org" References: Content-Language: en-US From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Op 08-10-2025 om 10:10 schreef Paul Procacci: > On Wed, Oct 8, 2025 at 4:04 AM Paul Procacci wrote: >> >> On Wed, Oct 8, 2025 at 3:59 AM Lexi Winter wrote: >>> >>> Paul Procacci wrote in : >>>> From hosts' perspective: >>>> ----------------------------------------------------------- >>>> root@host:~ # tcpdump -ni epair0a >>>> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode >>>> listening on epair0a, link-type EN10MB (Ethernet), snapshot length 262144 bytes >>> >>>> From Jail 1's perspective: >>>> ----------------------------------------------------------- >>>> root@Jail1:/ # tcpdump -ni epair0b.60 >>>> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode >>>> listening on epair0b.60, link-type EN10MB (Ethernet), snapshot length >>>> 262144 bytes >>>> 07:52:03.722196 ARP, Request who-has 192.168.60.2 tell 192.168.60.1, length 28 >>>> 07:52:04.785635 ARP, Request who-has 192.168.60.2 tell 192.168.60.1, length 28 >>> >>> this seems like the packets are not making it out of the vlan(4) >>> interface for some reason. could you please re-run this with >>> tcpdump -ve (it doesn't show .1q tags otherwise) and include >>> the output for both epair0b.60 and epair0b in the jail? >>> >>> also for my reference, please include the ifconfig output for >>> epair0b.60, epair0b and epair0a (i think you already showed this, >>> it's just easier to have it all together, if you don't mind). >> >> Sure. This isn't a problem and I think you're onto something: >> >> root@fw:/ # tcpdump -nvi epair0b -e >> tcpdump: listening on epair0b, link-type EN10MB (Ethernet), snapshot >> length 262144 bytes >> ^C >> root@Jail 1:/ # tcpdump -nvi epair0b.60 -e >> tcpdump: listening on epair0b.60, link-type EN10MB (Ethernet), >> snapshot length 262144 bytes >> 08:00:29.095183 58:9c:fc:10:bb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has >> 192.168.60.2 tell 192.168.60.1, length 28 >> 08:00:30.158598 58:9c:fc:10:bb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has >> 192.168.60.2 tell 192.168.60.1, length 28 >> >> >> .... and the output of the interfaces .... >> root@Host:~ # ifconfig epair0a >> epair0a: flags=1008943 >> metric 0 mtu 1500 >> options=60000b >> ether 58:9c:fc:10:8b:0f >> groups: epair >> media: Ethernet 10Gbase-T (10Gbase-T ) >> status: active >> nd6 options=29 >> >> >> root@Jail 1:/ # ifconfig epair0b; ifconfig epair0b.60 >> epair0b: flags=1008942 >> metric 0 mtu 1500 >> options=60000b >> ether 58:9c:fc:10:bb:b7 >> groups: epair >> media: Ethernet 10Gbase-T (10Gbase-T ) >> status: active >> nd6 options=29 >> epair0b.60: flags=1008843 >> metric 0 mtu 1500 >> options=0 >> ether 58:9c:fc:10:bb:b7 >> inet 192.168.60.1 netmask 0xffffff00 broadcast 192.168.60.255 >> groups: vlan >> vlan: 60 vlanproto: 802.1q vlanpcp: 0 parent interface: epair0b >> media: Ethernet 10Gbase-T (10Gbase-T ) >> status: active >> nd6 options=29 >> >> Let me know if you want anything more. >> >> ~Paul >> -- >> __________________ >> >> :(){ :|:& };: > > Problem fixed. I feel so ashamed. > While epair0b.60 was up ... epair0b wasn't. > A stupid stupid oversight. > > Thanks again for all the help and attention. And sorry for the noise. > I owe ya'll a beer if we ever cross paths. > > ~Paul Oh, I've been bitten by this so many times. Would be nice if ifconfig would show interface that are down in blinking bold red. :-) Thinking out loud. With these layered interfaces, I can't think of a reason why you would have epair0b.60 up, but epair0b down. Why wouldn't we bring up both if you ifconfig up one of them or at least when you bring up the top one? Similar thinking could be done for epair0a and epair0b. I have never been in a situation in which I want one side of the pair up and the other down. What would hold us back from implementing this? Ronald.