Re: FBSD 15 :: if_bridge help needed

Op 08-10-2025 om 10:10 schreef Paul Procacci:
> On Wed, Oct 8, 2025 at 4:04 AM Paul Procacci <pprocacci@gmail.com> wrote:
>>
>> On Wed, Oct 8, 2025 at 3:59 AM Lexi Winter <ivy@freebsd.org> wrote:
>>>
>>> Paul Procacci wrote in <CAFbbPuhiLsWcjbVD9F_RH+Q+5b2BZcAnLK2h3AqiJjkcOkxaMQ@mail.gmail.com>:
>>>>  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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
>> metric 0 mtu 1500
>>          options=60000b<RXCSUM,TXCSUM,VLAN_MTU,RXCSUM_IPV6,TXCSUM_IPV6>
>>          ether 58:9c:fc:10:8b:0f
>>          groups: epair
>>          media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
>>          status: active
>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>
>>
>> root@Jail 1:/ # ifconfig epair0b; ifconfig epair0b.60
>> epair0b: flags=1008942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
>> metric 0 mtu 1500
>>          options=60000b<RXCSUM,TXCSUM,VLAN_MTU,RXCSUM_IPV6,TXCSUM_IPV6>
>>          ether 58:9c:fc:10:bb:b7
>>          groups: epair
>>          media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
>>          status: active
>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> epair0b.60: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
>> 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 <full-duplex>)
>>          status: active
>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>
>> 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.