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

Reply via email to