Operações, automação e solução de problemas de redes

Os registros de rede respondem a perguntas diferentes: por onde passa um cabo, a qual sub-rede pertence um dispositivo ou qual serviço foi prometido. Mantenha os nomes dos dispositivos consistentes entre os registros para passar de uma visão a outra sem precisar adivinhar.

Escolha uma visão adequada à tarefa

Um diagrama físico mostra locais e conexões reais: salas, racks, tomadas de rede, painéis de conexão e portas de comutadores. Um diagrama lógico mostra relações de tráfego, como VLANs, sub-redes, gateways e rotas. Duas áreas de trabalho em andares diferentes podem pertencer à mesma VLAN, embora seus cabos terminem em racks diferentes.

Separe essas visões quando um desenho combinado ficar difícil de ler. Relacione-as com nomes como “SW1” e “PP1”, não com uma posição presumida na página.

Acompanhe um cabo até sua porta

Um diagrama de elevação do rack mostra as posições dos equipamentos em unidades de rack. Uma unidade, 1U, tem 44,45 mm de altura. Inclua painéis de conexão e unidades de distribuição de energia, além de comutadores e roteadores.

Um mapa de cabeamento registra o identificador, as extremidades e o tipo de um cabo. Por exemplo: “Cabo A-12: painel de conexão 1 porta 12 até SW1 Gi1/0/12, Cat 6.” Coloque o mesmo identificador nas duas extremidades. Se o cabo de conexão for substituído, transfira a etiqueta e atualize o mapa.

Suponha que um usuário na tomada 2.14 relate uma conexão inativa. Primeiro, encontre essa tomada no mapa de cabeamento. Acompanhe seu trecho permanente até o painel e identifique o cabo de conexão e a porta do comutador. O registro físico informa onde testar; o registro lógico informa qual VLAN e sub-rede essa porta deve atender.

Registre endereços, equipamentos e compromissos

O gerenciamento de endereços IP (IPAM) registra a finalidade, a VLAN, o gateway, a faixa DHCP, as reservas e os endereços estáticos de cada sub-rede. Consulte o IPAM antes de atribuir um endereço fixo para que ele não coincida com o de outro dispositivo nem com o pool dinâmico.

Um inventário de ativos identifica cada dispositivo por modelo, número de série, localização e firmware, com as datas de garantia e suporte. Um mapa de calor da rede sem fio registra a cobertura em uma planta baixa. Procedimentos operacionais padrão descrevem tarefas repetíveis, enquanto linhas de base de desempenho preservam medições da operação normal.

Um acordo de nível de serviço (SLA) estabelece os compromissos de serviço de um provedor, incluindo metas de disponibilidade, resposta e reparo. Para a disponibilidade em um ano de 365 dias:

Com 99,9%, isso equivale a 8,76 horas; com 99,99%, a cerca de 52,6 minutos. Use o período de medição efetivo do acordo ao verificar a conformidade. Um relatório mensal deve usar as horas daquele mês.

Após um reparo ou mudança, atualize as visões afetadas, os registros de cabos, o plano de endereçamento e o inventário. Um registro correto permite que o próximo técnico comece com evidências.

Uma configuração em funcionamento, uma configuração salva e uma cópia de segurança são três coisas diferentes. Gerenciar as três evita que uma reinicialização, uma falha de dispositivo ou uma edição incorreta cause uma interrupção prolongada.

Mantenha uma configuração recuperável

No Cisco IOS, a configuração em execução está ativa na memória. A configuração de inicialização é a cópia salva usada na inicialização. Um comando normalmente altera a configuração em execução imediatamente. Salve uma configuração aprovada e verificada com:

copy running-config startup-config

Uma cópia de segurança fora do dispositivo protege contra a perda do próprio equipamento. Identifique-a com dispositivo, data e versão e faça uma antes de cada mudança, além das cópias programadas. Uma cópia do mês passado pode não incluir uma VLAN adicionada ontem. Compare seu conteúdo e sua data antes de restaurá-la.

Uma configuração padrão de referência define o padrão aprovado para a função de um dispositivo. O desvio de configuração é a diferença entre esse padrão e as configurações reais. Por exemplo, um comutador de acesso pode ainda permitir Telnet, embora o padrão exija SSH. Compare as configurações para identificar o que mudou e verifique se a diferença foi aprovada.

Escolha um caminho de gerenciamento

O Telnet usa TCP 23 e envia credenciais em texto simples. Desative-o. Fortalecer a segurança também significa substituir credenciais padrão, desativar serviços e portas não utilizados e aplicar atualizações de segurança.

O gerenciamento em banda compartilha o caminho usado pelo tráfego de produção. O gerenciamento fora de banda tem um caminho separado, como um servidor de console acessado por uma conexão celular. Isso é útil quando uma mudança de roteamento elimina o acesso normal. Um servidor de salto é um ponto de entrada com segurança reforçada a partir do qual os administradores acessam os equipamentos gerenciados.

Planeje atualizações e substituições

Teste o firmware em um pequeno grupo antes de uma implantação ampla. Registre a versão, a cópia de segurança, os testes e o método de recuperação. Os anúncios de fim de vida dos fabricantes contêm várias datas: o fim das vendas encerra os pedidos; marcos posteriores encerram a manutenção, as correções de segurança e, por fim, o suporte. Planeje a substituição antes do fim das correções de segurança.

Para substituir um comutador, verifique a quantidade e a velocidade das portas, os transceptores aceitos, a compatibilidade do firmware e a capacidade PoE. Uma unidade com portas de dados suficientes, mas sem PoE, deixará telefones e pontos de acesso conectados sem energia.

Instale um substituto compatível, restaure a cópia de segurança correta e teste enlaces, VLANs e serviços. Salve o resultado verificado e atualize o inventário, os diagramas e o registro da cópia de segurança. Durante a desativação, primeiro transfira as funções do dispositivo antigo. Em seguida, apague sua configuração e as credenciais armazenadas usando o procedimento de restauração ou exclusão segura do fabricante e providencie o descarte pelo processo da organização.

Mesmo um comando correto pode interromper o serviço errado no momento errado. O gerenciamento de mudanças atribui à mudança um motivo, um responsável, uma aprovação, um teste e uma forma de retorno caso o resultado seja inaceitável.

Prepare uma mudança que outra pessoa possa executar

Uma solicitação de mudança identifica os equipamentos e serviços afetados, explica o motivo e lista as etapas exatas de implementação. Ela também inclui impacto e risco, uma janela de manutenção, um plano de teste e um plano de reversão.

O impacto descreve o que o trabalho pode interromper. O risco considera o que pode dar errado e qual seria a gravidade. Atualizar um comutador de núcleo pode desconectar vários andares; alterar uma porta de acesso não utilizada tem um alcance muito menor. Mudanças maiores podem exigir análise por um comitê consultivo de mudanças (CAB).

Uma janela de manutenção é um período acordado para trabalhos que causam interrupções. Informe aos usuários quais serviços podem parar e por quanto tempo. Reserve tempo suficiente para realizar a mudança, testá-la e recuperar o funcionamento antes do fim da janela.

Faça da reversão uma decisão, não uma esperança

Um plano de reversão informa como restaurar o estado anterior em funcionamento e quando fazê-lo. “Restaurar se necessário” deixa a decisão indefinida. “Se os usuários de teste não conseguirem entrar no sistema 15 minutos após a atualização, inicie a imagem anterior” fornece ao operador um critério mensurável.

Antes de começar, faça uma cópia de segurança atual e confirme que a imagem anterior ou outros arquivos de recuperação estão disponíveis. Confirme também que o operador ainda consegue acessar o dispositivo se o caminho normal de gerenciamento falhar.

Por exemplo, uma atualização de comutador de núcleo está programada para 22:00–23:00. O plano mantém a imagem antiga na memória flash e exige que todos os enlaces de subida e cinco servidores principais estejam acessíveis após a reinicialização. O prazo para decidir pela reversão deve deixar tempo suficiente na janela para iniciar a imagem antiga e repetir esses testes de serviço. Esperar até 22:59 para decidir inviabilizaria o plano.

Use o procedimento de mudança adequado

Uma emergência ainda exige uma ação controlada e um registro. Acompanhe cada mudança para que outro técnico saiba o que foi feito. Durante o diagnóstico, alterar várias configurações juntas oculta qual delas ajudou e dificulta a recuperação.

Verifique e encerre

Siga as etapas aprovadas e teste a melhoria pretendida e os serviços que possam ter sido afetados. Apenas entrar no sistema de gerenciamento diz pouco sobre a capacidade dos usuários de acessar suas aplicações.

Registre o resultado, incluindo qualquer reversão. Atualize os diagramas, o IPAM, o inventário e as cópias de segurança das configurações afetados pela mudança. Encerre a solicitação somente quando os testes estiverem concluídos e os registros descreverem o estado instalado. Se um problema aparecer mais tarde, esses horários e ações servirão de ponto de partida para o diagnóstico.

“A rede está lenta” descreve um sintoma, não uma medição. Escolha métricas que descrevam o problema do usuário e compare-as com um registro da operação normal.

Meça capacidade, entrega e atraso

Largura de banda é a taxa máxima de dados de um enlace. Vazão é a taxa efetivamente alcançada. Sobrecarga de protocolo, erros e congestionamento mantêm a entrega útil abaixo da capacidade anunciada. A taxa de utilização expressa quanto da capacidade está sendo usado:

Para 450 Mbit/s em um enlace de 1 Gbit/s, converta a capacidade para 1.000 Mbit/s. A utilização é 45%. Misturar Mbit/s e Gbit/s sem conversão produz uma razão sem sentido.

Latência é o tempo de percurso, geralmente medido como tempo de ida e volta (RTT). Variação do atraso é a variação do atraso entre pacotes. Perda de pacotes é a parcela de pacotes que não chegam. Perder 3 de 200 pacotes de teste significa 1,5% de perda.

Suponha que RTTs consecutivos sejam 20, 24, 21, 35 e 20 ms. Sua soma é 120 ms, portanto sua média é 24 ms. As diferenças absolutas entre valores consecutivos são 4, 3, 14 e 15 ms. A média delas é 9 ms: uma forma útil de calcular a variação do atraso. Produtos de monitoramento podem usar outros métodos, por isso compare resultados medidos da mesma maneira.

Relacione as métricas ao serviço

Chamadas de voz geralmente têm como meta atraso em um sentido inferior a cerca de 150 ms, variação do atraso inferior a cerca de 30 ms e perda inferior a cerca de 1%. Essas são orientações para a qualidade da chamada, não uma conversão do RTT em uma medição exata em um sentido. O download de um arquivo pode reenviar dados ausentes, mas as retransmissões aumentam o tempo de conclusão. Uma chamada pode apresentar falhas audíveis.

Um enlace com alta largura de banda ainda pode oferecer um serviço interativo ruim se o atraso ou a perda for alto. Verifique essas medidas junto com a vazão. Monitore também CPU, memória, temperatura, ventoinhas, fontes de alimentação, estado das interfaces e contadores de erros ou descartes. O uso intenso de CPU pode atrasar respostas de gerenciamento ou tráfego de controle mesmo quando um enlace de dados tem capacidade disponível.

Estabeleça o normal antes de configurar alarmes

Uma linha de base registra o comportamento normal em períodos representativos de pouco e muito uso. Colete medições por várias semanas, com intervalos de amostragem consistentes. Um valor de segunda-feira pela manhã é mais útil quando comparado com outros valores de segunda-feira pela manhã.

Um limiar dispara um alerta em um valor definido, muitas vezes combinado com uma duração: “utilização acima de 80% por 10 minutos”. A duração evita reações a cada breve pico. Os alertas de anomalia, por sua vez, verificam se o padrão difere do normal, como tráfego de saída inesperadamente intenso às 03:00.

O monitoramento de disponibilidade verifica respostas; o monitoramento de desempenho acompanha taxas e atrasos; o monitoramento de configuração detecta mudanças nas configurações. A descoberta de rede encontra dispositivos que podem estar ausentes dos registros. Escolha um teste de serviço quando a pergunta for se esse serviço funciona: um dispositivo pode responder ao ping enquanto seu serviço web está parado.

Gráficos mostram como um valor muda; logs mostram o que aconteceu. O SNMP fornece medições e notificações dos dispositivos, enquanto o syslog transporta mensagens de eventos. Juntos, eles ajudam a explicar quando uma interrupção ocorreu e quais foram seus efeitos.

Solicite medições aos agentes

Um gerente SNMP, frequentemente parte de um sistema de gerenciamento de rede (NMS), consulta um agente em cada dispositivo. Uma base de informações de gerenciamento (MIB) descreve as variáveis disponíveis. Um identificador de objeto (OID) localiza uma variável na árvore.

Por exemplo, 1.3.6.1.2.1.1.3.0 identifica sysUpTime, medido em centésimos de segundo desde a última inicialização do software de gerenciamento de rede. A zeragem desse valor pode indicar tanto a reinicialização do processo de gerenciamento quanto a do dispositivo. Compare-o com outras evidências antes de informar uma reinicialização completa.

Get, GetNext e GetBulk leem valores; Set altera um valor permitido. As requisições normalmente vão para a porta UDP 161 do agente. Uma notificação SNMP não confirmada (trap) é enviada sem solicitação à porta UDP 162 do gerente. Uma notificação SNMP confirmada (inform) solicita confirmação, permitindo que uma notificação perdida seja reenviada.

Consultas periódicas a cada cinco minutos geram 288 leituras por variável por dia. Um enlace pode falhar e se recuperar entre consultas. As notificações não confirmadas acrescentam relatos imediatos de eventos, enquanto as consultas também detectam um agente que deixa de responder completamente.

Proteja o tráfego de gerenciamento

SNMPv1 e v2c usam uma string de comunidade em texto simples. O acesso somente de leitura permite consultas; o acesso de leitura e escrita também permite Set. SNMPv3 oferece noAuthNoPriv, authNoPriv e authPriv, sendo que authPriv fornece autenticação e criptografia. Prefira authPriv. Se v2c for necessário, altere as strings de comunidade padrão, use acesso somente de leitura e restrinja os endereços dos gerentes que fazem consultas.

Interprete e filtre syslog

O syslog envia mensagens a um coletor central, tradicionalmente usando UDP 514. Também estão disponíveis transportes TCP e TLS; TLS geralmente usa TCP 6514. A coleta central preserva eventos após a perda do buffer local de um dispositivo.

Números menores indicam maior severidade. Um nível configurado como 4 envia os níveis 0 a 4. Ele exclui Notificação, Informativo e Depuração. Uma saída volumosa de Depuração pode sobrecarregar equipamentos, por isso habilite-a brevemente para uma investigação específica.

Em %LINEPROTO-5-UPDOWN, LINEPROTO identifica a categoria de origem e 5 significa Notificação. Eventos repetidos de ativação e desativação em uma interface indicam um enlace oscilante e orientam a inspeção do cabo ou dos componentes ópticos.

Organize os eventos em uma linha do tempo comum

Sincronize os relógios dos dispositivos com NTP. Caso contrário, um erro de sete minutos no relógio pode fazer um evento de firewall parecer anterior à sua causa. A agregação de logs reúne registros em um repositório pesquisável; um SIEM acrescenta correlação e alertas entre fontes. Defina um período de retenção e proteja os logs contra alterações indevidas. Por fim, teste o caminho de coleta: uma porta de notificações ou de logs bloqueada pode deixar um coletor em funcionamento sem evidências.

Perguntas diferentes sobre o tráfego exigem níveis diferentes de detalhe. Para encontrar quem mais enviou dados durante uma semana, use resumos. Para investigar uma resposta ausente em uma comunicação, examine os pacotes.

Comece com a evidência adequada

Um fluxo agrupa pacotes por campos como endereços de origem e destino, portas e protocolo. NetFlow e IPFIX exportam registros com contagens, totais de bytes e horários. Esses registros descrevem o tráfego sem armazenar o conteúdo dos pacotes. Um coletor pode classificar os dispositivos que mais geram tráfego ou mostrar quando um backup saturou um enlace de subida.

O sFlow amostra pacotes, por exemplo, um em 1.000, e exporta seus primeiros bytes junto com contadores de interface. Esses bytes geralmente contêm cabeçalhos e podem incluir parte da carga útil. A amostragem fornece uma estimativa dos padrões de tráfego; ela não registra todas as comunicações por completo.

A telemetria por streaming e as APIs oferecem outras maneiras de coletar dados operacionais. A telemetria pode enviar medições continuamente em vez de esperar por uma consulta periódica.

Capture uma comunicação

Uma captura de pacotes registra os pacotes em uma interface. Um analisador de protocolos como o Wireshark decodifica seus cabeçalhos e a carga útil capturada. O tcpdump oferece captura pela linha de comando. Procure a sequência de mensagens: uma solicitação sem resposta, retransmissões TCP repetidas ou uma troca DHCP que para em Discover.

Dados de aplicação criptografados capturados continuam criptografados, a menos que as informações necessárias para descriptografá-los estejam disponíveis. Os cabeçalhos e os horários dos pacotes ainda podem ajudar a diagnosticar a troca.

Um filtro de captura controla o que é registrado. Por exemplo, host 192.168.1.20 and port 53 limita uma captura do tcpdump ao tráfego da porta DNS que envolve esse host. Um filtro de exibição altera o que você vê após a captura: dns no Wireshark mostra o tráfego DNS decodificado, enquanto ip.addr == 192.168.1.20 mostra pacotes que envolvem esse endereço. Ocultar um pacote com um filtro de exibição mantém o pacote na captura.

Posicione a captura onde o tráfego passa

Um host em uma rede comutada normalmente vê seu próprio tráfego unicast e os broadcasts, não o tráfego de todos os outros hosts. O espelhamento de portas, chamado SPAN em equipamentos Cisco, copia o tráfego de portas ou VLANs selecionadas para uma porta de monitoramento. Um TAP de rede faz uma cópia por hardware do tráfego de um enlace independentemente do comutador.

Capture e varra apenas dentro dos limites de sua autorização; limite a coleta ao necessário para a investigação, proteja dados sensíveis e siga as regras de retenção e exclusão da organização.

Suponha que uma solicitação apareça antes de um firewall, mas nenhuma resposta apareça nesse ponto. Essa observação deixa várias causas possíveis. Compare capturas feitas antes e depois do firewall com seus logs. Se a solicitação alcançar o lado distante e uma resposta retornar até esse lado, mas nunca chegar ao lado próximo, a evidência restringe o problema à passagem de retorno por esse dispositivo. Preserve os pontos de observação e os horários junto com as descobertas.

Um relato como “sem internet” deixa a causa em aberto. Um método estruturado transforma esse relato em um problema que pode ser testado e, depois, em um reparo verificado. Separe observações de explicações: “todos os clientes no andar 2 apresentam falha” é uma evidência; “o novo comutador está errado” é uma hipótese.

Passe do sintoma à causa testada

As sete etapas são:

1. Identifique o problema. Reúna sintomas, logs e medições. Pergunte quando começou, quem foi afetado e o que mudou. Reproduza-o quando possível e trate problemas distintos um de cada vez.
2. Estabeleça uma hipótese de causa provável. Verifique as possibilidades óbvias e selecione a causa que melhor corresponde às evidências.
3. Teste a hipótese. Escolha um teste cujo resultado possa confirmar ou refutar a causa proposta. Se o teste não a confirmar, formule uma nova hipótese ou escalone o problema.
4. Estabeleça um plano de ação e identifique os efeitos. Decida como corrigir a causa confirmada e o que o trabalho pode interromper.
5. Implemente a solução ou escalone o problema. Siga o processo de mudança e registre cada ação.
6. Verifique o funcionamento completo e aplique medidas preventivas. Verifique o trabalho dos usuários e outros serviços afetados e, em seguida, reduza a chance de recorrência.
7. Documente descobertas, ações, resultados e lições. Registre a causa, as evidências, a correção e o resultado para o suporte futuro.

Um reparo rápido ainda precisa de verificação. Um cabo de conexão substituído pode restaurar um enlace enquanto a aplicação tem uma falha separada.

Escolha por onde começar

A abordagem de baixo para cima começa pela alimentação, pelo cabeamento e pelos enlaces e sobe por comutação, endereçamento e serviços. Ela é adequada quando não há indicação luminosa de enlace. A abordagem de cima para baixo começa pela aplicação e desce. Ela pode ser adequada a uma falha restrita a um serviço.

Dividir para conquistar testa um ponto intermediário, como o gateway padrão. Um teste bem-sucedido do gateway direciona a atenção para o roteamento ou os serviços adiante. Uma falha direciona a atenção para o endereçamento local, a associação à VLAN e o caminho físico, considerando também a filtragem ao interpretar uma sonda.

Investigue uma interrupção compartilhada

Usuários no andar 2 perdem o acesso às 09:10. Clientes cabeados e sem fio são afetados, e seu comutador de acesso foi substituído às 09:00. Esse alcance aponta para um caminho compartilhado, não para o cabo de um único usuário.

A hipótese é a ausência de configuração de enlace tronco no enlace de subida do comutador substituto. show interfaces trunk não lista nenhum enlace tronco. Compare as configurações ativas com a cópia de segurança anterior para testar a diferença de configuração. Planeje uma restauração, explicando a interrupção ao responsável pelo andar, implemente-a e verifique o acesso ao gateway, os serviços remotos e uma amostra de usuários.

Registre a configuração ausente e os testes bem-sucedidos. Acrescente a restauração e a verificação da configuração ao procedimento de substituição.

Escalone com evidências úteis

Escalone quando o acesso ou o conhecimento necessário estiver além de sua função ou quando os testes levarem a equipamentos gerenciados por outra equipe. Repasse os usuários e serviços afetados, os horários, as mudanças recentes, as saídas exatas, as hipóteses testadas e as alterações já feitas. Isso permite que o próximo técnico continue a partir das evidências atuais em vez de repetir a primeira hora de trabalho.

Execute os testes a partir do host ou segmento afetado e guarde a saída exata. Comparar um host com falha com outro próximo que funciona frequentemente revela uma diferença de configuração mais rápido do que testar a partir de uma rede não relacionada do administrador.

Leia primeiro as configurações locais

Em outros sistemas Linux, examine /etc/resolv.conf para obter informações do resolvedor. ifconfig mostra as configurações das interfaces no macOS e em sistemas mais antigos semelhantes ao Unix; rotas e DNS exigem verificações separadas. Em um cliente que deve usar DHCP, um endereço local de enlace 169.254.x.x atribuído automaticamente direciona a atenção para uma falha na obtenção da concessão.

Teste pontos progressivamente mais distantes

ping envia mensagens ICMP Echo Request e informa respostas, RTTs e perda. Teste o loopback 127.0.0.1, o endereço do próprio host, o gateway, um endereço remoto e um nome. Isso separa o software local, a LAN, a conectividade adiante e a resolução de nomes.

“Tempo limite da solicitação esgotado” significa que uma resposta não chegou a tempo. A causa pode ser um destino parado, filtragem ou uma rota ausente em qualquer direção. “Host de destino inacessível” informa uma falha de entrega a partir do host ou de um roteador. Mensagens repetidas de “TTL expirado em trânsito” sugerem um loop de roteamento; examine a rota e o caminho.

Uma sonda sem resposta deixa a filtragem entre as possibilidades. Teste também a aplicação necessária, usando o nome e o protocolo corretos.

Rastreie e resolva nomes

tracert no Windows e traceroute no Linux ou macOS enviam sondas com valores de TTL crescentes. Os roteadores nos quais o TTL expira podem retornar ICMP Time Exceeded. O Windows usa sondas ICMP Echo; o Linux normalmente usa sondas UDP.

Uma linha de asteriscos seguida por saltos que respondem mostra a ausência de respostas de um roteador, embora as sondas posteriores continuem adiante. A ausência de respostas de um salto até o fim pode indicar filtragem ou uma falha no caminho. Um aumento persistente do RTT sugere onde investigar, mas inclui o percurso de retorno e o processamento da resposta. Confirme-o com testes repetidos e medições de interface.

nslookup www.example.com e dig www.example.com consultam o DNS. Se um endereço estiver acessível, mas o nome não puder ser resolvido, examine as configurações do resolvedor e os registros.

Acrescente evidências do enlace local e do serviço

arp -a mostra mapeamentos de IP para MAC em cache. Para testar o contato atual com o gateway, remova essa entrada, envie tráfego e verifique se uma nova entrada aparece. Uma entrada antiga pode permanecer após uma falha.

netstat, ou ss no Linux, mostra conexões e portas de escuta. pathping e mtr combinam informações do caminho com medições repetidas de perda. nmap verifica portas abertas em destinos autorizados, enquanto iperf mede a vazão alcançada entre dispositivos finais. Um socket TCP 443 em escuta mostra que um serviço local está aguardando; um teste separado a partir de um cliente verifica se o caminho de rede permite alcançá-lo.

Testes no host mostram um sintoma a partir de um dispositivo final. Os comandos show de comutadores e roteadores acrescentam a visão do dispositivo: se uma porta está habilitada, qual VLAN transporta seu tráfego e para onde irá o próximo pacote. Os comandos apresentados aqui usam a sintaxe do Cisco IOS.

Leia o estado sem parar nele

show ip interface brief lista endereços, Status físico e Protocol de enlace. Interprete os dois campos de estado em conjunto:

Em comutadores, show interfaces status acrescenta a VLAN de acesso, velocidade, duplex e estados como connected, notconnect ou err-disabled. show interfaces fornece taxas e contadores detalhados, incluindo erros de CRC, quadros abaixo e acima do tamanho permitido, colisões e descartes na fila de saída.

Uma porta up/up pode transportar a VLAN errada ou acumular quadros danificados. Uma verificação útil, portanto, relaciona o estado à configuração pretendida e às mudanças nos contadores durante um intervalo medido.

Acompanhe o tráfego pela comutação e pelo roteamento

show mac address-table localiza um endereço MAC aprendido por porta e VLAN. show vlan brief lista a associação das portas de acesso. show interfaces trunk identifica enlaces tronco e as VLANs transportadas por eles.

Por exemplo, uma impressora usa 10.20.30.45, que o IPAM atribui à VLAN 30. Seu MAC aparece em Gi1/0/14 na VLAN 1. A evidência aponta para a atribuição da porta. Após uma correção controlada para a VLAN 30, teste novamente o acesso à impressora e atualize o registro da mudança.

show ip route lista rotas diretamente conectadas, estáticas e aprendidas, incluindo o gateway de último recurso. Se as sub-redes locais funcionam, mas as redes remotas falham, examine a rota padrão e o caminho de retorno. show ip arp acrescenta os mapeamentos locais de IP para MAC no roteador.

Verifique configurações, alimentação e eventos

show running-config exibe as configurações ativas para comparação com a cópia de segurança ou a configuração padrão de referência. show power inline mostra o uso de PoE por porta e o orçamento restante do comutador. show logging fornece o buffer local de eventos, que pode relacionar uma falha à oscilação de um enlace, a um evento de proteção ou a um problema de alimentação.

Guarde a saída exata do comando e seu horário. Uma mudança posterior de estado é mais fácil de interpretar quando a observação anterior é preservada.

Identifique a outra extremidade

O protocolo de descoberta da Cisco (CDP) é proprietário da Cisco; o protocolo de descoberta da camada de enlace (LLDP) é o padrão IEEE 802.1AB. Ambos anunciam informações aos dispositivos vizinhos diretamente conectados, como nome do dispositivo, modelo, porta e endereço de gerenciamento.

Use show cdp neighbors ou show lldp neighbors para confirmar para onde vai um enlace de subida quando o desenho estiver incompleto. Combine esse registro de vizinho com o mapa de cabeamento e os detalhes da porta local. O nome de um vizinho ajuda a localizar a conexão; verificações de VLAN, rota e serviço estabelecem se essa conexão atende ao tráfego pretendido.

Um cabo em funcionamento pode levar um host à VLAN errada, e um roteador em funcionamento pode não ter a rota necessária para uma resposta. Compare as configurações reais com o plano de endereçamento e acompanhe o serviço com falha nas duas direções.

Verifique a sub-rede e o gateway do host

Para acesso IPv4 roteado, um host precisa de um endereço único, da máscara correta e de um gateway acessível em sua sub-rede. O DNS também é necessário para transformar nomes em endereços. A comunicação por endereço IP pode funcionar enquanto o DNS falha.

Considere 10.1.1.130/25. Sua rede é 10.1.1.128/25 e sua faixa utilizável vai de .129 a .254. Um gateway 10.1.1.1 está fora dessa sub-rede. Consulte o IPAM: o gateway documentado deve estar dentro da /25 ou a máscara pretendida pode ser, na verdade, /24. Não invente um gateway apenas porque seu número parece familiar.

Um endereço duplicado pode causar acesso intermitente à medida que diferentes endereços MAC são associados a um mesmo IP. Use evidências ARP e a tabela MAC do comutador para localizar o segundo dispositivo. Corrija a atribuição estática ou a reserva DHCP e mantenha o IPAM consistente.

Separe DHCP de DNS

Um cliente DHCP que não recebe uma concessão pode usar um endereço automático 169.254.x.x. Verifique o servidor, os endereços disponíveis no pool, a VLAN do cliente e o caminho de retransmissão quando o servidor estiver em outra sub-rede. Em equipamentos Cisco, a retransmissão é geralmente configurada com ip helper-address.

Um pool de 192.168.5.100 até .199 contém 100 endereços, contando as duas extremidades. Um 101º cliente simultâneo precisa de outro endereço livre. Concessões mais curtas recuperam mais cedo os endereços de clientes que saíram; clientes ativos renovam suas concessões, portanto a duração não pode aumentar a capacidade simultânea do pool.

Para DNS, examine os endereços de resolvedores recebidos pelo host e consulte o servidor pretendido. Verifique o registro relevante. Após corrigir um registro alterado, ipconfig /flushdns limpa o cache local desatualizado de um cliente Windows. Limpar o cache do cliente não corrige um registro incorreto no servidor.

Verifique comutação, rotas e regras

Elimine a causa de um estado err-disabled antes de reativar a porta. Em uma porta Cisco, isso pode envolver shutdown seguido de no shutdown, após a correção da falha.

Uma solicitação pode chegar a um servidor enquanto a resposta não tem rota para a sub-rede de origem. Verifique as duas direções. Para filtragem de tráfego, examine os contadores de correspondências e os logs da regra relevante. Uma troca ICMP bem-sucedida testa ICMP, enquanto o tráfego TCP ou UDP da aplicação segue suas próprias regras.

Use o alcance do problema para escolher componentes compartilhados: um host afetado direciona a atenção para o ambiente local; uma sub-rede inteira direciona a atenção para seu gateway, comutador de acesso, serviço DHCP ou enlace de subida.

Ausência de indicação luminosa de enlace, oscilações repetidas do enlace, velocidade inesperadamente baixa e erros de quadro crescentes justificam uma verificação física logo no início. Comece pelas conexões visíveis e por uma substituição simples, como um cabo de conexão comprovadamente bom, e escolha uma ferramenta que meça a falha suspeita.

Entenda as falhas em cobre

Um circuito aberto é um condutor rompido; um curto-circuito une condutores que deveriam estar separados. Uma ligação incorreta coloca fios em pinos não pretendidos. Um par dividido pode preservar a continuidade entre os pinos enquanto mistura os pares trançados físicos, causando diafonia. Um teste simples de continuidade pode não detectá-lo.

Mantenha os pares trançados até perto da terminação; destrançá-los excessivamente, além de cerca de 13 mm, reduz a rejeição de ruído. Atenuação é a perda de sinal com a distância. Diafonia é a interferência entre pares, medida como NEXT perto da extremidade de envio e FEXT na extremidade distante. EMI vem de fontes elétricas externas, como motores ou cabos de energia adjacentes.

Um canal Ethernet padrão de par trançado permite 100 m, normalmente 90 m de cabo fixo mais 10 m de cabos de conexão. Cat 5e oferece suporte a 1 Gbit/s em 100 m; Cat 6 oferece suporte a 10GBASE-T em trechos menores, até cerca de 55 m conforme as condições de instalação; Cat 6A oferece suporte a 10GBASE-T em 100 m.

Escolha a ferramenta para cobre conforme a pergunta

Em um trecho de 42 m, um teste com TDR a partir da tomada de rede encontra um circuito aberto a 37 m. A ruptura está a cerca de 5 m da extremidade do painel. A direção do teste é relevante: o visor mostra a distância a partir do instrumento, não da extremidade mais fácil de alcançar.

A aprovação em um teste de continuidade verifica as conexões, enquanto uma certificação de categoria também mede o desempenho, como perda, diafonia e perda de retorno.

Inspecione e teste a fibra

Falhas em fibra incluem extremidades sujas ou riscadas, curvatura excessiva, fibra e componentes ópticos incompatíveis e caminhos de transmissão e recepção invertidos. Confira as especificações dos transceptores e verifique a polaridade antes de substituir um trecho longo.

Um localizador visual de falhas (VFL) envia luz vermelha visível para revelar algumas rupturas e curvas fechadas. Uma fonte de luz e um medidor de potência óptica medem a perda. Um OTDR identifica eventos ópticos e suas distâncias. Um microscópio de inspeção verifica a condição do conector. Um conector de loopback liga a transmissão de uma porta à recepção para um teste local da porta.

Nunca olhe para a extremidade de uma fibra, um transceptor ou a saída de um VFL. Siga as regras de segurança elétrica do local e respeite o raio mínimo de curvatura do cabo.

Após substituir ou reparar um componente, repita o teste relevante e registre a etiqueta do cabo, o resultado e os valores medidos. Isso associa o reparo à evidência de que o enlace instalado agora atende ao requisito.

Um enlace pode permanecer ativo enquanto quadros danificados, configurações incompatíveis ou alimentação insuficiente interrompem o trabalho. Interprete a tendência de erros da interface e verifique as especificações físicas nas duas extremidades.

Interprete as mudanças nos contadores

Os contadores são cumulativos, por isso primeiro preserve os valores atuais e o horário. Depois, compare os valores durante um intervalo de tráfego conhecido ou zere os contadores durante um teste controlado. Um total acumulado alto pode descrever um evento antigo; uma contagem que cresce rapidamente descreve um problema atual.

Erros de CRC identificam quadros recebidos danificados. Inspecione cabeamento, conectores, interferência, componentes ópticos e configurações de duplex. Para 2.500 erros em 1.000.000 de pacotes recebidos, a parcela de erros é 0,25%. Enlaces em boas condições devem permanecer próximos de zero.

Quadros abaixo do tamanho mínimo são quadros menores que o mínimo Ethernet de 64 bytes. Quadros acima do tamanho máximo excedem o limite aplicável; um quadro Ethernet padrão sem etiqueta tem tamanho máximo de 1.518 bytes. Verifique as configurações de MTU e quadros jumbo quando houver suspeita de tráfego acima do tamanho permitido. Descartes na fila de saída, por sua vez, mostram tráfego descartado da fila de envio, frequentemente durante congestionamento.

Compatibilize velocidade e duplex

Em 100 Mbit/s, fixar uma extremidade em duplex completo e deixar a outra em automático pode produzir uma incompatibilidade. A extremidade automática detecta a velocidade, mas recorre ao meio duplex quando não consegue negociar o duplex. Espere colisões tardias no lado em meio duplex e quadros danificados ou abaixo do tamanho mínimo no lado em duplex completo.

Configure as duas extremidades para autonegociação ou use as mesmas configurações fixas compatíveis em ambas. Confirme velocidade, duplex e novas contagens de erros depois. Desativação administrativa, desativação por erro e uma interface membro suspensa de uma agregação de enlaces exigem, cada uma, uma verificação da configuração ou da causa de proteção, não a substituição automática do cabo.

Verifique PoE por porta e no total

A alimentação por Ethernet (PoE) fornece dados e energia elétrica pelo mesmo cabo de cobre. Os limites no comutador são:

As perdas no cabo explicam a diferença. Um dispositivo que exige PoE+ pode falhar ou reiniciar em uma porta que oferece apenas af. Some também todas as alocações do lado do comutador: oito pontos de acesso de 30 W e dez câmeras de 15,4 W exigem 394 W. Isso excede um orçamento de 370 W em 24 W. show power inline revela as alocações por porta e a potência restante. Acrescente capacidade adequada ou transfira cargas para outra fonte.

Compatibilize componentes ópticos e peças de reposição

Os transceptores devem corresponder em velocidade, comprimento de onda e tipo de fibra nas duas extremidades. Verifique os módulos aceitos, as conexões de transmissão e recepção e a potência óptica recebida. Uma potência de recepção baixa aponta para conectores sujos, fibra danificada ou perda excessiva no caminho.

Em caso de reinicializações do hardware ou superaquecimento, inspecione ventoinhas, fontes de alimentação, temperatura e logs. Substitua por peças compatíveis e verifique configurações do enlace, erros, alimentação e serviços. Mantenha as peças de reposição críticas identificadas no inventário.

Uma aplicação lenta pode indicar um enlace de subida saturado, quadros danificados ou um caminho longo. Meça taxas, atraso, variação do atraso e perda nos pontos relevantes antes de escolher uma melhoria.

Encontre o recurso limitante

Congestionamento ocorre quando o tráfego recebido excede a capacidade de um enlace: as filas crescem, o atraso aumenta e quadros são descartados. Contenção é a disputa por um recurso compartilhado, como um canal sem fio. Um gargalo é o ponto que limita o caminho. Um servidor de 10 Gbit/s não consegue enviar nessa taxa a clientes alcançados por um enlace de 1 Gbit/s.

A sobressubscrição compara a capacidade total de acesso com a capacidade total dos enlaces de subida. Quarenta e oito portas de 1 Gbit/s atendidas por dois enlaces de subida ativos de 10 Gbit/s resultam em:

Essa é uma razão de capacidade, não uma medida do uso atual. A sobressubscrição é comum porque raramente todos os clientes transmitem à velocidade máxima. A utilização sustentada do enlace de subida e os descartes na fila de saída mostram quando a capacidade compartilhada se torna insuficiente.

Estime uma transferência corretamente

Converta o tamanho do arquivo em bytes para bits antes de dividi-lo por uma taxa em bits. Com prefixos decimais, um arquivo de 2 GB contém 16.000 megabits.

Com uma vazão real de 80 Mbit/s, a transferência leva 200 s. A taxa do enlace fornece um limite inferior ideal; a vazão medida oferece uma estimativa mais útil para o planejamento. Dividir gigabytes diretamente por megabits por segundo ignora tanto a conversão de prefixos quanto os oito bits de um byte.

Explique atraso e perda

A propagação leva tempo para cobrir uma distância; a serialização coloca os bits no enlace; os dispositivos acrescentam atrasos de processamento e de fila. A luz em fibra percorre cerca de 200 km por milissegundo. Mais largura de banda local não elimina o tempo de percurso de um caminho distante.

A perda pode resultar de descartes em filas, erros físicos, hardware sobrecarregado ou interferência sem fio. O TCP retransmite dados ausentes e reduz sua taxa de envio, por isso mesmo uma perda moderada pode diminuir muito a vazão. A mídia em tempo real pode apresentar falhas.

Para Wi-Fi, examine sinal fraco, canais congestionados, interferência, excesso de clientes e clientes que permanecem associados a um ponto de acesso distante. Compare com um teste cabeado no mesmo local para separar problemas de rádio de problemas mais amplos no caminho.

Escolha uma melhoria apoiada em evidências

Em uma filial, chamadas apresentam falhas das 13:00 às 15:00. O enlace de internet de 100 Mbit/s chega a 95 Mbit/s, e os registros de fluxo identificam um backup de 70 Mbit/s. Transferir esse backup para as 22:00 reduz a carga da tarde para cerca de 25 Mbit/s. O QoS pode então priorizar chamadas durante os picos restantes.

Outras melhorias incluem atualizar um gargalo, acrescentar capacidade por agregação de enlaces, corrigir falhas de firmware ou substituir equipamentos sobrecarregados. A agregação de enlaces aumenta a capacidade entre fluxos de tráfego; um único fluxo ainda pode ficar limitado a um enlace membro. O QoS altera a prioridade, não a capacidade total. Meça novamente sob carga comparável para verificar a melhoria.

A entrega significa demonstrar que a rede instalada atende aos requisitos e deixar registros utilizáveis para o próximo operador. Uma conexão bem-sucedida à internet cobre apenas uma pequena parte dessa tarefa.

Transforme requisitos em testes registrados

Comece pelos equipamentos, serviços, cobertura e metas de desempenho acordados. Crie uma lista de verificação que associe cada requisito a um teste e a um resultado. Inclua equipamentos novos e componentes reparados.

Teste cada enlace de cabo permanente, compare as etiquetas das duas extremidades com o mapa de cabeamento e repare e teste novamente as falhas. Use um certificador quando o contrato exigir certificação de categoria. Guarde o relatório e os resultados medidos de cada enlace com seu identificador.

Para a configuração, verifique se as credenciais padrão foram substituídas, se o firmware estável aprovado foi instalado, se a hora e o NTP foram configurados e se os endereços IP, as VLANs e a segurança sem fio planejados foram aplicados. Desative portas e serviços não utilizados. Salve e faça uma cópia de segurança das configurações finais verificadas.

Teste cada serviço e segmento

Use clientes de teste em portas representativas de cada VLAN e em cada rede sem fio. Verifique se eles obtêm o endereço pretendido, alcançam o gateway, resolvem nomes e acessam os servidores e serviços de internet necessários.

Depois, teste os tipos de dispositivos instalados: telefones fazem chamadas, impressoras imprimem, câmeras fornecem suas imagens e pontos de acesso atendem clientes. Se houver redundância instalada, realize o teste de comutação por falha acordado em uma janela controlada, por exemplo, removendo um enlace de subida e verificando a continuidade do serviço necessário.

Registre o local, o horário, o método e o resultado do teste. Uma falha restrita a uma VLAN precisa de um resultado separado mesmo quando as outras VLANs são aprovadas.

Meça e otimize

Meça a vazão entre dispositivos finais definidos, além da latência e da perda. Para redes sem fio, verifique a cobertura de sinal sala por sala. Essas leituras iniciais formam uma linha de base de desempenho.

A otimização melhora uma instalação que já funciona. Exemplos incluem escolher um canal sem fio menos ocupado, usar uma faixa mais rápida aceita pelos dispositivos, corrigir problemas de firmware, reforçar a segurança ou substituir um componente lento. Altere um item por vez e repita a medição relevante para que o resultado possa ser atribuído à mudança.

Suponha que uma tomada de rede passe no teste básico de continuidade, mas o tráfego nela produza erros de CRC crescentes. Um teste mais completo do mapa de fios identifica um par dividido. Refaz a terminação, repita os testes de cabo e de tráfego e registre “Tomada 1.04: aprovada após nova terminação.” Atualize o mapa para manter associados o local e o resultado.

Faça uma entrega operacional

Forneça diagramas físicos e lógicos, mapas de cabeamento e relatórios de teste, plano de endereçamento, inventário de ativos com números de série e firmware e cópias de segurança atuais das configurações. Transfira as credenciais de administrador por um canal seguro. Inclua instruções para suporte e recuperação de rotina.

A automação permite que um administrador descreva uma mudança uma vez e a aplique a muitos dispositivos. Ela também coleta o estado, faz cópias de segurança das configurações e compara as configurações reais com o padrão aprovado. A pessoa que a opera ainda precisa entender o resultado pretendido.

Descreva configurações de forma repetível

A infraestrutura como código (IaC) armazena definições de infraestrutura em arquivos de texto versionados. Uma edição revisada registra o que mudou e por quê. Modelos podem compartilhar configurações comuns enquanto variáveis fornecem o nome, o endereço de gerenciamento e a lista de VLANs de cada dispositivo.

Uma operação idempotente alcança o mesmo estado pretendido quando repetida. Se a VLAN 30 já corresponde à definição, uma tarefa idempotente adequada a deixa inalterada. Repetir não significa criar outra cópia do recurso.

O histórico de versões ajuda a recuperar definições anteriores, mas a rede instalada ainda deve ser verificada após a aplicação de uma versão. O estado dos dispositivos e os serviços dependentes determinam se uma reversão será bem-sucedida.

Reconheça ferramentas comuns

O Ansible usa inventários e playbooks em YAML. Ele normalmente acessa dispositivos de rede por SSH ou APIs sem instalar um agente no dispositivo. O Terraform descreve recursos de forma declarativa em HCL, compara a configuração desejada com o estado registrado e as informações do provedor, mostra um plano e aplica as ações aprovadas. É comum para recursos de nuvem e de controladoras.

Puppet e Chef tradicionalmente usam agentes que obtêm sua configuração de um serviço central. Essas ferramentas diferem em seu modelo de operação, mas todas precisam de definições corretas, acesso apropriado e uma forma de verificar os resultados.

A automação também apoia cópias de segurança de rotina, verificações de conformidade, detecção de desvios e coleta de estado. O provisionamento sem intervenção permite que um novo dispositivo obtenha sua configuração inicial automaticamente quando conectado.

Controle o alcance de uma mudança

Um modelo correto reduz a digitação repetida e as configurações inconsistentes. Um modelo com defeito pode espalhar o mesmo erro para todos os destinos. Revise a mudança proposta, teste-a em um pequeno grupo, verifique o resultado e amplie a implantação em etapas controladas. Mantenha cópias de segurança e um plano de reversão pelo processo habitual de mudanças.

Por exemplo, um playbook destinado a atualizar um servidor NTP deve ser testado primeiro em comutadores selecionados. Confirme a sincronização de horário e o acesso administrativo antes de executá-lo em todo o inventário. Um relatório de sucesso da ferramenta deve ser conferido com o estado dos dispositivos e serviços.

Submeta a saída da IA à revisão

A IA preditiva e o aprendizado de máquina detectam padrões incomuns de monitoramento e preveem necessidades de capacidade ou possíveis falhas. A IA generativa pode resumir eventos, responder a perguntas ou elaborar configurações.

Um rascunho plausível pode conter nome de interface, endereço ou comando incorreto. Revise-o em relação aos registros da rede e teste-o antes da implementação. A IA pode ajudar a organizar evidências; ela não elimina a responsabilidade de verificar a ação proposta e seus efeitos.

Uma API define como um programa solicita dados ou ações de outro. Controladoras de rede disponibilizam APIs para que ferramentas possam ler o estado dos dispositivos ou solicitar mudanças sem percorrer menus.

Interprete uma troca HTTP

Uma API no estilo REST identifica recursos por URIs, por exemplo, https://controller.example.com/api/v1/devices/42. Uma requisição tem método, cabeçalhos e, às vezes, um corpo. A resposta tem um código de status e frequentemente dados. Requisições sem estado carregam o contexto necessário para seu processamento, incluindo informações de autenticação quando exigidas.

Essas ações correspondem a CRUD: criação, leitura, atualização e exclusão. Consulte o contrato de recursos da API para conhecer o corpo aceito e o comportamento exato.

Leia o status antes de considerar uma requisição bem-sucedida. 200 significa OK, 201 significa criado e 204 significa sucesso sem conteúdo na resposta. Uma resposta 400 informa uma requisição inválida; examine seu corpo em busca de JSON malformado, campo ausente ou valor inválido. 401 diz respeito à autenticação ausente ou inválida. 403 significa que a requisição foi recusada por acesso insuficiente no fluxo habitual de gerenciamento autenticado. 404 significa que o recurso não foi encontrado; 500 informa um erro do servidor.

Proteja as informações de autenticação

A autenticação básica codifica nome de usuário e senha, mas não os criptografa; use-a apenas por HTTPS. Uma chave de API é uma credencial secreta. O acesso baseado em token envia um token, muitas vezes como Authorization: Bearer seguido do valor do token. OAuth é uma estrutura comumente usada para obter tokens de acesso.

Uma requisição de leitura com token expirado pode retornar 401. A mesma requisição com token válido pode retornar 200. Uma conta somente de leitura que tenta excluir algo pode receber 403. Alterar a senha não concede a essa conta permissão de exclusão.

Interprete valores e estrutura JSON

JSON usa objetos entre chaves e arrays ordenados entre colchetes. Chaves de objetos e valores de string usam aspas duplas retas. Números, valores booleanos e null não ficam entre aspas.

{
  "hostname": "SW1",
  "uptime_days": 41,
  "poe": true,
  "interfaces": [
    {"name": "Gi1/0/1", "vlan": 10},
    {"name": "Gi1/0/2", "vlan": 30}
  ]
}

O objeto externo tem quatro chaves. interfaces contém dois objetos, e o valor de VLAN da segunda interface é o número 30. Escrever "30" faria dele uma string. O cabeçalho Content-Type: application/json identifica JSON como formato do corpo.

JSON proíbe comentários, strings entre aspas simples e vírgulas após o último item. Ele exige vírgulas entre membros consecutivos. Verifique a sintaxe separadamente dos requisitos de campos da API: um JSON válido ainda pode solicitar uma VLAN inválida ou omitir um nome obrigatório. Leia o corpo da resposta para saber qual problema o servidor informou.

Em uma rede tradicional, cada dispositivo constrói informações de encaminhamento por suas próprias funções de controle e é normalmente gerenciado por sessões individuais. Redes baseadas em controladoras acrescentam uma visão central e políticas compartilhadas enquanto os dispositivos continuam encaminhando o tráfego.

Separe três funções

Uma rede definida por software (SDN) separa grande parte do trabalho de controle dos dispositivos de encaminhamento e o coordena por meio de uma controladora. A visão da controladora apoia políticas consistentes e automação. Os comutadores e roteadores mantêm sua função no plano de dados.

Posicione as interfaces em relação à controladora

Interfaces norte conectam aplicações, scripts e painéis à controladora, frequentemente com APIs REST. Uma aplicação solicita uma política ou consulta o estado de toda a rede por elas.

Interfaces sul conectam a controladora aos dispositivos. As tecnologias podem incluir NETCONF, RESTCONF, OpenFlow, SNMP ou SSH, conforme o projeto. “Norte” e “sul” descrevem a função da interface, não a localização dos dispositivos finais no edifício.

Para uma mudança na rede de visitantes, uma aplicação pode solicitar uma política pela interface norte. A controladora então aplica as configurações aos dispositivos pela interface sul e coleta os resultados. Uma implantação parcial ainda precisa ser investigada; o gerenciamento central torna os resultados visíveis, mas não garante que todos os destinos aceitaram a mudança.

Diferencie rede de suporte e rede sobreposta

A rede de suporte é a rede física de dispositivos e enlaces com conectividade IP. Uma rede sobreposta cria uma rede virtual sobre ela usando túneis, como VXLAN, para transportar segmentos separados. Uma malha de rede reúne a rede de suporte e a rede sobreposta em um sistema gerenciado.

Um túnel ainda depende do caminho subjacente. Quando um dispositivo final da rede sobreposta estiver inacessível, teste a conectividade da rede de suporte antes de supor que a política da rede virtual está errada.

Traduza a intenção em comportamento verificado

Com redes baseadas em intenção, o administrador declara uma meta como “visitantes só podem acessar a internet”. A controladora traduz isso em configurações e verifica se o comportamento corresponde à intenção. O Cisco Catalyst Center é um exemplo de controladora de gerenciamento de rede de campus.

A SD-WAN aplica políticas centralizadas às conexões entre unidades. Ela pode direcionar aplicações por vários enlaces conforme a qualidade medida e a política. Comutadores e pontos de acesso gerenciados pela nuvem oferecem um modelo relacionado de gerenciamento central por meio de um painel hospedado.

Controladoras oferecem provisionamento mais rápido, configurações consistentes e visibilidade compartilhada. Elas também exigem segurança, resiliência e habilidades da equipe e podem introduzir dependência de fornecedor. Durante uma interrupção da controladora, os dispositivos em projetos típicos continuam encaminhando o tráfego existente, enquanto novas políticas e operações de gerenciamento podem ficar indisponíveis. O comportamento exato depende do projeto e do estado já mantido pelos dispositivos.