Proxmox : Bond0 received packet with own address as source

De $1

 

A valider 

Apparemment, Proxmox ne supporte que les modes balance-tlb, active-backup, 802.3 ad et balance-rr (avec modifications)

 

Proxmox 1.9

proxmox10:~# pveversion -v
pve-manager: 1.9-26 (pve-manager/1.9/6567)
running kernel: 2.6.32-6-pve
proxmox-ve-2.6.32: 1.9-50
pve-kernel-2.6.32-6-pve: 2.6.32-50
qemu-server: 1.1-32
pve-firmware: 1.0-14
libpve-storage-perl: 1.0-19
vncterm: 0.9-2
vzctl: 3.0.29-3pve1
vzdump: 1.2-16
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.15.0-1
ksm-control-daemon: 1.0-6
proxmox10:~# 
 

Modifier la configuration réseau du Bridge (ici vmbr1) utilisant la carte Bond0

auto bond0
iface bond0 inet manual
	slaves eth2 eth3
	bond_miimon 100
	bond_mode balance-rr


auto vmbr1
iface vmbr1 inet manual
	bridge_ports bond0
	bridge_stp on
	bridge_fd 0
	bridge_maxwait 0
	bridge_maxage 0
	bridge_ageing 0

 
 

 

Round-robin bonding (mode 0) with virtualization breaks networking for guests. Why? How can I work around it?

Article ID: 16051 - Created on: Mar 5, 2009 12:53 AM - Last Modified:  Jun 22, 2010 11:18 AM

Release Found: Red Hat Enterprise Linux 5

 

Symptoms

After configuring round-robin bonding in Dom0, and attaching a guest to the bridge which is created using the bonded interface, pinging from guest to other systems in the same network or external network may completely fail or cause heavy packet loss.

 

Cause

When using bonding to provide increased throughput and fault tolerance for hosts that will use virtualization, it is important not to use round-robin (mode 0) bonding when using bridging for your guest network access.  Since round-robin bonding requires that the switch connected to the host is unaware that the host is doing any type of bonding (the switch will presume that two or more links are simply connected to different hosts rather than a single host), any traffic broadcast out of one member of the bond will come back to the host from the other bond links.  This is problematic when an Ethernet frame that will be broadcast is sourced from the virtualized guest.

 

When the broadcast frame originally sent by the guest arrives on the slave interfaces it will be passed to the networking stack through the bonding code by the bridging code.  This frame will have the same source MAC address as the virtual device that transmitted the frame, so the bridging code will associate that source MAC address with the bonded interface in its forwarding database.  Any further traffic that arrives on the bonded interface (before the guest transmits another non-broadcast frame) destined for the MAC address of the guest will be dropped.  This happens because the bridge is required to drop all frames with a destination MAC address that matches a forwarding database entry for the same port (this prevents unnecessary forwarding of frames).

 

Solution

There is no plan to provide a solution for this through a code change in the bridging code at this time. However, there is an effective workaround:

 

When trying to achieve greater throughput with bonding, balance-tlb (mode 5) or 802.3ad (mode 4) should be used since those modes will drop the additional incoming broadcast frames before passing the frames to the stack.  The problem described in this article is not found in these modes. If fault tolerance is the only concern, active-backup (mode 1) will avoid this problem by dropping broadcast frames on the backup interface.  Use of those alternative modes is recommended.

 

 

Le 04 février 2012

Test de proxmox avec un bond mode balance-rr + configuration additionnelle >> OK

Configuration balance-rr, fichier /etc/network/interfaces

auto bond0
iface bond0 inet manual
	slaves eth1 eth3
	bond_miimon 100
	bond_mode balance-rr

auto vmbr1
iface vmbr1 inet static
	address  192.168.XXX.XXX
	netmask  255.255.255.0
	bridge_ports bond0
	bridge_stp on
	bridge_maxwait 0
	bridge_maxage 0
	bridge_fd 0
	bridge_ageing 0


 howto05_small.pngVous en pensez quoi ?


 

 

 

   

 

Cette page n'a encore aucun contenu. Enrichissez Yakakliker en y contribuant vous aussi.

FichierTailleDateAttaché par 
 etherchannel.pdf
Aucune description
73.66 Ko16:35, 4 Fév 2012franckActions
Images (0)
 
Commentaires (0)
Vous devez être connecté pour poster un commentaire.