Resumo executivo
Contexto
A filial é uma planta industrial com firewall de borda e SD-WAN sobre links de provedores distintos, núcleo em pilha de switches e cerca de uma dezena de switches de acesso ligados em estrela ao núcleo. A topologia era conhecida apenas parcialmente por quem já havia trabalhado no local.
- Nenhum diagrama ou inventário estava atualizado.
- As descrições de porta no núcleo eram herdadas de equipamentos anteriores e não correspondiam ao cabeamento real.
- Cabos e portas não tinham identificação física.
- Qualquer mudança precisa respeitar a operação contínua da fábrica.
Problema
Sem documentação nem padrão de configuração, sintomas como “estação sem DHCP” ou “câmera conectada sem imagem” não tinham causa aparente, e cada mudança na rede era um risco. Era preciso saber o que existia de fato antes de propor qualquer correção.
Meu papel
- levantamento de campo, porta a porta, no rack de distribuição;
- coleta e auditoria dos backups de configuração dos switches;
- desenvolvimento de um script para extrair e comparar as configurações;
- diagrama de backbone confirmado por LLDP e visita de campo;
- plano de VLANs com o estado real de cada VLAN em cada equipamento;
- classificação dos achados por risco e roteiro de regularização.
Resultado
- 14 arquivos de configuração analisados por script.
- Mudanças não documentadas detectadas entre o levantamento de agosto e os backups de outubro.
- 52 portas de acesso sem VLAN definida, em 10 switches, identificadas como causa direta de estações sem DHCP.
- Inventário, diagrama e plano de VLANs mantidos como documentação viva.
- Todos os achados da matriz atual já foram corrigidos; novas análises e melhorias seguem em andamento.
Indicadores operacionais posteriores à regularização não são publicados porque pertencem ao ambiente corporativo.
O que este caso demonstra
- Engenharia e documentação de rede
- VLANs, troncos e spanning tree
- Automação de auditoria com script
- Detecção de drift de configuração
- Análise de redundância
- Priorização por risco
Detalhes técnicos
Decisões técnicas
1. Campo antes do papel
Em vez de confiar nas descrições de porta, os uplinks foram confirmados fisicamente. A visita mostrou que os switches sobem diretamente no núcleo, cada um com link único, e descartou a hipótese de cascata. Seis das onze portas do rack de distribuição no núcleo carregavam nomes de outros destinos. Esse dado físico virou a âncora para reconciliar backups e topologia.
2. Script em vez de leitura manual
Um script extrai de cada configuração as portas de acesso, os troncos, as VLANs presentes, as portas sem configuração, o modelo, o firmware e o endereço de gerência. A saída é uma tabela comparativa que expõe na hora as divergências entre equipamentos do mesmo modelo e lote.
3. Regularizar por risco, não tudo de uma vez
Corrigir todos os achados em uma única janela poderia parar a produção. A matriz de achados ordena as ações por risco e impacto, para que cada mudança tenha janela, validação e retorno definidos.
4. Documentação viva em Markdown
Uma nota por equipamento, diagrama de backbone em Mermaid e pendências como checklist. Quando uma hipótese é confirmada ou descartada, o registro é atualizado com a fonte, sem apagar o histórico de raciocínio.
Implementação por fases
- Visita de campoConfirmação física dos uplinks no rack de distribuição.
- Coleta dos backupsConfigurações de todos os switches de acesso e do núcleo.
- Parser e tabela comparativaExtração automática de portas, VLANs, modelo e firmware.
- Confronto campo × backupsDetecção de mudanças não documentadas entre agosto e outubro.
- Diagrama de backboneLigações confirmadas por LLDP e pela visita.
- Plano de VLANsEstado real de cada VLAN em cada equipamento.
- Matriz de achadosRisco, prioridade e ação recomendada para cada item.
- Regularização em janelasAchados da matriz atual corrigidos; novas análises em andamento.
Matriz de achados
| Achado | Risco | Prioridade | Ação recomendada | Status |
|---|---|---|---|---|
| Portas de acesso sem VLAN definida (52 portas em 10 switches) | Estações sem DHCP de usuário; chamados sem causa aparente | Alta | Padronizar perfil de porta de acesso e revisar portas soltas | Corrigido |
| VLAN de CFTV com três estados diferentes: correta, ausente, ou criada mas fora do tronco | Câmera aparece conectada, mas o tráfego não sai do switch | Alta | Declarar a VLAN e incluí-la nos troncos de forma padronizada | Corrigido |
| Uplinks do firewall concentrados em um único membro da pilha do núcleo | Redundância reduzida na borda | Alta | Distribuir os uplinks entre os membros da pilha | Corrigido |
| Mudanças de configuração sem registro entre agosto e outubro | Perda de rastreabilidade; sintomas difíceis de diagnosticar | Média | Backup periódico com comparação automática | Corrigido |
| Três versões de firmware em equipamentos do mesmo site | Comportamento divergente entre switches iguais | Média | Homologar e padronizar uma versão | Corrigido |
| Descrições de porta e cabos sem correspondência com o cabeamento real | Erros de manutenção e diagnóstico | Média | Identificação física e atualização das descrições | Corrigido |
Achados relacionados a controles de segurança foram tratados por canal interno e não são publicados.
Limitações
- O projeto continua em andamento; a matriz mostra os achados e as correções feitas até outubro de 2026.
- Nomes de equipamentos, endereços, quantidade exata de ativos e topologia real não são publicados.
- O script cobre o formato de configuração dos switches da filial; outros fabricantes exigiriam adaptação.
Evidências
Nomes de switches, endereços, VLAN IDs reais e topologia exata foram removidos. O diagrama é uma representação genérica; a tabela e o código usam dados fictícios.
Saída comparativa do parser (dados fictícios)
| Switch | Modelo | Firmware | VLAN CFTV | CFTV no tronco | Portas sem VLAN |
|---|---|---|---|---|---|
| SW-ACESSO-01 | modelo A | versão 1 | presente | sim | 0 |
| SW-ACESSO-02 | modelo A | versão 2 | ausente | não | 6 |
| SW-ACESSO-03 | modelo A | versão 1 | presente | não | 4 |
| SW-ACESSO-04 | modelo B | versão 3 | presente | sim | 11 |
Lógica do parser (exemplo simplificado)
Trecho reescrito para publicação, não o script original. Lê blocos de VLAN de uma configuração em formato ArubaOS-Switch e devolve as portas marcadas e não marcadas de cada VLAN.
# Exemplo simplificado: portas numéricas, um arquivo por switch
import re
from pathlib import Path
BLOCO_VLAN = re.compile(r"^vlan (\d+)\n(.*?)^\s*exit", re.M | re.S)
PORTAS = re.compile(r"^\s*(untagged|tagged) (\S+)", re.M)
def expandir(faixa):
portas = set()
for parte in faixa.split(","):
ini, _, fim = parte.partition("-")
portas.update(range(int(ini), int(fim or ini) + 1))
return portas
def vlans_do_switch(arquivo):
cfg = Path(arquivo).read_text()
return {
int(vid): {modo: expandir(faixa) for modo, faixa in PORTAS.findall(corpo)}
for vid, corpo in BLOCO_VLAN.findall(cfg)
}
Versão didática
Como eu ensinaria este conceito
O achado da VLAN de CFTV “criada mas fora do tronco” é um ótimo laboratório: o equipamento parece conectado, mas o tráfego não chega ao destino.
Público
Cursos técnicos de redes e disciplinas de redes na licenciatura em Computação.
Pré-requisitos
Endereço IP, switch e o comando ping.
Analogia
VLANs são andares de um prédio; o tronco é o elevador. Se o elevador não para em um andar, quem mora lá não sai do prédio, mesmo com a porta do apartamento aberta.
Experimento mínimo
Em um simulador de redes, dois switches ligados por tronco e uma VLAN de câmeras. Os alunos criam a VLAN nos dois switches, mas não a permitem no tronco, observam o ping falhar e corrigem.
Erro comum
Achar que criar a VLAN no switch basta; esquecer de incluí-la no tronco.
Pergunta de reflexão
Por que documentar a rede é uma medida de segurança, e não só de organização?