RHEL 6.4: la liaison des canaux en mode 1 ne bascule pas

11

J'utilise RHEL 6.4, kernel-2.6.32-358.el6.i686, sur un HP ML 350 G5 avec deux cartes réseau Broadcom NetXtreme II BCM5708 1000Base-T intégrées. Mon objectif est de canaliser les deux interfaces en une mode=1paire de basculement.

Mon problème est que, malgré toutes les preuves que la liaison est établie et acceptée, le retrait du câble de la carte réseau principale entraîne l'arrêt de toutes les communications.

ifcfg-etho et ifcfg-eth1

Tout d'abord, 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

Ensuite, 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

Fichier de configuration de mon lien:

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

J'ai un /etc/modprobe.d/bonding.conffichier qui est rempli ainsi:

alias bond0 bonding

sortie ip addr

Le lien est en place et je peux accéder aux services publics du serveur via l'adresse IP du lien:

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

Module de noyau de liaison

...est chargé:

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

/ sys / class / net

Le /sys/class/netsystème de fichiers montre de bonnes choses:

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

Rien de préoccupant n'apparaît dans le fichier journal. En fait, tout semble plutôt heureux.

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

Donc quel est le problème?!

Le fait de tirer le câble réseau de eth0 fait que toutes les communications deviennent sombres. Quel pourrait être le problème et quelles mesures supplémentaires devrais-je prendre pour résoudre ce problème?

ÉDITER:

Dépannage supplémentaire:

Le réseau est un seul sous-réseau, un seul VLAN fourni par un commutateur ProCurve 1800-8G. J'ai ajouté primary=eth0à ifcfg-bond0des services réseau de redémarrage, mais qui n'a pas changé tout comportement. J'ai vérifié à la /sys/class/net/bond0/bonding/primaryfois avant et après l'ajout primary=eth1et il a une valeur nulle, ce qui, je ne suis pas sûr, est bon ou mauvais.

Tailing /var/log/messagesquand eth1son câble a été retiré ne montre rien de plus que:

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

J'ai ajouté use_carrier=0à ifcfg-bond0la BONDING_OPTSsection de pour permettre l'utilisation des ioctls MII / ETHTOOL. Après le redémarrage du service réseau, il n'y avait aucun changement dans les symptômes. Le fait de retirer le câble eth0entraîne l'interruption de toute communication réseau. Encore une fois, aucune erreur n'a été /var/log/messagesenregistrée pour la notification que le lien sur ce port est tombé.

linux  redhat  rhel6  bonding 
— Wesley
source
1
Pouvez-vous ajouter des informations supplémentaires telles que le commutateur make / model connecté à, toute configuration de VLAN sur le commutateur, les états esclaves de liaison et / var / log / messages après que le câble vers eth0 est débranché?
— Andy Shinn du
@AndyShinn Le commutateur auquel il est directement connecté est un ProCurve 1800-8G. Il n'y a pas de VLAN sur le réseau. C'est un simple sous-réseau unique, un seul réseau VLAN.
— Wesley
@AndyShinn Ah, ainsi que les états esclaves obligataires sont tous deux signalés comme up. La mise à la queue /var/log/messagesau moment où eth0 est débranché montre seulement que la liaison en cuivre a été débranchée. Aucun message du module de liaison.
— Wesley

Réponses:

21

LIS. VOTRE. CONFIG.

Et quand ça échoue ...

LIS. TOUT. LES SORTIES.

Voyez-vous ce qu'il y a dedans ifcfg-bond0? Non, tu comprends ce qu'il y a dedans ifcfg-bond0?
Qu'est-ce que dans le monde des pingouins glissants miimmon=100?
Oh je suis désolé, tu voulais dire miimon=100?

Ouais, je pense que tu voulais dire miimonet non miimmon.

En outre, un gros cadeau est que lorsque vous redémarrez votre service réseau, vous voyez ceci:

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  ]

Portez une attention particulière à tout ce que vous tapez et lorsque vous faites votre inévitable erreur de frappe, portez une attention particulière à chaque sortie que vous voyez.

Vous êtes une mauvaise personne et vous devriez vous sentir mal.

— Wesley
source
8
MAUVAIS CHAT! sprays avec tuyau
— voretaq7
2

Essayez de spécifier l'un des NICS comme esclave principal. 

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"

Plus de documentation de RH :

primary = Spécifie le nom d'interface, tel que eth0, du périphérique principal. Le périphérique principal est la première des interfaces de liaison à utiliser et n'est abandonné qu'en cas d'échec. Ce paramètre est particulièrement utile lorsqu'une carte d'interface réseau dans l'interface de liaison est plus rapide et, par conséquent, capable de gérer une charge plus importante. Ce paramètre n'est valide que lorsque l'interface de liaison est en mode de sauvegarde active. Reportez-vous à /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt pour plus d'informations.

— dmourati
source
Avant de modifier, ifcfg-bond0j'ai vérifié /sys/class/net/bond0/bonding/primaryet la réponse est vide. J'ai ajouté primary=eth0à ifcfg-bond0et redémarrer le service réseau. Il n'y a aucun changement dans le symptôme et aucun changement à /sys/class/net/bond0/bonding/primaryMerci pour la suggestion!
— Wesley
essayez d'ajouter use_carrier = 0? voir ci-dessus doc RH pour plus de détails
— dmourati
Terminé - a ajouté les informations à la question. Il n'y a pas eu de changement de comportement, mais c'est une bonne option à connaître.
— Wesley
2

Ajoutez l'option de liaison suivante downdelay = xxxx dans milisec qui échoue un eth après qu'il a été détecté comme ayant échoué et définissez l'esclave principal sur le reste. Si ce paramètre n'est pas dans le bonding_opt, le lien détecte l'échec (car vous incluez miimom = yyyy) mais il n'échoue jamais à eth0. Vous pouvez voir cela se produire en consultant le fichier / proc / net / bonding / bondX.

Quoi qu'il en soit, avec RHEL 6.3 (presque la même version que la vôtre), nous rencontrons plusieurs autres problèmes de liaison liés à la reprise en arrière, l'adr du mac dupliqué vu depuis le commutateur.

bonne chance.

— mcw
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.