| raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>