RHEL 6.4: la vinculación de canales del modo 1 no falla

11

Estoy ejecutando RHEL 6.4, kernel-2.6.32-358.el6.i686, en una HP ML 350 G5 con dos NIC Broadcom NetXtreme II BCM5708 1000Base-T integradas. Mi objetivo es vincular las dos interfaces en un mode=1par de conmutación por error.

Mi problema es que, a pesar de todas las pruebas de que el vínculo está establecido y aceptado, sacar el cable de la NIC primaria hace que cese toda comunicación.

ifcfg-etho y ifcfg-eth1

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

A continuación, 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

El archivo de configuración de mi bono:

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

Tengo un /etc/modprobe.d/bonding.confarchivo que se rellena así:

alias bond0 bonding

salida de ip addr

El bono está activo y puedo acceder a los servicios públicos del servidor a través de la dirección IP del bono:

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

Módulo de unión del núcleo

...está cargado:

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

/ sys / class / net

El /sys/class/netsistema de archivos muestra cosas buenas:

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

Nada de preocupación aparece en el archivo de registro. De hecho, todo parece bastante feliz.

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

¡¿Entonces, cuál es el problema?!

Tirar del cable de red desde eth0 hace que toda la comunicación se apague. ¿Cuál podría ser el problema y qué pasos adicionales debo tomar para solucionarlo?

EDITAR:

Solución de problemas adicionales:

La red es una subred única, una VLAN única proporcionada por un conmutador ProCurve 1800-8G. He añadido primary=eth0a ifcfg-bond0y reiniciar los servicios de red, pero que no ha cambiado ningún comportamiento. Verifiqué /sys/class/net/bond0/bonding/primarytanto antes como después de agregar primary=eth1y tiene un valor nulo, que no estoy seguro de que sea bueno o malo.

Seguir /var/log/messagescuando se eth1ha quitado el cable no muestra nada más 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

He añadido use_carrier=0a ifcfg-bond0's BONDING_OPTSsección para permite el uso de ioctl MII / Ethtool. Después de reiniciar el servicio de red, no hubo cambios en los síntomas. Al tirar del cable, se eth0interrumpe toda comunicación de red. Una vez más, no hay errores al /var/log/messagesguardar la notificación de que el enlace en ese puerto se cayó.

linux  redhat  rhel6  bonding 
— Wesley
fuente
1
¿Puede agregar más información, como el conmutador de marca / modelo conectado, cualquier configuración de VLAN en el conmutador, estados de esclavo de enlace y / var / log / mensajes después de que el cable a eth0 esté desconectado?
— Andy Shinn
@AndyShinn El conmutador al que está conectado directamente es un ProCurve 1800-8G. No hay VLAN en la red. Es una simple subred única, una sola red VLAN.
— Wesley
@AndyShinn Ah, y también se informa que los estados esclavos de bonos son up. Cuando /var/log/messagesse desconecta el eth0 cuando se desconecta eth0 solo se muestra que el enlace de cobre se ha desconectado. No hay mensajes del módulo de vinculación.
— Wesley

Respuestas:

21

LEER. TU. CONFIGS.

Y cuando eso falla ...

LEER. TODAS. SALIDAS

¿Ves lo que hay dentro ifcfg-bond0? No, ¿ entiendes lo que hay dentro ifcfg-bond0?
¿Qué hay en el mundo de los pingüinos resbaladizos miimmon=100?
Oh lo siento, ¿quisiste decir miimon=100?

Sí, creo que quisiste decir miimony no miimmon.

Además, un gran regalo es que cuando reinicias tu servicio de red ves esto:

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  ]

Presta especial atención a todo lo que escribes y cuando cometes tu inevitable error de escritura, presta especial atención a cada salida que veas.

Eres una mala persona y deberías sentirte mal.

— Wesley
fuente
8
¡GATO MALO! aerosoles con manguera
— voretaq7
2

Intente especificar uno de los NICS como esclavo primario. 

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"

Más documentación de RH :

primary = Especifica el nombre de la interfaz, como eth0, del dispositivo primario. El dispositivo principal es la primera de las interfaces de enlace que se utiliza y no se abandona a menos que falle. Esta configuración es particularmente útil cuando una NIC en la interfaz de enlace es más rápida y, por lo tanto, capaz de manejar una carga mayor. Esta configuración solo es válida cuando la interfaz de enlace está en modo de copia de seguridad activa. Consulte /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt para obtener más información.

— dmourati
fuente
Antes de editar ifcfg-bond0revisé /sys/class/net/bond0/bonding/primaryy la respuesta está en blanco. He añadido primary=eth0a ifcfg-bond0y reiniciar el servicio de red. Sin /sys/class/net/bond0/bonding/primaryembargo, no hay cambios en los síntomas y no hay cambios en Gracias por la sugerencia.
— Wesley
intente agregar use_carrier = 0? ver arriba RH doc para más detalles
— dmourati
Hecho: se agregó la información a la pregunta. No hubo cambios en el comportamiento, pero esa es una buena opción para conocer.
— Wesley
2

Agregue la siguiente opción de enlace downdelay = xxxx en milisegundos que falla un eth después de que se haya detectado como fallido y configure el esclavo primario en el resto. Si este parámetro no está en bonding_opt, el enlace detecta el fallo (porque incluye miimom = aaaa) pero nunca falla el eth0. Puede ver que esto suceda mirando el archivo / proc / net / bonding / bondX.

De todos modos, con RHEL 6.3 (casi la misma versión que la suya) estamos teniendo varios otros problemas con la vinculación relacionados con la falla, el addr mac duplicado visto desde el switch.

buena suerte.

— mcw
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.