RHEL 6.4: Łączenie kanałów w trybie 1 nie ulega awarii

11

Używam RHEL 6.4, jądro-2.6.32-358.el6.i686, na HP ML 350 G5 z dwoma wbudowanymi kartami sieciowymi Broadcom NetXtreme II BCM5708 1000Base-T. Moim celem jest połączenie kanałów dwóch interfejsów w mode=1parę przełączania awaryjnego.

Mój problem polega na tym, że pomimo wszelkich dowodów na to, że połączenie zostało ustanowione i zaakceptowane, wyciągnięcie kabla z głównej karty sieciowej powoduje przerwanie wszelkiej komunikacji.

ifcfg-etho i ifcfg-eth1

Po pierwsze, 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

Następnie 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

Plik konfiguracyjny mojej obligacji:

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

Mam odpowiednio /etc/modprobe.d/bonding.confwypełniony plik:

alias bond0 bonding

wyjście ip addr

Wiązanie wygasło i mogę uzyskać dostęp do usług publicznych serwera za pośrednictwem adresu IP obligacji:

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

Klejący moduł jądra

...jest załadowana:

# cat /proc/modules | grep bond
bonding 111135 0 - Live 0xf9cdc000

/ sys / class / net

System /sys/class/netplików pokazuje dobre rzeczy:

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

W pliku dziennika nie ma nic niepokojącego. W rzeczywistości wszystko wygląda raczej na szczęśliwe.

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

Więc w czym problem?!

Wyciągnięcie kabla sieciowego z eth0 powoduje, że cała komunikacja staje się ciemna. Jaki może być problem i jakie dalsze kroki powinienem podjąć, aby rozwiązać ten problem?

EDYTOWAĆ:

Dalsze rozwiązywanie problemów:

Sieć to pojedyncza podsieć, pojedyncza sieć VLAN zapewniana przez przełącznik ProCurve 1800-8G. Dodałem primary=eth0do ifcfg-bond0i restart usługi sieciowe, ale nie zmienił żadnych zachowań. Sprawdziłem /sys/class/net/bond0/bonding/primaryzarówno przed dodaniem, jak i po dodaniu, primary=eth1i ma wartość zerową, co nie jest pewne, czy jest dobre czy złe.

Ogonowanie /var/log/messagespo eth1usunięciu kabla pokazuje tylko:

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

Po dodaniu use_carrier=0do ifcfg-bond0„S BONDING_OPTSsekcji, umożliwia zastosowanie ioctl MII / ethtool. Po ponownym uruchomieniu usługi sieciowej objawy nie uległy zmianie. Wyciągnięcie kabla eth0powoduje przerwanie całej komunikacji sieciowej. Po raz kolejny nie /var/log/messageswystąpiły błędy w zapisywaniu powiadomienia, że ​​łącze do tego portu zostało zerwane.

linux  redhat  rhel6  bonding 
— Wesley
źródło
1
Czy możesz dodać więcej informacji, takich jak podłączony przełącznik make / model, dowolna konfiguracja VLAN na przełączniku, stany slave wiązania i komunikaty / var / log / po odłączeniu kabla do eth0?
— Andy Shinn
@AndyShinn Przełącznik, do którego jest bezpośrednio podłączony, to ProCurve 1800-8G. W sieci nie ma sieci VLAN. To prosta pojedyncza podsieć, pojedyncza sieć VLAN.
— Wesley,
@AndyShinn Ah, a także stany niewolników obligacji są zgłaszane jako up. Tailing /var/log/messagesw momencie odłączenia eth0 pokazuje tylko, że miedziane łącze zostało odłączone. Brak komunikatów z modułu łączenia.
— Wesley,

Odpowiedzi:

21

CZYTAĆ. TWÓJ. KONFIGURACJE.

A kiedy to się nie powiedzie ...

CZYTAĆ. WSZYSTKO. WYJŚCIA.

Widzisz co jest w ifcfg-bond0środku? Nie, rozumiesz co jest w ifcfg-bond0środku?
Co w świecie śliskich pingwinów miimmon=100?
Och przepraszam, miałeś na myśli miimon=100?

Tak, myślę, że miałeś na myśli miimoni nie miimmon.

Dużym wyróżnieniem jest to, że po ponownym uruchomieniu usługi sieciowej widzisz to:

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  ]

Zwróć szczególną uwagę na wszystko, co piszesz, a kiedy popełnisz nieunikniony błąd w pisaniu, zwróć szczególną uwagę na każdy wynik, który widzisz.

Jesteś złym człowiekiem i powinieneś czuć się źle.

— Wesley
źródło
8
ZŁY KOT! spraye z wężem
— voretaq7
2

Spróbuj określić jeden z NICS jako głównego slave. 

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"

Więcej dokumentacji z RH :

primary = Określa nazwę interfejsu, na przykład eth0, urządzenia podstawowego. Główne urządzenie jest pierwszym używanym interfejsem łączącym i nie jest porzucane, chyba że zawiedzie. To ustawienie jest szczególnie przydatne, gdy jedna karta sieciowa w interfejsie łączenia jest szybsza i dlatego jest w stanie obsłużyć większe obciążenie. To ustawienie jest ważne tylko wtedy, gdy interfejs łączenia jest w trybie aktywnej kopii zapasowej. Więcej informacji znajduje się w /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt.

— dmourati
źródło
Przed edycją ifcfg-bond0sprawdziłem, /sys/class/net/bond0/bonding/primarya odpowiedź jest pusta. I dodaje primary=eth0się ifcfg-bond0i ponownie uruchomić usługę sieciową. /sys/class/net/bond0/bonding/primaryJednak nie ma żadnej zmiany w objawie ani zmiany w podziękowaniu za sugestię!
— Wesley,
spróbuj dodać use_carrier = 0? szczegóły patrz wyżej dokument RH
— dmourati
Gotowe - dodano informacje do pytania. Nie było żadnych zmian w zachowaniu, ale to dobra opcja, aby o tym wiedzieć.
— Wesley
2

Dodaj następującą opcję łączenia downdelay = xxxx in milisec, która zawiedzie et po wykryciu go jako nieudaną, i ustaw podstawowe slave na pozostałe. Jeśli tego parametru nie ma w opcji bonding_opt, wiązanie wykrywa awarię (ponieważ dołączasz miimom = rrrr), ale nigdy nie zawodzi et0. Możesz zobaczyć, jak to się dzieje, patrząc na plik / proc / net / bonding / bondX.

W każdym razie, z RHEL 6.3 (prawie ta sama wersja, co twoja) mamy kilka innych problemów z wiązaniem związanych z awarią, powieleniem adresu MAC widzianego z przełącznika.

powodzenia.

— McW
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.