Gestern Nacht bin ich etwas länger gehockt um den einen oder anderen Fehler der sich mit der Umstellung auf Ubuntu 10.04 LTS eingeschlichen hat zu beheben.
Einer hat mich dann heute noch beschäftigt – bonding funktioniert nach eine Neustart nicht mehr, erst nach einem erneuten „service networking restart“ lief das bonding wieder.
Die Konfiguration hatte ich exakt so vorgenommen wie es in den Releasenotes von Ubuntu Lucid drinnen steht (bzw. unter /usr/share/doc/ifenslave-2.6/examples/two_hotplug_ethernet):
auto bond0
iface bond0 inet static
address 192.168.10.10
network 255.255.255.0
gateway 192.168.10.1
dns-nameservers 192.168.10.1
bond-slaves none
bond-mode 1
bond-miimon 100auto eth0
iface eth0 inet manual
bond-master bond0
bond-primary eth0 eth1auto eth1
iface eth1 inet manual
bond-master bond0
bond-primary eth0 eth1
Nach einem Neustart hat mich dann tatsächlich ein Bonding Interface inkl. zweier Slaves (eth0/eth1) erwartet, allerdings konnte man das System nicht pingen bzw. das System konnte auf das Netzwerk auch nicht zugreifen!
Interessant finde ich die Tatsache dass die Zähler bei RX/TX trotz fehlender Funktionalität sich munter bewegt haben, also irgend ein Traffic muss angekommen nur nicht korrekt verarbeitet worden sein.
Nachdem ich so gut wie jede Möglichkeit durchgetestet habe, bin ich zu der Erkenntnis gekommen dass das definitiv nicht so wie angegeben funktioniert!
Eine funktionierende Lösung sieht wie folgt aus:
Datei: /etc/modprobe.d/bonding
install bond0 /sbin/modprobe bonding -o bond0 mode=balance-xor miimon=100
Datei: /etc/network/interfaces
auto bond0
iface bond0 inet static
address 192.168.10.10
netmask 255.255.255.0
gateway 192.168.10.1
dns-nameservers 192.168.10.1
post-up ifenslave bond0 eth0 eth1
pre-down ifenslave -d bond0 eth0 eth1
Mit diesen Einstellungen funktioniert bei mir das Bonding auch unmittelbar nach einem Reboot und das ohne dass „service networking restart“ ausgeführt werden muss.
Der in den Release-Notes angepriesene hotplug-stlye funktioniert im Moment ganz einfach nicht – zumindest nicht so wie es dort geschrieben steht dass es funktionieren sollte 🙂
Falls jemand den tatsächlichen Fehler kennt der das Problem beim „hotplug-style“ verursacht, ich freue mich über jeden Tip – erstmal werde ich das ganze aber bei Launchpad einpflegen.
2010-05-04 Nachtrag: Ein Server hat sich bei mir jetzt ganz hartnäckig geweigert mit der Lösung zu laufen, da musste ich in der Datei /etc/rc.local folgende Zeilen einpflegen:
ifenslave -d bond0 eth0 eth1 eth2
ifenslave bond0 eth0 eth1 eth2
Man macht es nicht jeden Tag, darum schadet es nicht sich's kurz zu notieren... Hier…
Meine Suche bei Google hatte mal wieder keinen vernünftigen Treffer gelandet, das Problem - ich…
Ich muss mal eben etwas Druck ablassen, ein Kunde von mir setzt einen Drucker von…
Wer beim Server bestellen vergessen hat die erweiterte IRMC Lizenz zu ordern, der steht vor…
Ich nutze seit langer Zeit ein System für meine Backups welches in der Nacht von…
Es scheint wohl eine noch nicht so häufig genutzte Kombination zu sein - Apache Guacamole…
View Comments
Hallo,
hab grad Deine Lösung versucht anzuwenden, es kommt eine "Failed to bring up bond0" Meldung.
wie hast Du folgendes gelöst:
root@server:/etc/modprobe.d# modprobe -a -v *
WARNING: Module blacklist_ath_pci.conf not found.
WARNING: Module blacklist.conf not found.
WARNING: Module blacklist_firewire.conf not found.
WARNING: Module blacklist_framebuffer.conf not found.
WARNING: Module blacklist_watchdog.conf not found.
WARNING: Module bonding.conf not found.
?
Was muss ich da machen?
Gruss
edubidu
was genau willst du mit dem "modprobe -a -v *" machen?
der versucht in deinem fall die config-dateien im aktuellen verzeichnis als modul zu landen! das klappt natürlich nicht.
ich glaub was du ausführen willst ist das hier:
/sbin/modprobe bonding -o bond0 mode=balance-xor miimon=100
rechner neustarten wäre natürlich auch eine variante, da wird das was in der bonding.conf drinnen steht dann automatisch ausgeführt.
hoffe das hilft dir weiter! :-)
Also ein Neuboot hat mir den Rechner mit einem fsck hängen gelassen. Ich muss ihn nun nochmals neu aufsetzen (ist nich so schlimm, das Bonding war eh die erste Konfig nach dem Aufsetzen). Aber eigenartig is das ja schon.
na der fsck kann mal nicht mit dem bonding zusammenhängen, aber eigenartig ist's auf jeden fall!
fsck nach installation hatte ich nur wenn vorher das datum komplett falsch war und er beim ersten kontakt mit dem internet die zeit synchronisiert hat und nachher festgestellt hat dass er schon seit jahren keinen fsck mehr gemacht hat :-)
viel erfolg dann beim 2. versuch!
Hallo, jetzt funkt's. Allerdings war das fsck doch wegen der Bonding Konfig, denn es ist ein 2. und 3. mal - jedesmal nach der Bonding Konfig - so gekommen.
Habe ich auch noch nie erlebt.
Anyway. Es funkt bei mir mit der ersten Konfig, die bei Dir nicht ging. Und es funkt auch nach einem Reboot.
Hier die /etc/network/interfaces
auto lo
iface lo inet loopback
# The primary network interface
#auto eth0
#iface eth0 inet dhcp
#auto eth1
#iface eth1 inet dhcp
auto bond0
iface bond0 inet static
address 192.168.57.52
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.57.1
dns-nameservers 192.168.202.100
#post-up ifenslave bond0 eth0 eth1
#pre-down ifenslave -d bond0 eth0 eth1
bond-slaves none
bond-mode 1
bond-miimon 100
auto eth0
iface eth0 inet manual
bond-master bond0
bond-primary eth0 eth1
auto eth1
iface eth1 inet manual
bond-master bond0
bond-primary eth0 eth1
in /etc/modprobe.d musste ich nun nix eintragen und auch in /etc/rc.local musste ich nix eintragen.
ifconfig zeigt das bond auch korrekt an.
Da soll man noch die Welt verstehn!
Gruss
edubidu
das mit dem fsck ist wirklich schräg weil das eine definitiv nichts mit dem anderen zu tun hat! :-)
aber auch dass bei dir das bonding mit der variante funktioniert die bei mir überhaupt nicht geklappt hat finde ich lustig.
dein network eintrag ist übrigens nicht ganz korrekt, der müsste lauten:
network 192.168.57.0
ansonsten - super dass du es zum laufen gebracht hast!
Hallo,
würde sagen es liegt an den unterschiedlichen Versionen. Nachzulesen ist das ganze hier.
http://wiki.debian.org/Bonding
Der bond_updelay Parameter ist mir neu, kann mir gut vorstellen dass der mit Abhilfe bringt!
Bei mir konnte ich ja meist mit einem nachträglichen /etc/init.d/networking restart das System zum laufen bringen, nur beim Neustart lief das Bonding unter Garantie nie.
Die Version hätte bei mir schon gepasst, daran liegts wohl eher nicht.
Werds bei nächster Gelegenheit dann mal mit dem bond_updelay austesten!