Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP

Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

Introdução

Este artigo toca num tema que frequentemente visita os bate-papos com amigos, nos eventos, e em grupos de discussão. Muitas das vezes o profissional está precisando resolver algum tipo de problema e não faz a menor idéia por onde começar.

Não mais! Este artigo de nossa Wiki foi elaborado especialmente para você, profissional que sente dificuldades ao tentar resolver problemas na sua rede! Espero que curta a abordagem e didática aqui empregados!

Afinal de contas, o que é o troubleshooting?

Troubleshooting é o conjunto de ações orientadas à resolução de problemas na infraestrutura de redes, computadores, sistemas ou serviços correlatos. O seu único propósito é o de sanar o problema, restaurando assim o bom funcionamento do equipamento, rede, sistema ou serviço afetado, preferencialmente em tempo hábil e sem causar distúrbios adicionais para os usuários no decorrer do processo.

O troubleshooting consiste de ações de definição, análise, diagnóstico e reparo, e fazendo isto devidamente com auxílio de processos, ferramentas e boas práticas, sendo estas o foco deste artigo.

Troubleshooting de redes: a "arte suave"!

Roteiro recomendado para um troubleshooting mais efetivo

Todo o processo é dividido em três fases primárias, denominadas Problema, Diagnóstico e Solução. Cada uma destas fases possui etapas, e cada uma destas etapas contém um conjunto de ações específicas para o tratamento e condução do suporte ao problema. O que será mostrado a seguir é uma expansão dos conceitos de cada fase.

• Problema

Nesta fase, o principal objetivo é a definição do problema. As redes IP podem ser um tanto complexas em alguns ambientes, pois frequentemente empregam tecnologias em configurações mais sofisticadas e que agregam complexidade e dificuldades de entendimento para o cenário de suporte a problemas. Como a dinâmica para surgimento de problemas envolve diversas possibilidades para cada caso, fica impraticável por muitas vezes corrigir um problema sem causar outros problemas, ou resolver o problema em tempo hábil. Uma coisa é certa: uma hora ou outra o problema será resolvido!

As questões aqui na verdade são: a) você conseguirá resolver o problema em tempo hábil, buscando minimizar os impactos para o negócio? b) você conseguirá resolver o problema sem causar distúrbios adicionais (graves ou não) para o ambiente?

Isto tudo pode ser evitado em grande parte através da correta definição do problema.

• Diagnóstico

Tão importante quanto definir o problema é saber diagnosticá-lo o mais precisamente possível. A proposta desta fase é conduzir diagnósticos efetivos alimentados pelas conclusões obtidas na fase "Problema" supracitada. Uma vez que você for capaz de compreender o problema com clareza (ou seja, defini-lo), você estará apto para iniciar o trabalho de coleta de informações e análises correspondentes com o intuito de identificar a causa-raiz e de completar o seu diagnóstico com maior clareza.

A qualidade da definição do problema impactará positiva ou negativamente o seu diagnóstico. Por onde começar o seu diagnóstico? Qual equipamento você acessará primeiro para coletar informações? Quais áreas funcionais da configuração e operação daquele equipamento deverão ser verificadas em primeira e segunda instâncias? Quais deverão ser as suas expectativas de comparação, contraste e constatação?

• Solução

Bastante óbvio... certo? Esta fase promoverá a correção do problema que: a) foi definido/compreendido corretamente, b) foi analisado e diagnosticado corretamente.

Na verdade, é mais que isso. Bem mais que isso. É resolver o problema com qualidade de ações, atitude e responsabilidade.

Esta fase constitui na correção do problema de forma mais cirúrgica, e não "matar uma barata com bala de canhão" como ocorre em muitos casos. Será nesta fase que você determinará o roteiro de correção do problema, as implicações e riscos associados com as manobras corretivas, ou seja, se a manobra de correção apresenta riscos de indisponibilidades parciais ou totais em caráter temporário, isto é, se haverá mais impacto ou não no ambiente para resolver aquele problema. E será nesta fase que você validará a necessidade de abertura de GMUD em caráter emergencial, se deverá haver um plano de comunicação com gestores e clientes, definir o plano de validação e rollback, dentre outras iniciativas.

Fases do processo de troubleshooting: Definição, Diagnóstico, Solução

Etapas da fase "Problema"

Verifiquemos o roteiro esmiuçado e recomendado da fase "Problema".

Defina o problema

O mal que assola a humanidade, e em praticamente todas as áreas de interação: fornecer soluções para problemas que não compreendemos adequadamente. Isto pode dar certo, ou pode dar (muito) errado.

Isto é muito válido no universo da tecnologia da informação e comunicação (TIC), em especial quando algum problema ocorre na infraestrutura e o analista sai disparando comandos, configurações, etc., no intuito de corrigir um problema que ele mesmo não sabe exatamente o que é ou como surgiu! Isto consome tempo e recursos, além de contribuir para o estresse e esgotamento emocional das equipes de suporte, principalmente em ambientes onde há aquela "panela de pressão". Quem nunca sentiu-se pressionado, estressado, frustrado, desmotivado, quando atuando sob pressão de clientes e de gestores?

Mas há outros problemas associados aos modelos de suporte rápidos e pouco estruturados, ou seja a abordagem de suporte "à bangu":

1. As correções em muitos casos provocam desvios dos padrões estabelecidos pela Engenharia da empresa.
   1. Com o tempo, os padrões das configurações dos elementos de rede tendem a divergir razoavelmente daqueles que correspondem às práticas aprovadas. E você começa a bagunçar com a configuração dos dispositivos da rede. E isto é péssimo!
   2. Isto acarreta no aumento da complexidade operacional e dificulta as ações de manutenção das documentações e demais procedimentos operacionais. Como manter a documentação da rede sincronizada e consistente nestas circunstâncias?
2. Aumenta substancialmente o risco decorrentes de falha humana durante estas ações de suporte "impensadas". Ou seja, durante uma atividade de suporte, você poderá, acidentalmente, agravar a situação!

A parte mais crítica do processo de resolução de problemas ("troubleshooting") é a condução de uma análise adequada com o objetivo de definição do problema. Algumas sugestões de ações cabíveis neste estágio tão importante:

• Descrição do Problema ("título")
  • Além de data e hora do surgimento do problema - quando o problema foi notado ou comunicado por usuários/clientes e/ou pela equipe de operação?
• Escopo do Problema
  • Quais serviços da rede estão sendo afetados? Por exemplo:
    • Wireless corporativo ou de convidados, acesso à Internet de usuários banda larga, acesso à Internet de usuários corporativos, acesso a websites ou serviços específicos, etc.
  • Fator de indisponibilidade associado ao problema:
    • 100% indisponível?
    • Parcialmente indisponível?
    • Problema de natureza intermitente?
    • Lentidão apenas?
  • Locais afetados pelo problema:
    • Prédios/sites, andares, departamentos/setores, sites, pops, e os usuários ou clientes espalhados nestes
    • Segmentos lógicos afetados, do conceito lógico do projeto
      • VLANs específicas? Subredes específicas? Servidores específicos? Aplicações específicas?
      • Perímetros específicos, tais como usuários autenticados em um BNG/BRAS específico, usuários de um anel Metro, usuários atendidos por um roteador PE específico, etc.
• Análise temporal do problema - quanto à detecção e recebimento da notificação ou relato do problema
  • Quando o problema surgiu pela primeira vez, isto é, quando a equipe de TI foi acionada?
  • Algum analista estava realizando alguma configuração ou modificação em algum equipamento da rede?
  • Há registros de mudanças recentes que coincidam com o surgimento do problema? (ex: revisão dos logs de TACACS+ ou registros internos de GMUD)
    • Caso afirmativo, qual é a probabilidade de relevância das alterações que foram realizadas com o problema reportado?
      • É factível considerar rollback, caso esta análise indique alta probabilidade.
  • É um problema recorrente, ou seja, ocorre com alguma frequência em sua rede?
  • Dentre outras iniciativas e questionamentos desta natureza.

Este pequeno roteiro embarca fatores tais como escopo temporal + perímetro + qualitativo + quantitativo, fomentando toda a lógica de análise preliminar e a devida compreensão do problema, ou seja, trazendo à tona todas as informações que você precisa saber para definir o problema! A qualidade das confirmações das situações e contextos acima ditará o seu grau de sucesso no troubleshooting nas etapas posteriores.

Isto é o que chamamos de Abordagem de Troubleshooting Estruturado, ao oposto dos métodos pouco ortodoxos (“from the hip” ou "à bangu") usados por muitos ou pela maioria dos analistas.

Etapas da fase "Diagnóstico"

Verifiquemos o roteiro esmiuçado e recomendado da fase Diagnóstico.

Colete informações

Com a definição do problema realizada com êxito, aqui você buscará coletar as informações necessárias para promover um diagnóstico efetivo do problema. Os equipamentos que você deverá acessar e as respectivas áreas funcionais a serem inspecionadas, enfim, tudo isto dependerá das informações obtidas durante a definição do problema. Já neste estágio, você deverá saber quais tecnologias (protocolos, serviços) deverão ser verificadas e em quais equipamentos você deverá conduzir estas verificações inicialmente.

Aqui você analisará logs, processos, CPU, memória, filas, buffers, interfaces, VLANs, tabelas MAC, ARP cache, vizinhanças/adjacências de protocolos de roteamento, estruturas de dados dos protocolos de roteamento, tabela de roteamento, ACLs, policies de BGP ou IGP, NAT, e tantos outros, mas tudo aquilo e somente os componentes que tiverem relação ou conexão parcial ou total com a definição do problema.

Analise as informações coletadas

Na medida em que a coleta de informações vai desenrolando-se, você deverá traçar uma estratégia de análise para cada componente inspecionado. Em outras palavras, saber exatamente o que olhar e o que verificar em cada situação coletada. Isto inclui estado das interfaces, erros nas interfaces, configuração das interfaces (endereços IP, MTU, etc.), configurações e estados VLAN/802.1Q/STP/etc., configurações e estados de protocolos de roteamento (métricas, áreas, autenticações, políticas, filtros, adjacências, etc.), rotas na tabela de roteamento, serviços diversos e que por ventura se façam presentes (ex: port security, DHCP Snooping, DAI, IPSG, IP SLA, PBR, PPPoE, NAT, QoS/policy, o que for.. etc.), e assim por diante.

Obviamente isto exigirá bons conhecimentos sobre cada uma das tecnologias mantidas nas coletas que você realizou, como elas funcionam, como interagem, e quais são os requisitos de integração de cada uma destas tecnologias.

Elimine hipóteses

Das informações que você coletou, e após efetuar as análises preliminares, você deverá saber identificar o que certamente não contribui para o problema, ou o que não promoveu participação para o surgimento do problema.

O foco é o seguinte: tudo o que não for relacionado ao problema deverá ser desconsiderado.

A idéia aqui é fazer você ir ao campo de batalha com as armas necessárias apenas e com, no máximo, 3 possibilidades de ações visando a correção do problema. Como costumamos afirmar, “não adianta dar tiro pra tudo quanto é lado”, pois, além de levar muito mais tempo, é pouco efetivo, confunde, e pode causar outros e indesejáveis problemas, além do estresse emocional já comentado. Procure ser cirúrgico na hora de eliminar possibilidades, pois não adianta você encaminhar "10 possibilidades" para a fase de solução!

Etapas da fase "Solução"

Verifiquemos o roteiro esmiuçado e recomendado da fase Solução.

Proponha hipóteses

Em muitos casos você pode ter sido muito eficiente ou ter tido sorte, pois o problema foi fácil de diagnosticar! Isto é, você definiu bem o problema, fez as análises devidas, e, num piscar de olhos, conseguiu identificar a causa-raiz do problema!

No entanto, em muitos casos, poderão restar dúvidas, pois o diagnóstico do problema em questão talvez possa ser mais complexo e exigir mais conhecimentos por parte do analista, mas que, mesmo assim, você acredita que o problema esteja relacionado a duas ou três possibilidades, cujas interpretações são decorrentes da análise de informações e eliminação de hipóteses. Neste caso, a sugestão aqui é a de propor as hipóteses restantes devidamente classificadas por fidelidade (com o problema) versus o risco e esforço de implementação da correção.

Por exemplo, você tem duas hipóteses para resolver um determinado problema: uma delas, aparentemente a mais óbvia de ser o problema, mas que você não tem muita certeza ainda, exige uma manobra que provocará algum distúrbio na rede, tipo uma indisponibilidade. Já a segunda hipótese, menos provável de ser o problema, exige uma manobra corretiva mais rápida e que ainda apresenta zero risco para o negócio. Em razão disto, você poderá optar por aplicar a hipótese #2 e, caso não dê certo, fazer o rollback, e agendar a manobra necessária para a execução da hipótese #1, seja em caráter emergencial ou em horário apropriado, dependendo da urgência para o saneamento do problema no seu caso.

Testar hipóteses

É exatamente aqui que você conduzirá as ações especificamente corretivas. Não saia mexendo em vários componentes de uma vez só! Seja organizado e tenha o controle absoluto da situação. Isto significa que você deverá implementar uma única ação corretiva (hipótese) por vez, sabendo que, em muitos casos, uma única hipótese poderá exigir a intervenção de uma ou mais tecnologias e em um ou mais equipamentos. Execute o procedimento com cautela, e faça as validações devidas para confirmar a correção do problema. Certifique-se que a manobra não tenha causado outros problemas (as vezes resolve “aquele” problema, mas pode afetar outras coisas na rede).

Não funcionou? Desfaça a alteração e implemente a próxima hipótese, ou, caso o problema não tenha sido corrigido, mas a correção (que não deu certo) é necessária mesmo assim, talvez esteja faltando conhecimentos para resolver o problema ou que talvez algum componente adicional tenha ficado de fora. Ou você (talvez) não tenha sido eficiente durante a coleta e análise de informações.

É a parte mais difícil de todo o processo de suporte, por isto que insisto que você seja bem efetivo nos estágios anteriores, justamente para atenuar a complexidade de compreensão, diagnóstico e correção do problema aqui, neste estágio.

Problema Resolvido

Aqui você celebrará a resolução do problema! Aliás, não somente isto, aproveite a oportunidade para documentar o problema e a solução empregada, e fazendo isto em uma base de conhecimentos que poderá servir para capacitar os times de suporte para que o problema em questão possa ser evitado futuramente, ou, caso haja nova ocorrência, ter a solução ou correção implementada em menor prazo e esforço.

Todas estas etapas podem ser representadas visualmente conforme mostrado a seguir:

Abordagens para o troubleshooting estruturado

Como prestar um suporte técnico de alto nível para a sua empresa

Convenhamos, algumas redes são relativamente grandes e contam com uma diversidade bem razoável de equipamentos e tecnologias. Em adição, alguns projetos técnicos são razoavelmente ousados e complexos, especialmente em ambientes com boa redundância e proteção do plano de controle, dentre outras sofisticações. Saber exatamente quais equipamentos acessar, quais tecnologias verificar, e em qual ordem isto deverá ser feito, isto tudo exige algumas coisas por parte do analista.

Certifique-se de cumprir com as seis dicas a seguir para elevar o seu padrão de suporte a problemas na rede para o nível Black Belt (faixa-preta)!

1. Conheça bem o seu próprio ambiente
2. Conheça as tecnologias utilizadas na sua infraestrutura
3. Conheça os padrões de configuração utilizados pelas áreas de engenharia e operação
4. Conheça os estados operacionais desejados para as áreas funcionais da sua infraestrutura
5. Domine as boas práticas de suporte a problemas na rede (foco deste artigo aqui)
6. Antecipe problemas com processos consistentes de prevenção de falhas e recuperação de desastres

Tratemos cada um destes pontos isoladamente.

Conheça bem o seu próprio ambiente

Aqui é onde eu vejo com muita frequência alguns "absurdos" e em várias empresas Brasil afora. Profissionais com mais de um ano "de casa" e que não conhecem detalhes fundamentais sobre os seus próprios ambientes! Surreal!

Amigo, sendo franco aqui, se eu contrato um profissional para operar a minha rede, é obrigação daquele profissional de dedicar o tempo necessário para estudar e compreender o meu/seu ambiente, documentar e revalidar todo e qualquer "parafuso" presente, e saber dissertar sobre cada componente necessário para a viabilidade dos serviços ofertados para clientes internos e externos. E isto dentro do escopo de atribuições daquele profissional, nada mais e nada menos. E não é o que eu vejo por aí na maioria dos casos, infelizmente.

Quer aprender bem sobre redes? Ótimo! Comece aprendendo sobre a sua rede, o seu ambiente.

Eu vejo com alguma frequência pessoas desprendendo um tempo bem razoável em aprender uma tecnologia ou uma solução que sequer faz parte da infraestrutura ou da realidade do projeto técnico da empresa, enquanto este mesmo profissional sequer conhece profundamente o seu próprio "quintal"! Aprender coisas novas é luxo para aqueles que já dominam os seus próprios ambientes; conhecem bem sobre tudo aquilo que estiver embarcado nele.

Antes de você sair aventurando-se no universo de tecnologias de rede sem um propósito, foque em dominar o seu próprio ambiente, seja ele bom (sólido) ou ruim. É para isto que você é pago, e há uma expectativa de resultados associados ao seu desempenho em implementar recursos, operar o seu próprio ambiente e resolver problemas. Isto deverá ser a sua prioridade. Com o tempo você poderá aventurar-se em outras áreas e tecnologias que ainda não façam parte da realidade da empresa. Publicarei um artigo em breve na Wiki do BPF para estudarmos este tema com maior profundidade.

Como sugestão para esta questão de "conhecimentos sobre o seu próprio ambiente", também comprometo-me em publicar outros artigos para falarmos somente disto. Por hora, recomendo que você dedique o seu tempo em documentar e estudar o seu próprio ambiente. Neste quesito, recomendo a leitura do seguinte artigo, da Wiki do BPF: Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor.

Conheça as tecnologias utilizadas na sua infraestrutura

Como resolver um problema de OSPF, se você só sabe configurar o básico de OSPF e, mesmo assim, porque alguém na empresa, ou em algum lugar, compartilhou seus padrões de configuração da sua rede?

Se você não sabe apropriadamente como este protocolo funciona, quais são os seus pacotes ou mensagens, como estas mensagens são transportadas através da rede, as estruturas de dados mantidas pelo protocolo, os requerimentos para formação de adjacências, etc. Então, como você poderá ser garantidamente efetivo na resolução de problemas do OSPF? Só se for na base do "chutômetro" ou de alguma coisa muito óbvia!

Como resolver um problema relacionado ao BGP, se você desconhece a sua operação e mecanismos mais básicos? (dica: dê uma conferida no artigo O Mínimo que Você precisa saber sobre o BGP para você confirmar o quanto você não sabe sobre o BGP, este mesmo aí que roda na sua rede...).

Para você ser realmente eficiente na resolução de problemas na sua rede, você precisará, nesta ordem:

1. Documentar ou revalidar a documentação da sua rede, incluindo o projeto lógico, padrões, diagramas, etc. Ou seja, passar efetivamente a conhecer/dominar a sua própria rede.
2. Revalidar os seus conhecimentos sobre cada tecnologia utilizada pela sua infraestrutura. Você identificará tecnologias aqui que não domina ainda, então você poderá preparar-se em termos de estudos e revisões.

A minha recomendação neste caso é que você una as duas coisas: conheça a sua própria rede e estude as tecnologias presentes no seu ambiente.

Isto fará toda a diferença na qualidade e agilidade do seu suporte a problemas no seu ambiente.

Conheça os padrões de configuração utilizados pelas áreas de engenharia e operação

Uma coisa é conhecer bem ou muito bem uma tecnologia, tipo um protocolo ou serviço de rede. Outra é compreender os critérios e padrões quanto à utilização daquela tecnologia no seu ambiente. São duas coisas distintas. Para exemplificar isto bem, as práticas de configuração e manutenção do BGP da sua empresa anterior podem ser bastante distintas das práticas e padrões usados no BGP da sua empresa atual. Obviamente que experiência conta, claro! Mas, antes de você sair fazendo "do seu jeito", certifique-se dos padrões vigentes adotados pela empresa.

Alguns ambientes possuem padrões específicos que foram selecionados e afirmados por alguém, ou por um setor inteiro da empresa (ex: Engenharia). Caberá à você confirmar os padrões de configuração destas tecnologias em sua infraestrutura. Procure entender o "por que" de cada bloco da configuração dos elementos. Isto assegurará consistência no seu trabalho de provisionamento e suporte de serviços, e até mesmo melhorará os seus conhecimentos acerca destas mesmas tecnologias em muitos casos. Você evolui ao mesmo tempo em que passa a ser muito útil para a empresa, especialmente no momento em que problemas acontecerem.

E, obviamente, haverá uma oportunidade aqui para você encaminhar sugestões para aprimoramentos ou refinamentos destas configurações com base nos seus conhecimentos e experiência prévia, caso você domine o assunto em padrões ou moldes superiores aos encontrados no seu ambiente atual.

Conheça os estados operacionais desejados para as áreas funcionais da sua infraestrutura

De certa forma, um tanto redundante com relação à documentação da rede já discutida previamente. Só que aqui as necessidades ou objetivos são mais específicos: você quer (deve) tirar um "snapshot" do estado operacional das tecnologias (protocolos e serviços) em uso na sua rede!

Aproveite a oportunidade que a sua rede não está apresentando quaisquer problemas no momento para documentar este estado operacional "saudável", arquivar isto, e, posteriormente, poder identificar e confrontar problemas que surgirem no ambiente com este estado operacional de rede "saudável" que foi coletado/documentado. Esta atitude poderá ser extremamente útil quando problemas de alto impacto acontecerem na sua rede e você precisar de uma referência de estado operacional para nortear o seu diagnóstico de problemas!

Domine as boas práticas de suporte a problemas na rede

É o que justamente este artigo tenta promover. Métodos, conhecimentos, boas práticas. Prossiga com a leitura!

Antecipe problemas com processos consistentes de prevenção de falhas e recuperação de desastres

Aqui é onde eu vejo muito "vacilo" por parte dos analistas de redes! Muitos profissionais não dedicam o tempo necessário para estudar o "merdômetro" (não encontrei expressão mais irônica que esta para usar aqui...), que é a probabilidade de algum problema ocorrer no seu ambiente e o que você deverá fazer para:

1. Antecipar ou evitar o problema
2. Reagir cirurgicamente para sanar o problema, atenuando seus impactos, aborrecimentos e perdas para o negócio

Ou seja, o profissional fica "moscando" por meses e sem planejar uma resposta sequer a eventuais tipos de incidentes e, quando um problema grave ocorre, fica mais perdido que cego em tiroteio. É uma das situações que vejo muito frequentemente em empresas do setor de ISP de pequeno e médio portes.

Além de perder tempo apenas para entender ou compreender (definir) o problema, o analista desprenderá um tempo razoável nas ações de diagnóstico e reparo do problema, algo que poderia ter fluído muito mais rápida e efetivamente caso ele tivesse um plano de resposta pronto, em mãos. Sem contar que muitos dos problemas que geram aborrecimentos para clientes internos e externos podem (e devem!) ser evitados por completo, caso haja a correta identificação do risco durante os exercícios de planejamento de contingência da organização.

Você ou a sua empresa exercita cenários de falhas e determina impactos para o negócio? Não? Está na hora de você ou a sua empresa passar a fazer isto com seriedade, profissionalismo e compromisso.

Dica: conduza uma extensa e apropriada análise qualitativa de riscos para identificar quais problemas podem ser evitados ou antecipados, seus respectivos impactos quantificados (inclusive financeiros!), e faça um plano de contingência para descrever as ações necessárias para a resolução destes incidentes.

Método seguro: como refinar as suas habilidades de suporte à problemas em redes

Você poderá conduzir o processo de suporte com métodos próprios, mas isto dependerá do seu conhecimento acerca das tecnologias empregadas e do quanto você compreende sobre a sua própria rede, conforme comentado ou sugerido anteriormente.

O que disseminarei a seguir é extremamente útil para dois perfis de profissionais de redes que identifico frequentemente em diversas empresas: profissionais iniciantes e profissionais enferrujados.

O profissional "iniciante" seria um perfil tipo Nível 1 e que esteja começando na área, com pouco tempo de experiência. Já o "enferrujado", é aquele "macaco-velho" (Nível 2 ou 3, ou até mesmo um N1!) e que já está há alguns anos na empresa, mas que nunca parou para pensar como as coisas deveriam ser feitas e da melhor forma possível. Ou seja, aquele profissional que possui algum, bom ou ótimo conhecimento sobre algumas das tecnologias e configurações de seu próprio ambiente de redes, mas que nunca organizou o seu próprio trabalho a ponto de evitar e sanear problemas. E, em ambos os perfis, os profissionais frequentemente saem atirando para todos os lados quando um problema ocorre na rede.

Você identifica-se com um destes dois perfis? Então este artigo foi feito para você.

Na hora em que estiver coletando informações para uma análise de causa-raiz, você poderá partir para a linha de execução com os seguintes métodos didáticos. Em todos os casos, consideraremos o modelo de referência OSI para a condução destes métodos.

Métodos de condução do suporte ao problema na rede

De Cima a Baixo (Top-down)

Lembra-se das camadas do modelo de referência OSI? O seu trabalho será balizado por estas camadas! Por exemplo:

• Um problema para o qual que você está efetuando suporte diz que o usuário não consegue acessar um servidor Web interno.
• Você, então, a partir da VLAN/subrede do usuário, poderia realizar um telnet para a porta TCP 80 ou 443 do referido servidor.
  • Abriu (conectou)? Então você sabe que a VLAN/subrede do usuário está OK, portanto confirme que outros usuários na mesma VLAN consigam acessar o servidor pelo procedimento padrão (http ou https).
    • Se nenhum deles conseguir, o problema pode ser DNS, ou configurações do servidor Web, pois da camada de Transporte para baixo está definitivamente OK (em algumas raras exceções, pode ser a rede também).
  • Se não funcionar (a conexão com o servidor via telnet ip porta):
    • Se não há a conexão com a porta TCP correspondente à aplicação, o problema pode ser a aplicação no servidor, ou algum firewall no meio do caminho, ou falha na conectividade IP (camada de Rede), ou em camadas inferiores.
    • O próximo passo seria confirmar se há a conectividade IP da origem (VLAN/subrede dos usuários) até o destino, e vice-versa.
  • Neste caso você procederia com a validação das funções de roteamento da rede IP, usando procedimentos tais como ping, traceroute, e validação das rotas correspondentes nas tabelas de roteamento.
    • Caso o ping não funcione, possa ser que algum firewall no meio do caminho esteja bloqueando as mensagens ICMP. Resta então fazer uma validação das rotas necessárias para o cenário funcionar.
      • Caso estejam faltando rotas, o problema pode estar nos protocolos de roteamento, o que exigiria validações das vizinhanças/adjacências e configurações...
      • ... ou o problema pode estar em alguma camada inferior (L2 ou L1).
  • Caso não haja a vizinhança devida dos protocolos de roteamento, é possível que haja um problema com a camada de Enlace de Dados (L2) e, portanto, você teria que inspecionar as VLANs, tabelas MAC, entroncamentos 802.1Q, protocolos de resiliência L2, etc.
    • Caso não sejam identificados problemas nos componentes L2 diretamente, o problema pode estar na camada Física (L1).
      • As interfaces ou enlaces estão "Up"? Há contadores de erros nestas interfaces (ex: erros ou drops excessivos?).

Enfim, acho que você compreendeu a lógica de todo este processo Top-Down. Nesta abordagem, testamos as camadas de cima para baixo. A abordagem em si é muito segura, o único "problema" é que você terá que testar a pilha toda, de cima para baixo, o que pode levar mais tempo. Mas é um mal necessário, enfim.

De Baixo para Cima (Bottom-Up)

É justamente o inverso do Top-down. Aqui você testará tudo de baixo para cima: a interface ou link está Up? A porta tem erros? A máquina está na VLAN certa? A tabela MAC daquela VLAN mostra os endereços MAC do usuário e do default gateway? O endereço IP/máscara/default gateway está correto? Você consegue pingar o default gateway? Você consegue pingar o servidor? Onde morre o traceroute? Há rota para ir e rota para retornar? Você consegue fazer um Telnet na porta do servidor? E assim por diante...

Dividir para Conquistar (Divide and Conquer)

É o método mais rápido para se chegar lá, pois a proposta aqui é economizar tempo mesmo. Para iniciar, você poderá realizar um traceroute a partir da subrede de origem até o endereço IP de destino e identificar onde o teste "morre".

• Se todos os saltos forem reportados no traceroute, então você aparentemente não tem problemas na rede, pelo menos não no que diz respeito ao L3, L2 e L1. O problema pode estar relacionado a firewalls, outros dispositivos de segurança (ex: IPS), balanceador de carga, ou com o serviço do próprio servidor, etc.
• Se o traceroute "morrer" em algum salto, você então sabe que da subrede de origem até aquele salto onde o traceroute "morreu" não há problemas L1, L2 ou L3.
  • Daquele pondo em diante você fará então o Top-down ou Bottom-up.

Por exemplo, o usuário não acessa o servidor. Então, da VLAN deste usuário, ou diretamente da máquina dele, você faz um traceroute até o servidor, e verifica até onde o teste reporta como bem sucedido. Se pingar ou der OK no traceroute, tente o telnet na porta da aplicação. Se não funcionar, procure por firewalls ou outros tipos de dispositivos de segurança presentes no meio do caminho.

Agora, se o traceroute não for bem sucedido, vá até o último gateway que reportou OK no teste e verifique as configurações e modos operacionais daquele router (com Top-Down ou Bottom-Up), e use o Follow-the-Path abaixo para ir seguindo o caminho até encontrar o equipamento que possui problemas nos componentes físicos ou lógicos envolvidos nesta comunicação pretendida.

Siga o Caminho (Follow-the-Path)

Geralmente é usado juntamente com o Divide and Conquer. Quando o traceroute “morrer”, você tem que ir seguindo o caminho a partir do último gateway que reportou o OK no teste de rastreamento de rotas, e fazer as verificações necessárias com Top-Down ou Bottom-Up.

Aqui uma boa e atualizada documentação (tipo um diagrama) fará toda a diferença nos quesitos tempo e esforço. Você poderá comparar os resultados dos comandos de verificação com a topologia mostrada no diagrama e encurtar substancialmente o seu tempo e esforço. Do contrário, você terá que praticamente desenhar a sua rede no papel na medida em que faz as verificações e validações. Possa ser que você encontre o problema rapidamente, ou que você tenha que ir, um por um, até o último equipamento para matar a charada, enquanto valida as tabelas MAC, rotas, adjacências, conexões físicas, etc.

Encontrar Diferenças (Spot the Diferences)

Ao realizar o Divide and Conquer, e em combinação com o Follow-the-Path e Top-Down ou Bottom-Up, e se você tiver muitas dificuldades na identificação de onde o problema possa estar, você poderá comparar um serviço na rede que seja similar àquele que você está realizando o troubleshooting, preferencialmente algo idêntico ou similar e que esteja funcionando. Ou comparar com um snapshot obtido previamente. Isto é muito útil, por exemplo, quando testando ou fazendo troubleshooting de emparelhamentos BGP ou MPLS L3VPNs, ou outros cenários com configurações mais elaboradas, para citar alguns casos, onde você poderia comparar estas configurações mais complexas (ex: VRFs, policies, contextos, redistribuições de protocolos de roteamento, configurações de NAT e afins) com a configuração do serviço que está apresentando o problema.

Mover o Problema de Lugar (Move The Problem)

Próximo da hora do desespero: após você ter validado tudo e não ter conseguido localizar o problema, tendo praticamente esgotado as possibilidades, uma medida radical seria experimentar tentar isolar o problema através de uma ação de mudança (de lugar), seja esta física ou lógica. Por exemplo, mudar o ponto de rede do usuário, trocar cabos, trocar a conexão na porta do switch onde o usuário estiver localizado, migrar a conexão para outro equipamento, e ações deste tipo. Procure adotar as medidas mais rápidas e/ou de menor esforço e risco, visando economizar tempo. Para exemplificar, o que é mais rápido, trocar o cabo do usuário na baia dele ou na porta do switch? Seria mais rápido você trocar uma fibra ou remanejar o usuário de switch? Seria mais rápido migrar a conexão para outro módulo físico no mesmo equipamento, ou migrar para outro o equipamento? É viável você transferir as configurações L3 do roteador PE atual para outro equipamento a ser posicionado? Substituir o equipamento inteiro é a ação mais rápida ou viável?

É melhor termos um método seguro para trabalhar do que inventar moda na hora de resolver um problema na rede!

Não que eu curta ser burocrático, até mesmo porque as sugestões e conceitos deste artigo não são qualquer coisa deste tipo. Para ser efetivo, você precisa de processos, de um "norte"; de uma bússola. Com as empresas e indivíduos cada vez mais dependentes da disponibilidade de recursos computacionais, haverá sempre uma pressão, frustração e perdas associadas com a queda de produtividade e lucratividade de empreendimentos inteiros e que dependem das soluções e ferramentas da tecnologia da informação e comunicação para fazer negócios, agilizar processos, e servir interesses com maior comodidade e agilidade. Sem contar que muitas tecnologias estão orientadas aos conceitos de redução de custos também e, portanto, cada falha e cada indisponibilidade é péssima para todos: empresa, usuários e clientes.

Conforme citado anteriormente, você tem total liberdade para gerir o suporte técnico de seu ambiente como melhor lhe convier. Eu apenas entendo que você será mais efetivo com os seus próprios métodos somente a partir do momento em que você passar a conhecer bem (ou muito bem) os componentes e situações particulares do seu ambiente.

Para todos os demais casos, sugiro seguir as recomendações deste artigo!

Falando de seguir as dicas deste artigo: no início, você poderá ter um pouco de dificuldade em seguir os roteiros propostos. Caso isto aconteça, a resposta é simples: você não está acostumado ainda a trabalhar de forma pautada e organizada. É que nem frequentar uma academia após anos de sedentarismo, e amanhecer no dia seguinte repleto de dores! "Uma vida de contemplações glutônicas e sedentárias o deixou lento demais para agir...". :-D

Encare este desafio como "aprender a andar de bicicleta". Para não tomar aquele tombo, coloque os processos em ordem, pratique, ganhe confiança, antecipe-se, e, em pouco tempo, você estará fera no assunto! Pode apostar nisto!

Roteiro estruturado de troubleshooting é que nem aprender a andar de bicicleta: leva algum tempo pra dominar, mas funciona e dá resultados permanentes!

Fique atento quanto a situações mais complicadas

Há algumas situações onde realmente o problema fica difícil de ser resolvido. Dedicarei esta seção para dissertar um pouco a respeito.

Em suma, como você provavelmente já deva saber, os equipamentos presentes nas infraestruturas L2 e L3 possuem áreas sistêmicas denominadas plano de controle (control plane), plano de dados (data plane), plano de serviços (service plane) e plano de gerenciamento (management plane). Resumindo aqui o que são, o que fazem, e exemplificando também alguns dos principais componentes de cada um destes planos:

Control Plane

É a área sistêmica onde ficam hospedados os protocolos de roteamento, tais como RIP, OSPF, EIGRP, ISIS, BGP, assim como as rotas estáticas e a tabela de roteamento (routing information base ou RIB). Em adição, diversos protocolos são mantidos também no control plane, tais como os protocolos associados ao MPLS (LDP, RSVP-TE, BGP-LS (uma address-family do BGP)), além de protocolos de resiliência L2 (Spanning Tree, EAPS, REP, G.8032, e outros), e suas respectivas estruturas de dados. E, para finalizar, protocolos tais como o ARP e o IPv6 ND (ICMPv6). Outras tecnologias e recursos normalmente presentes nas redes implementam partes de suas funções também neste plano, mas buscarei simplificar este entendimento e, portanto, pararei por aqui.

A principal função do control plane é fornecer as funções de programabilidade das estruturas de comutação e encaminhamento de pacotes, ou seja, a alimentação de suas tabelas de roteamento de forma dinâmica ou estática e no intuito de termos uma convergência da rede (entendimento coletivo acerca dos caminhos da rede, mas cada roteador tendo o seu próprio entendimento quanto a isto), e sinalizar ao plano de dados, via mecanismos de troca de mensagens entre processos (ou IPCs), sobre a disponibilidade destes caminhos.

Alguns dos diversos problemas que você terá que resolver ("efetuar o troubleshooting") tem relação direta com estes protocolos. E, em grande parte, estes problemas podem ser evitados com boas práticas na configuração do roteamento (L3) e também valendo o mesmo para as tecnologias L2. Portanto, procure projetar e configurar estas tecnologias obedecendo às boas práticas, pois, assim, raramente você terá que se preocupar em resolver problemas na rede com estes protocolos e serviços. Fica a dica!

Todavia, caso isto venha a acontecer (os problemas), esteja preparado! A análise de informações coletadas precisa ser feita corretamente. O que olhar no output de um comando para verificação de adjacências do OSPF? O que olhar na tabela BGP de rotas recebidas de um peer EBGP? Isto significa que você precisa conhecer previamente as tecnologias que você mesmo deverá suportar em sua rede para quando os problemas ocorrerem.

O meu julgamento aqui:

• Identificar e localizar problemas nos protocolos é "mamão-com-açúcar" para profissionais organizados, metódicos, e conhecedores destas tecnologias e protocolos.
• Os comandos "show" e "display" disponíveis na CLI dos equipamentos revelam praticamente tudo aquilo que você precisa olhar para localizar um problema ou alguma inconsistência.
• Há opções bem versáteis de diagnósticos de problemas com protocolos no plano de controle, tais como consultas de logs e debugs específicos.
• É o troubleshooting mais fácil de todos. Acredite!

Data Plane

O plano de dados por sua vez representa as estruturas específicas para as ações de processamento e encaminhamento de pacotes, podendo ser baseada em software (softrouting) ou em silício especializado, tais como ASICs e FPGAs. É no plano de dados onde ocorre de fato a determinação de caminhos e o efetivo encaminhamento do pacote, em adição a toda e qualquer manobra ou ação a ser executada sobre os cabeçalhos dos pacotes (ex: manipulação do tag de VLAN, imposição/swap/pop de label, marcação de QoS, tradução de endereços IP) ou sobre a transmissão do pacote em si (ex: policiamento, moldagem, ajuste de TCP MSS, ou fragmentação).

O plano de dados vive em plena harmonia com o plano de controle - ou pelo menos deveria! Em roteadores mais sofisticados, em termos de processos em execução, um plano não depende do outro para funcionar, mas, na prática, sem o plano de controle, como o roteador preencherá a sua FIB lá no plano de dados?

Isto significa que um problema num protocolo de roteamento provocará a fuga de rotas na tabela de roteamento (RIB), a qual é mantida no plano de controle. Consequentemente, o plano de dados fica sem as instruções correspondentes (ex: entradas na FIB e respectivas adjacências para reescrita de cabeçalhos) para encaminhar pacotes para aqueles destinos. Tudo muito óbvio.

Ou seja, muitos dos problemas que experimentamos na rede à título de "encaminhamento de pacotes" na verdade não estão no plano de dados, e sim no plano de controle. Mas esta parte é fácil de identificar (vide comentário da seção acima).

O que realmente dificulta muitos casos de suporte é quando não há problemas aparentes no plano de controle! Aí, meu amigo, como diria o Galvão Bueno, "haaaaaja coração!".

A maioria dos problemas específicos do plano de dados são relativamente fáceis de identificar e resolver, mas não sem um esforço antes, até mesmo custos em alguns casos! Citarei apenas alguns exemplos aqui, pois as possibilidades são muito vastas mesmo:

• Problemas associados à perda de conectividade:
  • Possíveis causas: queda ou rompimento de enlace. Fácil de identificar e resolver.
• Problemas associados à lentidão de comunicações com perda de pacotes:
  • Possível causa: tráfego excedente em uma policy (que pode ser resolvido por meios de configurações). Fácil de resolver.
  • Possível causa: congestionamentos (os "gargalos", os quais podem ser atenuados com ajustes no cenário de QoS, ou aumentando a capacidade do circuito). Relativamente fácil de resolver, mas pode levar tempo (ex: aumento de capacidade).
  • Possível causa: problemas com o processamento de um ou mais dispositivos presentes na rede. O diagnóstico aqui é razoavelmente mais difícil, pois normalmente exige que você compreenda bem as capacidades dos dispositivos, além de algum (bom) conhecimento da arquitetura dos equipamentos envolvidos. Além de saber onde obter as informações necessárias na configuração e estado operacional dos componentes do equipamento, e fazendo isso para cada equipamento.
• Problemas associados à lentidão de comunicações com aumento de latência e/ou jitter:
  • Estando a latência geral um pouco elevada, mas estável ou consistente, talvez um refinamento das políticas de QoS atenuem o delay fim a fim e o jitter. Exige maior capacitação por parte do analista para efetuar este tipo de correção.
• Agora, há situações bem complicadas onde você começa a investigar e descobre que:
  • Você não encontra problemas nas configurações dos protocolos e serviços no plano de controle.
  • Você descobre que a carga (processamento) dos processos correspondentes está aparentemente normal.
  • Você não encontra indicadores de erros nas interfaces físicas e/ou lógicas dos respectivos enlaces da comunicação fim a fim.
  • Você não encontra indícios de congestionamentos nas filas de saída destas interfaces.
  • O seu time de transmissão realizou um teste de RFC no circuito usando uma ferramenta específica (ex: JDSU) e reportou não haver problemas com o circuito suspeito.
  • Mas, mesmo assim, o seu cliente reporta a lentidão, e este problema pode ser confirmado por você!
    • O que você faz? Onde você olha? Qual tecnologia você inspeciona? Qual comando você digita? E em qual equipamento?
    • É o tipo de situação mais difícil de se resolver; o que consome maior esforço e tempo.

O meu julgamento aqui:

• Muitos do problemas específicos do plano de dados podem ser evitados com abordagens mais atraentes e profissionais. Ou seja, um bom projeto técnico e com boa engenharia de rede, tráfego e planejamento de capacidades.
• A maioria dos problemas no plano de dados deixa um rastro observável e reportado por comandos específicos na CLI ou na plataforma de gerenciamento da rede.
• Há, no entanto, algumas situações onde realmente você possa vir a ter extrema dificuldade em termos de diagnósticos!
  • É nessas horas que você precisará conhecer melhor a arquitetura dos equipamentos e envolver o suporte do fabricante. E contar com profissionais mais experientes ou com uma consultoria de excelência.
    • Aiás, você possui os contratos de assistência técnica e suporte estendidos vigentes, em dia? É nessas horas que isto faz uma tremenda falta!
• No geral, o troubleshooting de problemas do plano de dados é mais complexo do que o troubleshooting de problemas do plano de controle, e normalmente exige mais experiência por parte do analista.

Service Plane

Não esmiuçarei este com detalhes. Mas nesta área é onde ficam hospedados protocolos e serviços tais como PPPoE, IPoE, GRE, IPsec, L2VPN e outros. Normalmente ou quase sempre estes protocolos e serviços compartilham os mesmos componentes onde estão hospedados os demais protocolos e serviços do plano de controle (ex: CPU e memória).

Os problemas mais frequentes aqui são: padrões de configuração empregados (fora das boas práticas), desalinhamento de utilização com relação à capacidade do recurso naquele equipamento (ex: violação quanto a quantidade de sessões, quantidade de túneis, etc.). A resolução destes problemas, quando o componente estiver operando dentro de suas capacidades, requer conhecimento da tecnologia em questão.

Management Plane

E, para finalizar, a área sistêmica onde estão hospedados os protocolos e serviços específicos de gerenciamento, tais como Telnet, SSH, Netconf, SNMP, OAM, CFM, NetFlow, IPFIX e afins. Em muitos casos, compartilhando os mesmos ou a maioria dos componentes onde estão hospedados, também, os protocolos e serviços dos planos de controle e de serviços (ex: CPU e memória).

Os problemas aqui tendem a ser bem pontuais e de fácil diagnóstico, na maioria dos casos. Não entrarei em detalhes para não estender-me desnecessariamente com o artigo.

Quando a "casa cai'

Falando aqui especificamente de defeitos de software, os famosos "bugs". Há situações onde as configurações dos protocolos e serviços estão corretas no ponto de vista do que deveriam ser mesmos, e em alinhamento com as boas práticas, mas, mesmo assim, você está com um baita problema em algum serviço da rede.

Malditos... bugs!

Não estenderei-me demasiadamente nesta seção, pois já estou projetando um artigo para falar somente disto ("gerenciamento de crises provocadas por bugs de software", ou algum nome intuitivo assim). Siga acompanhando a Wiki do BPF!

Para sintetizar, o que posso falar, e com absoluta propriedade, são os seguintes:

• Não há software isento de defeitos (bugs).
• Felizmente, em muitos casos, um eventual defeito (bug) existente no código do software do equipamento, referente a um protocolo ou serviço, poderá não te causar qualquer problema ou distúrbio, pois, da maneira como você configurou o recurso, o referido bug não é acionado ("trigger").
• Nenhum equipamento, modelo, marca ou fabricante está imune quanto a bugs no software.

Existem bugs "bons", "mais ou menos bons", e "nojento e maus"!

É óbvio que todo bug é muito ruim! Mas, como não temos como rodar software 100% imune com relação a bugs, em algum momento na sua carreira você se deparará com um bug! Fato! Quando isto acontecer, você rezará para que seja um bug "bom", e não um bug "nojento e mau"! Não entendeu ainda? Relaxe! Acompanhe a minha linha de raciocínio a seguir:

• Bug "bom" é aquele que "mostra a cara", ou seja, quando há uma notificação no log do equipamento indicando um problema, e geralmente acompanhando alguma mensagem ou indicador que pode ser pesquisado por você ou pelo suporte do fabricante do seu equipamento.
  • Se você tiver que experimentar - indesejavelmente - um bug no software do seu equipamento, e este bug vier a te causar algum problema, você realmente desejará que este bug "mostre a sua cara". Por que?
    • Porque ficará muito mais fácil para você pesquisar por um software isento daquele bug (fixed) e/ou acionar o fabricante para comunicar o problema e, assim, obter o devido suporte.
• Bug "mais ou menos bom" é aquele onde você precisará conduzir diversos diagnósticos e coletas, geralmente seguindo procedimentos com a orientação do suporte técnico do fabricante e, ao encaminhar toda a coleta para o fabricante, os times de suporte fazem as depurações diversas e "acertam" (hit) o bug, ou seja, localizam um bug que já é conhecido pelos times de engenharia e desenvolvimento daquele software. Ufa!
  • Este "hit" do bug na base interna dos times de desenvolvimento do fabricante permite localizar o problema por um "bug ID" já conhecido. Alguns fabricantes chamam isto de Distributed Defect Tracking System (DDTS).
    • Geralmente aqui já tem uma ação paliativa conhecida e documentada para aquele bug ID ou DDTS, ou;
    • Uma release de software já disponível, isenta deste bug ID ou DDTS.
• Bug "nojento e mau" é aquele que o suporte do fabricante, após ter recebido os dados das suas coletas, debugs, etc., não consegue localizar um problema conhecido na base interna de bugs! Amigo, você acabou de "abrir" um bug! Ou seja, sequer ainda existe correção disponível para o seu problema. Que azar, hein?!
  • Com pouco ou muito esforço, o fabricante poderá recomendar um "workaround", que seria uma solução paliativa para você fugir do problema provocado pelo bug, enquanto você ainda usa o software que contém o defeito, normalmente por falta de opções no momento com relação a software.
    • E enquanto os times de desenvolvimento do fabricante correm atrás do que fazer para corrigir o código contendo o problema, o que poderá levar meses em alguns casos.
    • Por exemplo, isto pode exigir algum comando adicional, ou ajustes de parâmetros de algum recurso, remoção da configuração correspondente ao problema (o que é inviável em muitos casos ou projetos), ou reboot pontual ou periódico do equipamento.
  • Ou trocar o software do equipamento por outro que seja compatível com os recursos e funcionalidades exigidas pelo seu projeto técnico.
  • Em alguns casos mais graves, a solução seria aguardar uma correção do problema em nova release de software! Isto é cruel.

No entanto, há formas de evitarmos surpresas desagradáveis com relação a problemas de software. Quer ver? Confira este artigo Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede, disponível em nossa Wiki!

Conclusão do artigo

Para concluir, entenda que o troubleshooting de redes pode ser uma "ciência" um tanto ampla e complexa, pois são variáveis praticamente infinitas em termos de dinâmicas de surgimento de problemas. As situações são muitas, mesmo!

Felizmente, muitos dos problemas podem ser evitados através da adoção de excelentes abordagens de projeto técnico e com o auxílio das boas práticas. E, claro, da sua capacidade e compromisso em antecipar-se aos diversos tipos de problemas que podem surgir em sua rede. Antecipe-se! Tome as iniciativas necessárias através de uma boa documentação, e monte um bom roteiro de suporte, bem elaborado e estruturado. Isto fará toda a diferença!

Espero que você tenha curtido este artigo! Compartilhe-o e ajude a divulgar o trabalho do Brasil Peering Forum (BPF)!

Obrigado!

Autor: Leonardo Furtado