RHEL 6.4: collegamento canale modalità 1 non in errore

11

Sto eseguendo RHEL 6.4, kernel-2.6.32-358.el6.i686, su un HP ML 350 G5 con due schede di rete Broadcom NetXtreme II BCM5708 1000Base-T integrate. Il mio obiettivo è quello di incanalare le due interfacce in una mode=1coppia di failover.

Il mio problema è che, nonostante tutte le prove che il legame sia impostato e accettato, l'estrazione del cavo dalla scheda di rete primaria provoca l'interruzione di tutte le comunicazioni.

ifcfg-etho e ifcfg-eth1

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

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

Il file di configurazione del mio legame:

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

Ho un /etc/modprobe.d/bonding.conffile che viene popolato così:

alias bond0 bonding

uscita addr ip

Il legame è scaduto e posso accedere ai servizi pubblici del server tramite l'indirizzo IP del legame:

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

Modulo del kernel di legame

... è caricato:

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

/ Sys / class / net

Il /sys/class/netfilesystem mostra cose buone:

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

Nulla di preoccupante appare nel file di registro. In effetti, tutto sembra piuttosto felice.

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

Allora, qual'è il problema?!

Se si strappa il cavo di rete da eth0, tutte le comunicazioni diventano scure. Quale potrebbe essere il problema e quali ulteriori passi devo prendere per risolvere questo problema?

MODIFICARE:

Ulteriore risoluzione dei problemi:

La rete è una singola sottorete, singola VLAN fornita da uno switch ProCurve 1800-8G. Ho aggiunto primary=eth0al ifcfg-bond0e servizi di riavvio di rete, ma che non è cambiata qualsiasi comportamento. Ho controllato /sys/class/net/bond0/bonding/primarysia prima che dopo l'aggiunta primary=eth1e ha un valore nullo, che non sono sicuro sia buono o cattivo.

La coda /var/log/messagesquando eth1viene rimosso il cavo non mostra altro che:

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

Ho aggiunto use_carrier=0a ifcfg-bond0's BONDING_OPTSsezione consente l'utilizzo di ioctls MII / ethtool. Dopo aver riavviato il servizio di rete, non si sono verificati cambiamenti nei sintomi. L'estrazione del cavo eth0causa l'interruzione di tutte le comunicazioni di rete. Ancora una volta, nessun errore nel /var/log/messagessalvataggio per la notifica che il collegamento su quella porta è andato giù.

linux  redhat  rhel6  bonding 
— Wesley
fonte
1
Potete aggiungere qualche informazione in più come switch make / model collegato, qualsiasi impostazione VLAN su switch, stati slave bond e / var / log / messaggi dopo aver scollegato il cavo su eth0?
— Andy Shinn,
@AndyShinn Lo switch a cui è direttamente collegato è un ProCurve 1800-8G. Non ci sono VLAN sulla rete. È una singola sottorete singola, una singola rete VLAN.
— Wesley,
@AndyShinn Ah, e anche gli stati degli schiavi del legame sono entrambi riportati come up. La coda /var/log/messagesal momento della disconnessione di eth0 mostra solo che il collegamento in rame è stato scollegato. Nessun messaggio dal modulo di collegamento.
— Wesley,

Risposte:

21

LEGGERE. IL TUO. CONFIGS.

E quando fallisce ...

LEGGERE. TUTTI. USCITE.

Vedi cosa c'è dentro ifcfg-bond0? No, capisci cosa c'è dentro ifcfg-bond0?
Cosa c'è nel mondo dei pinguini scivolosi miimmon=100?
Oh mi dispiace, intendevi miimon=100?

Sì, penso che tu intendessi miimone non miimmon.

Inoltre, un grande regalo è che quando riavvii il servizio di rete vedi questo:

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 molta attenzione a tutto ciò che scrivi e quando commetti il ​​tuo inevitabile errore di battitura, presta molta attenzione a ogni output che vedi.

Sei una persona cattiva e dovresti sentirti male.

— Wesley
fonte
8
GATTO CATTIVO! spruzzi con tubo flessibile
— voretaq7
2

Prova a specificare uno dei NICS come slave 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"

Più documentazione da RH :

primary = Specifica il nome dell'interfaccia, come eth0, del dispositivo principale. Il dispositivo principale è la prima delle interfacce di bonding da utilizzare e non viene abbandonato se non viene a mancare. Questa impostazione è particolarmente utile quando una scheda NIC nell'interfaccia di collegamento è più veloce e, quindi, in grado di gestire un carico maggiore. Questa impostazione è valida solo quando l'interfaccia di collegamento è in modalità di backup attivo. Fare riferimento a /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt per ulteriori informazioni.

— dmourati
fonte
Prima di modificare ifcfg-bond0ho controllato /sys/class/net/bond0/bonding/primarye la risposta è vuota. Ho aggiunto primary=eth0al ifcfg-bond0e riavviare il servizio di rete. Non vi è alcun cambiamento nel sintomo e nessun cambiamento in /sys/class/net/bond0/bonding/primaryGrazie per il suggerimento però!
— Wesley,
prova ad aggiungere use_carrier = 0? vedi sopra il documento RH per i dettagli
— dmourati,
Fatto: aggiunte le informazioni alla domanda. Non ci sono stati cambiamenti nel comportamento, ma questa è una buona opzione da sapere.
— Wesley,
2

Aggiungere la seguente opzione di legame downdelay = xxxx in milisec che non riesce a superare un eth dopo che è stato rilevato come non riuscito e impostare lo slave primario sul rimanente. Se questo parametro non è in bonding_opt, il legame rileva l'errore (perché includi miimom = yyyy) ma non fallisce mai eth0. Puoi vederlo accadere guardando il file / proc / net / bonding / bondX.

Ad ogni modo, con RHEL 6.3 (quasi la stessa versione della tua) stiamo riscontrando molti altri problemi con il bonding relativo al failback, duplicato mac addr visto dallo switch.

in bocca al lupo.

— MCW
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.