[libvirt-users] STP default behavior for bridged (off) and NAT (on) networking in libvirt

Hello, when talking about networking in hypervisors, it's easy to distinguish the two classic configurations, NAT and bridged, and the official libvirt wiki does exactly in this way here [1]. NAT networking is already configured by libvirt creating a bridge called libvirt0, while bridged networking have to be configured manually by the user. The libvirt0 bridge for NAT networking is default configured in this way: STP=on MAXWAIT=0 While suggested br0 bridge for bridged networking is configured in this way: STP=off MAXWAIT=5 Please, can you explain me why STP is on for NAT and should be off for bridged networking? It seems much easier to me to create loops when using bridged networking than NAT. Moreover, reading this old debian bug about complaints of MAXWAIT != 0 when STP off, I'm wondering if the suggested configurations aren't actually switched. Thanks, Francesco [1] http://wiki.libvirt.org/page/Networking [2] http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg700924.html

On Thu, Apr 15, 2010 at 09:23:46PM +0200, Francesco Pretto wrote:
Hello,
when talking about networking in hypervisors, it's easy to distinguish the two classic configurations, NAT and bridged, and the official libvirt wiki does exactly in this way here [1]. NAT networking is already configured by libvirt creating a bridge called libvirt0, while bridged networking have to be configured manually by the user.
The libvirt0 bridge for NAT networking is default configured in this way: STP=on MAXWAIT=0
While suggested br0 bridge for bridged networking is configured in this way: STP=off MAXWAIT=5
I don't believe we're recommending STP=off for bridging. Our recommended config is # cat > ifcfg-br0 <<EOF DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 NM_CONTROLLED=no EOF And IIUC, STP defaults to on if not specified. I agree STP should always be on for bridging to avoid netloops. The main important param DELAY=0 is there to ensure that you get instant network connectivity when doing live migration - without it you'll get a 30 second network blackout Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2010/4/16 Daniel P. Berrange <berrange@redhat.com>:
I don't believe we're recommending STP=off for bridging.
Actually STP=off is "recommended" in the wiki [1] in the ubuntu part, and there are quotes even in the fedora RHEL parts like this: # brctl show bridge name bridge id STP enabled interfaces virbr0 8000.000000000000 yes br0 8000.000e0cb30550 no eth0 I don't know who actually wrote that document but is well written and helpful, and "!google libvirt networking" points there, so it's just a matter of fix imprecisions. If you agree, I'll fix the wiki later (if is editable by anyone), recommending to set STP=on and DELAY=0 in all cases, whatever NAT or bridging configurations are chosen. Greetins, Francesco

On Fri, Apr 16, 2010 at 12:47:13PM +0200, Francesco Pretto wrote:
2010/4/16 Daniel P. Berrange <berrange@redhat.com>:
I don't believe we're recommending STP=off for bridging.
Actually STP=off is "recommended" in the wiki [1] in the ubuntu part, and there are quotes even in the fedora RHEL parts like this:
# brctl show bridge name bridge id STP enabled interfaces virbr0 8000.000000000000 yes br0 8000.000e0cb30550 no eth0
I don't know who actually wrote that document but is well written and helpful, and "!google libvirt networking" points there, so it's just a matter of fix imprecisions. If you agree, I'll fix the wiki later (if is editable by anyone), recommending to set STP=on and DELAY=0 in all cases, whatever NAT or bridging configurations are chosen.
Yes, that sounds good to me. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Daniel P. Berrange
-
Francesco Pretto