Call for 2024Q2 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

The deadline for the next FreeBSD Status Report update is
June, 30th 2024 for work done since the last round of quarterly reports:
April 2024 - June 2024.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the last month of each quarter,
You are also welcome to submit them even earlier if you want, and the
earlier you submit them, the more time we have for reviewing.

Status report submissions do not need to be very long. They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The following methods are available to submit your reports:

* submit a review on Phabricator and add the group "status" to the
  reviewers list. You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* submit a pull request at .
  You should put your reports in the directory
  doc/website/content/en/status/report-2024-04-2024-06/
  (create it if it is missing);

* send an email to status-submissi...@freebsd.org including your report.

An AsciiDoc template is available at
.

We look forward to seeing your 2024Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

bridge: no traffic with vnet (epair) beyond bridge device

[FreeBSD User]

Hello,

I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several 
jails. Jails are
attached to a bridge device (bridge1), the physical device on that bridge is 
igb1 (i350 based
NIC). The bridge is created via host's rc scripts, adding and/or deleting epair 
members of the
bridge is performed by the jail.conf script.

I do not know how long the setup worked, but out of the blue, last week after a 
longish
poudriere run after updating the host to most recent CURRENT (as of today, 
latest update
kernel and world) and performing "etcupdate" on both the host and all jails, 
traffic beyond
the bridge is not seen on the network! All jails can communicate with each 
other. Traffic from
the host itself is routed via igb0 to network and back via igb1 onto the bridge.

I check all setups for net.link.bridge:

net.link.bridge.ipfw: 0
net.link.bridge.log_mac_flap: 1
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I did not change anything (knowingly). 

I also have an oldish box running single socket processor, also driven by the 
very same
CURRENT and similar, but not identical setup. The box is running very well and 
the bridge is
working as expected.

I was wondering if something in detail has changed in the handling of jails, 
epair and
bridges. I followed the setup "after the book", nothing suspicious.

Maybe someone has a clue what might break the bridge.

By the way: ifconfig bridge1 looks as always, igb1 as member and it doesn't 
make any
difference whether I force the bridge to inherit igb1's MAC or not.

We also checked for the switches whether BPDU Guard may have been triggered, 
but everything
looks good from the outside - execept the fact the brdiged interface seems 
inactive (but up)
from the outside ...

Kind regards

oh

-- 
O. Hartmann

Re: bridge: no traffic with vnet (epair) beyond bridge device

[Zhenlei Huang]

> On Jun 4, 2024, at 3:02 AM, FreeBSD User  wrote:
> 
> Hello,
> 
> I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several 
> jails. Jails are
> attached to a bridge device (bridge1), the physical device on that bridge is 
> igb1 (i350 based
> NIC). The bridge is created via host's rc scripts, adding and/or deleting 
> epair members of the
> bridge is performed by the jail.conf script.
> 
> I do not know how long the setup worked, but out of the blue, last week after 
> a longish
> poudriere run after updating the host to most recent CURRENT (as of today, 
> latest update
> kernel and world) and performing "etcupdate" on both the host and all jails, 
> traffic beyond
> the bridge is not seen on the network! All jails can communicate with each 
> other. Traffic from
> the host itself is routed via igb0 to network and back via igb1 onto the 
> bridge.

Can you elaborate your setup of network. I'm getting confused by the last 
sentence.

Is it ( the network for jails ) a bridged one or routed one ?

> 
> I check all setups for net.link.bridge:
> 
> net.link.bridge.ipfw: 0
> net.link.bridge.log_mac_flap: 1
> net.link.bridge.allow_llz_overlap: 0
> net.link.bridge.inherit_mac: 0
> net.link.bridge.log_stp: 0
> net.link.bridge.pfil_local_phys: 0
> net.link.bridge.pfil_member: 0
> net.link.bridge.ipfw_arp: 0
> net.link.bridge.pfil_bridge: 0
> net.link.bridge.pfil_onlyip: 0
> 
> I did not change anything (knowingly). 
> 
> I also have an oldish box running single socket processor, also driven by the 
> very same
> CURRENT and similar, but not identical setup. The box is running very well 
> and the bridge is
> working as expected.
> 
> I was wondering if something in detail has changed in the handling of jails, 
> epair and
> bridges. I followed the setup "after the book", nothing suspicious.

No functional changes to if_bridge / if_epair / jail since the beginning of 
this year as far as I known.

> 
> Maybe someone has a clue what might break the bridge.
> 
> By the way: ifconfig bridge1 looks as always, igb1 as member and it doesn't 
> make any
> difference whether I force the bridge to inherit igb1's MAC or not.
> 
> We also checked for the switches whether BPDU Guard may have been triggered, 
> but everything
> looks good from the outside - execept the fact the brdiged interface seems 
> inactive (but up)
> from the outside ...
> 
> Kind regards
> 
> oh
> 
> -- 
> O. Hartmann
> 

Best regards,
Zhenlei