Introdução
O Maple Hall agora usa dois switches de software ligados por um cabo compartilhado. Os grupos locais de visitantes e funcionários já estão corretos. Sua tarefa é transportar ambos pelo enlace e depois mover um dispositivo reatribuído ao grupo dos funcionários sem prejudicar os demais.
Conclua o primeiro laboratório ou conheça seu fluxo: ler o plano de portas, remover uma associação exata, adicionar o PVID previsto e saída sem tags e observar serviços/ARP reais. São necessárias noções de MAC/IP e sub-redes. Esta cena independente não depende da VM anterior.
Switch A e Switch B são consoles persistentes separados para namespaces distintos de uma instância com kernel compartilhado. Client Checks observa dispositivos; LAN Groups mostra estado e solicitações reais. Somente associação VLAN/PVID/propriedades de tags das duas portas uplink e da porta ticket em Switch B podem mudar. Preserve endereços, outras portas, serviços, bridges e firewalls. Os 45 minutos são uma estimativa do autor, sem teste piloto com iniciantes.
Complete o enlace marcado
Nesta etapa, você distinguirá um grupo local funcional de um caminho compartilhado incompleto e depois completará suas duas pontas. Abra LAN Groups e Open device plan. Visitantes usam VLAN 10; funcionários, VLAN 20. Servidores locais ficam em Switch A; servidores remotos e ticket, em Switch B. O endereço /24 preparado de cada dispositivo já corresponde ao grupo previsto.
Mude para Client Checks. Primeiro use os dois caminhos locais funcionais com o auxiliar do primeiro laboratório:
python3 /opt/labex/lan-groups/checks.py request visitor local
python3 /opt/labex/lan-groups/checks.py request staff local
Leia a programação e as instruções completas. Agora omita local para alcançar o servidor do mesmo grupo além do enlace. Espera-se tempo limite, pois o enlace não permite VLAN alguma. O auxiliar retorna estado diferente de zero e informa o tempo limite. Isso é esperado aqui; continue com o próximo comando:
python3 /opt/labex/lan-groups/checks.py request visitor
Mude para Switch A e leia suas associações reais:
bridge vlan show
Mude para Switch B e leia esse outro switch:
bridge vlan show
Ambos os consoles começam em /home/labex/project/lan-groups, mas atuam em namespaces diferentes. Leia o nome da aba antes de alterar algo. Uma linha uplink vazia ou ausente significa ausência de grupos permitidos, não um dispositivo desconectado. Os dois grupos locais podem funcionar mesmo com o caminho compartilhado incompleto.
O dispositivo ticket já possui o endereço dos funcionários 10.60.20.31/24, mas sua porta ainda mostra VLAN de visitantes 10. Essa diferença deliberada será tratada após o enlace. Não a corrija alterando seu IP.
Permita os grupos nas duas pontas
Agora você transportará dois grupos pelo mesmo link. Um enlace marcado acrescenta um identificador VLAN IEEE 802.1Q a cada quadro Ethernet para o próximo switch reconhecer seu grupo. Dispositivos comuns de acesso continuam recebendo quadros sem tags. Ambas as pontas precisam permitir os mesmos grupos.
Comece em Switch A. Adicione as associações de visitantes e funcionários a uplink. Os comandos omitem intencionalmente pvid e untagged: esse link leva quadros marcados e não possui grupo nativo sem tags:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
Mude para Switch B e configure sua ponta:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
bridge vlan show dev uplink
Espere VLANs 10 e 20, sem indicadores PVID ou Egress Untagged. Volte a Switch A e leia também sua ponta:
bridge vlan show dev uplink
Mude para Client Checks e teste os dois caminhos remotos:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Capture cada grupo nos dispositivos reais e em ambas as pontas do enlace:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Leia uplink-a e uplink-b: as linhas de visitantes contêm 802.1Q e vlan 10; as dos funcionários, vlan 20. O servidor remoto do mesmo grupo recebe ARP sem tag VLAN, e o servidor do outro grupo recebe zero correspondências. Isso demonstra marcação real no caminho compartilhado e entrega sem tags nos dispositivos.
Nesse ponto intermediário, ticket ainda recebe broadcasts de visitantes e não dos funcionários, pois sua porta conserva a associação antiga. É esperado até o próximo passo. Se um servidor remoto não recebe seu grupo, compare ambas as tabelas do enlace antes de repetir; uma ponta correta não basta. Se adicionou uma VLAN errada, remova só aquela linha com a forma ensinada bridge vlan del dev uplink vid ... na aba do switch afetado e depois adicione a associação prevista.
Coloque o dispositivo reatribuído no grupo previsto
Nesta etapa, você concluirá a reatribuição de ticket mantendo os dois grupos remotos. Comece em Switch B. Leia primeiro a porta atual exata:
bridge vlan show dev ticket
Sua VLAN antiga de visitantes é 10, embora o endereço preparado e a finalidade já pertençam aos funcionários. Remova a associação e configure PVID dos funcionários e saída sem tags:
bridge vlan del dev ticket vid 10
bridge vlan add dev ticket vid 20 pvid untagged
bridge vlan show dev ticket
Espere apenas 20 PVID Egress Untagged. Endereço IP e associação VLAN são camadas diferentes; não é preciso reendereçar dispositivos nesta tarefa.
Mude para Client Checks e use o serviço real dos funcionários a partir do dispositivo reatribuído:
python3 /opt/labex/lan-groups/checks.py request ticket
Repita as duas solicitações remotas originais:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Capture novamente os dois grupos:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Agora ticket recebe broadcasts dos funcionários e zero de visitantes. Ambas as cópias marcadas do enlace e todos os dispositivos do mesmo grupo devem continuar visíveis. Um serviço parado não passa nas verificações positivas, e sub-redes diferentes não escondem vazamento ARP.
Abra LAN Groups, recarregue e solicite o serviço em todos os cartões, incluindo as duas referências e ticket. Leia os recursos completos. Abra as associações atuais e compare ambas as pontas e ticket com o plano. Se modificou a porta errada, restaure somente a associação original do plano com o padrão ensinado de remoção/adição; não reinicie a VM nem apague a bridge.
A avaliação lê a configuração e envia sondas de leitura limitadas sem repará-la. Aprendizado de vizinhos, de MAC para portas na FDB (Forwarding Database) e logs normais de acesso podem mudar naturalmente. São grupos cabeados temporários em uma instância de treinamento com kernel compartilhado, sem roteamento entre VLANs ou persistência após reinício.
Leia a resposta completa sob cada botão. Os rótulos descrevem o plano; as solicitações bem-sucedidas e as tabelas atuais mostram o resultado real.
Resumo
Você distinguiu sucesso local de um caminho completo entre switches, permitiu ambas as VLANs marcadas nas duas pontas e corrigiu uma porta reatribuída. Capturas 802.1Q reais, capturas sem tags nos dispositivos, respostas completas e referências preservadas demonstram o resultado. O desafio muda os IDs VLAN e combina as mesmas operações.
