Estou com problemas em fazer com que um tronco do LACP funcione corretamente no Ubuntu 12.04.2 LTS.
Minha configuração é um único host conectado com duas interfaces 10 Gbe a dois switches Nexus 5548 separados, com o vPC configurado para habilitar o LACP de vários chassi. A configuração do Nexus é conforme as diretrizes da Cisco e a configuração do Ubuntu de acordo com o link
O servidor está conectado à porta Ethernet1 / 7 em cada comutador Nexus, cujas portas são configuradas idênticas e colocadas no canal de porta 15. O canal de porta 15 é configurado como VPC 15 e a saída VPC parece boa. Estas são portas de acesso simples, ou seja, nenhum entroncamento 801.1q envolvido.
Diagrama:
+----------+ +----------+ +----------+ +----------+
| client 1 |------| nexus 1 |------| nexus 2 |------| client 2 |
+----------+ +----------+ +----------+ +----------+
| |
| +--------+ |
+----| server |----+
eth4 +--------+ eth5
Quando um dos links está inativo, os clientes 1 e 2 conseguem acessar o servidor. No entanto, quando eu trago o link secundário para cima, o cliente conectado ao switch com o link recém-ativado não consegue acessar o servidor.
Veja a tabela a seguir para transições de estado e resultados:
port states (down by means of "shutdown")
nexus 1 eth1/7 up up down up
nexus 2 eth1/7 down up up up
connectivity
client 1 - server OK OK OK FAIL
client 2 - server OK FAIL OK OK
Agora, acredito que isolei a questão para o lado do Linux. Quando em estado de up-up, cada nexo usa o link local para o servidor para entregar os pacotes, conforme verificado olhando para a tabela de endereços mac. O que eu posso ver no servidor é que os pacotes de cada cliente estão sendo recebidos na interface ethX (pacotes do cliente 1 em eth4, pacotes do cliente 2 em eth4) usando tcpdump -i ethX, mas quando executo o tcpdump -i bond0 Eu só posso trafegar de qualquer um dos hosts (de acordo com o que afirmei acima).
Eu observo o mesmo comportamento para o tráfego ARP e ICMP (IP); O ARP falha de um cliente quando ambos os links estão ativos, funciona (junto com o ping) quando um está inativo, o ping falha quando eu habilito o link novamente (os pacotes ainda são recebidos na interface eth, mas não no bond0).
Para esclarecer, estou configurando vários servidores nessa configuração e todos exibem os mesmos sintomas, de modo que não pareçam estar relacionados a hardware.
Então - descobrir como consertar isso é com o que estou lidando; meu googling não me trouxe sorte alguma até agora.
Todos os ponteiros são muito apreciados.
/ etc / network / interfaces
auto eth4
iface eth4 inet manual
bond-master bond0
auto eth5
iface eth5 inet manual
bond-master bond0
auto bond0
iface bond0 inet static
address 10.0.11.5
netmask 255.255.0.0
gateway 10.0.0.3
mtu 9216
dns-nameservers 8.8.8.8 8.8.4.4
bond-mode 4
bond-miimon 100
bond-lacp-rate 1
#bond-slaves eth4
bond-slaves eth4 eth5
/ proc / net / bonding / bond0
A little further information:
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Actor Key: 33
Partner Key: 1
Partner Mac Address: 00:00:00:00:00:00
Slave Interface: eth4
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 8
Permanent HW addr: 90:e2:ba:3f:d1:8c
Aggregator ID: 1
Slave queue ID: 0
Slave Interface: eth5
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 13
Permanent HW addr: 90:e2:ba:3f:d1:8d
Aggregator ID: 2
Slave queue ID: 0
EDIT: configuração adicionada do Nexus
vpc domain 100
role priority 4000
system-priority 4000
peer-keepalive destination 10.141.10.17 source 10.141.10.12
peer-gateway
auto-recovery
interface port-channel15
description server5
switchport access vlan 11
spanning-tree port type edge
speed 10000
vpc 15
interface Ethernet1/7
description server5 internal eth4
no cdp enable
switchport access vlan 11
channel-group 15
EDIT: Adicionado os resultados do canal de porta não-VPC no nexus1 para o mesmo servidor, antes e depois da alteração do IP (IP alterado para influenciar o algoritmo de balanceamento de carga). Isso ainda está usando as mesmas configurações no servidor.
port states (down by means of "shutdown")
nexus 1 eth1/7 up up down up
nexus 1 eth1/14 down up up up <= port moved from nexus 2 eth1/7
connectivity (sever at 10.0.11.5, hashing uses Eth1/14)
client 1 - server OK OK OK FAIL
client 2 - server OK OK OK FAIL
Os resultados após a alteração do IP são os previstos; A interface não usada que está sendo criada causa falhas.
connectivity (sever at 10.0.11.15, hashing uses Eth1/7)
client 1 - server OK FAIL OK OK
client 2 - server OK FAIL OK OK