Aula 23: Troubleshooting Cisco — debug, show e diagnóstico de falhas
O Troubleshooting Cisco é, sem exagero, a competência mais valiosa que um profissional de redes pode desenvolver ao longo da carreira. Enquanto a configuração de um roteador ou switch segue roteiros previsíveis e bem documentados, o diagnóstico de falhas exige raciocínio estruturado, domínio profundo dos comandos de inspeção e a capacidade de correlacionar sintomas espalhados por diferentes camadas do modelo OSI. Nesta aula avançada, você vai aprender a utilizar os principais comandos show, debug e ferramentas de diagnóstico do Cisco IOS para identificar, isolar e corrigir problemas reais de rede com eficiência cirúrgica.
O que diferencia um administrador de redes mediano de um especialista em Troubleshooting Cisco não é a quantidade de comandos memorizados, mas a metodologia aplicada diante de uma falha. Quando um link cai, uma rota desaparece ou uma sessão BGP oscila, a ordem das verificações importa tanto quanto os comandos em si. Ao longo desta aula, você vai internalizar um fluxo de diagnóstico que começa na camada física, sobe pela camada de enlace, atravessa a camada de rede e chega até as aplicações — sempre com comandos de verificação imediatos após cada etapa.
Antes de começar, é fundamental que você tenha concluído as aulas anteriores do curso, especialmente aquelas sobre configuração de interfaces, roteamento estático e dinâmico, VLANs e Spanning Tree. Você precisará de acesso a um ambiente de laboratório, que pode ser físico (com roteadores e switches reais rodando IOS) ou virtualizado com ferramentas como GNS3, EVE-NG ou Cisco Modeling Labs (CML). Ter dois roteadores e dois switches interligados é o cenário mínimo recomendado para reproduzir os procedimentos práticos desta aula.
Ao final desta aula, você será capaz de diagnosticar falhas de conectividade ponta a ponta, interpretar as saídas dos principais comandos show, utilizar comandos debug com segurança e critério, correlacionar eventos de syslog com problemas de rede e, principalmente, aplicar uma metodologia de isolamento de falhas que reduz drasticamente o tempo de indisponibilidade. Nos projetos e atendimentos que realizamos na JRT Technology Solutions, essa abordagem estruturada é aplicada diariamente em ambientes críticos de clientes corporativos e provedores de internet.
Prepare seu laboratório, abra sua sessão de console ou SSH e vamos mergulhar fundo no universo do Troubleshooting Cisco com comandos reais, saídas reais e cenários que reproduzem os desafios mais comuns enfrentados no dia a dia de operação de redes.
O que você vai aprender nesta aula
- Compreender a metodologia estruturada de Troubleshooting Cisco baseada no modelo OSI e na abordagem top-down/bottom-up
- Dominar os comandos show mais relevantes para diagnosticar problemas de interfaces, rotas, protocolos e serviços
- Utilizar comandos debug com segurança, entendendo o impacto de cada um no desempenho do equipamento
- Interpretar saídas de debug e correlacioná-las com sintomas observados na rede
- Diagnosticar e corrigir falhas de camada 2, incluindo problemas de VLAN, trunking e Spanning Tree
- Diagnosticar e corrigir falhas de camada 3, incluindo ausência de rotas, problemas de adjacência e métricas incorretas
- Utilizar ferramentas complementares como ping estendido, traceroute, syslog e SNMP no contexto de troubleshooting
- Aplicar boas práticas de documentação e prevenção de falhas recorrentes
Pré-requisitos e Ambiente
Para executar todos os procedimentos desta aula sem lacunas, você precisará de um ambiente de laboratório funcional. O cenário mínimo recomendado consiste em dois roteadores Cisco interligados por um link serial ou Ethernet, dois switches realizando trunking entre si e pelo menos dois hosts (podem ser interfaces loopback simulando redes locais) em cada extremidade. Se você utiliza GNS3 ou EVE-NG, pode criar este ambiente virtualmente em poucos minutos. Em ambientes físicos, um roteador Cisco ISR 4321 ou mesmo um Cisco 1841 com IOS 12.4 ou superior é suficiente para acompanhar a aula.
O acesso ao equipamento deve ser feito por console (recomendado durante a fase de debug para evitar que comandos de depuração interfiram na sua própria sessão de acesso) ou por SSH com privilégio de nível 15. Certifique-se de que o logging synchronous esteja habilitado nas linhas de console e VTY, pois durante a execução de comandos debug a saída no terminal pode interromper a digitação de comandos. Se ainda não estiver configurado, execute no modo de configuração global: line console 0, logging synchronous, exec-timeout 0 0 e, em seguida, line vty 0 15, logging synchronous. Isso evita frustrações desnecessárias no meio do diagnóstico.
Outro pré-requisito essencial é ter o clock e o timezone corretamente configurados nos equipamentos, pois a correlação de eventos entre múltiplos dispositivos depende de timestamps precisos nos logs. Configure clock timezone GMT -3 e, se possível, habilite NTP com o comando ntp server <endereço>. Em nossos laboratórios na JRT Technology Solutions, utilizamos um servidor NTP interno como fonte de referência para todos os dispositivos de teste, garantindo que os logs de diferentes equipamentos possam ser cruzados com precisão de milissegundos.
Por fim, tenha em mãos um caderno de documentação ou uma ferramenta de tickets para registrar cada sintoma observado, cada hipótese levantada e cada ação executada. O Troubleshooting Cisco profissional é, antes de tudo, um processo científico: observação, hipótese, teste e conclusão. Sem documentação, você corre o risco de se perder no meio do caminho ou de repetir testes desnecessários em momentos de alta pressão.
Fundamentos do Troubleshooting Cisco — Metodologia e Modelo OSI
Toda atividade de Troubleshooting Cisco começa com a definição clara do problema. Antes de tocar em qualquer comando, você precisa responder a três perguntas fundamentais: O que exatamente está falhando? Desde quando a falha ocorre? O que mudou no ambiente recentemente? A resposta a essas perguntas define o escopo da investigação e evita que você perca tempo testando hipóteses irrelevantes. Em incidentes reais, a causa raiz frequentemente está relacionada a uma mudança recente — uma atualização de configuração, uma alteração física no cabeamento ou a adição de um novo dispositivo à rede.
O modelo OSI é a espinha dorsal da metodologia de diagnóstico. A abordagem bottom-up começa na camada física e sobe progressivamente até a camada de aplicação, verificando em cada nível se os pré-requisitos para o funcionamento da camada superior estão satisfeitos. Já a abordagem top-down parte da aplicação e desce até a camada física, sendo útil quando o sintoma é específico de um serviço ou aplicação. Para a maioria dos problemas de conectividade, a abordagem bottom-up é mais eficiente, pois elimina causas básicas rapidamente — um problema físico nunca será resolvido por ajustes de configuração de camada 3.
Uma terceira abordagem, frequentemente utilizada por especialistas, é o divide-and-conquer (dividir e conquistar). Nela, você inicia o diagnóstico em uma camada intermediária — geralmente a camada de rede — e, dependendo do resultado, sobe ou desce na pilha OSI. Por exemplo, se um ping para o gateway local funciona, mas o ping para um host remoto não, você sabe que o problema está acima da camada 2 local e pode concentrar esforços no roteamento. Se nem o gateway responde, o problema está nas camadas 1 ou 2 e não faz sentido testar rotas antes de verificar cabos, VLANs e Spanning Tree.
Independentemente da abordagem escolhida, o fluxo de trabalho do Troubleshooting Cisco profissional segue sempre esta sequência: coletar informações do sintoma, localizar os dispositivos no caminho da falha, verificar o estado operacional de cada um, testar a conectividade em cada salto, isolar o segmento problemático, identificar a causa raiz e, somente então, aplicar a correção. Aplicar correções antes de identificar a causa raiz é o erro mais comum entre profissionais iniciantes e pode transformar um problema simples em uma falha complexa e prolongada.
Os comandos show e debug são as duas ferramentas primárias nesse processo, mas têm propósitos distintos. Os comandos show exibem o estado atual de estruturas de dados, tabelas e configurações — são instantâneos, não intrusivos e podem ser executados a qualquer momento. Os comandos debug, por outro lado, ativam a exibição em tempo real de eventos específicos à medida que ocorrem — são dinâmicos, consomem CPU e devem ser usados com critério. Um especialista em Troubleshooting Cisco sabe que a maioria dos problemas pode ser resolvida apenas com comandos show bem escolhidos, reservando os debug para situações em que o estado instantâneo não revela a causa.
Diagnóstico de Camada 1 e 2 — Interfaces, Cabeamento e Switching
O ponto de partida de qualquer diagnóstico bottom-up é a verificação do estado físico e lógico das interfaces. O comando show interfaces fornece um panorama completo de cada interface, incluindo contadores de erros, pacotes descartados, estado de linha e protocolo, taxa de transmissão e muito mais. A primeira informação a observar é o par line protocol / status no início da saída: uma interface com administratively down está desligada por configuração, enquanto down/down indica ausência de sinal físico ou problema de encaminhamento na camada de enlace. Já up/down sugere que o enlace físico está ativo, mas o protocolo de camada 2 não está funcionando adequadamente — um sintoma clássico de incompatibilidade de encapsulamento ou falha de negociação.
O comando show ip interface brief é a ferramenta de triagem mais rápida para obter o estado de todas as interfaces em uma única visão. Em cenários de falha, ele permite identificar imediatamente quais interfaces estão operacionais e quais estão com problemas, economizando tempo precioso. Em nossos atendimentos na JRT Technology Solutions, este é frequentemente o primeiro comando executado ao acessar um equipamento com suspeita de falha, pois fornece um mapa instantâneo da saúde das interfaces e dos endereços IP associados.
Para investigar problemas de camada 2 em switches, três comandos são indispensáveis: show vlan brief para verificar quais VLANs existem e quais portas estão atribuídas a cada uma, show interfaces trunk para confirmar o status dos trunks e quais VLANs estão permitidas em cada link, e show spanning-tree para analisar o estado do protocolo STP em cada VLAN. Um erro comum em infraestruturas corporativas é a ausência de uma VLAN no banco de dados do switch, o que faz com que o tráfego daquela VLAN seja descartado silenciosamente sem gerar logs de erro aparentes.
! ============================================================
! TROUBLESHOOTING CISCO - CAMADA 1 E 2
! Verificando o estado das interfaces do switch
! ============================================================
! Mostra um resumo de todas as interfaces com IP e status
show ip interface brief
! Mostra o estado detalhado da interface GigabitEthernet0/1
! Inclui contadores de erros, colisões, drops e estado físico
show interfaces gigabitEthernet 0/1
! Verifica o banco de dados de VLANs e o mapeamento de portas
show vlan brief
! Confirma o status dos trunks e as VLANs permitidas/ativas
show interfaces trunk
! Analisa o estado do Spanning Tree para a VLAN 10
show spanning-tree vlan 10
! Verifica a tabela MAC do switch para a VLAN 20
show mac address-table vlan 20
! Verifica o status de Power over Ethernet nas portas
show power inline
! Verifica contadores de erros em todas as interfaces resumidamente
show interfaces summary
Switch# show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES unset administratively down down
Vlan10 192.168.10.1 YES manual up up
Vlan20 192.168.20.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset up up
GigabitEthernet0/2 unassigned YES unset down down
GigabitEthernet0/3 unassigned YES unset up up
Switch# show interfaces gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is aabb.cc00.0100
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is RJ45
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
12345 packets input, 987654 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
15678 packets output, 1234567 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Na saída acima, o estado up/up da interface confirma que tanto a camada física quanto o protocolo de enlace estão operacionais. Os contadores de erros zerados — 0 input errors, 0 CRC, 0 frame, 0 collisions — indicam um link saudável. Se você observar contadores de CRC incrementando rapidamente, isso sugere problemas físicos no cabeamento, conectores danificados ou interferência eletromagnética. Já late collisions apontam para problemas de duplex mismatch ou cabos excessivamente longos em redes half-duplex.
Troubleshooting Cisco de Camada 3 — Roteamento e Conectividade IP
Uma vez confirmado que as camadas 1 e 2 estão funcionando, o próximo passo no Troubleshooting Cisco é verificar a conectividade IP e o roteamento. O comando show ip route exibe a tabela de roteamento do equipamento, listando todas as rotas conhecidas, seus próximos saltos, interfaces de saída e distâncias administrativas. Uma rota ausente da tabela pode ter diversas causas: a interface da rede de destino está desativada, o protocolo de roteamento não está anunciando a rede corretamente, um filtro está bloqueando a propagação ou a rota foi substituída por outra com distância administrativa menor.
O comando ping continua sendo a ferramenta de teste mais básica e eficaz para validar a conectividade fim a fim. No Cisco IOS, o ping estendido oferece recursos adicionais valiosos: permite escolher a interface de origem, alterar o tamanho do pacote, definir o número de repetições e, crucialmente, selecionar o DF bit para testar problemas de MTU. Muitos sintomas de “a rede está lenta” ou “alguns sites não abrem” têm como causa raiz um problema de MTU em algum ponto do caminho, e o ping estendido com DF bit é a ferramenta ideal para detectá-lo.
! ============================================================
! TROUBLESHOOTING CISCO - CAMADA 3 E ROTEAMENTO
! Verificando a tabela de roteamento e conectividade
! ============================================================
! Exibe a tabela de roteamento completa
show ip route
! Exibe apenas rotas estáticas
show ip route static
! Exibe apenas rotas aprendidas via OSPF
show ip route ospf
! Exibe rotas para uma rede específica
show ip route 10.10.10.0
! Testa conectividade básica com 5 pacotes ICMP
ping 192.168.20.1
! Ping estendido - permite escolher origem, tamanho, DF bit e repetições
ping
! Traça a rota até o destino, exibindo cada salto
traceroute 192.168.20.1
! Verifica a tabela ARP para mapeamento IP -> MAC
show ip arp
! Verifica o status dos protocolos de roteamento configurados
show ip protocols
! Verifica vizinhos OSPF e o estado das adjacências
show ip ospf neighbor
! Verifica a base de dados OSPF para LSA tipo 1 e 2
show ip ospf database
! Verifica o binding DHCP para clientes atendidos
show ip dhcp binding
Router# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
O 10.2.2.0/24 [110/2] via 10.1.1.2, 00:15:32, GigabitEthernet0/0
O IA 10.3.3.0/24 [110/3] via 10.1.1.2, 00:15:32, GigabitEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.254/32 is directly connected, GigabitEthernet0/1
S* 0.0.0.0/0 [1/0] via 192.168.1.1
Na saída acima, observe a presença de rotas conectadas (código C), locais (código L), rotas OSPF internas (código O), rotas inter-área OSPF (código O IA) e uma rota estática padrão (código S*). O campo entre colchetes nas rotas dinâmicas, como [110/2], indica respectivamente a distância administrativa e a métrica da rota. A distância administrativa de 110 é típica do OSPF, enquanto a métrica de 2 sugere que o destino está a dois saltos de distância em enlaces com custo unitário.
O traceroute é outro instrumento valioso no Troubleshooting Cisco de camada 3. Diferentemente do ping, que apenas confirma se o destino responde, o traceroute revela o caminho completo percorrido pelos pacotes, identificando exatamente em qual salto ocorre a perda ou o atraso. Em redes com caminhos redundantes, o traceroute também revela se o tráfego está seguindo um caminho subótimo, o que pode indicar problemas de configuração de protocolo de roteamento ou de métricas incorretas.
Utilizando Comandos debug com Segurança no Troubleshooting Cisco
Os comandos debug são a ferramenta mais poderosa e, ao mesmo tempo, a mais perigosa do arsenal de Troubleshooting Cisco. Eles ativam a geração de mensagens detalhadas em tempo real sobre eventos específicos do sistema, permitindo observar o comportamento interno de protocolos como OSPF, EIGRP, BGP, DHCP, ARP e muitos outros. No entanto, cada comando debug consome ciclos de CPU para gerar e exibir essas mensagens, e em equipamentos de produção com alto volume de tráfego, um debug mal escolhido pode sobrecarregar o processador e causar degradação de desempenho ou até mesmo a perda de conectividade com o próprio dispositivo.
Antes de ativar qualquer debug, você deve seguir três regras fundamentais. Primeira: verifique a carga atual do processador com show processes cpu sorted e a utilização de memória com show memory summary. Se a CPU já estiver acima de 50%, evite comandos debug pesados. Segunda: utilize filtros para restringir a saída apenas ao tráfego relevante. O Cisco IOS oferece access-lists que podem ser associadas a comandos debug, limitando as mensagens geradas apenas aos pacotes que correspondem ao critério definido. Terceira: sempre execute undebug all ou no debug all imediatamente após concluir a coleta de informações para desativar todos os comandos debug ativos.
! ============================================================
! TROUBLESHOOTING CISCO - COMANDOS DEBUG COM SEGURANÇA
! Verificando a carga do sistema antes do debug
! ============================================================
! Verifica os processos que mais consomem CPU
show processes cpu sorted
! Verifica a utilização de memória do equipamento
show memory summary
! Verifica quais comandos debug estão ativos no momento
show debug
! Cria uma access-list para filtrar apenas o tráfego de interesse
! Neste exemplo, apenas pacotes de/para o host 192.168.10.50
access-list 100 permit ip any host 192.168.10.50
access-list 100 permit ip host 192.168.10.50 any
! Ativa o debug de pacotes IP aplicando a access-list como filtro
debug ip packet 100
! Ativa o debug de ICMP para observar pings e mensagens de erro
debug ip icmp
! Ativa o debug de eventos de roteamento OSPF (adjacências, SPF)
debug ip ospf events
! Ativa o debug de pacotes hello do OSPF
debug ip ospf hello
! DESATIVA TODOS OS COMANDOS DEBUG ATIVOS
undebug all
! Ou, alternativamente
no debug all
Router# show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 2%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 1234 1000 1234 0.00% 0.00% 0.00% 0 Chunk Manager
23 56789 23456 2421 0.50% 0.30% 0.25% 0 IP Input
45 12345 6789 1819 0.20% 0.15% 0.10% 0 OSPF Router
67 8901 3456 2576 0.10% 0.08% 0.05% 0 ARP Input
Router# debug ip icmp
ICMP packet debugging is on
Router#
*Sep 4 14:32:01.123: ICMP: echo reply sent, src 192.168.10.1, dst 192.168.10.50
*Sep 4 14:32:02.456: ICMP: echo reply sent, src 192.168.10.1, dst 192.168.10.50
*Sep 4 14:32:03.789: ICMP: echo reply sent, src 192.168.10.1, dst 192.168.10.50
*Sep 4 14:32:05.012: ICMP: destination unreachable: port unreachable, src 192.168.10.50, dst 192.168.20.1
Router# undebug all
All possible debugging has been turned off
Observe na saída que antes de ativar o debug, a utilização de CPU estava em apenas 2%, indicando que o equipamento tinha folga suficiente para suportar a execução dos comandos. Durante o debug de ICMP, cada evento gerado recebeu um timestamp preciso (*Sep 4 14:32:01.123), permitindo correlação temporal com eventos observados em outros equipamentos. A mensagem destination unreachable: port unreachable é um achado importante: indica que o host de origem alcançou o destino, mas o destino não tinha aplicação escutando na porta solicitada — um problema de camada 4 ou 7, não de roteamento.
Troubleshooting Cisco de Roteamento Dinâmico — OSPF e EIGRP
Falhas em protocolos de roteamento dinâmico estão entre as mais desafiadoras do Troubleshooting Cisco, pois os sintomas podem ser intermitentes e as causas sutis. No OSPF, por exemplo, a ausência de uma adjacência entre vizinhos pode ter dezenas de causas distintas: incompatibilidade de Hello/Dead timers, áreas configuradas incorretamente, MTU mismatch, autenticação incompatível, IDs de roteador duplicados ou até mesmo a ausência de uma interface na declaração network do processo OSPF.
O diagnóstico começa sempre com show ip ospf neighbor, que lista todos os vizinhos OSPF conhecidos e o estado de cada adjacência. Um estado FULL indica adjacência formada com sucesso, enquanto INIT, EXSTART ou 2-WAY indicam que a negociação está em andamento ou travada em algum estágio específico. O estado DOWN sugere que nenhum pacote Hello está sendo recebido — um problema de camada 1, 2 ou de configuração de área. O comando show ip ospf interface complementa o diagnóstico exibindo os parâmetros OSPF configurados em cada interface, incluindo área, timers, prioridade e tipo de rede.
No EIGRP, o diagnóstico segue lógica semelhante. O comando show ip eigrp neighbors lista os vizinhos EIGRP e o estado de cada adjacência, enquanto show ip eigrp topology revela a tabela de topologia com todas as rotas viáveis e as métricas associadas. Um problema específico do EIGRP é a condição de stuck in active (SIA), que ocorre quando uma rota é perdida e nenhum vizinho responde às consultas de rota dentro do tempo limite. O log DUAL-3-SIA indica essa condição, que pode ser causada por links congestionados, CPUs sobrecarregadas ou problemas de MTU impedindo a troca adequada de pacotes de consulta e resposta.
! ============================================================
! TROUBLESHOOTING CISCO - OSPF
! Verificando adjacências e parâmetros de interface
! ============================================================
! Lista todos os vizinhos OSPF e o estado de cada adjacência
show ip ospf neighbor
! Exibe parâmetros OSPF de todas as interfaces habilitadas
show ip ospf interface
! Exibe o banco de dados OSPF completo
show ip ospf database
! Exibe eventos recentes do processo OSPF
show ip ospf events
! Verifica rotas OSPF instaladas na tabela de roteamento
show ip route ospf
! ============================================================
! TROUBLESHOOTING CISCO - EIGRP
! ============================================================
! Lista os vizinhos EIGRP e o estado das adjacências
show ip eigrp neighbors
! Exibe a tabela de topologia EIGRP com métricas
show ip eigrp topology
! Verifica rotas EIGRP na tabela de roteamento
show ip route eigrp
! Exibe estatísticas de pacotes EIGRP enviados/recebidos
show ip eigrp traffic
Router# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.10.10.2 1 FULL/DR 00:00:35 192.168.1.2 GigabitEthernet0/1
10.10.10.3 1 FULL/BDR 00:00:38 192.168.1.3 GigabitEthernet0/1
10.10.10.4 0 2-WAY/DROTHER 00:00:32 192.168.1.4 GigabitEthernet0/1
Router# show ip ospf interface gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.1/24, Area 0
Process ID 1, Router ID 10.10.10.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.10.10.1, Interface address 192.168.1.1
Backup Designated router (ID) 10.10.10.3, Interface address 192.168.1.3
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 10.10.10.2 (Designated Router)
Adjacent with neighbor 10.10.10.3 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Na saída acima, observe que o roteador possui três vizinhos OSPF descobertos na interface GigabitEthernet0/1. O vizinho 10.10.10.2 está no estado FULL/DR, o vizinho 10.10.10.3 está em FULL/BDR e o vizinho 10.10.10.4 está em 2-WAY/DROTHER. Em uma rede broadcast, todos os roteadores formam adjacência FULL apenas com o DR e o BDR; entre si, os DROTHER permanecem em estado 2-WAY, o que é completamente normal e esperado. Um estado EXSTART persistente, por outro lado, apontaria para um MTU mismatch entre os vizinhos — uma das causas mais comuns de travamento de adjacência OSPF.
Troubleshooting Cisco de DHCP, ARP e Serviços de Rede
Problemas de atribuição de endereços IP são responsáveis por uma parcela significativa dos chamados de suporte em redes corporativas. O Troubleshooting Cisco de DHCP em equipamentos IOS envolve verificar a configuração do serviço, o estado dos binds e o fluxo de pacotes entre cliente e servidor. O comando show ip dhcp pool exibe todas as pools configuradas, os ranges de endereços e o estado de utilização de cada uma. Já show ip dhcp binding lista as atribuições ativas, permitindo identificar se um cliente específico obteve endereço, qual IP foi atribuído e por quanto tempo o lease é válido.
O protocolo ARP é outro ponto crítico de falha em redes IP. Problemas de ARP se manifestam tipicamente como conectividade intermitente, onde alguns hosts conseguem comunicar e outros não, ou onde a comunicação funciona em uma direção mas não na outra. O comando show ip arp exibe a tabela ARP do equipamento, mapeando endereços IP a endereços MAC. Uma entrada ARP incorreta — causada por conflito de IP, ataque de ARP spoofing ou configuração errada de sub-rede — pode direcionar o tráfego para o destino errado silenciosamente. O comando debug arp permite observar em tempo real as requisições e respostas ARP processadas pelo equipamento.
! ============================================================
! TROUBLESHOOTING CISCO - DHCP E ARP
! Verificando serviços de atribuição de IP e resolução
! ============================================================
! Exibe todas as pools DHCP configuradas e estatísticas de uso
show ip dhcp pool
! Lista todos os bindings DHCP ativos (IP, MAC, lease)
show ip dhcp binding
! Exibe estatísticas de mensagens DHCP processadas
show ip dhcp server statistics
! Exibe conflitos de endereço detectados pelo servidor DHCP
show ip dhcp conflict
! Exibe a tabela ARP do equipamento
show ip arp
! Ativa o debug de ARP (use com cautela em redes grandes)
debug arp
! Ativa o debug do servidor DHCP (eventos de atribuição)
debug ip dhcp server events
! Ativa o debug detalhado de pacotes DHCP
debug ip dhcp server packet
! Desativa todos os debugs
undebug all
Router# show ip dhcp pool
Pool LAN_CLIENTES :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 47
Excluded addresses : 10
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
192.168.10.1 192.168.10.10 - 192.168.10.253 47 / 10 / 254
Router# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.10.10 0100.0c29.1234.56 Sep 05 2026 08:30 AM Automatic
192.168.10.11 0100.0c29.5678.90 Sep 05 2026 09:15 AM Automatic
192.168.10.12 0100.0c29.abcd.ef Sep 05 2026 10:45 AM Automatic
Router# show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.10.1 - aabb.cc00.0100 ARPA GigabitEthernet0/0
Internet 192.168.10.10 5 0000.0c29.1234 ARPA GigabitEthernet0/0
Internet 192.168.10.11 12 0000.0c29.5678 ARPA GigabitEthernet0/0
Internet 192.168.10.50 0 0000.0c29.9999 ARPA GigabitEthernet0/0
Na saída acima, a pool LAN_CLIENTES está com 47 endereços alugados de um total de 254 disponíveis, indicando que o serviço DHCP está operacional. Os bindings mostram três clientes ativos com leases válidos até o dia seguinte, e a tabela ARP está populada com os mapeamentos corretos. Se um cliente relatar que não obtém endereço IP, você deve verificar se a pool correspondente à sua VLAN existe, se há endereços disponíveis, se a interface de atendimento está com estado up/up e se o comando ip helper-address está configurado corretamente nos switches para encaminhar broadcasts DHCP entre VLANs.
Syslog e Monitoramento Contínuo no Troubleshooting Cisco
O syslog é a memória viva de um equipamento Cisco e uma fonte inestimável de informações para o Troubleshooting Cisco. Cada evento significativo do sistema — interfaces que sobem ou caem, adjacências que formam ou se perdem, alterações de configuração, falhas de hardware — gera uma mensagem de log com um nível de severidade que varia de 0 (emergências) a 7 (debugging). O comando show logging exibe o buffer de logs local do equipamento, enquanto o encaminhamento para um servidor syslog externo garante que os logs sejam preservados mesmo se o equipamento falhar ou for reinicializado.
Configurar syslog para um servidor central é prática obrigatória em qualquer ambiente de produção. Nos projetos de infraestrutura que implementamos na JRT Technology Solutions, todos os equipamentos Cisco são configurados para enviar logs nível 6 (informational) ou superior para um coletor central, permitindo que a equipe de operação monitore eventos de todos os dispositivos em uma única interface. O comando logging host <endereço> define o destino, enquanto logging trap <nível> define o filtro de severidade. Para que os timestamps sejam úteis, o relógio do equipamento deve estar sincronizado via NTP, como mencionado nos pré-requisitos.
! ============================================================
! TROUBLESHOOTING CISCO - SYSLOG E MONITORAMENTO
! Configurando e verificando o registro de eventos
! ============================================================
! Entra no modo de configuração global
configure terminal
! Ativa o logging de mensagens para o buffer local
! Buffer de 16384 bytes armazenará eventos mesmo sem servidor externo
logging buffered 16384 6
! Define o envio de logs para um servidor syslog externo
logging host 192.168.100.50
! Define o nível de severidade mínimo para envio ao servidor
! Nível 6 (informational) inclui eventos informativos e superiores
logging trap 6
! Marca a origem dos logs com o hostname do equipamento
logging origin-id hostname
! Habilita timestamps detalhados com precisão de milissegundos
service timestamps log datetime msec localtime show-timezone
! Sai do modo de configuração global
end
! Verifica a configuração de logging e o conteúdo do buffer
show logging
! Exibe apenas as últimas 20 mensagens de log
show logging | last 20
! Exibe mensagens de log que contenham a palavra "error"
show logging | include error
Router# show logging
Syslog logging: enabled (0 messages dropped, 2 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: level debugging, 1234 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level informational, 1234 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
Logging to 192.168.100.50 (udp port 514, audit disabled,
link up),
567 message(s) logged,
0 message(s) rate-limited,
0 message(s) dropped by MD5,
xml disabled, filtering disabled
Log Buffer (16384 bytes):
*Sep 4 08:15:00.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
*Sep 4 08:15:01.234: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down
*Sep 4 08:15:45.567: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Sep 4 08:16:10.890: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on GigabitEthernet0/1 from DOWN to INIT, Loading Done
*Sep 4 08:16:12.345: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on GigabitEthernet0/1 from INIT to FULL, Loading Done
A saída acima revela uma sequência de eventos extremamente informativa. Às 08:15:00, a interface GigabitEthernet0/2 caiu, levando consigo o protocolo de linha. Quarenta e cinco segundos depois, uma adjacência OSPF com o vizinho 10.10.10.2 expirou devido ao Dead timer expired — uma consequência direta da queda da interface que conectava os dois roteadores. Às 08:16:10, a adjacência foi reestabelecida após a interface voltar a operar. Essa correlação temporal entre eventos é exatamente o que torna o syslog tão valioso no Troubleshooting Cisco: ele permite reconstruir a sequência de eventos que levou a uma falha e identificar a causa raiz com precisão.
Verificando a Instalação / Testando a Configuração
Após aplicar qualquer correção ou ajuste de configuração em um cenário de troubleshooting, é obrigatório validar se o problema foi efetivamente resolvido e se nenhum efeito colateral foi introduzido. Esta seção apresenta o roteiro completo de verificação pós-correção que utilizamos em nossos atendimentos na JRT Technology Solutions. O objetivo é confirmar que a conectividade foi restaurada, que os protocolos estão estáveis e que o equipamento permanece saudável após as alterações.
! ============================================================
! VERIFICAÇÃO COMPLETA PÓS-CORREÇÃO
! Roteiro de validação após troubleshooting Cisco
! ============================================================
! 1. VERIFICAÇÃO DE CONECTIVIDADE BÁSICA
! Testa conectividade com o gateway local
ping 192.168.10.1 source 192.168.10.50 repeat 10
! Testa conectividade com um destino remoto na rede
ping 192.168.20.50 source 192.168.10.50 repeat 10
! Testa conectividade com um destino externo (Internet)
ping 8.8.8.8 source 192.168.10.50 repeat 5
! 2. VERIFICAÇÃO DE ROTEAMENTO
! Confirma a presença das rotas esperadas na tabela
show ip route
! Confirma a rota padrão
show ip route 0.0
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Cisco IOS para equipes corporativas.
