Um único canal LACP em vários switches aumenta a redundância?

Tenho curiosidade por opiniões, descobertas ou evidências de que ter várias interfaces ligadas usando o LACP a portas em vários comutadores pode aumentar a redundância. As interfaces previamente ligadas sempre foram em um único switch, com um canal redundante em outra porta.

Sem entrar em detalhes específicos do fornecedor, meu pensamento é que, como se trata de um único LACP, a probabilidade de um evento ou mudança poder levar a uma ampla interrupção do serviço. Sem o equipamento ou tempo de sobra para testar esse canal único em diversos comutadores, alguém com um conhecimento de rede maior do que eu poderia me dizer se existe um evento do lado da rede que derrubaria a conectividade da rede a um servidor que criara uma interface ligada duas portas em switches separados?

O uso de canais Ethernet conectados em vários comutadores (que recomendamos que possamos usar) do servidor fornece uma taxa de transferência aprimorada (inquestionavelmente) e redundância aprimorada (incerta). Eventos de rede poderiam / teriam ocorrido, como falha do comutador, migração de portas, aplicação de patches, recuperação, etc., fazendo com que o canal para as duas interfaces de rede do servidor não estivesse disponível?

Desde já, obrigado.

O próprio LACP não oferece a capacidade de se conectar através de vários switches; ele se une através de várias portas em um único comutador Ethernet e, dependendo do fornecedor, pode até haver restrições sobre quais portas em um comutador podem ser conectadas.

Alguns fornecedores possuem protocolos proprietários (normalmente chamados MLAG ) que permitem canais Ethernet ligados em diferentes switches Ethernet. Como exemplo, o Cisco Nexus vPC (ou genericamente MLAG) trabalha com comutadores ou vincula um único canal de porta LACP em um servidor através de dois comutadores conectados.

O uso de canais Ethernet conectados em vários comutadores (que recomendamos que possamos usar) do servidor fornece uma taxa de transferência aprimorada (inquestionavelmente) e redundância aprimorada (incerta). Eventos de rede poderiam / teriam ocorrido, como falha do comutador, migração de portas, aplicação de patches, recuperação, etc., fazendo com que o canal para as duas interfaces de rede do servidor não estivesse disponível?

O LACP deve fornecer proteção contra uma única porta física ou falha de cabo no canal LACP.

O LACP não pode proteger contra fatores humanos, como desligar acidentalmente a interface LACP, remover a vlan ou executar um TDR em um link de membro do canal de porta. O LACP também não pode proteger contra o excesso de provisionamento de largura de banda por meio de um link de membro único nesse canal LACP, eventos de spanning tree, tempestades de transmissão, inundação de unicast desconhecida excessiva, etc.

Se você estiver preocupado com o tempo de recuperação, certifique-se de usar tempos limite curtos do protocolo LACP em suas interfaces.

O LACP geralmente pode ser realizado apenas em um único dispositivo ou grupo de dispositivos que atuam como um. Então ... você pode fazer isso entre um switch e uma pilha de switches, mas não se espalhando por vários dispositivos exclusivos.

O LACP é um protocolo para o host se comunicar com os comutadores que deseja agregar várias conexões físicas. Porém, essa agregação nem sempre é possível. Se a conexão for feita com vários comutadores, esses comutadores deverão oferecer suporte a algum método de cooperação para criar o link vinculado ou eles não conseguirão.

A maioria dos switches não suporta essa cooperação. Alguns, no entanto. O método mais comum é o protocolo SMLT, que permite que os comutadores cooperem na criação de links vinculados. Alguns switches também oferecem suporte a protocolos de empilhamento que permitem que vários switches atuem como um único switch lógico. Nos dois casos, convém verificar a documentação para garantir o suporte e a configuração.

O LACP agrega vários links físicos entre os mesmos dois dispositivos em um link lógico com maior taxa de transferência. Se você estiver procurando redundância no caso de uma falha do comutador, precisará configurar links para dois comutadores e configurar o servidor para conectar os dois links com o protocolo da Spanning Tree ativado. O STP escolherá automaticamente um link para estar ativo e o outro backup. Se o link principal cair (o interruptor morreu), ele alternará para o backup. Isso realmente não tem nada a ver com o LACP.

Agregação 4nics (2of4 ativo + failover automático):

Linux: eth0-3 -> bond0, modo de ligação = 4

Switches (Juniper por exemplo): porta 1 + porta 2 -> interfaces de conjunto ae1 interfaces de conjunto passivo lacp de opções de éter agregado ae1 interfaces de conjunto passivo lace ae1 (... atribuições de vlan aqui ...)

passivo no lado do switch garante que é o Linux quem fará o dispositivo com o parceiro com o qual conversar. Se você precisar de inicialização PXE no mesmo nics - Procura força-up opção (zimbro) em A-switch, ge-0/0/1

A agregação de link pode ocorrer entre um dispositivo e 2 ou mais comutadores Cisco, desde que estejam em uma pilha ou em núcleos usando o VSS, por exemplo. Geralmente, uma boa regra geral é que, se houver apenas uma interface mgmt controlando uma pilha de comutadores, ela terá uma tabela de endereços mac na qual Etherchannel ou LACP pode ser usado para rastrear os IPs e MACs que estão sendo usados ​​no cada um dos caminhos agregados da EC / LACP.