RHEL 6.4: ligação de canal no modo 1 não falha

11

Estou executando o RHEL 6.4, kernel-2.6.32-358.el6.i686, em um HP ML 350 G5 com duas NICs Broadcom NetXtreme II BCM5708 1000Base-T integradas. Meu objetivo é canalizar as duas interfaces em um mode=1par de failover.

Meu problema é que, apesar de todas as evidências de que o vínculo está configurado e aceito, puxar o cabo para fora da NIC principal faz com que toda a comunicação seja interrompida.

ifcfg-etho e ifcfg-eth1

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

Em seguida, 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

Arquivo de configuração do meu vínculo:

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

Eu tenho um /etc/modprobe.d/bonding.confarquivo que é preenchido assim:

alias bond0 bonding

saída de endereço IP

O vínculo acabou e eu posso acessar os serviços públicos do servidor através do endereço IP do vínculo:

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 ligação do kernel

...está carregado:

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

/ sys / class / net

O /sys/class/netsistema de arquivos mostra coisas boas:

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 preocupação aparece no arquivo de log. De fato, tudo 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

Então qual é o problema?!

Retirar o cabo de rede de eth0 faz com que toda a comunicação fique escura. Qual poderia ser o problema e que etapas adicionais devo tomar para solucionar isso?

EDITAR:

Solução de problemas adicionais:

A rede é uma única sub-rede e uma VLAN única fornecida por um switch ProCurve 1800-8G. Eu adicionei primary=eth0a ifcfg-bond0e serviços de rede de reinício, mas que não mudou qualquer comportamento. Eu verifiquei /sys/class/net/bond0/bonding/primaryantes e depois da adição primary=eth1e ele tem um valor nulo, que não tenho certeza se é bom ou ruim.

A cauda /var/log/messagesquando eth1seu cabo foi removido não mostra nada mais do 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

I adicionado use_carrier=0a ifcfg-bond0's BONDING_OPTSsecção que permite o uso de ioctls MII / ethtool. Depois de reiniciar o serviço de rede, não houve alteração nos sintomas. Se você puxar o cabo, eth0interromperá toda a comunicação em rede. Mais uma vez, nenhum erro foi /var/log/messagessalvo na notificação de que o link nessa porta caiu.

linux  redhat  rhel6  bonding 
— Wesley
fonte
1
Você pode adicionar mais informações, como o comutador make / model conectado, qualquer configuração de VLAN no comutador, estados de escravos de bond e / var / log / messages após o cabo do eth0 ser desconectado?
— Andy Shinn
@AndyShinn O switch ao qual está diretamente conectado é um ProCurve 1800-8G. Não há VLANs na rede. É uma simples sub-rede única, uma rede VLAN única.
— Wesley
@AndyShinn Ah, e também os estados escravos dos títulos são relatados como up. O final /var/log/messagesno momento em que eth0 foi desconectado apenas mostra que o link de cobre foi desconectado. Nenhuma mensagem do módulo de ligação.
— Wesley

Respostas:

21

LER. SEU. CONFIGURA.

E quando isso falha ...

LER. TODOS. SAÍDAS.

Você vê o que está dentro ifcfg-bond0? Não, você entende o que está acontecendo ifcfg-bond0?
O que no mundo dos pingüins escorregadios é miimmon=100?
Oh, desculpe, você quis dizer miimon=100?

Sim, acho que você quis dizer miimone não miimmon.

Além disso, uma grande oferta é que, quando você reinicia o serviço de rede, vê o seguinte:

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  ]

Preste muita atenção a tudo que você digita e, quando cometer seu inevitável erro de digitação, preste muita atenção a todas as saídas que vê.

Você é uma pessoa má e deve se sentir mal.

— Wesley
fonte
8
GATO MAU! sprays com mangueira
— voretaq7
2

Tente especificar um dos NICS como o escravo 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"

Mais documentação do RH :

primary = Especifica o nome da interface, como eth0, do dispositivo principal. O dispositivo primário é a primeira das interfaces de ligação a ser usada e não é abandonada, a menos que falhe. Essa configuração é particularmente útil quando uma NIC na interface de ligação é mais rápida e, portanto, capaz de lidar com uma carga maior. Essa configuração é válida apenas quando a interface de ligação está no modo de backup ativo. Consulte /usr/share/doc/kernel-doc-/Documentation/networking/bonding.txt para obter mais informações.

— dmourati
fonte
Antes de editar ifcfg-bond0, verifiquei /sys/class/net/bond0/bonding/primarye a resposta está em branco. Eu adicionei primary=eth0a ifcfg-bond0e reinicie o serviço de rede. No /sys/class/net/bond0/bonding/primaryentanto, não há alteração no sintoma nem em Obrigado pela sugestão!
— Wesley
tente adicionar use_carrier = 0? veja acima RH doc para obter detalhes
— dmourati 15/06/2013
Concluído - adicionou as informações à pergunta. Não houve mudança de comportamento, mas é uma boa opção para se conhecer.
— Wesley
2

Adicione a seguinte opção de ligação downdelay = xxxx em milissegundos que falha em uma eth depois que ela foi detectada como falha e configure o escravo primário para o restante. Se esse parâmetro não estiver no bonding_opt, o vínculo detectará a falha (porque você inclui miimom = aaaa), mas nunca falha no eth0. Você pode ver isso acontecendo olhando para o arquivo / proc / net / bonding / bondX.

De qualquer forma, com o RHEL 6.3 (quase a mesma versão que a sua), estamos tendo vários outros problemas com ligações relacionadas à falha de retorno, addr mac duplicado visto no switch.

boa sorte.

— mcw
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.