Hey tudo isso é um repost de uma pergunta que eu fiz nos fóruns do Cisco, mas nunca recebi uma resposta útil.
Ei, estou tentando converter os servidores do FreeBSD no trabalho para links lagg de dupla função a partir de links regulares de gigabit. Nossos servidores de produção estão em um 3560. Eu tenho um ambiente de teste pequeno em um 3550. Eu consegui failover, mas estou tendo problemas para alcançar o aumento de velocidade. Todos os servidores estão executando cartões gig intel (em). As configurações para os servidores são:
BSDServer:
#!/bin/sh
#bring up both interfaces
ifconfig em0 up media 1000baseTX mediaopt full-duplex
ifconfig em1 up media 1000baseTX mediaopt full-duplex
#create the lagg interface
ifconfig lagg0 create
#set lagg0's protocol to lacp, add both cards to the interface,
#and assign it em1's ip/netmask
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 ***.***.***.*** netmask 255.255.255.0
Os comutadores são configurados da seguinte forma:
#clear out old junk
no int Po1
default int range GigabitEthernet 0/15 - 16
# config ports
interface range GigabitEthernet 0/15 - 16
description lagg-test
switchport
duplex full
speed 1000
switchport access vlan 192
spanning-tree portfast
channel-group 1 mode active
channel-protocol lacp
**** switchport trunk encapsulation dot1q ****
no shutdown
exit
interface Port-channel 1
description lagginterface
switchport access vlan 192
exit
port-channel load-balance src-mac
end
obviamente mude de 1000 para 100 e Gigabit Ethernet para FastEthernet para a configuração do 3550, já que esse switch tem portas de velocidade de 100 Mbit.
Com essa configuração no 3550, recebo failover e velocidade de 92 Mbits / s em ambos os links, simultaneamente, conectando-me a dois hosts. (testado com iperf) Êxito. No entanto, isso é apenas com a linha "dot1q" de encapsulamento de tronco switchport.
Primeiro, eu não entendo porque eu preciso disso, eu pensei que era apenas para conectar switches. Existe alguma outra configuração que isso aconteça que é realmente responsável pelo aumento de velocidade? Segundo,
Esta configuração não funciona no 3560. Eu recebo failover, mas não o aumento de velocidade. As velocidades caem de gig / seg para 500Mbit / seg quando faço 2 conexões simultâneas ao servidor com ou sem a linha de encapsulamento. Devo mencionar que ambos os switches estão usando o balanceamento de carga de origem-mac.
No meu teste estou usando o Iperf. Eu tenho a configuração do servidor (caixa lagg) como o servidor (iperf -s), e os computadores cliente são cliente (iperf -c server-ip-address), então a fonte mac (e IP) é diferente para ambas as conexões. / p>
Quaisquer idéias / correções / perguntas seriam úteis, já que os comutadores de gigabytes são o que eu realmente preciso dos links em lagg. Pergunte se você precisa de mais informações.
A agregação de links 802.3ad (e muitas outras técnicas de caminhos múltiplos) normalmente dividem o tráfego entre vários links em uma base por fluxo, não por pacote - e por uma boa razão: sempre haverá uma ligeira diferença na transmissão atraso em cada link. Talvez uma interface tenha um driver mais eficiente, ou maior prioridade de interrupção, ou o cabo seja um pouco mais curto para que os elétrons possam chegar lá mais rápido (seriamente). Seja qual for o caso, é extremamente comum que os pacotes cheguem ao destino em uma ordem diferente daquela em que foram enviados.
Muitos pacotes fora de ordem são geralmente uma Coisa Ruim porque o TCP somente reconhece o último pacote recebido na ordem . Os pacotes fora de ordem resultarão no envio de TCPs ACKs duplicados, que são interpretados pelo TCP como indicativos de congestionamento, fazendo com que o TCP fique lento (ou até mesmo retransmita desnecessariamente se o TCP retransmitir rapidamente for disparado).
Nada disso é um problema, é claro, se cada conversa estiver restrita a um único link. Ninguém se importa se o pacote de uma conversa for reordenado com um pacote de outra conversa.
Assim, a maioria das implementações de caminhos múltiplos seleciona o link físico de saída executando um algoritmo de hash em alguns campos de cabeçalho. Normalmente, os campos de cabeçalho analisados seriam uma combinação de:
- src-ip
- src-port (or possibly another identifier if not TCP/UDP)
- dst-ip
- dst-port (or possibly another identifier if not TCP/UDP)
- ip-proto
- vlan-id
Assim, para cada pacote, os valores de cada um desses campos são reunidos e o resultado determina qual interface enviar o pacote. Em média, se houver muitos fluxos diferentes, uma quantidade semelhante de tráfego terminará em cada link. Se você tiver apenas um fluxo, todos esses campos serão os mesmos para cada pacote, então cada pacote terminará no mesmo link.
Se você tem dois fluxos, basicamente está apostando 50/50 que os dois fluxos estarão em links diferentes, o que é exatamente o que você está vendo. Se você tiver azar, você pode jogar os dados novamente, alterando qualquer uma das variáveis que são consideradas pela função hash: tente uma porta diferente, por exemplo. De fato, ao ativar a marcação 802.1q, você introduziu um ID-vlan na mistura que aparentemente mudou o resultado do hash.
Além disso, não há uma maneira padrão de executar o hash, o que significa que, se você conectou sistemas de fornecedores diferentes (ou mesmo versões diferentes de software do mesmo fornecedor), cada lado pode executar o hash de uma maneira diferente. dois fluxos específicos podem acabar com links diferentes do servidor para o switch, mas o mesmo link do switch para o servidor.
A conclusão é que o 802.3ad e outras técnicas de múltiplos caminhos em nível de pacote são necessariamente baseadas em fluxo e funcionam muito bem se você tiver muitos fluxos diferentes, mas não são adequados para um pequeno número de grandes fluxos.