RHEL 6.4: Modus 1-Kanal-Bonding nicht fehlgeschlagen

11

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=1Failover-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.confDatei, 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/netDateisystem 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=eth0zu ifcfg-bond0und Neustart Netzwerk - Service, aber das jedes Verhalten nicht geändert hat. Ich habe /sys/class/net/bond0/bonding/primarysowohl vor als auch nach dem Hinzufügen überprüft , primary=eth1und es hat einen Nullwert, von dem ich nicht sicher bin, ob er gut oder schlecht ist.

/var/log/messagesWenn eth1das 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=0habe ifcfg-bond0den BONDING_OPTSAbschnitt 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 eth0die gesamte Netzwerkkommunikation unterbrochen. Wiederum keine Fehler beim /var/log/messagesSpeichern für die Benachrichtigung, dass die Verbindung an diesem Port unterbrochen wurde.

linux  redhat  rhel6  bonding 
— Wesley
quelle
1
Können Sie weitere Informationen hinzufügen, z. B. make / model switch verbunden, VLAN-Setup on switch, Bond-Slave-Status und / var / log / messages, nachdem das Kabel zu eth0 abgezogen wurde?
— Andy Shinn
@AndyShinn Der Switch, mit dem er direkt verbunden ist, ist ein ProCurve 1800-8G. Es gibt keine VLANs im Netzwerk. Es ist ein einfaches einzelnes Subnetz, ein einzelnes VLAN-Netzwerk.
— Wesley
@AndyShinn Ah, und auch die Bond-Slave-Zustände werden beide als gemeldet up. Ein Tailing /var/log/messageszum Zeitpunkt des Abziehens von eth0 zeigt nur an, dass die Kupferverbindung abgezogen wurde. Keine Nachrichten vom Bonding-Modul.
— Wesley

Antworten:

21

LESEN. IHRE. KONFIG.

Und wenn das fehlschlägt ...

LESEN. ALLE. AUSGÄNGE.

Sehen Sie, was drin ist ifcfg-bond0? Nein, verstehst du was drin ist ifcfg-bond0?
Was in der Welt der rutschigen Pinguine ist miimmon=100?
Oh, tut mir leid, meintest du miimon=100?

Ja, ich denke du meintest miimonund nicht miimmon.

Ein großes Werbegeschenk ist auch, dass beim Neustart Ihres Netzwerkdienstes Folgendes angezeigt wird:

service network restart
Shutting down interface bond0:                             [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface bond0:  ./network-functions: line 446: /sys/class/net/bond0/bonding/miimmon: No such file or directory
./network-functions: line 446: /sys/class/net/bond0/bonding/miimmon: No such file or directory
                                                           [  OK  ]

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.

— Wesley
quelle
8
BÖSE KATZE! Sprays mit Schlauch
— voretaq7
2

Versuchen Sie, einen der NICS als primären Slave anzugeben. 

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 primary=eth0"

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.

— dmourati
quelle
Bevor ich bearbeitet habe, habe ifcfg-bond0ich überprüft /sys/class/net/bond0/bonding/primaryund die Antwort ist leer. Ich habe primary=eth0zu ifcfg-bond0und starten Sie den Netzdienst. Es gibt keine Änderung im Symptom und keine Änderung in /sys/class/net/bond0/bonding/primaryDanke für den Vorschlag!
— Wesley
versuchen Sie use_carrier = 0 hinzuzufügen? siehe oben RH doc für Details
— dmourati
Fertig - fügte der Frage die Informationen hinzu. Es gab keine Verhaltensänderung, aber das ist eine gute Option, um darüber Bescheid zu wissen.
— Wesley
2

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.

— mcw
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.