Evitação de Loop de Camada 2: Três Interruptores em Série

Question

Eu sei que isso parece uma questão de lição de casa, mas na verdade é parte de um projeto maior (e de rede) e precisa dividi-lo em partes para que eu fique claro com o que estou fazendo. Eu nunca trabalhei com o [R / M] STP e só configurei um LAG estático antes, então não tenho certeza do que preciso aqui.

Eu tenho três switches todos dentro do mesmo domínio de broadcast por meio de marcação de VLAN, interconectados por um grupo LAG que consiste em 2 x Gigabit ethernet de cobre por grupo LAG.

Suponha que essas opções suportem a marcação LAG / LACP / * STP / 802.1q VLAN; Tentando minimizar as extensões proprietárias de fornecedores aqui para comparação, mas se houver um padrão aberto de "re-badged" de um fornecedor, ou merecedor de menção, sinta-se à vontade para fazê-lo.

Os objetivos são:

• para ter uplinks redundantes para o comutador A via B e C
• para ter balanceamento de carga / maior largura de banda nos dois uplinks (se possível, ou seja, 4 x GbE LAG group ou 2 x 2 GbE LAG group "ativo / passivo" se isso fizer sentido)

O que eu não tenho certeza é:

1. Veja como eu acho que esse loop funciona: uma requisição ARP da Máquina B1 (no Switch B) procurando por 1.2.3.4, que pertence à Máquina A1 (no Switch A), chegaria ao Switch A de ambos -a-B e A-para-C uplinks. O switch A receberia (estou supondo) receber a transmissão primeiro através do uplink B-para-A LAG direto, mas enviaria a resposta de volta de ambas as portas LAG de uplink (por exemplo, LAG A-to-B é portas 1/2 e LAG A-para-C são as portas 23/24), confundindo muito o Switch B. Estou correto em como estou interpretando esse loop?

2. Se minha afirmação de que # 1 é realmente um loop, eu preciso de * STP. Pelo que li, STP é velho e lento; RSTP é muito mais rápido (pode ser ponto discutível em todos, mas as maiores redes? Parece ser o que o Intarweb está dizendo). Então há o MSTP, que me confundiu: parece permitir múltiplos grupos STP para múltiplas VLANs, mas assumindo que estou lidando com apenas uma VLAN (2), isso é necessário? E se eu adicionasse uma segunda VLAN que transportasse todos os 3 switches?

3. Tenho certeza de que o M-LAG (eu acho que é como é chamado) permitirá LAGs que se estendem por switches, mas não estou claro se isso seria um LAG que inclui as 4 conexões ethernet que compreendem os uplinks de A a B (2) e A a C (2) do Switch A?

4. Eu li em um fórum em algum lugar (não me lembro onde) que o LACP eliminaria a necessidade de * STP porque é "dinâmico" e "saberia" qual uplink encaminhará o tráfego de broadcasts / unicast com base em algoritmos de balanceamento de carga, mas alguém comentou mais tarde que esse não era o caso.

Para resumir isso, dada a sigla de LAG / LACP / * STP e minha topologia, o que devo fazer aqui em alto nível?

    

Answer 1

Para ser honesto, minha visão disso é que projetar propositalmente um loop em seu projeto de rede não é um bom design. Spanning tree pode ser um grande ponto problemático para gerenciar, projetar, implementar, solucionar problemas, etc.

LACP e STP são duas coisas completamente diferentes. Em um nível muito alto, o LACP é o que permite criar seu LAG - ele terá várias interfaces e as tratará como um único link. Geralmente, isso requer que as portas se conectem aos mesmos dois switches, ou seja, você não pode distribuir um LAG com o LACP entre vários switches. O LACP impediria um loop ao conectar dois switches em conjunto com vários links, desde que você os tenha configurado como um LAG usando o LACP. A Spanning Tree foi projetada para impedir que os loops desativem sua rede. Ele faz isso detectando um loop na topologia e bloqueará ativamente o tráfego em um ou mais links se um loop for detectado. Isso leva algum pensamento para fazer o certo e pode ser diferente por VLAN, dependendo de qual versão do STP você está executando.

Sua ideia de como o loop funcionará está incorreta. Depois de conectar os comutadores dessa maneira, se você tiver configurado corretamente a árvore de abrangência, ele desligará um dos LAGs. Qual delas será desativada dependerá de onde sua bridge raiz está. Então, digamos que o Spanning Tree desliga o LAG entre os switches A e B. Seu tráfego proveniente do switch B precisaria primeiro ir para o switch C, e então fluir por aquele LAG para o switch A. Se você configurasse spanning tree de maneira diferente, você pode desligue o LAG entre o Comutador A e C. Nesse caso, o tráfego do comutador A para o comutador B passaria diretamente do comutador A para B. No entanto, o tráfego do comutador A para C precisaria passar primeiro pelo comutador B. Como você pode ver, quanto maior o loop, mais o tráfego de saltos precisará ser feito antes de atingir seu destino, dependendo da origem / destino e quais links estão sendo desativados. Spanning Tree não ativará / desativará dinamicamente os links para encontrar o caminho mais curto.

Então, como isso se encaixa em seus objetivos:

1. Você tecnicamente ganharia redundância com esse design. O failover não seria instantâneo, uma vez que a árvore geradora precisaria fazer a sua parte.
2. Dependendo dos seus switches, você não terá mais largura de banda ou balanceamento de carga. Os switches padrão configurados corretamente com Spanning Tree desativarão um dos LAGs. Se não desativasse o LAG, você teria um loop e sua rede ficaria lenta para um rastreamento.

De que outras maneiras você pode alcançar esses objetivos? Isso dependerá do orçamento / necessidades / locais

1. O MLAG ajuda a resolver muitos desses problemas. Perto de redundância total, sem desperdício de largura de banda, etc. Mas, cada fornecedor faz as coisas de forma um pouco diferente, portanto, certifique-se de fazer sua pesquisa sobre como / o quê / por que eles o implementam. A Cisco tem VSS na linha de switches 6500, vPC na linha Nexus. Juniper faz seu chassi virtual, Extreme tem sua versão (não lembra do nome). Você poderia analisar um switch Nexus com alguns módulos FEX (ou vários switches Nexus e um módulo FEX com uma configuração de vPC para se conectar a cada Nexus). Seguir a rota da MLAG abre muitas possibilidades diferentes e geralmente exige um orçamento maior e alguém com conhecimento dos produtos para entrar e fazer uma avaliação adequada do site e precisa criar uma solução adequada.
2. Compre uma solução de comutador empilhável que tenha uma conexão de backplane dedicada. Isso liga os switches em um switch lógico, geralmente com um backplane compartilhado maior entre os switches. Vai lhe dar redundância e desempenho.
3. Compre uma solução de switch de chassi. Novamente backplane compartilhado, geralmente melhor hardware e recursos e maior desempenho que a maioria das soluções empilháveis. Pode não parecer tão redundante desde que você tenha um único chassi, mas eu quase nunca vi um chassi falhar completamente. Você pode configurar módulos de supervisor redundantes e pode ter várias placas de linha para fornecer a contagem de portas.

Esta é uma visão geral de alto nível dos technologoies. Você pode cavar bem fundo em spanning tree, MLAG / vPC / etc se você quisesse. No entanto, se esta parte de uma rede maior e você estiver olhando para a MLAG e afins, você provavelmente deve ter alguém na equipe / contrato que esteja um pouco mais familiarizado com as tecnologias envolvidas.