Prevenção de Loop na Camada 2: Três Switches em Série

Eu sei que isso parece uma pergunta de lição de casa, mas na verdade faz parte de um projeto maior (e da rede) e precisa dividi-lo em pedaços, 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 muita 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 Ethernet Gigabit de cobre por grupo LAG.

Suponha que esses comutadores suportem a identificação de VLAN LAG / LACP / * STP / 802.1q; tentando minimizar extensões proprietárias de fornecedores aqui para fins de comparação, mas se houver um padrão aberto "remarcado" pelo fornecedor, ou vale a pena mencionar, sinta-se à vontade para fazê-lo.

Os objetivos são:

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

O que não tenho certeza é:

1. Eis como eu acho que esse loop funciona: uma solicitação ARP da Máquina B1 (no Switch B) procurando pela 1.2.3.4, que pertence à Máquina A1 (no Switch A), chegaria ao Switch A de A para B e A uplinks para C. O switch A (suponho) receberia a transmissão primeiro através do uplink direto de BAG para BAG, mas enviaria a resposta de volta das duas portas LAG de uplink (ou seja, o LAG de A a B é as portas 1/2 e LAG De A a C são as portas 23/24), confundindo bastante o Switch B. Estou correto em como estou interpretando esse loop?

2. Se minha afirmação de que o número 1 é realmente um loop, preciso de * STP. Pelo que li, STP é antigo e lento; O RSTP é muito mais rápido (pode ser discutível em todas as redes, exceto as maiores)? Parece ser o que a Intarweb está dizendo). Depois, há o MSTP, que me confundiu: parece permitir vários grupos STP para várias VLANs, mas assumindo que estou lidando com apenas uma VLAN (2), isso é necessário? E se eu adicionasse uma segunda VLAN com todos os três switches?

3. Tenho certeza de que o M-LAG (acho que é assim que é chamado) permitirá LAGs que abrangem os comutadores, mas não estou claro se esse seria um LAG que inclui as 4 conexões Ethernet que compõem o A- uplinks para B (2) e A para C (2)?

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

Para resumir, dada a sopa de sinônimos do LAG / LACP / * STP e minha topologia, o que devo fazer em alto nível aqui?

Para ser honesto, minha visão disso é que projetar propositalmente um loop no design de sua rede não é um bom design. A extensão da árvore pode ser um grande problema 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 precisará de várias interfaces e as tratará como um único link. Geralmente, isso requer que as portas se conectem aos mesmos dois comutadores, ou seja, você não pode espalhar um LAG com LACP entre vários comutadores. O LACP impediria um loop ao conectar dois comutadores com vários links, desde que você configurasse essas portas como um LAG usando o LACP. O Spanning Tree foi projetado para impedir que os loops derrubem sua rede. Ele faz isso detectando um loop na topologia e bloqueará ativamente o tráfego em um ou mais dos links se um loop for detectado. Isso leva a pensar o que é certo e pode ser diferente por VLAN, dependendo da versão do STP em execução.

Sua ideia de como o loop funcionará está incorreta. Depois de conectar os comutadores dessa maneira, se você configurou corretamente a árvore de expansão, ele desligará um dos LAGs. Qual deles será desligado dependerá de onde está sua ponte raiz. Então, digamos que o Spanning Tree desligue o LAG entre os comutadores A e B. Seu tráfego originado no comutador B precisaria primeiro ir para o comutador C e depois fluir sobre esse LAG para o comutador A. Se você configurou o spanning tree de maneira diferente, poderá desligue o LAG entre os comutadores A e C. Nesse caso, o tráfego do comutador A para o comutador B passaria diretamente do comutador A para o B. No entanto, o tráfego do comutador A para C precisaria passar primeiro pelo comutador B. Como você pode ver, quanto maior você aumentar seu loop, pode ser necessário mais tráfego de saltos antes de atingir seu destino, dependendo da origem / destino e dos links da árvore de abrangência desativados. A árvore de abrangência não ativará / desativará dinamicamente os links para encontrar o caminho mais curto.

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

1. Tecnicamente, você obteria redundância com esse design. O failover não seria instantâneo, pois a árvore de abrangência precisaria fazer sua coisa.
2. Dependendo dos seus switches, você não terá maior largura de banda ou balanceamento de carga. Os comutadores padrão configurados corretamente com o Spanning Tree desativarão um dos LAGs. Se não desativasse o LAG, você teria um loop e sua rede diminuiria para um rastreamento.

De que outras maneiras você pode alcançar esses objetivos? Isso vai depender do orçamento / necessidades / localizações

1. O MLAG ajuda a resolver muitos desses problemas. Quase com redundância total, sem desperdício de largura de banda etc. Mas todo fornecedor faz as coisas de maneira um pouco diferente, portanto, faça sua pesquisa sobre como / o que / por que eles a implementam. A Cisco possui VSS na linha de 6500 switches e vPC na linha Nexus. O Juniper faz seu chassi virtual, o Extreme tem sua versão (não lembra o nome). Você pode olhar para um comutador Nexus com alguns módulos FEX (ou vários comutadores Nexus e um módulo FEX com uma configuração de vPC para conectar-se a cada Nexus). Seguir a rota do MLAG abre muitas possibilidades diferentes e geralmente exige um orçamento maior e alguém com conhecimento dos produtos deve entrar e fazer uma avaliação adequada do site e precisa projetar uma solução adequada.
2. Compre uma solução de switch empilhável que tenha uma conexão de backplane dedicada. Isso une os switches em um switch lógico, geralmente com um backplane compartilhado maior entre os switches. Dará redundância e desempenho.
3. Compre uma solução de switch de chassi. Backplane compartilhado novamente, geralmente hardware e recursos melhores e melhor desempenho do que a maioria das soluções empilháveis. Pode não parecer tão redundante, pois você tem um único chassi, mas quase nunca vi um chassi falhar completamente. Você pode configurar módulos 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 das tecnologias. Você pode cavar profundamente na árvore de abrangência, MLAG / vPC / etc, se quiser. No entanto, se esta parte de uma rede maior e você estiver olhando para a MLAG e similares, provavelmente deverá ter alguém na equipe / contrato que esteja um pouco mais familiarizado com as tecnologias envolvidas.