Sometime after F-8 GA the kernel changed the bridge forwarding delay to be 15 seconds. kernel source: net/bridge/br_if.c: br->bridge_forward_delay = br->forward_delay = 15 * HZ; This makes it really annoying for KVM PXE boot users, because DHCP fails for 15 seconds instead of working instantly like it did in the past. Workaround: brctl setfd virbr0 0.1 Two questions: 1) Why did the kernel change this? 2) Can we workaround this in the virbr0 creation?
The line you quoted was added in 2.3.47pre5 It hasn't changed since. I think the problem is elsewhere.
OK, it was some other host kernel change that caused this problem.
Reassigning to libvirt. > I think I understand what's going on here. > > - The libvirt 'default' network XML config (aka that for virbr0) does > not specify any forward delay or STP setting, so it defaults to > delay=0, and STP=on > > - The libvirt in F8 GA had a bug, where it called 'setfd' instead > 'stp' when invoking brctl. > > - Thus, the default config would result in a bridge with STP off > and a delay of 1 second. > > - A libvirt update fixed the bug in the way we call brctl. Fixing > the bug means we now by default create a bridge with STP on > and the default kernel delay setting of 15 seconds. > > - There is a further bug in that if you specify delay=0 in the XML > it'll never call 'brctl setfd 0', so you'll be stuck with the 15 > second default still. > > So yes, we need to fix things such that it has STP=on and a tiny (or even > zer) forward forward delay again, as per F8 GA behaviour. Can you file > a BZ about this problem against libvirt. It impacts F9 and rawhide too > > Daniel
libvirt now explicitly sets FD to zero, from at least 0.4.5 release