Ich verwende RHEL 6.4, Kernel-2.6.32-358.el6.i686, auf einem HP ML 350 G5 mit zwei integrierten Broadcom NetXtreme II BCM5708 1000Base-T-Netzwerkkarten. Mein Ziel ist es, die beiden Schnittstellen zu einem mode=1
Failover-Paar zu verbinden.
Mein Problem ist, dass trotz aller Beweise dafür, dass die Verbindung hergestellt und akzeptiert wurde, das Herausziehen des Kabels aus der primären Netzwerkkarte dazu führt, dass die gesamte Kommunikation unterbrochen wird.
ifcfg-etho und ifcfg-eth1
Erstens, ifcfg-eth0:
DEVICE=eth0
HWADDR=00:22:64:F8:EF:60
TYPE=Ethernet
UUID=99ea681d-831b-42a7-81be-02f71d1f7aa0
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
Als nächstes ifcfg-eth1:
DEVICE=eth1
HWADDR=00:22:64:F8:EF:62
TYPE=Ethernet
UUID=92d46872-eb4a-4eef-bea5-825e914a5ad6
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
ifcfg-bond0
Konfigurationsdatei meiner Anleihe:
DEVICE=bond0
IPADDR=192.168.11.222
GATEWAY=192.168.11.1
NETMASK=255.255.255.0
DNS1=192.168.11.1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="mode=1 miimmon=100"
/etc/modprobe.d/bonding.conf
Ich habe eine /etc/modprobe.d/bonding.conf
Datei, die so ausgefüllt ist:
alias bond0 bonding
IP-Adr-Ausgabe
Die Anleihe ist aktiv und ich kann über die IP-Adresse der Anleihe auf die öffentlichen Dienste des Servers zugreifen:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:22:64:f8:ef:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.222/24 brd 192.168.11.255 scope global bond0
inet6 fe80::222:64ff:fef8:ef60/64 scope link
valid_lft forever preferred_lft forever
Bonding-Kernel-Modul
... wird geladen:
# cat /proc/modules | grep bond
bonding 111135 0 - Live 0xf9cdc000
/ sys / class / net
Das /sys/class/net
Dateisystem zeigt gute Dinge:
cat /sys/class/net/bonding_masters
bond0
cat /sys/class/net/bond0/operstate
up
cat /sys/class/net/bond0/slave_eth0/operstate
up
cat /sys/class/net/bond0/slave_eth1/operstate
up
cat /sys/class/net/bond0/type
1
/ var / log / messages
In der Protokolldatei wird nichts Besorgniserregendes angezeigt. Tatsächlich sieht alles ziemlich glücklich aus.
Jun 15 15:47:28 rhsandbox2 kernel: Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: setting mode to active-backup (1).
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: Adding slave eth0.
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: using MSI
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: making interface eth0 the new active one.
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: first active interface up!
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: enslaving eth0 as an active interface with an up link.
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: Adding slave eth1.
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:05:00.0: eth1: using MSI
Jun 15 15:47:28 rhsandbox2 kernel: bonding: bond0: enslaving eth1 as a backup interface with an up link.
Jun 15 15:47:28 rhsandbox2 kernel: 8021q: adding VLAN 0 to HW filter on device bond0
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
Jun 15 15:47:28 rhsandbox2 kernel: bnx2 0000:05:00.0: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
Also, was ist das Problem?!
Wenn Sie das Netzwerkkabel von eth0 abziehen, wird die gesamte Kommunikation dunkel. Was könnte das Problem sein und welche weiteren Schritte sollte ich unternehmen, um dieses Problem zu beheben?
BEARBEITEN:
Weitere Fehlerbehebung:
Das Netzwerk ist ein einzelnes Subnetz, ein einzelnes VLAN, das von einem ProCurve 1800-8G-Switch bereitgestellt wird. Ich habe hinzugefügt primary=eth0
zu ifcfg-bond0
und Neustart Netzwerk - Service, aber das jedes Verhalten nicht geändert hat. Ich habe /sys/class/net/bond0/bonding/primary
sowohl vor als auch nach dem Hinzufügen überprüft , primary=eth1
und es hat einen Nullwert, von dem ich nicht sicher bin, ob er gut oder schlecht ist.
/var/log/messages
Wenn eth1
das Kabel entfernt wird, wird nur Folgendes angezeigt :
Jun 15 16:51:16 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Down
Jun 15 16:51:24 rhsandbox2 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
Ich use_carrier=0
habe ifcfg-bond0
den BONDING_OPTS
Abschnitt hinzugefügt , um die Verwendung von MII / ETHTOOL-Ioctls zu ermöglichen. Nach dem Neustart des Netzwerkdienstes gab es keine Änderung der Symptome. Durch Ziehen des Kabels wird eth0
die gesamte Netzwerkkommunikation unterbrochen. Wiederum keine Fehler beim /var/log/messages
Speichern für die Benachrichtigung, dass die Verbindung an diesem Port unterbrochen wurde.
up
. Ein Tailing/var/log/messages
zum Zeitpunkt des Abziehens von eth0 zeigt nur an, dass die Kupferverbindung abgezogen wurde. Keine Nachrichten vom Bonding-Modul.Antworten:
LESEN. IHRE. KONFIG.
Und wenn das fehlschlägt ...
LESEN. ALLE. AUSGÄNGE.
Sehen Sie, was drin ist
ifcfg-bond0
? Nein, verstehst du was drin istifcfg-bond0
?Was in der Welt der rutschigen Pinguine ist
miimmon=100
?Oh, tut mir leid, meintest du
miimon=100
?Ja, ich denke du meintest
miimon
und nichtmiimmon
.Ein großes Werbegeschenk ist auch, dass beim Neustart Ihres Netzwerkdienstes Folgendes angezeigt wird:
Achten Sie sorgfältig auf alles, was Sie eingeben, und wenn Sie einen unvermeidlichen Tippfehler machen, achten Sie sorgfältig auf jede Ausgabe, die Sie sehen.
Du bist ein schlechter Mensch und du solltest dich schlecht fühlen.
quelle
Versuchen Sie, einen der NICS als primären Slave anzugeben.
Weitere Dokumentation von RH :
primary = Gibt den Schnittstellennamen (z. B. eth0) des primären Geräts an. Das primäre Gerät ist die erste der zu verwendenden Verbindungsschnittstellen und wird nicht verlassen, es sei denn, es fällt aus. Diese Einstellung ist besonders nützlich, wenn eine Netzwerkkarte in der Verbindungsschnittstelle schneller ist und daher eine größere Last aufnehmen kann. Diese Einstellung ist nur gültig, wenn sich die Bonding-Schnittstelle im aktiven Sicherungsmodus befindet. Weitere Informationen finden Sie unter /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt.
quelle
ifcfg-bond0
ich überprüft/sys/class/net/bond0/bonding/primary
und die Antwort ist leer. Ich habeprimary=eth0
zuifcfg-bond0
und starten Sie den Netzdienst. Es gibt keine Änderung im Symptom und keine Änderung in/sys/class/net/bond0/bonding/primary
Danke für den Vorschlag!Fügen Sie die folgende Verbindungsoption downdelay = xxxx in milisec hinzu, bei der ein eth fehlschlägt, nachdem es als fehlgeschlagen erkannt wurde, und setzen Sie den primären Slave auf den verbleibenden Wert. Wenn dieser Parameter nicht in bonding_opt enthalten ist, erkennt die Bindung den Fehler (da Sie miimom = yyyy einschließen), aber eth0 schlägt niemals fehl. Sie können dies anhand der Datei / proc / net / bonding / bondX sehen.
Wie auch immer, mit RHEL 6.3 (fast die gleiche Version wie Ihre) haben wir einige andere Probleme mit der Verbindung im Zusammenhang mit dem Zurücksetzen einer duplizierten Mac-Adresse, die vom Switch aus gesehen wird.
Viel Glück.
quelle