A Deus, que me guia e ilumina. Aos meus pais, Everaldo e Helenita, pela confiana e carinho.

Ao meu esposo Beto, pelo apoio e pacincia. Aos meus irmos, familiares e amigos que sempre torcem por mim. Por fim, mas no menos importante, dedico este livro a Jacques e a Peter, por todos os ensinamentos que me passaram. Raquel Vigolvino Lopes

Dedico este livro a Ana Lcia, minha luz. Jacques Philippe Sauv

Aos diversos pais e mes que tive na vida, pais dos meus melhores amigos de infncia, e especialmente aos meus pais Pedro e Elza que, com pacincia, dedicao e amor, souberam transmitir para mim e meus amigos, verdadeiros ensinamentos de vida: humildade, honestidade, perseverana e respeito aos semelhantes. Pedro Srgio Nicolletti

P R E F C I O

Prefcio

termo melhores prticas vem sendo utilizado no mercado para designar prticas e processos de trabalho utilizados por empresas ou equipes que, reconhecidamente, sejam bem sucedidas nas tarefas que empreendem. Empregar este termo na rea de gerncia de redes de computadores significa descrever prticas e processos que auxiliem um time de gerncia de redes a manter o bom funcionamento de uma rede. Bons livros que descrevem protocolos e bases de informaes de gerncia so facilmente encontrados no mercado. Mas a literatura de gerncia de redes ainda pobre quando mudamos de paradigma e buscamos materiais que nos ensinem como, na prtica, obter, combinar e interpretar dados de gerncia com o objetivo de efetivamente gerenciar uma rede. Apesar da palavra melhor estar sendo empregada no termo melhores prticas, isto no significa que as idias descritas sejam perfeitas e que qualquer outra forma de se obter um determinado resultado seja errada. Significa apenas que, no momento, chegou-se a um consenso por pesquisas e experincias de que esta , at ento, uma forma com a qual equipes bem sucedidas obtiveram sucesso para alcanar um certo objetivo.

OBJETIVOS
Este livro foi escrito com o objetivo de ajudar os profissionais responsveis por gerenciar redes de computadores a atingir um melhor desempenho em seu trabalho. As melhores prticas para a gerncia de redes de computadores encontradas aqui vo ajud-lo a detectar, diagnosticar e solucionar problemas numa rede de forma eficaz. Voc tambm encontrar boas prticas de configurao que, quando seguidas, podem evitar ou diminuir a probabilidade de ocorrncia de certos problemas. Os objetivos deste livro so, portanto: definir uma metodologia geral para deteco, diagnstico e resoluo de problemas de redes; descrever, de forma organizada, problemas que podem ocorrer em uma rede, mostrando seus sintomas, sinais e como podem ser confirmados e solucionados; mostrar como obter e interpretar algumas informaes de gerncia, tais como taxa de erros e utilizao, que chamamos neste livro de sinais.

ii

P R E F C I O

AUDINCIA
Este livro foi escrito principalmente para profissionais responsveis pela operao e resoluo de problemas apresentados por uma rede. Mas outras pessoas podem se beneficiar tambm de sua leitura: pessoas responsveis por desenvolver aplicaes de gerncia de redes. Para estas pessoas os procedimentos podem ser teis, pois eles explicam como obter determinadas informaes de gerncia e como utilizar ou analisar a informao para chegar a concluses sobre o estado de sade de uma rede; estudantes ou outros profissionais interessados em aprender mais sobre a prtica da gerncia de redes.

ORGANIZAO
F
E

P A

A R T E

I :

U N D A M E N T O S B O R D A G E M

A Parte I deste livro formada pelos Captulos 1 a 3. O primeiro captulo consiste de uma introduo geral gerncia de redes, uma analogia entre a Gerncia de Redes e a Medicina e a apresentao de uma organizao tpica de um time de gerncia. No Captulo 2 explicamos o que so e como esto organizados o catlogo de problemas, os ndices invertidos e os procedimentos. Finalmente, no Captulo 3, definimos uma metodologia geral para deteco, diagnstico e resoluo de problemas de rede. Na Parte II, formada pelos Captulos 4 a 8, encontram-se o catlogo de problemas e os ndices invertidos. Cada um destes captulos excetuando-se o Captulo 8, no qual so apresentados os ndices invertidos encontramos problemas de uma determinada camada do modelo de referncia OSI1. No Captulo 4, por exemplo, encontram-se os problemas da camada fsica. Os Captulos 9 a 12 formam a Parte III deste livro. Neles encontram-se os procedimentos. Cada procedimento ensina pelo menos uma forma de se obter uma determinada informao de gerncia. Procedimentos so referenciados no catlogo de problemas. A parte IV encontra-se no CD que acompanha este livro. Nela encontram-se captulos tericos sobre diversos temas de redes, como por exemplo: Entendendo Ethernet e Introduo a VLANs.

A R T E

I I :

O
D E

C A T L O G O

P R O B L E M A S

A R T E T O S

I I I :

R O C E D I M E N

P A R T E A P N D

I V :
I C E S

COMO LER ESTE LIVRO

Se voc j estiver bastante familiarizado com o tema Gerncia de Redes, tem uma idia de como essa atividade se assemelha atividade de um mdico e conhece a organizao tpica de um time de gerncia de redes, voc pode pular o Captulo 1.

O modelo OSI foi criado como primeiro passo para a padronizao internacional dos protocolos usados nas vrias camadas.

iii

P R E F C I O

Recomendamos que o Captulo 2 seja lido pois ele explica como o catlogo de problemas, os ndices invertidos e os procedimentos esto organizados e por qu. A leitura do Captulo 3 tambm recomendada. Nele apresentamos uma metodologia geral de deteco e resoluo de problemas e mostramos como o restante do livro pode ser usado em conjunto com esta metodologia para auxiliar o gerente a diagnosticar e solucionar os problemas apresentados pela rede. Este livro pode ser usado como um manual de primeiros socorros. Aps levantar informaes sobre um problema que est ocorrendo na rede no momento, veja no ndice invertido apresentado no Captulo 8 que problemas podem causar os sintomas e sinais percebidos. Voc ter em mos uma lista de hipteses. Em seguida, consulte os problemas referenciados no catlogo de problemas. Um deles pode estar ocorrendo em sua rede. Ao consultar os problemas voc pode optar por tentar confirm-los (Seo TESTES CONFIRMATRIOS) ou por buscar novas informaes (Seo SINAIS). Quando quiser recuperar uma determinada informao de gerncia e no souber como faz-lo, um dos procedimentos pode ajudar. Os procedimentos apresentados no Captulo 9, em especial, so bastante genricos: informam como conectar um analisador de protocolos rede e como obter uma interface de linha de comando em um equipamento de interconexo. O catlogo de problemas (Parte II) pode tambm ser lido seqencialmente. medida que procedimentos forem referenciados voc pode escolher consultlos. Aps a leitura, voc ter aumentado sua bagagem de experincias e conhecimentos. Ser como se voc j tivesse vivido cada problema apresentado. uma boa forma de adquirir experincia sem sofrimento. Para entender bem cada problema do catlogo preciso ter conhecimentos bsicos sobre o assunto abordado. Cada problema referenciar um apndice que dever ser lido caso o leitor no conhea o assunto. Se voc no sabe para que serve e como funciona o protocolo de rvore de cobertura, por exemplo, voc ter dificuldades em entender problemas relacionados a este protocolo.

SOBRE REFERNCIAS ON-LINE

Em alguns captulos voc encontrar referncias que podem ser acessadas atravs da Internet. Ns garantimos que todas estas referncias esto funcionando (link correto) em novembro de 2002. No entanto, mudanas em sites so bastante comuns atualmente, sendo possvel que, mais tarde, infelizmente alguns dos links referenciados no livro estejam quebrados. Se isto ocorrer um dia a dica : ir na pgina principal do site em questo e pesquisar pelo ttulo da referncia ou ir direto no link para publicaes, recursos ou biblioteca digital e procurar pelo que voc deseja.

LEGENDA

iv

P R E F C I O

Durante a leitura deste livro voc encontrar alguns estilos diferentes de fontes e cones ilustrativos. Na Tabela 1-1 apresentamos uma legenda com o significado de alguns destes estilos.

cone usado para enfatizar uma boa prtica de gerncia, em geral, de configurao.

cone usado para chamar a sua ateno para certos aspectos.

cone que indica incio de um exemplo que servir para esclarecer melhor o entendimento de algo.

comando
comando iterativo

Estilo para apresentao de comandos. Estilo usado para diferenciar respostas de comandos e comandos quando se tratam de comandos iterativos. Estilo usado para destacar palavras ou frases chave de um pargrafo. usado para destacar sintomas e sinais de um problema. Estilo usado para indicar um sinal diferencial, cuja existncia confirma um determinado problema. Estilo usado para representar algo que deve estar escrito em um arquivo. Estilo que representa nomes de arquivos. Estilo que indica itens de interfaces amigveis como as do Windows: menu, botes, etc. Estilo para apresentao de equaes. Estilo para representar nomes de variveis de MIBs (Management Information Base).
Tabela 1-1: Legenda de estilos encontrados no livro.

Destaque

Sinal diferencial

$TTL
/etc/resolv.conf

Menu
equaes

ifInErrors

S U M R I O

SUMRIO
1 INTRODUO GERNCIA DE REDES.......................................................... 16 1.1 INTRODUO GERNCIA DE REDES DE COMPUTADORES ................................... 17 1.2 O PAPEL DO GERENTE DE REDES ........................................................................... 19 1.3 VOC: O MDICO DA REDE .................................................................................... 21 1.4 REFERNCIAS ....................................................................................................... 24 1.4.1 Livros ............................................................................................................ 24 2 INTRODUO AO CATLOGO DE PROBLEMAS......................................... 25 2.1 ANALOGIA ENTRE A GERNCIA DE REDES E A MEDICINA ..................................... 25 2.2 O CATLOGO DE PROBLEMAS ............................................................................... 26 2.2.1 Por que um catlogo de problemas? ............................................................ 29 2.2.2 Os ndices invertidos..................................................................................... 30 2.3 OS PROCEDIMENTOS ............................................................................................. 30 3 METODOLOGIA GERAL DE DETECO, DIAGNSTICO E RESOLUO DE PROBLEMAS ....................................................................................................... 32 3.1 DETECO: A REDE EST APRESENTANDO COMPORTAMENTO ESTRANHO ............ 34 3.2 BUSQUE INFORMAES......................................................................................... 34 3.3 RECORRNCIA DE PROBLEMA? MUDANAS NA REDE?.......................................... 36 3.4 DESENVOLVA HIPTESES ...................................................................................... 36 3.5 ORGANIZE A LISTA DE HIPTESES ......................................................................... 38 3.6 TESTE AS HIPTESES LEVANTADAS ....................................................................... 39 3.7 SOLUCIONE O PROBLEMA ...................................................................................... 40 3.8 TESTE A SOLUO IMPLANTADA ........................................................................... 40 3.9 DOCUMENTE SUAS ATIVIDADES ............................................................................ 41 3.10 REFERNCIAS ..................................................................................................... 41 4 PROBLEMAS DE NVEL FSICO ........................................................................ 42 4.1 CABO ROMPIDO OU DANIFICADO........................................................................... 42 4.1.1 Descrio...................................................................................................... 42 4.1.2 Sintomas........................................................................................................ 43 4.1.3 Sinais ............................................................................................................ 43 4.1.4 Testes confirmatrios.................................................................................... 43 4.1.5 Sugestes de tratamento ............................................................................... 47 4.2 CONECTOR DEFEITUOSO OU MAL INSTALADO ....................................................... 47 4.2.1 Descrio...................................................................................................... 47 4.2.2 Sintomas........................................................................................................ 48 4.2.3 Sinais ............................................................................................................ 48 4.2.4 Testes confirmatrios.................................................................................... 48 4.2.5 Sugestes de tratamento ............................................................................... 51 4.3 DESCASAMENTO DE MODO E/OU VELOCIDADE DE OPERAO ............................... 52 4.3.1 Descrio...................................................................................................... 52 4.3.2 Sintomas........................................................................................................ 53 4.3.3 Sinais ............................................................................................................ 53 4.3.4 Testes confirmatrios.................................................................................... 53 4.3.5 Sugestes de tratamento ............................................................................... 54 4.4 EQUIPAMENTO DE INTERCONEXO DEFEITUOSO ................................................... 56 4.4.1 Descrio...................................................................................................... 56 4.4.2 Sintomas........................................................................................................ 56 4.4.3 Sinais ............................................................................................................ 57 4.4.4 Testes confirmatrios.................................................................................... 57 4.4.5 Sugestes de tratamento ............................................................................... 60 4.5 PLACA DE REDE OU PORTA DE EQUIPAMENTO DE INTERCONEXO DEFEITUOSAS .. 61 4.5.1 Descrio..................................................................................................... 61 4.5.2 Sintomas........................................................................................................ 62 4.5.3 Sinais ............................................................................................................ 62 6

S U M R I O

4.5.4 Testes confirmatrios.................................................................................... 63 4.5.5 Sugestes de tratamento ............................................................................... 66 4.6 INTERFERNCIA NO CABO ..................................................................................... 66 4.6.1 Descrio...................................................................................................... 66 4.6.2 Sintomas........................................................................................................ 67 4.6.3 Sinais ............................................................................................................ 67 4.6.4 Testes confirmatrios.................................................................................... 67 4.6.5 Sugestes de tratamento ............................................................................... 68 4.7 SATURAO DE BANDA EM SEGMENTOS ETHERNET COMPARTILHADOS ............... 68 4.7.1 Descrio...................................................................................................... 68 4.7.2 Sintomas........................................................................................................ 68 4.7.3 Sinais ............................................................................................................ 69 4.7.4 Testes confirmatrios.................................................................................... 69 4.7.5 Sugestes de tratamento ............................................................................... 71 4.8 TIPO ERRADO DE CABO ......................................................................................... 71 4.8.1 Descrio...................................................................................................... 71 4.8.2 Sintomas........................................................................................................ 72 4.8.3 Sinais ............................................................................................................ 72 4.8.4 Testes confirmatrios.................................................................................... 72 4.8.5 Sugestes de tratamento ............................................................................... 75 4.9 VIOLAO DE REGRAS DE CABEAMENTO ETHERNET ............................................ 75 4.9.1 Descrio...................................................................................................... 75 4.9.2 Sintomas........................................................................................................ 75 4.9.3 Sinais ............................................................................................................ 76 4.9.4 Testes confirmatrios.................................................................................... 76 4.9.5 Sugestes de tratamento ............................................................................... 78 4.10 REFERNCIAS ..................................................................................................... 78 4.10.1 Livros .......................................................................................................... 78 4.10.2 Recursos online (Internet)........................................................................... 79 4.10.3 RFCs ........................................................................................................... 79 4.10.4 Livros base.................................................................................................. 79 4.10.5 Outros recursos on-line .............................................................................. 80 5 PROBLEMAS DE NVEL DE ENLACE............................................................... 82 5.1 INTERFACE DESABILITADA ................................................................................... 82 5.1.1 Descrio...................................................................................................... 82 5.1.2 Sintomas........................................................................................................ 82 5.1.3 Sinais ............................................................................................................ 83 5.1.4 Testes confirmatrios.................................................................................... 83 5.1.5 Sugestes de tratamento ............................................................................... 83 5.2 PROBLEMA COM RVORE DE COBERTURA ............................................................. 84 5.2.1 Descrio...................................................................................................... 84 5.2.2 Sintomas........................................................................................................ 84 5.2.3 Sinais ............................................................................................................ 84 5.2.4 Testes confirmatrios.................................................................................... 85 5.2.5 Sugestes de tratamento ............................................................................... 90 5.3 SATURAO DE RECURSOS DEVIDO A EXCESSO DE QUADROS DE DIFUSO............ 91 5.3.1 Descrio...................................................................................................... 91 5.3.2 Sintomas........................................................................................................ 92 5.3.3 Sinais ............................................................................................................ 92 5.3.4 Testes confirmatrios.................................................................................... 92 5.3.5 Sugestes de tratamento ............................................................................... 93 5.4 TEMPO DE ENVELHECIMENTO DE TABELAS DE ENDEREOS INADEQUADO ............ 94 5.4.1 Descrio...................................................................................................... 94 5.4.2 Sintomas........................................................................................................ 95 5.4.3 Sinais ............................................................................................................ 95 5.4.4 Testes confirmatrios.................................................................................... 95 5.4.5 Sugestes de tratamento ............................................................................... 96 5.5 VALIDADE DA CACHE ARP INADEQUADA ............................................................. 96 5.5.1 Descrio...................................................................................................... 96 7

S U M R I O

5.5.2 Sintomas........................................................................................................ 97 5.5.3 Sinais ............................................................................................................ 97 5.5.4 Testes confirmatrios.................................................................................... 98 5.5.5 Sugestes de tratamento ............................................................................... 99 5.6 REFERNCIAS ..................................................................................................... 100 5.6.1 Livros .......................................................................................................... 100 5.6.2 Recursos online (Internet) .......................................................................... 100 5.6.3 RFCs ........................................................................................................... 100 5.6.4 Livros base.................................................................................................. 100 6 PROBLEMAS DE NVEL DE REDE .................................................................. 102 6.1 TABELA DE ROTAS DE HOSPEDEIROS INCORRETAS .............................................. 102 6.1.1 Descrio.................................................................................................... 102 6.1.2 Sintomas...................................................................................................... 102 6.1.3 Sinais .......................................................................................................... 103 6.1.4 Testes confirmatrios.................................................................................. 103 6.1.5 Sugestes de tratamento ............................................................................. 105 6.2 ENDEREO IP DE HOSPEDEIRO INCORRETO ......................................................... 106 6.2.1 Descrio.................................................................................................... 106 6.2.2 Sintomas...................................................................................................... 106 6.2.3 Sinais .......................................................................................................... 107 6.2.4 Testes confirmatrios.................................................................................. 107 6.2.5 Sugestes de Tratamento ............................................................................ 109 6.3 HOSPEDEIRO COM MSCARA DE REDE INCORRETA ............................................. 110 6.3.1 Descrio.................................................................................................... 110 6.3.2 Sintomas...................................................................................................... 110 6.3.3 Sinais .......................................................................................................... 111 6.3.4 Testes confirmatrios.................................................................................. 111 6.3.5 Sugestes de tratamento ............................................................................. 112 6.4 CLIENTE DNS MAL CONFIGURADO ..................................................................... 113 6.4.1 Descrio.................................................................................................... 113 6.4.2 Sintomas...................................................................................................... 113 6.4.3 Sinais .......................................................................................................... 114 6.4.4 Testes confirmatrios.................................................................................. 114 6.4.5 Sugestes de tratamento ............................................................................. 115 6.5 SERVIDOR DHCP MAL CONFIGURADO ................................................................ 115 6.5.1 Descrio.................................................................................................... 115 6.5.2 Sintomas...................................................................................................... 117 6.5.3 Sinais .......................................................................................................... 118 6.5.4 Testes confirmatrios.................................................................................. 119 6.5.5 Sugestes de tratamento ............................................................................. 122 6.6 ROTAS ESTTICAS MAL CONFIGURADAS ............................................................. 124 6.6.1 Descrio.................................................................................................... 124 6.6.2 Sintomas...................................................................................................... 126 6.6.3 Sinais .......................................................................................................... 126 6.6.4 Testes confirmatrios.................................................................................. 126 6.6.5 Sugestes de tratamento ............................................................................. 130 6.7 EQUIPAMENTO INSERIDO EM VLAN INCORRETA ................................................ 130 6.7.1 Descrio.................................................................................................... 130 6.7.2 Sintomas...................................................................................................... 132 6.7.3 Sinais .......................................................................................................... 133 6.7.4 Testes confirmatrios.................................................................................. 134 6.7.5 Sugestes de tratamento ............................................................................. 136 6.8 VLANS NO ESTO CONFIGURADAS .................................................................. 137 6.8.1 Descrio.................................................................................................... 137 6.8.2 Sintomas...................................................................................................... 138 6.8.3 Sinais .......................................................................................................... 139 6.8.4 Testes confirmatrios.................................................................................. 140 6.8.5 Sugestes de tratamento ............................................................................. 141 8

S U M R I O

6.9 COMUTADORES NO CONSEGUEM TROCAR INFORMAES SOBRE VLANS ENTRE SI ................................................................................................................................. 141 6.9.1 Descrio.................................................................................................... 141 6.9.2 Sintomas...................................................................................................... 143 6.9.3 Sinais .......................................................................................................... 144 6.9.4 Testes confirmatrios.................................................................................. 145 6.9.5 Sugestes de tratamento ............................................................................. 146 6.10 AMBIENTE RIP-1 COM VLSM E/OU REDES NO CONTGUAS ............................ 146 6.10.1 Descrio.................................................................................................. 146 6.10.2 Sintomas.................................................................................................... 148 6.10.3 Sinais ........................................................................................................ 148 6.10.4 Testes confirmatrios................................................................................ 148 6.10.5 Sugestes de tratamento ........................................................................... 150 6.11 DIMETRO RIP COM MAIS DE 15 ROTEADORES ................................................. 151 6.11.1 Descrio.................................................................................................. 151 6.11.2 Sintomas.................................................................................................... 152 6.11.3 Sinais ........................................................................................................ 152 6.11.4 Testes confirmatrios................................................................................ 153 6.11.5 Sugestes de tratamento ........................................................................... 156 6.12 ROTEADORES RIP-2 NO ENVIAM OU RECEBEM PACOTES RIP-1 ...................... 156 6.12.1 Descrio.................................................................................................. 156 6.12.2 Sintomas.................................................................................................... 157 6.12.3 Sinais ........................................................................................................ 158 6.12.4 Testes confirmatrios................................................................................ 158 6.12.5 Sugestes de tratamento ........................................................................... 160 6.13 TRFEGO RIP SATURANDO LARGURA DE BANDA .............................................. 161 6.13.1 Descrio.................................................................................................. 161 6.13.2 Sintomas.................................................................................................... 162 6.13.3 Sinais ........................................................................................................ 162 6.13.4 Testes confirmatrios................................................................................ 162 6.13.5 Sugestes de tratamento ........................................................................... 164 6.14 FILTRO IP NO PERMITE A PASSAGEM DE TRFEGO RIP (UDP 520) ................. 164 6.14.1 Descrio.................................................................................................. 164 6.14.2 Sintomas.................................................................................................... 165 6.14.3 Sinais ........................................................................................................ 165 6.14.4 Testes confirmatrios................................................................................ 166 6.14.5 Sugestes de tratamento ........................................................................... 167 6.15 REFERNCIAS ................................................................................................... 168 6.15.1 Recursos online (Internet)......................................................................... 168 6.15.2 RFCs ......................................................................................................... 168 6.15.3 Livros base................................................................................................ 169 7 PROBLEMAS DE NVEL DE APLICAO ..................................................... 170 7.1 O SERVIO DE NOMES NO EST HABILITADO .................................................... 170 7.1.1 Descrio.................................................................................................... 170 7.1.2 Sintomas...................................................................................................... 171 7.1.3 Sinais .......................................................................................................... 171 7.1.4 Testes confirmatrios.................................................................................. 171 7.1.5 Sugestes de tratamento ............................................................................. 174 7.2 DNS: DESCASAMENTO DE REGISTROS A E PTR EM ARQUIVOS DE ZONAS ........... 175 7.2.1 Descrio.................................................................................................... 175 7.2.2 Sintomas...................................................................................................... 177 7.2.3 Sinais .......................................................................................................... 177 7.2.4 Testes confirmatrios.................................................................................. 177 7.2.5 Sugestes de tratamento ............................................................................. 177 7.3 INCONSISTNCIA ENTRE REGISTROS DOS SERVIDORES DNS PRIMRIO E SECUNDRIOS ........................................................................................................... 178 7.3.1 Descrio.................................................................................................... 178 7.3.2 Sintomas...................................................................................................... 180 7.3.3 Sinais .......................................................................................................... 180 9

S U M R I O

7.3.4 Testes confirmatrios.................................................................................. 180 7.3.5 Sugestes de tratamento ............................................................................. 181 7.4 O TTL DEFAULT DE UMA ZONA DNS NO EST CONFIGURADO .......................... 181 7.4.1 Descrio.................................................................................................... 181 7.4.2 Sintomas...................................................................................................... 183 7.4.3 Sinais .......................................................................................................... 184 7.4.4 Testes confirmatrios.................................................................................. 184 7.4.5 Sugestes de tratamento ............................................................................. 184 7.5 DNS: TTL E OUTROS CAMPOS DO REGISTRO SOA COM VALORES INADEQUADOS ................................................................................................................................. 185 7.5.1 Descrio.................................................................................................... 185 7.5.2 Sintomas...................................................................................................... 187 7.5.3 Sinais .......................................................................................................... 188 7.5.4 Testes confirmatrios.................................................................................. 188 7.5.5 Sugestes de tratamento ............................................................................. 190 7.6 FALTA . APS NOMES TOTALMENTE QUALIFICADOS EM REGISTROS DNS........ 192 7.6.1 Descrio.................................................................................................... 192 7.6.2 Sintomas...................................................................................................... 193 7.6.3 Sinais .......................................................................................................... 194 7.6.4 Testes confirmatrios.................................................................................. 194 7.6.5 Sugestes de tratamento ............................................................................. 194 7.7 FILTRO IP BARRANDO TRFEGO DNS................................................................. 195 7.7.1 Descrio.................................................................................................... 195 7.7.2 Sintomas...................................................................................................... 196 7.7.3 Sinais .......................................................................................................... 197 7.7.4 Testes confirmatrios.................................................................................. 197 7.7.5 Sugestes de tratamento ............................................................................. 199 7.8 SERVIDOR DE CORREIO ELETRNICO COM REPASSE TOTALMENTE ABERTO ........ 201 7.8.1 Descrio.................................................................................................... 201 7.8.2 Sintomas...................................................................................................... 202 7.8.3 Sinais .......................................................................................................... 202 7.8.4 Testes confirmatrios.................................................................................. 202 7.8.5 Sugestes de tratamento ............................................................................. 203 7.9 SERVIDOR DE CORREIO ELETRNICO COM REPASSE TOTALMENTE FECHADO ...... 204 7.9.1 Descrio.................................................................................................... 204 7.9.2 Sintomas...................................................................................................... 204 7.9.3 Sinais .......................................................................................................... 204 7.9.4 Testes confirmatrios.................................................................................. 204 7.9.5 Sugestes de tratamento ............................................................................. 205 7.10 REFERNCIAS ................................................................................................... 206 7.10.1 Livros ........................................................................................................ 206 7.10.2 Recursos online (Internet)......................................................................... 206 7.10.3 RFCs ......................................................................................................... 207 7.10.4 Livros base................................................................................................ 207 8 OS NDICES INVERTIDOS ................................................................................. 208 8.1 NDICE INVERTIDO DE SINTOMAS ........................................................................ 208 8.2 NDICE INVERTIDO DE SINTOMAS E SINAIS .......................................................... 210 9 PROCEDIMENTOS GERAIS .............................................................................. 217 9.1 UTILIZANDO UM ANALISADOR DE PROTOCOLOS ................................................. 217 9.1.1 Conectando o analisador de protocolos ..................................................... 217 9.1.2 Criando e selecionando filtros de captura.................................................. 222 9.1.3 Capturando e decodificando quadros......................................................... 225 9.1.4 Outras funes interessantes do Sniffer...................................................... 226 9.1.5 Sobre analisadores de protocolos............................................................... 228 9.2 ACESSANDO A INTERFACE DE LINHA DE COMANDO DE UM EQUIPAMENTO DE INTERCONEXO ........................................................................................................ 229 9.2.1 Acesso atravs da porta console................................................................. 229 9.2.2 Acesso atravs de sesso de telnet.............................................................. 229 10

S U M R I O

9.2.3 Sobre logins e senhas.................................................................................. 230 9.2.4 Dicas gerais de uso..................................................................................... 230 9.3 LOCALIZANDO PROBLEMAS COM AUXLIO TRACEROUTE .................................... 232 9.3.1 Descrio e Dicas....................................................................................... 232 9.3.2 Usando traceroute ...................................................................................... 232 9.4 REFERNCIAS ..................................................................................................... 234 9.4.1 Recursos online (Internet) .......................................................................... 234 10 PROCEDIMENTOS REFERENCIADOS NOS PROBLEMAS DE NVEL FSICO E ENLACE .................................................................................................. 235 10.1 OBTENDO TAXA DE ERROS ................................................................................ 235 10.1.1 Descrio e dicas...................................................................................... 235 10.1.2 Usando uma estao de gerncia SNMP.................................................. 238 10.1.3 Usando um analisador de protocolos ....................................................... 243 10.1.4 Usando interface de linha de comando..................................................... 244 10.1.5 Usando ifconfig e netstat .......................................................................... 245 10.2 OBTENDO A TAXA DE COLISES ........................................................................ 247 10.2.1 Descrio e Dicas..................................................................................... 247 10.2.2 Usando uma Estao de Gerncia SNMP ................................................ 248 10.2.3 Usando um analisador de protocolos ....................................................... 250 10.2.4 Usando uma interface de linha de comando............................................. 252 10.2.5 Usando ifconfig......................................................................................... 253 10.3 VERIFICANDO OCORRNCIA DE COLISES TARDIAS .......................................... 253 10.3.1 Descrio e dicas...................................................................................... 254 10.3.2 Usando uma estao de gerncia SNMP.................................................. 254 10.3.3 Usando uma interface de linha de comando............................................. 255 10.4 OBTENDO ESTADO OPERACIONAL DE EQUIPAMENTOS....................................... 256 10.4.1 Descrio e dicas...................................................................................... 256 10.4.2 Usando uma estao de gerncia SNMP.................................................. 256 10.4.3 Usando ping e traceroute ......................................................................... 257 10.5 OBTENDO ESTADO OPERACIONAL DE INTERFACES ............................................ 258 10.5.1 Descrio e Dicas..................................................................................... 258 10.5.2 Usando uma estao de gerncia SNMP.................................................. 258 10.5.3 Usando uma interface de linha de comando............................................. 259 10.5.4 Usando outras ferramentas de gerncia................................................... 260 10.6 OBTENDO UTILIZAO DE CPU ........................................................................ 261 10.6.1 Descrio e dicas...................................................................................... 261 10.6.2 Usando uma estao de gerncia SNMP.................................................. 262 10.6.3 Usando uma interface de linha de comando............................................. 263 10.6.4 Usando top e vmstat.................................................................................. 264 10.7 OBTENDO UTILIZAO DE MEMRIA EM ROTEADORES E COMUTADORES ......... 265 10.7.1 Descrio e dicas...................................................................................... 265 10.7.2 Usando uma estao de gerncia SNMP.................................................. 266 10.7.3 Usando uma interface de linha de comando............................................. 268 10.8 OBTENDO UTILIZAO DE MEMRIA EM HOSPEDEIROS..................................... 270 10.8.1 Descrio e dicas...................................................................................... 270 10.8.2 Usando uma estao de gerncia SNMP.................................................. 270 10.8.3 Usando top................................................................................................ 271 10.9 ANALISANDO QUANTIDADE DE TRFEGO DE BROADCAST E MULTICAST.............. 273 10.9.1 Descrio e dicas...................................................................................... 273 10.9.2 Usando uma estao de gerncia SNMP.................................................. 276 10.9.3 Usando uma interface de linha de comando............................................. 279 10.9.4 Usando um analisador de protocolos ....................................................... 280 10.9.5 Usando outras ferramentas de gerncia................................................... 280 10.10 OBTENDO UTILIZAO DE ENLACES ............................................................... 281 10.10.1 Descrio e Dicas................................................................................... 281 10.10.2 Usando uma estao de gerncia SNMP ................................................ 283 10.10.3 Usando uma interface de linha de comando........................................... 286 10.10.4 Usando um analisador de protocolos ..................................................... 288 10.10.5 Usando outras ferramentas de gerncia................................................. 289 11

S U M R I O

10.11 VERIFICANDO EXISTNCIA DE QUADROS MUITO LONGOS ................................ 290 10.11.1 Descrio e Dicas................................................................................... 290 10.11.2 Usando uma estao de gerncia SNMP ................................................ 290 10.11.3 Usando uma interface de linha de comando........................................... 291 10.11.4 Usando um analisador de protocolos ..................................................... 292 10.12 OBTENDO NEXT E ATENUAO EM CABOS DE PARES TRANADOS ................ 292 10.12.1 Descrio e Dicas................................................................................... 292 10.12.2 Usando uma ferramenta de certificao................................................. 294 10.13 OBTENDO ESTADO ADMINISTRATIVO DE INTERFACES ..................................... 295 10.13.1 Descrio e Dicas................................................................................... 295 10.13.2 Usando uma estao de gerncia SNMP ................................................ 296 10.13.3 Usando uma interface de linha de comando........................................... 296 10.13.4 Usando ifconfig....................................................................................... 297 10.14 VERIFICANDO OCORRNCIA DE ENCHENTES ................................................... 299 10.14.1 Descrio e Dicas................................................................................... 299 10.14.2 Usando uma estao de gerncia SNMP ................................................ 299 10.14.3 Usando um analisador de protocolos ..................................................... 300 10.15 ANALISANDO TRFEGO DE DIFUSO ARP ...................................................... 300 10.15.1 Descrio e Dicas................................................................................... 301 10.15.2 Usando um analisador de protocolos ..................................................... 301 10.16 REFERNCIAS ................................................................................................. 303 10.16.1 Livros ...................................................................................................... 303 10.16.2 Recursos online (Internet)....................................................................... 304 10.16.3 RFCs ....................................................................................................... 305 11 PROCEDIMENTOS REFERENCIADOS NOS PROBLEMAS DE NVEL DE REDE .......................................................................................................................... 307 11.1 VERIFICANDO SE DUAS MQUINAS RESPONDEM MESMA CONSULTA ARP...... 307 11.1.1 Descrio e Dicas..................................................................................... 307 11.1.2 Usando um analisador de protocolos ....................................................... 307 11.2 VERIFICANDO OCORRNCIA DE CONSULTAS ARP SEM RESPOSTA ..................... 309 11.2.1 Descrio e Dicas..................................................................................... 309 11.2.2 Usando um analisador de protocolos ....................................................... 309 11.3 OBTENDO TABELA DE ROTAS DE ROTEADORES ................................................. 312 11.3.1 Descrio e Dicas..................................................................................... 312 11.3.2 Usando uma estao de gerncia SNMP.................................................. 313 11.3.3 Usando uma interface de linha de comando............................................. 313 11.3.4 Usando netstat e route .............................................................................. 314 11.4 VERIFICANDO OCORRNCIA DE REQUISIES DHCP SEM RESPOSTA DO SERVIDOR ................................................................................................................................. 315 11.4.1 Descrio e Dicas..................................................................................... 315 11.4.2 Usando um analisador de protocolos ....................................................... 315 11.4.3 Verificando logs do servidor DHCP......................................................... 316 11.5 VERIFICANDO SE LOG DO SERVIDOR DHCP INDICA FALTA DE ENDEREOS IP .. 318 11.5.1 Descrio e dicas...................................................................................... 318 11.5.2 Verificando logs do servidor..................................................................... 318 11.6 VERIFICANDO OCORRNCIA DE MENSAGENS DHCPNAK NA REDE .................. 319 11.6.1 Descrio e Dicas..................................................................................... 319 11.6.2 Usando um analisador de protocolos ....................................................... 320 11.6.3 Verificando logs do servidor DHCP......................................................... 320 11.7 ANALISANDO REQUISIES DE CLIENTES DHCP EXTERNOS ............................. 320 11.7.1 Descrio e Dicas..................................................................................... 320 11.7.2 Usando um analisador de protocolos ....................................................... 321 11.8 VERIFICANDO EXISTNCIA DE MENSAGENS ICMP DE REDIRECIONAMENTO NA REDE ......................................................................................................................... 322 11.8.1 Descrio e dicas...................................................................................... 322 11.8.2 Usando uma estao de gerncia SNMP.................................................. 323 11.8.3 Usando uma interface de linha de comando............................................. 323 11.8.4 Usando um analisador de protocolos ....................................................... 324 11.9 ANALISANDO TRFEGO DE MENSAGENS ICMP TIME EXCEEDED ...................... 326 12

S U M R I O

11.9.1 Descrio e dicas...................................................................................... 326 11.9.2 Usando uma estao de gerncia SNMP.................................................. 326 11.9.3 Usando uma interface de linha de comando............................................. 327 11.9.4 Usando um analisador de protocolos ....................................................... 327 11.10 ANALISANDO TRFEGO DE MENSAGENS ICMP DE DESTINO INALCANVEL .. 329 11.10.1 Descrio e Dicas................................................................................... 329 11.10.2 Usando uma estao de gerncia SNMP ................................................ 329 11.10.3 Usando uma interface de linha de comando........................................... 330 11.10.4 Usando um analisador de protocolos ..................................................... 331 11.11 VERIFICANDO SE PACOTES ESTO SENDO DESCARTADOS POR FALTA DE ROTAS ................................................................................................................................. 334 11.11.1 Descrio e dicas.................................................................................... 334 11.11.2 Usando uma estao de gerncia SNMP ................................................ 334 11.11.3 Usando uma interface de linha de comando........................................... 334 11.12 ANALISANDO A ORIGEM DO TRFEGO DE DIFUSO EM UM DOMNIO DE DIFUSO ................................................................................................................................. 335 11.12.1 Descrio e Dicas................................................................................... 335 11.12.2 Usando um analisador de protocolos ..................................................... 336 11.13 ANALISANDO A CONFIGURAO DE REDE EM UM HOSPEDEIRO ....................... 338 11.13.1 Descrio e dicas.................................................................................... 338 11.13.2 Usando outras ferramentas de gerncia................................................. 338 11.14 VERIFICANDO CONECTIVIDADE VIA IP E CONECTIVIDADE VIA NOME DE DOMNIO ................................................................................................................................. 341 11.14.1 Descrio e Dicas................................................................................... 341 11.14.2 Usando ping............................................................................................ 341 11.15 REFERNCIAS ................................................................................................. 342 11.15.1 Recursos online (Internet)....................................................................... 342 11.15.2 RFCs ....................................................................................................... 342 11.15.3 Livros base.............................................................................................. 342 12 PROCEDIMENTOS REFERENCIADOS NOS PROBLEMAS DE NVEL DE APLICAO ............................................................................................................. 343 12.1 VERIFICANDO CONSISTNCIA DE DADOS NOS SERVIDORES DNS PRIMRIO E SECUNDRIOS ........................................................................................................... 343 12.1.1 Descrio e dicas...................................................................................... 343 12.1.2 Usando nslookup, dig e host ..................................................................... 344 12.2 ANALISANDO MENSAGENS DE LOG DO SERVIDOR DNS BIND .......................... 347 12.2.1 Descrio e Dicas..................................................................................... 347 12.2.2 Verificando logs do servidor DNS ............................................................ 348 12.3 VERIFICANDO A RESOLUO DE NOMES DE DOMNIO EXTERNOS ...................... 349 12.3.1 Descrio e Dicas..................................................................................... 349 12.3.2 Usando nslookup, dig e host ..................................................................... 349 12.4 ANALISANDO TRFEGO DNS DE UM SERVIDOR DE NOMES DE DOMNIO ........... 353 12.4.1 Descrio e Dicas..................................................................................... 353 12.4.2 Usando um analisador de protocolos ....................................................... 353 12.5 VERIFICANDO CONSISTNCIA DE MAPEAMENTOS DNS DIRETO E REVERSO ...... 354 12.5.1 Descrio e dicas...................................................................................... 354 12.5.2 Usando nslookup, dig e host ..................................................................... 355 12.6 CONSULTANDO O SERVIDOR DNS E OBTENDO RESPOSTAS COM NOMES DE DOMNIO DUPLICADOS .............................................................................................. 358 12.6.1 Descrio e Dicas..................................................................................... 358 12.6.2 Usando nslookup, dig e host ..................................................................... 358 12.7 VERIFICANDO SE UM SERVIDOR SMTP EST COM REPASSE TOTALMENTE FECHADO .................................................................................................................. 361 12.7.1 Descrio e Dicas..................................................................................... 361 12.7.2 Usando uma interface de linha de comando............................................. 361 12.8 VERIFICANDO SE UM SERVIDOR SMTP EST COM RELAY TOTALMENTE ABERTO363 12.8.1 Descrio e Dicas..................................................................................... 363 12.8.2 Usando uma interface de linha de comando............................................. 363 12.8.3 Usando servios oferecidos por instituies anti-spam............................ 364 13

S U M R I O

12.9 REFERNCIAS ................................................................................................... 364 12.9.1 Livros ........................................................................................................ 364

14

Parte I Introduo

Captulo

1. RESUMO

ste captulo est dividido em trs grandes sees: introduo gerncia de redes, organizao tpica de uma equipe de gerncia e analogia entre Gerncia de Redes e a Medicina.

Na primeira seo oferecemos uma breve introduo gerncia de redes. Para manter o bom funcionamento de uma rede de computadores necessrio o auxlio de instrumentao adequada: uma ou mais estaes de gerncia que mostrem o mapa da rede e estatsticas como taxa de erros, de colises, estado operacional de equipamentos e interfaces, dentre outras; analisadores de protocolos e outras ferramentas de gerncia como ping, traceroute e netstat. preciso tambm saber utilizar estas ferramentas e saber interpretar os dados de gerncia obtidos com elas. Para muitas informaes de gerncia estabelecemos limiares que, quando ultrapassados, indicam problemas e podem gerar alarmes. Na segunda seo mostramos a organizao tpica de um time de gerncia. O help desk responsvel por ouvir reclamaes de usurios sobre recursos de tecnologia da informao, consertar problemas, repassando para outros tcnicos aqueles que no pode solucionar. A equipe de suporte tcnico a responsvel final pela manuteno e configurao da rede. O operador da rede responsvel por receber os alarmes gerados pela estao de gerncia. Existe ainda o gerente da equipe, que dirige e monitora o desempenho dos membros da equipe. Esta diviso no obrigatria. possvel que uma ou duas pessoas apenas formem a equipe e acumulem para si todos os papis apresentados. Finalmente, a analogia entre a Gerncia de Redes e a Medicina apresentada na terceira seo deste captulo. Um gerente de redes pode ser considerado o mdico da rede, capaz de tratar as possveis doenas (problemas apresentados pela rede) que possam surgir.

1 Introduo Gerncia de Redes

Nas prximas sees deste captulo uma introduo bsica Gerncia de Redes de Computadores, a organizao tpica da equipe de gerncia em uma empresa e uma analogia entre a Medicina e a Gerncia de Redes que nos acompanhar durante todo o livro.

16

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

1.1 Introduo Gerncia de Redes de Computadores

O objetivo da Gerncia de Redes monitorar e controlar os elementos da rede (sejam eles fsicos ou lgicos), assegurando um certo nvel de qualidade de servio. Para realizar esta tarefa, os gerentes de redes so geralmente auxiliados por um sistema de gerncia de redes. Um sistema de gerncia de rede pode ser definido como uma coleo de ferramentas integradas para a monitorao e controle da rede. Este sistema oferece uma interface nica, com informaes sobre a rede e pode oferecer tambm um conjunto poderoso e amigvel de comandos que so usados para executar quase todas as tarefas da gerncia da rede [STALLINGS]. A arquitetura geral dos sistemas de gerncia de redes apresenta quatro componentes bsicos: elementos gerenciados, estaes de gerncia, protocolos de gerncia e informaes de gerncia. A seguir falaremos um pouco sobre cada um deles: os elementos gerenciados possuem um software agente. Este software permite que o equipamento especial chamado seja monitorado e controlado atravs de uma ou mais estaes de gerncia; em um sistema de gerncia de redes deve haver pelo menos uma Em sistemas de gerncia distribudos existem duas ou mais estaes de gerncia. Em sistemas centralizados mais comuns existe apenas uma. Chamamos de gerente o software da estao de gerncia que conversa diretamente com os agentes nos elementos gerenciados, seja com o objetivo de monitor-los, seja com o objetivo de control-los. A estao de gerncia oferece uma interface atravs da qual usurios autorizados podem gerenciar a rede;

estao de gerncia.

para que a troca de informaes entre gerente e agentes seja possvel necessrio que eles falem o mesmo idioma. O idioma que eles falam um protocolo de gerncia. Este protocolo permite operaes de monitoramento (leitura) e controle (escrita); gerentes e agentes podem trocar informaes, mas no qualquer tipo de informao. As informaes de gerncia definem os dados que podem ser referenciados em operaes do protocolo de gerncia, isto , dados sobre os quais gerente e agente conversam. Na Figura 1-1 vemos roteadores, comutadores2, repetidores, impressoras, servidores e estaes clientes. Todos estes equipamentos podem ter agentes instalados (idealmente tero). A estao de gerncia deve obter informaes de gerncia destes agentes usando o protocolo SNMP.

Consideramos que comutadores so equipamentos que realizam todas as tarefas realizadas por pontes e apresentam ainda algumas funcionalidades adicionais como, por exemplo definio de VLANs (Virtual LANs). No utilizaremos em nenhum momento a palavra ponte quando nos referirmos a equipamentos de interconexo que operam na camada de enlace. Exceto quando estivermos tratando de funcionalidades no suportadas pelas pontes, o que for dito para comutadores vlido tambm para pontes.

17

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

Figura 1-1: Elementos de uma arquitetura geral de soluo de gerncia.

A padronizao de soluo de gerncia mais usada no mundo chama-se InternetStandard Network Management Framework. Ela soluo mais conhecida como gerncia SNMP. SNMP Simple Network Management Protocol o protocolo de gerncia deste padro. Este padro descreve no apenas o protocolo de gerncia, mas tambm um conjunto de regras que so usadas para definir as informaes de gerncia e um conjunto inicial de informaes de gerncia que j podem ser utilizadas [ROSE]. Atravs da estao de gerncia podemos obter informaes tais como: taxa de erros, estado operacional de enlaces e equipamentos, utilizao de enlace, dentre outras. To importante quanto obter estas informaes saber interpret-las. Por exemplo, em um determinado momento, a estao de gerncia informa que a taxa de erros de um certo enlace 1%. Esta uma taxa de erros aceitvel? Para muitas informaes de gerncia estabelecemos valores limites. Se o valor da informao obtida for maior que o limite estabelecido inferimos que algo anormal est ocorrendo na rede. Chamamos estes limites de limiares (thresholds). Assim, quando dizemos que limiares foram excedidos, estamos querendo dizer que obtivemos valores de informaes de gerncia que no esto dentro da faixa de normalidade e, portanto, so indicativos de problemas. Limiares excedidos e outros eventos podem gerar alarmes na estao de gerncia. Quando a estao de gerncia percebe que uma interface parou de operar, por exemplo, um alarme pode ser gerado. Alm do sistema de gerncia de redes, outras ferramentas nos auxiliam a gerenciar uma rede. Dentre elas encontram-se analisadores de protocolos e
18

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

outras ferramentas mais simples como os comandos ping, traceroute e netstat, disponveis sob vrios sistemas operacionais. Com os analisadores de protocolos podemos ver quais dados esto trafegando na rede. Eles nos permitem tirar um raio-X da rede, sendo, portanto, ferramentas importantes de gerncia. Certas tarefas da gerncia s podem ser realizadas com o auxlio de um analisador de protocolos. Em todo o livro e, em especial, nos procedimentos (ver Seo 2.3) estaremos falando de estaes de gerncia SNMP, informaes de gerncia, limiares, analisadores de protocolos e outras ferramentas de gerncia. Nesta seo apresentamos uma brevssima introduo gerncia de redes. Tentamos expor aqui apenas algumas definies que precisam ser entendidas antes que voc continue a leitura deste livro. Se voc sentir a necessidade de saber mais sobre a teoria de gerncia veja algumas referncias recomendadas na Seo REFERNCIAS no final deste captulo. Leia mais sobre SNMP no apndice 3. No apndice 2 encontra-se uma breve introduo (e motivao para o uso) sobre ferramentas de gerncia.

1.2 O papel do gerente de redes

Um dos objetivos da gerncia de redes prevenir e solucionar problemas na rede. Geralmente esta tarefa realizada por uma equipe. No existe uma regra rgida sobre os profissionais que fazem parte desta equipe. Cada organizao tem autonomia para criar seu prprio time de gerncia de redes de acordo com suas convenincias. Porm, comum que nesta equipe existam profissionais que executem quatro tarefas distintas: o pessoal do help desk, o operador da rede, a equipe de suporte tcnico e o gerente da equipe de gerncia. Nesta seo iremos estudar as responsabilidades de cada um destes profissionais. Quando os usurios enfrentam problemas relacionados tecnologia de informao (os computadores nas suas mesas, aplicaes, servios, problemas na rede, etc.), eles pedem auxlio ao help desk. Em algumas organizaes o help desk composto por apenas uma pessoa, que atende chamadas telefnicas de usurios e tem certo grau de conhecimento para lidar com alguns problemas que forem reportados. Em organizaes maiores, o help desk composto por um grupo de pessoas um pouco mais especializadas, auxiliadas por aplicaes que ajudam a gerenciar os problemas reportados (incluir novo problema, ver estado de problemas, criticalidade, etc.). Alm disso, esta equipe pode ser auxiliada por outras ferramentas que ofeream informaes que possam ajudar a localizar e/ou solucionar problemas. Por exemplo, ferramentas que apresentam o estado operacional das interfaces e equipamentos da rede. Geralmente, esta equipe capaz de solucionar os problemas mais simples e os erros cometidos pelos prprios usurios. Quando o help-desk existe, os usurios nunca (ou muito raramente) tm contato com a equipe de suporte tcnico ou com o operador da rede, apenas com o help-desk. Quando um usurio reporta um problema, o help desk solicita ao usurio algumas informaes (mais detalhes sero apresentados na Seo 3.2), como por
19

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

exemplo, desde quando o problema est sendo observado e em que momentos do dia. Quando o help desk no capaz de solucionar o problema em curto espao de tempo, todas as informaes coletadas so repassadas imediatamente a uma outra equipe: o pessoal do suporte tcnico. A equipe de suporte tcnico quem pe a mo na massa para solucionar os problemas mais abrangentes que surgirem ou que possam surgir e que no foram solucionados pela equipe de help desk ou pelo operador do sistema. esta a equipe responsvel pela configurao, operao e manuteno dos equipamentos da rede. Este , portanto, o time que precisa possuir o maior nvel de conhecimento tcnico. Foi pensando mais especificamente neste pessoal que escrevemos este livro. O operador do sistema o profissional encarregado de acompanhar os alarmes gerados pela estao de gerncia. Quando, por exemplo, um equipamento passa para o estado no operacional, o operador da rede perceber um alarme na estao de gerncia. Alarmes podem ser informados de diversas formas: mudana de cores no mapa da rede (o vermelho em geral indica problema), por e-mail, celular, etc. Quando o operador percebe que um problema est ocorrendo ou pode ocorrer, ele tenta resolver o problema ou o encaminha equipe de suporte tcnico. O gerente da equipe de gerncia de rede no , necessariamente, um tcnico em redes. O gerente tem um certo conhecimento em redes, mas no no nvel do suporte tcnico. Dentre as atividades deste gerente encontram-se: avaliar o desempenho da sua equipe de suporte, solicitar compra de equipamentos, aplicaes ou outros recursos necessrios, providenciar treinamento adequado para a equipe, reescalonar a soluo de problemas para outros membros da equipe quando a soluo demora, etc. Para avaliar o desempenho da equipe de gerncia, o gerente pode se valer de certas mtricas tais como: o tempo mdio entre falhas e o tempo mdio para correo de falhas na rede, percentual de problemas resolvidos em menos de 1 hora, entre outros. importante ressaltarmos novamente que esta diviso da equipe de gerncia3 de redes comum, mas no obrigatria. Podem existir organizaes pequenas onde o mesmo profissional acumula todas as tarefas descritas. possvel tambm que o prprio suporte tcnico realize as tarefas do operador da rede. Em organizaes maiores o suporte tcnico pode ser dividido em primeiro e segundo nveis. Enfim, o importante que voc saiba que, na realidade, o profissional que chamamos neste livro de gerente de redes pode assumir vrios papis distintos em momentos distintos, mas geralmente, estaremos falando com a equipe de suporte tcnico. A Figura 1-2 ilustra os papis mais comuns dos componentes da equipe de gerncia de redes.

Na realidade, o help desk no faz parte apenas da equipe da gerncia da rede. Os usurios ligam para o help desk quando enfrentam problemas relacionados tecnologia de informao, o que inclui problemas com a rede.

20

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

A R A

Q U E M E S T E L I V R O F O I E S C R I T O

Em muitas organizaes, alm da equipe de gerncia de redes existe a equipe de gerncia de aplicaes. Muitas vezes, a equipe de gerncia de aplicaes culpa a rede pelo mau desempenho de suas aplicaes (e vice versa!). , portanto, salutar que a equipe de rede colete informaes da rede que possam ser apresentadas equipe de gerncia de aplicaes quando necessrio, para provar (ou no) que tudo est bem com a infra-estrutura de rede. Utilizao de enlaces e taxa de erros so dados sempre interessantes.

Figura 1-2: Uma equipe de gerncia de redes de computadores.

1.3 Voc: o mdico da rede

Voc j se deu conta de que voc um mdico? No bem aquele mdico que consultamos quando estamos doentes. Na realidade, voc um mdico diferente. O seu paciente a rede que voc gerencia. No dicionrio, a primeira definio da Medicina : Arte e cincia de prevenir e curar as doenas. Qual seria a arte e cincia responsveis por prevenir e solucionar os problemas da rede? No seria a Gerncia de Redes? Vamos adequar esta definio de Medicina e criar uma definio para a gerncia de redes: Arte e cincia de prevenir e solucionar os problemas da rede. A diferena entre um mdico e uma pessoa responsvel pela gerncia de uma rede que o paciente do mdico um ser humano, enquanto o paciente do gerente de redes a rede. Felizmente, nossa realidade no to rdua quanto a dos mdicos reais: no existem problemas sem soluo. Ela pode ser cara, ser complexa, mas sempre existe. Percebendo esta semelhana com a Medicina, podemos escrever os problemas de redes que apresentaremos na Parte II do livro baseados nesta analogia, apresentada na Tabela 1-1.
21

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

Medicina Muitas doenas podem ser prevenidas, outras no. Por exemplo, a AIDS uma doena que pode ser prevenida, j a leucemia no.

Gerncia de Redes Um problema de rede para ns, gerentes, o que uma doena para um mdico. Alguns podem ser prevenidos quando utilizamos boas prticas de projeto e configurao e manuteno de redes, outros no. Um problema de rede algo que deve ser consertado diretamente. Um roteador com configurao errada, por exemplo. Rede lenta e falta de conectividade no so problemas, elas no so consertadas diretamente. Elas so manifestaes da rede devido a um problema. Ao se consertar o problema, estas manifestaes devem cessar. Para ns um sintoma tem o mesmo significado, mas, como a rede no fala, os usurios que os descrevero. Quando a rede est com problemas o pessoal do helpdesk4 receber bastantes ligaes. So os usurios reclamando que a rede est lenta, que no conseguem enviar e-mails ou que a rede no est funcionando. No contexto da gerncia, sintomas so as conseqncias de um problema para os usurios. Rede lenta e falta de conectividade so exemplos de sintomas de problemas.

Quando estamos doentes vamos ao mdico. A primeira pergunta que ele nos faz : o que voc est sentindo? Em geral, respondemos esta pergunta descrevendo o que o mdico chama de sintomas. No dicionrio, a palavra sintoma tem o seguinte significado quando empregada Medicina: Qualquer fenmeno de carter subjetivo provocado no organismo por uma doena, e que, descritos pelo paciente, auxiliam, em grau maior ou menor, a estabelecer um diagnstico. Aps conversar com o paciente e descobrir o que ele est sentindo, o mdico realiza alguns exames e observaes em busca de sinais. Quem nunca foi para um otorrinolaringologista5? Com instrumentao adequada ele vai realizar certos exames (o exame da garganta certamente o pior deles). Com estes exames o mdico obtm mais informaes, que iro lhe auxiliar a chegar ao diagnstico correto. Estes exames s podem ser realizados pelo

Em uma rede no diferente. Os usurios assim como os pacientes podem observar certos sintomas. Mas s o time de gerncia est instrumentado e capacitado para coletar e interpretar informaes mais ntimas da rede: os sinais. Por exemplo, um usurio nunca ligaria dizendo que a rede est lenta porque a taxa de colises no domnio de colises do qual participa est muito elevada. Em primeiro lugar porque ele provavelmente no sabe o que so colises. Em segundo, ele no sabe como calcular esta taxa e no tem instrumentos adequados para tal. Por fim, e no menos

Ou outro profissional com o qual os usurios da rede entrem em contato para fazer reclamaes. Mdico que trata de doenas de ouvido, nariz e garganta.

22

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

mdico, que tem instrumentao e/ou procedimentos adequados para coletar certas informaes, e conhecimentos suficientes para interpret-las.

importante, ele no sabe o limiar para a taxa de colises. Quanto muito? 25%? Ele no sabe. Os sinais de que um problema existe so os mais diversos: taxa de colises elevada, trfego de difuso em excesso, taxa de erros elevada, dentre outros. Um gerente s capaz de obter informaes de gerncia com instrumentao adequada. Aps obtlas, o gerente precisa saber interpret-las, isto , precisa identificar quando esto com valores estranhos, tornando-se sinais. Problemas de rede tambm podem apresentar sinais patognomnicos. Chamaremos estes sinais de sinais diferenciais. Quando o sinal diferencial encontrado nenhum teste confirmatrio necessrio. J achamos o problema. Muitos problemas de redes podem causar sinais e sintomas bastante semelhantes, sendo impossvel distinguir, antes de uma anlise mais detalhada, que problema est ocorrendo. Quando no formos capazes de identificar o problema com os sintomas e sinais reunidos, devemos realizar testes confirmatrios. Por exemplo, aps analisar os sintomas/sinais, podemos ficar em dvida entre um cabo danificado ou uma interface defeituosa. Ento, precisamos testar cada uma destas suspeitas para, enfim, chegar ao diagnstico. possvel que um problema seja detectado na rede antes mesmo dos usurios o terem percebido. Este o objetivo da gerncia de redes pr-ativa. Numa rede bem administrada, problemas de rede devem ser de conhecimento da equipe de gerncia antes que os usurios percebam problemas. (pelo menos quando o problema afetar mais do que uma simples estao de trabalho). Numa empresa onde os problemas so descobertos apenas com reclamao de usurios, a equipe de gerncia no est fazendo um bom trabalho. A rede em si pode ser um paciente, se adequadamente instrumentada. Ela mesma fala que est doente.
23

Certas doenas apresentam sinais tpicos, cuja existncia confirmam o diagnstico sem a necessidade de testes adicionais. Na Medicina, estes sinais so chamados patognomnicos. Para dar o diagnstico diferencial quando os sintomas e sinais coletados, por si s, no confirmam uma determinada doena, o mdico precisa realizar alguns testes para confirmar ou negar suas suspeitas. Por exemplo, aps os exames, o mdico est em dvida entre dois diagnsticos. Ento ele vai realizar outros testes ou exames que possam confirmar uma das hipteses e negar as demais. Muitas vezes uma doena pode ser descoberta antes mesmo dos seus sintomas se manifestarem. Por exemplo, em um exame de rotina no ginecologista, uma mulher pode descobrir que est com cncer de ovrio, apesar de nenhum sintoma ter se manifestado ainda.

C A P T U L O

I N T R O D U O

G E R N C I A

D E

R E D E S

Tabela 1-1: Analogia entre a Medicina e a Gerncia de Redes.

1.4 Referncias 1.4.1 Livros

[HARNEDY] Harnedy, S., Harnedy, S. J. Total SNMP: Exploring the Simple Network Management Protocol. Segunda Edio. Editora Prentice Hall, Agosto, 1997.

[MAURO & Mauro, Schmidt. Essential SNMP. OReilly and Associates, 2001. SCHMIDT] [ROSE1] [ROSE2] Rose, T. M. The Simple Book: An Introduction to Network Management. Segunda Edio. Editora Prentice Hall, Maro, 1996. Rose, T.M., McCloghrie, K. How to Manage Your Network using SNMP: The Network Management Practicum. Editora Prentice Hall, Janeiro, 1995. Stallings, W. SNMP, SNMPv2, SNMPv3 and RMON1 and 2. Terceira Edio. Editora Addison-Wesley, 1998.

[STALLINGS]

24

Captulo

2. RESUMO

o catlogo de problemas voc encontrar informaes sobre 37 problemas, classificados por camada OSI, que podem ocorrer em uma rede de computadores. Para cada um destes problemas apresentamos:

uma descrio do problema; efeito negativo do problema observado pelos usurios da rede (sintomas); comportamentos ou caractersticas internas da rede que podem ser observadas pelo time de gerncia com instrumentao adequada (sinais). Para cada sinal apresentado existe um procedimento que informa como obt-lo; testes adicionais que podem confirmar o problema; sugestes de como solucionar o problema.

2 Introduo ao catlogo de problemas

Apesar do ttulo, neste captulo introduzimos no apenas o catlogo de problemas (Parte I), mas tambm os procedimentos (Parte II). Na primeira seo apresentamos um breve resumo da analogia entre a Medicina e a Gerncia de Redes, para aqueles que no leram o Captulo 2. Na seo seguinte apresentamos o que o catlogo de problemas, como ele est organizado, por que ele est organizado assim e o que so os ndices invertidos. Por fim, definimos os procedimentos e sua organizao.

2.1 Analogia entre a Gerncia de Redes e a Medicina

Na Tabela 2-1 apresentamos um pequeno resumo da analogia entre a Gerncia de Redes e a Medicina. Para obter mais detalhes consulte a Seo 1.3. Medicina
Sintomas:

Gerncia de Rede

o que um paciente sente Sintomas: o que o usurio da rede quando est doente. sente quando um problema est ocorrendo.
25

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

Sinais: informaes sobre o Sinais: informaes sobre o estado/comportamento do paciente estado/comportamento da rede obtidas pelo mdico atravs de exames obtidas pelo gerente da rede com o e/ou observaes. auxlio de instrumentao adequada. Sinais patognomnicos:

sinais cuja Sinais diferenciais: sinais cuja existncia j confirmam a existncia de existncia confirmam um certo uma certa doena. problema.
Testes confirmatrios:

testes que o Testes confirmatrios: testes que o mdico precisa realizar para chegar ao gerente de redes precisa realizar para diagnstico diferencial quando estiver confirmar ou negar um ou mais suspeitando de vrias doenas. problemas.
Tabela 2-1: Resumo da analogia entre a Medicina e a Gerncia de Redes.

2.2 O catlogo de problemas

O catlogo de problemas uma coletnea de 376 problemas que podem ocorrer em uma rede. Como a metodologia de deteco de problemas que seguimos (ver Captulo 3) sugere que as hipteses sejam testadas por camadas da camada fsica em direo camada de aplicao os problemas foram agrupados no catlogo por camada OSI. Um problema algo que se deve consertar diretamente, como um cabo com conector frouxo ou uma configurao errada de um roteador. Rede lenta, por exemplo, no um problema, pois no se conserta a lentido da rede diretamente. Rede lenta , sim, um sintoma de um problema. Ao consertar o problema, os sintomas no mais devem ser percebidos. No catlogo de problemas desta edio encontramos os problemas apresentados na Tabela 2-2. Levando em considerao a analogia com a Medicina e a metodologia para deteco, diagnstico e resoluo de problemas (que ser apresentada no captulo a seguir), um problema tem 5 elementos essenciais:
1. Descrio

Na descrio de um problema sero apresentadas as circunstncias em que o problema surge. Algumas vezes podero tambm ser apresentadas causas mais comuns e subconjuntos mais especficos deste problema. Se fosse uma doena, a descrio (resumida) de resfriado seria: processo inflamatrio causado por vrus ou por vrus associados a outros microrganismos ou, ainda, de natureza alrgica. A descrio importante para que voc entenda o problema. Ao ler a descrio voc j comear a ter uma boa idia do reflexo do problema na rede, pois voc o ter entendido.

Pretendemos aumentar o nmero de problemas includos no catlogo a cada nova edio do livro.

26

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

Camada Fsica

Camada de Enlace

Camada de Rede

Camada de Aplicao

Cabo rompido ou danificado; Conector defeituoso ou mal instalado; Descasamento de modo e/ou velocidade de operao; Equipamento de interconexo defeituoso; Placa de rede ou porta de equipamento de interconexo defeituosas; Interferncia no cabo; Saturao de banda em segmentos Ethernet compartilhados; Tipo errado de cabo; Violao de regras de cabeamento Ethernet; Interface desabilitada; Problema com rvore de cobertura; Saturao de recursos devido a excesso de quadros de difuso; Tempo de envelhecimento de tabelas de endereos inadequado; Validade da cache ARP inadequada; Tabela de rotas de hospedeiros incorretas; Endereo IP de hospedeiro incorreto; Hospedeiro com mscara de rede incorreta; Cliente DNS mal configurado; Servidor DHCP mal configurado; Rotas estticas mal configuradas; Equipamento inserido em VLAN incorreta; VLANs no esto configuradas; Comutadores no conseguem trocar informaes sobre VLANs entre si; Ambiente RIP-1 com VLSM e/ou redes no contguas; Dimetro RIP com mais de 15 roteadores; Roteadores RIP-2 no enviam ou recebem pacotes RIP-1; Trfego RIP saturando largura de banda Filtro IP no permite a passagem de trfego RIP (UDP 520); O servio de nomes no est habilitado; DNS: descasamento de registros A e PTR em arquivos de zonas; Inconsistncia entre registros dos servidores DNS primrio e secundrios; O TTL default de uma zona DNS no est configurado; DNS: TTL e outros campos do registro SOA com valores inadequados; Falta . aps nomes totalmente qualificados em registros DNS; Filtro IP barrando trfego DNS; Servidor de correio eletrnico com repasse totalmente aberto;
27

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

Servidor de correio eletrnico com repasse totalmente fechado;

Tabela 2-2: Problemas organizados por camada OSI trazidos nesta edio.
2. Sintomas

Os sintomas de um problema informam o que os usurios da rede podem perceber como conseqncia da existncia do problema. Em outras palavras, os sintomas descrevem o efeito negativo do problema para os usurios. Sintomas tpicos de problemas em rede so: a rede est lenta, a rede no est funcionando, um determinado servio est indisponvel. Lembre-se que voc tambm usurio da rede e, como tal, pode perceber os sintomas.
3. Sinais

Os sinais so caractersticas mais internas da rede que tm seu estado normal alterado em conseqncia da existncia do problema. Os sinais, geralmente, no so percebidos pelos usurios, pois eles s podem ser obtidos com o auxlio de instrumentao adequada, como estaes de gerncia, analisadores de protocolos ou outras ferramentas de gerncia. So manifestaes adicionais, alm das manifestaes externas que se apresentam aos usurios. Cada sinal referencia um procedimento. Cada procedimento informa pelo menos uma maneira de obter o sinal em questo. Falaremos mais sobre os procedimentos na Seo 2.3. Alguns sinais podem no ser percebidos na fase de busca das informaes, apenas na fase de testes. possvel ainda que o problema seja confirmado sem que todos os sinais apresentados sejam vistos. O objetivo deste campo descrever caractersticas internas da rede que podem ser observadas quando um determinado problema estiver ocorrendo. Alguns sinais so facilmente percebidos quando utilizamos uma boa estao de gerncia: taxa de erros, estado operacional de enlaces e equipamentos, dentre outros. Outros sinais s podem ser detectados com o auxlio de um analisador de protocolos ou uma interface de linha de comando. Alm disso, possvel que em uma situao especfica, voc encontre sinais que no listamos aqui para um determinado problema.
4. Testes confirmatrios

Os testes confirmatrios indicam os passos que devem ser seguidos para confirmar ou negar a existncia do problema de rede que est sendo apresentado. Quando sinais diferenciais forem encontrados, no ser necessria a realizao de testes adicionais para confirmar o problema.
5. Sugestes de tratamento

Nas sugestes de tratamento iremos sugerir solues eficientes para o problema sendo descrito. O problema que foi confirmado deve ser
28

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

solucionado o mais rapidamente possvel. A soluo deve ser tambm correta, no introduzindo outros problemas na rede. Alm disso, em alguns casos, daremos sugestes de como proceder para evitar que o problema ocorra. Neste caso, alm do tratamento indicamos a preveno.

2.2.1 Por que um catlogo de problemas?

Neste momento, voc pode estar se perguntando: por que essa turma escreveu um catlogo de problemas e no de sintomas? Esta uma boa questo, que merece uma explicao. Nosso intuito inicial foi criar um catlogo de sintomas. Mas, nossos primeiros estudos mostraram e voc perceber isso ao ler o catlogo que um sintoma pode ser causado por diversos problemas diferentes. O sintoma rede lenta, por exemplo, pode ser causado por um grande nmero de problemas. Alm disso, um mesmo problema pode causar ora um sintoma ora outro. Ao considerar um catlogo de sintomas teramos muito a falar sobre cada sintoma. Alguns problemas teriam que ser referenciados em um determinado sintoma e repetidos em outros sintomas. No achamos didtico misturar vrios problemas desta forma. Organizar o catlogo por sinal tambm no se mostrou uma boa idia. Muitos sinais tambm se repetem em vrios problemas diferentes, levando mesma situao de um catlogo escrito por sintomas. Alm disso, um nico sinal (exceto quando ele diferencial) pode no dizer muito sobre o problema. Existem problemas distintos em que o mesmo sinal se repete, e a existncia de outro sinal um fator chave para a localizao do problema. Decidimos ento organizar o catlogo por problema, mostrando, para cada um deles os possveis sintomas e sinais. A finalidade de um gerente de redes diante de uma notificao de um problema descobrir e solucionar o problema, no os sintomas e sinais. Estes devem ser conhecidos para que o problema seja localizado. Os sinais e sintomas so o meio, no o fim. Concordamos, no entanto, que uma tabela indexada por grupos especficos de sintomas e sinais ajudaria bastante na hora de criar hipteses. Portanto, criamos os ndices invertidos, onde cada grupo especfico de sintomas ou sintomas/sinais referencia um ou mais problemas. Falaremos mais sobre os ndices invertidos na seo a seguir. Uma outra razo que nos leva a organizar o catlogo por problema diz respeito ao desenvolvimento e melhoramento futuros do catlogo. Da forma como ele est organizado, novos problemas podem ser inseridos e melhorados facilmente, pois j sabemos onde encontr-los. Se o catlogo fosse de sintomas, modificaes e adies no seriam to simples. Precisaramos encontrar os locais correto para inserir cada novo problema, j que estariam todos juntos, sendo referenciados pelo mesmo sintoma.

29

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

2.2.2 Os ndices invertidos

Os ndices invertidos so tabelas que nos ajudam a descobrir que problemas podem ser causados por determinados grupos de sintomas e sinais. No Captulo 8 (ltimo captulo da Parte II do livro), voc encontrar dois ndices invertidos: o ndice invertido de sintomas e o ndice invertido de sintomas e sinais. Os ndices invertidos so particularmente importantes quando a rede que voc gerencia estiver com problema. De posse dos sintomas e sinais coletados sobre o problema, voc pode recuperar, atravs dos ndices invertidos, que problemas podem estar ocorrendo na rede. Isto ficar mais claro no captulo seguinte, quando apresentamos como o catlogo, os ndices e os procedimentos podem ser usados em conjunto com uma metodologia para deteco, diagnstico e resoluo de problemas de rede.

2.3 Os procedimentos
Na seo anterior, quando falvamos de sinais, dissemos que cada sinal referencia um procedimento e cada procedimento ensina pelo menos uma maneira de se obter o sinal em questo. Nesta seo explicaremos o que queremos dizer com isso. Para ns um sinal uma informao interna ou caracterstica da rede, que deve ser obtida com o auxlio de instrumentao adequada. Um procedimento ensina como obter um sinal e interpret-lo. Eis alguns exemplos de sinais: taxa de erros elevada, taxa de colises elevada, requisies ARP sem resposta e resoluo de nomes externos no funciona. Sobre todos os sinais podemos perguntar: como posso obt-lo? Outras perguntas que podem ser feitas so: quando considero que seu valor est Os procedimentos tm o objetivo de responder estas perguntas.
anormal? O que este sinal significa? Qual seria o comportamento normal?

Cada procedimento, assim como cada problema do catlogo, ser apresentado de uma forma padronizada. Em sees chamadas DESCRIO E DICAS descrevemos o que o sinal significa, e, quando cabvel, que valores do sinal so considerados anormais ou como deveria ser o comportamento normal da rede ou servio envolvido. Na realidade, quando chamamos a informao de gerncia de sinal, significa que o seu valor ou comportamento j no normal. Desta forma, seria mais correto reescrever a frase anterior da seguinte forma: em sees chamadas DESCRIO E DICAS descrevemos o que a informao de gerncia significa, e que valores ou comportamentos so considerados anormais, transformando-a em um sinal de problema. A forma como a informao de gerncia obtida , na prtica, dependente do tipo de instrumentao que devemos usar. Para cada sinal apresentado, existe uma instrumentao mais adequada. Tentamos, no entanto, apresentar vrias formas de obter cada sinal, uma vez que muitas equipes podem no possuir toda a instrumentao. Cada leitor tenta obter o sinal com os instrumentos de que dispe.
30

C A P T U L O

I N T R O D U O

A O

C A T L O G O

D E

P R O B L E M A S

Em sees chamadas USANDO UMA ESTAO DE GERNCIA SNMP apontamos que variveis de gerncia SNMP devem ser monitoradas e como devem ser combinadas a fim de se obter a informao de gerncia em questo. Sees chamadas USANDO UMA INTERFACE DE LINHA DE COMANDO explicam como obter a informao de gerncia com o auxlio de uma interface de linha de comando: a interface oferecida pelo software dos equipamentos de interconexo. Para mais informaes sobre interface de linha de comando veja o procedimento apresentado na Seo 9.2. Se for possvel ou necessrio obter a informao de gerncia desejada atravs de um analisador de protocolos, o procedimento a ser seguido ser explicado em sees intituladas USANDO UM ANALISADOR DE PROTOCOLOS. Pode ser ainda possvel obter a informao de gerncia com o auxlio de outras ferramentas de gerncia, geralmente programas de computador ou hardware especial. Neste caso, o ttulo da seo muda dependendo da ferramenta a ser apresentada. Se as ferramentas a serem utilizadas forem, por exemplo, ifconfig e netstat, a seo ser intitulada USANDO IFCONFIG E NETSTAT. Alguns sinais podem ser obtidos atravs de vrios tipos de instrumentao, outros no. Podemos obter a taxa de erros com o auxlio de uma estao de gerncia, de uma interface de linha de comando, de um analisador de protocolos e de outras ferramentas de gerncia, como netstat. Por outro lado, s podemos analisar o endereo origem de quadros de difuso com o auxlio de um analisador de protocolos. Por esta razo, alguns procedimentos apresentaro todas as sees mencionadas aqui e outros no. Resumindo: no catlogo de problemas descrevemos que sinais so reflexos de cada problema de rede e nos procedimentos indicamos como obter as informaes de gerncia correspondentes a estes sinais e como interpret-las.

31

Captulo

3. RESUMO

este captulo apresentamos uma metodologia geral de deteco, diagnstico e resoluo de problemas de rede. Segundo esta metodologia, quando um problema ocorrer na rede precisamos inicialmente buscar informaes sobre o comportamento da rede os sintomas e sinais. Os Procedimentos podem ajudar nesta etapa. Com base nas informaes coletadas, comeamos a desconfiar de certos problemas (desenvolver hipteses com o auxlio dos ndices Invertidos). O terceiro passo testar as hipteses levantadas iniciando por aquelas que envolvam problemas da camada fsica. Neste ponto os Testes confirmatrios dos problemas levantados devem ser realizados. Uma vez confirmado um problema, devemos elaborar uma boa soluo (veja Sugestes de tratamento do problema confirmado), implant-la e test-la. Por fim, importante que documentemos os passos seguidos para a localizao e resoluo do problema.

3 Metodologia geral de deteco, diagnstico e resoluo de problemas

Infelizmente, mesmo o melhor sistema de gerncia de redes no pode evitar todas as falhas. Quando somos notificados de que algo errado est ocorrendo na rede, precisamos, assim como o mdico, dar o diagnstico diferencial. Precisamos localizar e solucionar o problema o mais rapidamente possvel. Mas, como o problema detectado e localizado? Nesta seo apresentaremos uma metodologia geral de deteco e localizao de problemas de rede. Ao mesmo tempo, damos dicas de como o catlogo de problemas, os ndices invertidos e os procedimentos podem ser usados em conjunto com metodologia. Alm desta metodologia, muito importante a existncia de uma boa e atualizada documentao da rede e de uma equipe especializada, com conhecimentos avanados sobre redes de computadores, para lidar com os problemas inevitveis. Leia mais sobre documentao de rede no apndice 5. Ao apresentar a metodologia consideraremos os trs papis de gerncia mencionados na seo anterior. Mas, todos eles podem ser realizados pela mesma pessoa. Depende de como a equipe de gerncia est organizada. A metodologia que ser apresentada nas prximas sees est ilustrada na Figura 3-1.

32

C A P T U L O

M E T O D O L O G I A

Figura 3-1: Fluxograma da Metodologia Geral de Localizao e Resoluo de Problemas de rede.

33

C A P T U L O

M E T O D O L O G I A

3.1 Deteco: a rede est apresentando comportamento estranho

Nesta etapa, a equipe de gerncia notificada de que algo estranho est ocorrendo na rede. A notificao pode ser feita de duas formas distintas: os usurios ligam para o help desk e reportam sintomas de um problema; o operador da rede percebe a existncia de dispositivos ou interfaces no operacionais, limiares sendo excedidos ou padres de trfego estranhos. Estas situaes podem gerar alarmes na estao de gerncia. Quando o estado operacional de um equipamento crtico da rede muda para no operacional, o equipamento em questo pode mudar de cor no mapa da rede ficar vermelho, por exemplo ou um e-mail pode ser enviado ao operador do sistema. Uma vez notificado sobre um problema, inicie imediatamente a fase de coleta de informaes. No interessante que problemas graves, que levem grande parte da rede a no funcionar, sejam descobertos atravs dos usurios. Uma das seguintes situaes pode estar ocorrendo: no existe uma estao de gerncia ou qualquer outra ferramenta de monitorao dos enlaces e equipamentos mais crticos da rede; existem ferramentas, mas muitos enlaces importantes no esto sendo monitorados, ou as ferramentas esto sendo utilizadas de forma errada; a ferramenta de gerncia maravilhosa, todos os enlaces e equipamentos crticos esto sendo monitorados, mas a equipe de gerncia no analisa com bastante freqncia os dados apresentados por esta ferramenta. Seja qual for a razo pela qual problemas graves esto sendo descobertos atravs de usurios, algo deve ser feito para reverter esta situao. O ideal que somente problemas que envolvam um nico usurio ou no mximo alguns usurios ligados a um mesmo repetidor/comutador sejam descobertos atravs deles.

3.2 Busque informaes

Uma vez notificado sobre a existncia de um problema, a primeira ao buscar informaes relevantes que possam ajudar a definir que problema est ocorrendo e onde ele est localizado. Tente responder seja com a ajuda dos usurios reclamantes, seja observando estatsticas e alarmes da estao de gerncia as seguintes questes: Quem est sendo afetado pelo problema? Apenas um usurio? Todos os usurios? Alguns usurios que fazem parte de uma mesma sub-rede?
34

C A P T U L O

M E T O D O L O G I A

Quando o problema comeou a ser percebido? Desde ento, o problema ocorre sempre, ou apenas em certos horrios? Neste caso, em que horrios? O problema se manifesta sempre ou apenas quando alguma aplicao e/ou servio especficos so usados? Neste caso, que aplicaes e/ou servios? Alguma mensagem de erro est sendo gerada? Qual? O problema intermitente? Por exemplo, o usurio consegue enviar e-mails em certos momentos, mas em outros recebe mensagens de erro. As informaes obtidas sobre os problemas so passados para a equipe de suporte tcnico atravs do help desk7 ou atravs do operador da rede, quando estes no so capazes de resolver o problema em curto espao de tempo. Com base nestas informaes, voc pode iniciar a busca por outros sinais na estao de gerncia ou usando outras ferramentas de gerncia. interessante que voc obtenha o estado operacional dos equipamentos e interfaces envolvidas, taxa de erros e utilizao de entrada e sada destas interfaces. Use a estao de gerncia para obter o mximo de informaes possvel. Se voc no sabe como obter um sinal, procure ajuda nos PROCEDIMENTOS. Eles ensinam como obter considerando vrios tipos de instrumentao e interpretar informaes de gerncia. Se voc no possui uma estao de gerncia monitorando os elementos crticos da rede e no tem ainda idia de onde o problema possa estar ocorrendo, o procedimento apresentado na Seo 9.3 pode lhe ajudar. Outras ferramentas de gerncia teis nesta fase so analisadores de protocolos, ping e traceroute. Em muitos casos, o problema pode envolver equipamentos ou servios que no esto sendo monitorados pela estao de gerncia. Outra possibilidade ocorre quando a quantidade de informao coletada no suficiente para diagnosticar o problema. Alm disso, no nvel de gerncia do qual estamos falando, no somos capazes de descobrir, atravs da estao de gerncia, que um servio est com problemas enquanto a infraestrutura de rede sob a qual ele se apia no est. Nestes casos, o auxlio de analisadores de protocolos e de outras ferramentas auxiliares imprescindvel. Se o problema envolver um pequeno grupo de usurios, verifique a configurao de rede das mquinas de alguns deles. Elas podem revelar informaes importantes. As informaes obtidas nesta etapa da metodologia nos deixam mais prximos do problema, levando-nos a focar a ateno onde o problema realmente est ocorrendo.

Quando esta equipe existir e considerar que realmente existe um problema e no for capaz de solucion-lo.

35

C A P T U L O

M E T O D O L O G I A

3.3 Recorrncia de problema? Mudanas na rede?

Muitas perguntas j foram respondidas no passo anterior, mas deixamos duas, em especial, para ser respondidas nesta etapa: este problema ocorreu nos ltimos 30 ou 60 dias? o se a resposta for sim, grandes chances existem de o problema ter voltado a ocorrer; houve alguma modificao recentemente na rede que possa ter causado os sinais e sintomas verificados no passo anterior? o se a resposta for sim, muito provvel que esta modificao tenha originado o problema reportado. Respondendo positivamente a uma destas perguntas, v direto ao ponto. No perca tempo. Voc muito provavelmente j localizou o problema, ou pelo menos j identificou que ele envolve um determinado servio ou elemento da rede. Suponha que voc j descobriu que o problema envolve um certo servio que foi instalado ontem. Voc vai ento criar uma lista de hipteses, mas esta no levar em considerao hipteses no relacionadas a este servio. No fluxograma apresentado na Figura 3-1, dizemos que voc dever criar uma lista de hipteses especficas. Voc j coletou informaes sobre o problema, mas no criou uma lista genrica de hipteses. Caso os testes que vm a seguir no revelem que o problema era o imaginado, desenvolva hipteses genricas com base nos sintomas e sinais j reunidos. Nesta etapa da metodologia, a documentao dos problemas j enfrentados poder ser de grande auxlio (ver Seo 3.9).

3.4 Desenvolva hipteses

Neste momento ns j temos informaes suficientes sobre o problema para comear a desenvolver hipteses. At agora um problema foi apenas detectado, isto , sabe-se de sua existncia. J temos tambm uma boa idia de como a rede est reagindo ao problema (sintomas e sinais reunidos) e que partes da rede esto sendo afetadas. Com base em todas estas informaes, podemos criar hipteses sobre que problema pode estar ocorrendo. A pergunta bsica a ser respondida neste momento : que problemas podem causar os sintomas e sinais percebidos? A criao da lista de hipteses o primeiro passo para localizar especificamente o problema. importante ressaltar que, para conseguir criar a lista de hipteses necessrio que tenhamos um bom conhecimento sobre como as redes e os servios oferecidos por elas funcionam. preciso saber como as coisas deveriam estar
36

C A P T U L O

M E T O D O L O G I A

funcionando se nenhum problema estivesse ocorrendo, comparar com o que est ocorrendo e perceber o que pode estar causando o comportamento atpico. Se voc desconhece como o servio DHCP funciona, no poder jamais desvendar problemas que envolvam este servio. Alm disso, precisamos tambm conhecer a rede que est sendo gerenciada. Onde esto os servios, como deve ser o roteamento, como se d a interconexo dos equipamentos e onde esto implantados firewalls, so exemplos de informaes que devemos conhecer previamente. Vamos voltar a nossa analogia com a Medicina. Para que um mdico consiga, a partir de sintomas e sinais, suspeitar de certas doenas, ele precisa conhecer a anatomia e o funcionamento do corpo humano. Caso contrrio, ele no conseguiria chegar ao diagnstico diferencial. Nesta etapa da metodologia os NDICES INVERTIDOS podem auxiliar. Veja nos ndices invertidos que problemas podem causar os sintomas e sinais observados. Desta forma, voc obter facilmente uma lista de hipteses inicial. Chegou o momento de exemplificarmos a metodologia sendo apresentada. Suponha que voc tenha as seguintes informaes: alguns usurios do Setor de Marketing ligaram para o help desk reclamando que a rede no est funcionando h 15 minutos. Nem logon na rede eles conseguem fazer; o estas foram as informaes repassadas pela equipe de help desk; todos os equipamentos e interfaces monitorados pela estao de gerncia esto operacionais e no apresentam limiares excedidos. Mas, existem repetidores que ligam mquinas clientes do Setor de Marketing rede que no esto sendo monitorados; Baseados nestas informaes, consultamos o ndice invertido de sintomas e sinais e desenvolvemos as seguintes hipteses: cabo rompido ou danificado entre repetidores localizados no Setor de Marketing; conector defeituoso ou mal instalado entre repetidores localizados no Setor de Marketing; um ou mais repetidores defeituosos no Setor de Marketing; problema com o servio DHCP do Setor de Marketing; problema com o servio de nomes do Setor de Marketing; No se preocupe neste momento em identificar claramente o problema. O que voc e sua equipe iro fazer nesta etapa um brain storm. Iro levantar todas as possibilidades que vierem em mente. Se, no entanto, voc estiver criando uma lista de hipteses especficas, leve em considerao apenas o elemento da rede ou servio que j estiver sob suspeita.
37

C A P T U L O

M E T O D O L O G I A

3.5 Organize a lista de hipteses

Uma vez confeccionada a lista de hipteses, classifique-as com base nas camadas do modelo de referncia OSI. Rena hipteses relacionadas camada fsica separadas das hipteses relacionadas camada de enlace e assim por diante. As hipteses da camada fsica so as primeiras a serem testadas. Em seguida vm as da camada de enlace e assim sucessivamente. Nos ndices invertidos, os problemas j esto organizados por camada OSI. Duas razes nos fazem iniciar os testes pela camada fsica: uma delas que citase na literatura que 90% dos problemas de uma rede recaem em problemas de cabeamento [HAUGDAHL]; a segunda razo no menos importante que se a camada fsica no est bem, as demais camadas tambm no estaro, pois dependem dela para seu bom funcionamento. Retomando o exemplo citado na seo anterior, temos os seguintes grupos: Camada fsica cabo rompido ou danificado entre repetidores localizados no Setor de Marketing; conector defeituoso ou mal instalado entre repetidores localizados no Setor de Marketing; um ou mais repetidores defeituosos no Setor de Marketing; Gerentes mais experientes e que j conhecem profundamente a rede que gerenciam podem organizar esta lista de forma diferente, baseados na probabilidade de ocorrncia de um problema. Com o tempo, acabamos definindo em nossa mente que problemas so mais provveis de ocorrer na rede que estamos gerenciando e estes so os primeiros da lista. claro que acidentes ocorrem, e quando erramos somos mesmo obrigados a organizar a lista por camadas e iniciar pela camada fsica. Se voc criou uma lista de hipteses especficas, voc pode organiz-la segundo a probabilidade de ocorrncia de cada problema. Ao organizar esta lista, j devemos estar pensando em como os testes sero feitos. Muitas vezes, ser necessrio criar um plano de ao, para que no cometamos erros na prxima fase. Ser necessrio no apenas classificar os problemas por camada OSI, mas ordenar problemas de uma mesma camada. O que testar primeiro: o cabo de rede ou a placa de rede? Com o tempo, voc perceber que fica mais fcil testar alguns problemas quando outros j tiverem sido testados. Por exemplo, alguns testes de Camada de rede e aplicao servidor desativado8; DHCP

servidor DHCP com escopo incorreto; servidor de desativado; nomes

Consideramos neste livro problemas com o servio DHCP como sendo da camada de rede, pois este servio est diretamente relacionado configurao da camada de rede em hospedeiros.

38

C A P T U L O

M E T O D O L O G I A

diagnstico da placa de rede envolvem testes de comunicao com o equipamento remoto. , portanto, mais interessante que o cabo de rede ligado a esta placa seja testado antes da placa. Problemas de uma mesma camada podem tambm ser organizados por probabilidade de ocorrncia ou facilidade de teste. Cabe a voc e a sua equipe decidir a ordem em que eles sero testados.

3.6 Teste as hipteses levantadas

Na etapa anterior voc organizou as hipteses na ordem em que devem ser testadas. Nesta etapa voc vai testar as hipteses. Voc vai simplesmente implementar o plano de ao de testes criado na fase anterior. Se as etapas anteriores tiverem sido bem realizadas, aps esta fase voc ter localizado claramente o problema. Uma vez obtida a lista de hipteses dos ndices invertidos, consulte os problemas referenciados nela. Um por vez, iniciando pelos problemas da camada fsica (na ordem em que eles esto na lista). Para confirmar ou negar cada problema da lista basta seguir os TESTES CONFIRMATRIOS de cada problema. Nos testes confirmatrios, assim como nos procedimentos, tentamos apresentar testes alternativos, para quem no tem a ferramenta apropriada para confirmar o problema. Caso nenhuma das hipteses tenha sido confirmada, volte para o passo de busca de informaes (Seo 3.2). Tente reunir mais informaes sobre o problema e em seguida crie novas hipteses, organize-as e teste-as. Faa isto at localizar claramente o problema. Para no perder o controle do problema, realize um teste por vez. Muitos testes envolvem modificaes, por exemplo, substituio de equipamentos ou cabos de rede. Se aps a modificao os sintomas e sinais cessarem, o problema foi confirmado. Se voc fizer duas modificaes ao mesmo tempo e perceber que o problema foi resolvido, ficar sem saber qual era o problema, invalidando o seu teste. Portanto, nunca efetue mais de uma modificao por vez, o que implica tambm em nunca testar mais de uma hiptese por vez. Voltemos ao exemplo j citado em sees anteriores. Suponha que voc no tem um testador de cabos. Para descobrir o problema mais rpido voc resolve trocar um repetidor suspeito e um cabo suspeito ao mesmo tempo. Aps as trocas, os sintomas e sinais cessaram. Mas voc ficar sem saber se o cabo estava com problema, ou o repetidor estava defeituoso. Quanto mais bem equipado voc estiver, mais rpidos e simples sero os testes. Por exemplo, testar problemas de cabeamento sem o auxlio de um bom testador de cabos pode ser uma tarefa bastante trabalhosa. importante tambm que voc tenha cabos de rede, placas de rede e equipamentos de interconexo sobressalentes que possam ser usados durante os testes e que possam substituir peas que estiverem com defeito.
39

C A P T U L O

M E T O D O L O G I A

se voc desconfia de muitos problemas de camadas inferiores, um nico teste pode negar todos eles, ou confirmar que um deles existe, infelizmente, sem revelar qual. Para realizar este teste use ping. Suponha que um usurio reclamou que no consegue usar determinada aplicao de rede. Se a mquina deste usurio estiver com as configuraes de rede corretas, voc pode enviar ping para o servidor (usando o endereo IP do servidor, no o nome). Se obtiver resposta deste servidor (nenhum quadro for perdido e o tempo de ida e volta for normal) ter descoberto que h conectividade fsica e lgica (at camada de rede) com o servidor. Ao descobrir isso, voc no precisar mais perder tempo testando as hipteses da camada fsica levantadas. Apenas se no obtiver resposta, ou se a resposta do ping indicar que houve perda de datagramas ou tempos de ida e volta absurdos, as hipteses da camada fsica, de enlace e de rede precisaro ser testadas, pois voc ter descoberto que o problema realmente em camadas inferiores.
Dica:

3.7 Solucione o problema

Neste momento, o problema j foi confirmado, e voc deve solucion-lo no menor prazo de tempo e da melhor forma possvel. Olhe a Seo SUGESTES DE TRATAMENTO do problema que foi confirmado. Elas lhe daro dicas de como corrigir o problema da forma correta e, muitas vezes, como evitar que ele ocorra novamente. Em algumas situaes, a primeira soluo (mais rpida) paliativa. Pode ser uma soluo temporria para que os usurios no fiquem mais tempo sem poder usar a rede. De qualquer modo, uma soluo definitiva e correta deve ser elaborada. Mais uma vez como na Medicina: aps dar o diagnstico o mdico ir tratar a enfermidade. Felizmente, na gerncia de redes, todos os problemas tm soluo. Elas podem ser caras, complexas ou demandar muito tempo para ser implantadas, mas sempre possvel solucionar um problema.

3.8 Teste a soluo implantada

No v para casa satisfeito, certo de que resolveu o problema sem antes testar a soluo implantada. Muitas vezes o cansao nos leva a solues aparentemente corretas, mas que no solucionam o problema, e, ao contrrio, introduzem novos problemas. Para testar sua soluo use a rede, analise as estatsticas da estao de gerncia. Se o problema foi descoberto atravs de reclamaes dos usurios, use a rede a partir das mquinas destes usurios. Analise as estatsticas da estao de gerncia, mesmo das redes onde nenhum problema foi reportado. Fique ainda muito atento a toda a rede nos prximos 30 ou 40 minutos. Se a sua soluo foi ineficaz, voc perceber neste intervalo de tempo. Se voc descobrir que a soluo no resolveu o problema, analise o que voc fez e tente descobrir por que no deu certo. Voc pode apenas ter esquecido de um detalhe bobo, ou
40

C A P T U L O

M E T O D O L O G I A

pode ainda ter que desfazer o que fez e elaborar uma nova soluo. Neste caso, volte para o passo anterior (Seo 3.7). Em casos mais raros (estes casos foram omitidos na Figura 3-1) possvel que voc descubra que voc solucionou um problema, mas ainda existe outro perturbando o bom funcionamento da rede. Neste caso, voc pode decidir coletar mais informaes, ou testar outras hipteses que no foram testadas ainda, pois uma hiptese testada antes dela foi confirmada.

3.9 Documente suas atividades

Por fim, documente tudo. Documente as informaes iniciais que obteve sobre o problema (o reflexo do problema na rede), as hipteses levantadas, os testes e as solues propostas. Se teve que voltar na metodologia em busca de novas informaes para criar novas hipteses, documente. Mesmo aquilo que no resolveu o problema deve ser documentado, pois ajudar outros (ou voc prprio) a no repetir os mesmos erros. Essa documentao tambm pode lhe ajudar no futuro, caso o problema ocorra novamente. Esta etapa no precisa ser feita, necessariamente, no fim. Geralmente, quando estamos tentando localizar um problema no queremos perder tempo com a documentao do mesmo. Ento, esquecemos da documentao e pensamos apenas no problema que deve ser resolvido. Esta atitude pode dificultar a elaborao de uma boa documentao. Portanto, durante as fases anteriores, pelo menos anote escreva frases curtas e objetivas as aes realizadas. Assim voc no esquecer de informaes importantes aqui. No temos a inteno de impor o uso desta metodologia. Ela no baseada em estudos formais e no h provas matemticas de que seja esta a melhor, se que existe uma! Com a prtica, voc perceber que esta metodologia intuitiva. Voc passar a utiliz-la naturalmente e no mais perceber to claramente a diviso entre cada uma de suas etapas. Elas se misturam e se complementam de forma natural.

3.10 Referncias
Outras metodologias ou estratgias para deteco, localizao e resoluo de problemas podem ser encontradas em: [3COM] Network Troubleshooting Overview. http://support.3com.com/infodeli/tools/netmgt/tncsunix/produ ct/091500/c1ovrvw.htm [GUIAETHERNET] Spurgeon, C. E. Ethernet O Guia Definitivo. Traduo Daniel Vieira, Editora Campus, 2000.

41

Captulo

4 Problemas de nvel fsico

Neste captulo encontram-se 9 problemas que podem ocorrer em uma rede relacionados camada fsica: Cabo rompido ou danificado, Conector defeituoso ou mal instalado, Descasamento de modo e/ou velocidade de operao, Equipamento de interconexo defeituoso, Placa de rede ou porta de equipamento de interconexo defeituosas, Interferncia no cabo, Saturao de banda em segmentos Ethernet compartilhados, Tipo errado de cabo, Violao de regras de cabeamento Ethernet.

4.1 Cabo rompido ou danificado 4.1.1 Descrio

A maioria dos enlaces de hospedeiros em redes locais (10Base-T e 100Base-TX, por exemplo) formada por trs componentes de hardware: uma placa de rede no cliente, uma porta em um equipamento de interconexo e um cabo conectando os dois primeiros componentes. Um cabo de rede, portanto, interliga dois ou mais componentes da rede. O rompimento de um cabo, conseqentemente, impossibilita a comunicao entre os dispositivos da rede interligados por ele. Da mesma forma, cabos de redes danificados dificultam a comunicao entre os equipamentos unidos por ele. Cabos de fibra tica so os mais sensveis. Quando flexionados alm de um certo limite sofrem micro-fraturas, que no so visveis externamente. As micro-fraturas causam uma maior perda de sinais no enlace. Curvas mais fechadas ou impactos muito fortes podem quebrar a fibra completamente. A trao ou toro excessivas da fibra durante a instalao tambm podem causar o seu rompimento. Cuidado quando obras na rede hidrulica ou eltrica estiverem em execuo. mais freqente que danos ou rompimentos em cabos ocorram quando trabalhos de deste tipo esto sendo realizados prximos aos cabos de fibra tica areos ou terrestres. Por esta razo, quando estes trabalhos estiverem sendo realizados recomendada uma ateno redobrada. Os tcnicos da rede eltrica e hidrulica no conhecem a sensibilidade dos cabos ticos e por isso so, na maioria dos casos, responsveis por causar fraturas e micro-fraturas nos cabos ticos. Cabos de pares tranados tambm podem ter sua capacidade de transmisso prejudicada devido a tores, curvas muito acentuadas e ns apertados, pois estas formas de disposio do cabo alteram sua geometria. As alteraes na
42

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

geometria do cabo podem causar prejuzos permanentes cuja gravidade depende da categoria do cabeamento utilizada. Dispor cabos sobre objetos afiados, como por exemplo quinas de bastidores muito pontiagudas, uma causa comum de curto circuito em cabos [LAN WIRING].

4.1.2 Sintomas
Cabos de fibra tica quebrados completamente no permitem a passagem de sinais de uma extremidade a outra, inibindo o funcionamento da rede. Neste caso, os usurios reclamaro de falta de conectividade. Micro-fraturas tornam a rede lenta uma vez que causam uma grande quantidade de erros. Pares tranados com geometria alterada podem causar falta de conectividade, conectividade intermitente ou ainda conexes lentas. Se o cabo danificado fizer parte do backbone, muitos usurios sero afetados. Os usurios, em geral, reclamaro que a rede no funciona, ou alguns servios no funcionam ou a que a rede ou alguns servios esto muito lentos. Isto ir depender da localizao do cabo com problema e do tipo de defeito no cabo.

4.1.3 Sinais
Procedimento

10.1

Um dos principais sintomas de cabeamento ruim a taxa de erros elevada, principalmente erros de CRC. Desconfie de taxas de erros que no sejam muito prximas de zero. Em enlaces metlicos pode ser detectado no mximo 1 erro a cada 109 bits transmitidos e em enlaces ticos 1 erro a cada 1012 bits transmitidos.

4.1.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Verificar LEDs; Testar o cabo sob suspeita com um testador de cabos; Se no tiver um testador de cabos disposio:

E S T E

T T

E S T E

3 4

trocar o cabo por outro, ou utilizar outra porta nos equipamentos de interconexo envolvidos.

E S T E

43

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Teste confirmatrio 1

O primeiro teste bastante simples: trata de verificar se os LEDs dos equipamentos de rede onde o cabo suspeito est conectado esto acesos. Praticamente todas as placas de rede mais novas e todas as portas dos equipamentos de interconexo possuem LEDs que acendem ao receber pulsos vindos do outro lado da conexo, seja para enlaces metlicos, seja para enlaces de fibra tica. Se os LEDs de ambos os lados da conexo acendem ao conectar o cabo e apagam ao desconect-lo pequena a probabilidade da existncia de um cabo danificado ou rompido. Porm, conectores inadequadamente instalados, interferncia eletromagntica e cabeamento inadequado podem fazer o cabo falhar e ainda assim os LEDs da conexo acenderem [STEINKE]. Se apenas o LED de um dos lados estiver aceso quase certa a existncia de problema no cabo. No entanto, a falha pode ser devido a danos no cabo, conectores mal instalados ou interferncia no cabo. Se um testador de cabos estiver disponvel, o prximo teste pode confirmar ou negar a existncia de problemas no cabo. E pode fazer ainda mais: pode indicar especificamente qual o defeito (se problema no conector ou se realmente um cabo rompido ou danificado).

Teste confirmatrio 2

Teste o cabo (ou os cabos) sob suspeita com um testador de cabos. Um TDR um equipamento usado para caracterizar e localizar falhas em cabos metlicos (par tranado e coaxial, por exemplo). Um TDR realiza sua tarefa enviando pulsos ao longo do condutor e examinando os pulsos refletidos. A onda refletida revela situaes indesejveis, como curtos-circuitos, quebras e anomalias na transmisso devido a curvas, ns ou compresses excessivas [LAN WIRING]. Testadores de cabos TDR so, portanto, capazes de identificar e localizar problemas em cabos metlicos. Um testador de cabos apresentado na Figura 4-1. O OTDR um equipamento que tem os mesmos objetivos do TDR, mas realiza testes em cabos ticos. Testadores de cabos OTDR so capazes de localizar exatamente o local da fratura em cabos de fibras ticas [LAN WIRING]. A Figura 4-2 apresenta um testador de cabo tico.

44

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Figura 4-1: DSP 4100 Digital CableAnalyzer da Fluke.

Figura 4-2: NetTekTM OTDR da Tektronix.

Se um testador de cabos no est disponvel ser ainda possvel confirmar se existe ou no problemas com o cabo suspeito, mas no ser possvel determinar qual o problema. Para tal, os prximos testes podem ser teis.

Teste confirmatrio 3

Troque o cabo suspeito por outro confivel um cabo de testes, por exemplo para certificar-se de que os equipamentos envolvidos esto configurados corretamente e no apresentam defeitos fsicos. Se com seta troca os sintomas e sinais descritos cessarem, a suspeita de problemas no cabo foi confirmada. Se aps a troca os sintomas e sinais continuam sendo percebidos o problema existente na rede no est relacionado com o cabo de rede sob suspeita. Em outras palavras, voc acabou de confirmar que no havia problemas com o cabo de rede9. Se no for factvel trocar o cabo por outro (no h outro cabo para a substituio ou o cabo suspeito subterrneo e sobre ele existe uma avenida movimentada, por exemplo) voc pode realizar o seguinte teste:

Teste confirmatrio 4

Para realizar este teste voc precisar de uma mquina de testes. Conecte a mquina de testes em uma das extremidades do cabo. Envie ping para o equipamento ligado outra extremidade do cabo. Se este equipamento for um repetidor envie ping para um outro dispositivo ligado ao repetidor. Realize o mesmo teste conectando a mquina de testes no outro equipamento. Se o

possvel que a rede esteja apresentando dois problemas que causem os mesmos sintomas e sinais e que o cabo de rede substitudo realmente estivesse com problemas. Mas a probabilidade disto ocorrer bastante pequena.

45

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

resultado dos pings anunciar taxas de perda de pacotes maiores que zero em ambas as direes, o problema foi confirmado. Se em apenas uma direo o ping resultar em perda de dados, a suspeita recai sobre o equipamento ligado ao cabo (o que no a mquina de testes). Por exemplo: voc suspeita de um cabo que liga dois comutadores entre si, comutador1 e comutador2. O cabo de rede utilizado para ligar estes equipamentos cruzado a porta de inverso est sendo utilizada. O teste realizado em duas fases: 1. primeiro voc desconecta o cabo suspeito de comutador1 e conecta na sua mquina de testes. A mquina de testes deve ser configurada com o endereo de rede e mscara de rede da rede onde ela vai ser conectada. Em comutador2 o cabo de rede suspeito est conectado em uma porta que participa da VLAN 110. As mquinas desta VLAN so da rede 10.10.10.0/24. O endereo 10.10.10.13 no est sendo utilizado. Voc configura a mquina de teste com este endereo e mscara 255.255.255.0. Enfim, envie ping para comutador2 (# ping 10.10.10.2) e analise o resultado; 2. na segunda fase, o cabo sob suspeita vai novamente ser conectado em comutador1. Voc pode deixar a mquina de testes com a mesma configurao de rede. Desconecte comutador2 do cabo de rede suspeito, e em seu lugar conecte a mquina de testes. Envie ping para comutador1 (# ping 10.10.10.1) e analise o resultado. Se houve perda de dados em ambas as fases do teste o problema foi confirmado. O cabo realmente est com problemas. Caso em apenas uma fase haja perda de dados, a suspeita passa para o equipamento conectado ao cabo. Se, por exemplo, apenas na primeira fase do exemplo apresentado houver perda de dados, comutador2 e a interface (de comutador2) qual o cabo est conectado passam a ser suspeitos. Algumas redes no utilizam um nico tipo de cabeamento. Parte da rede possui cabeamento tico e parte cabeamento metlico (par tranado, por exemplo). Neste caso conversores ticos podem ser utilizados. O conversor tico simplesmente repete o sinal que chega de um enlace metlico em uma forma apropriada para transmisso em fibra tica e vice-versa. O conversor tico da Figura 4-3 foi projetado para conectar redes Ethernet 100Base-TX com Ethernet 100Base-FX.

10 Configure a mquina de testes de forma que ela possa se comunicar na rede. Se VLANs por MAC estiverem definidas, o endereo MAC da placa de rede da mquina de teste deve ser cadastrado na VLAN adequada.

46

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Figura 4-3: Fast Ethernet 100Base-TX/FX Converter da MFico.

Se o cabo suspeito na realidade formado por mais de um tipo de cabo e um conversor entre eles (tal como um conversor tico), possvel que o conversor esteja com defeito e que os cabos estejam intactos. O teste mais simples consiste em trocar o conversor por outro que esteja funcionando adequadamente (voc provavelmente tem outros conversores de reserva ou para testes) e monitorar o enlace. Se os sintomas e sinais cessaram o problema no conversor foi confirmado.

4.1.5 Sugestes de tratamento

A soluo para cabos metlicos mesmo substitu-lo por outro devidamente instalado. As fraturas em fibras ticas podem ser reparadas utilizando-se tcnicas de fiber splice. [LAN WIRING]. Esta tcnica consiste na juno, atravs de fuso ou utilizando um acoplador tico, dos dois lados do cabo na quebra, sendo a fuso uma tcnica que resulta em uma menor perda. Chame pessoas especializadas para realizar esta juno das fibras.

4.2 Conector defeituoso ou mal instalado 4.2.1 Descrio

No mundo das redes, um conector a pea responsvel pela ligao entre o cabo de rede e o equipamento de interconexo ou hospedeiro. possvel que conectores mal instalados ou defeituosos sejam a causa de problemas na rede que, em uma primeira anlise, podem aparentar ser mais complexos. Problemas em conectores RJ-45, utilizados em cabos de pares tranados, so mais comuns. As causas so diversas: a crimpagem pode ter sido mal feita, podem existir pares separados (split pairs), etc. Em um cabo de pares tranados existem 4 pares de fios condutores. Os fios de cada par esto tranados entre si, como molculas de DNA (forma helicoidal). Estas tranas so necessrias para reduzir a interferncia eltrica entre os fios condutores. O fio 1 est tranado com o 2, o 3 com o 4 e assim sucessivamente.
47

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Quando cabos de pares tranados so utilizados para comunicao Ethernet padro (10Base-T e 100Base-TX), apenas os pinos 1, 2, 3 e 6 so utilizados11. Para evitar a interferncia troca-se, em cada extremidade do cabo, a posio do fio 4 com o fio 6. Desta forma, todos os fios utilizados para transmisso e recepo de dados estaro tranados entre si, evitando interferncias eltricas. Quando a troca entre os fios 4 e 6 no realizada erros podem ser causados devido interferncia entre os fios condutores, causando o que se chama pares separados.

4.2.2 Sintomas
Os sintomas de conectores com problema podem ser diversos, depende do problema existente. O problema com conector pode causar mau contato com o equipamento ao qual o cabo est conectado, levando a conectividade intermitente. Em outras situaes a conseqncia pode ser falta de conectividade ou rede lenta.

4.2.3 Sinais
Procedimento

10.1
Procedimento

especial erros de CRC

Conectores mal crimpados podem levar a um nmero elevado de erros, em [GUIA-ETHERNET, TIPS-ETHERNET] e de alinhamento. Deve-se sempre suspeitar de uma taxa de erros que no esteja muito prxima de zero.

10.2
Procedimento

Taxa de colises elevada. Uma taxa de colises superior a 10% deve ser investigada. Conectores com problema tambm podem ser a causa de colises excessivas12 [TIPS-ETHERNET].

10.12

Outras conseqncias de conectores mal instalados so near-end crosstalk (NEXT), que ocorre quando um sinal poderoso em um dos pares de fio apanhado pelo par de fios adjacentes e atenuao do sinal [CABLETESTING-NEXT]. Uma boa ferramenta de certificao de cabeamento informa em que lado do cabo NEXT foi detectado. NEXT pode indicar tambm a existncia de split pairs [HAUGDAHL].

4.2.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Use um testador de cabos para testar o cabo sob suspeita; Se um bom testador no estiver disponvel os seguintes testes podem ser realizados:

11

Para 1000baseT (Gigabit Ethernet) so usados os 4 pares.

12

Na tentativa de transmitir um quadro, aps 16 colises sucessivas a estao desiste da transmisso. Camadas superiores sero responsveis pela solicitao da retransmisso do quadro.

48

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

T T T

E S T E

2 3 4

Verificar LEDs dos equipamentos conectados ao cabo com conector suspeito; Troque o cabo sob suspeita por outro que esteja funcionando apropriadamente; Use uma mquina de testes e a ferramenta ping para confirmar problemas no cabo; Realize uma inspeo visual no cabo de pares tranados;

E S T E

E S T E

E S T E

Teste confirmatrio 1

Use uma ferramenta de certificao de cabos para encontrar problemas no cabo. Bons testadores de cabos conseguem localizar exatamente onde est a falha. Se no for possvel testar o cabo, oferecemos a seguir alguns outros testes que podem ser realizados para confirmar o problema.

Teste confirmatrio 2

Tendo identificado o cabo com conector suspeito verifique se os LEDs dos equipamentos de rede onde o cabo est conectado esto acesos. Praticamente todas as placas de rede mais novas e todas as portas dos equipamentos de interconexo possuem LEDs que acendem ao receber pulsos vindos do outro lado da conexo, seja para enlaces de par tranado ou para enlaces de fibra tica. Em se tratando de cabos de pares tranados, ao verificar os LEDs chacoalhe o cabo prximo ao conector e verifique se a conectividade torna-se intermitente, isto , se os LEDs ora acendem e ora apagam, dependendo da posio do cabo. Se voc observar mau contato o problema com o conector est confirmado. Se os LEDs de ambos os lados da conexo acendem ao plugar o cabo e apagam ao desconect-lo mais provvel que o problema no seja no cabeamento, mas nos equipamentos envolvidos. Infelizmente, se isto ocorrer, no ser possvel confirmar o negar problemas nos conectores. raro, mas conectores mal instalados, interferncia eletromagntica e cabeamento inadequado podem fazer o cabo falhar e ainda assim os LEDs da conexo acenderem [STEINKE]. Se apenas o LED de um dos lados est aceso quase certa a existncia de problema no cabo. No entanto, a falha pode ser devido a conectores mal instalados, danos no cabo, interferncia no cabo, etc.

49

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Os mesmos testes confirmatrios 3 e/ou 4 do problema CABO ROMPIDO OU DANIFICADO podem ser realizados aqui. Eles iro ajudar a confirmar se o cabo sob suspeita est realmente com problema, mas no so suficientes para descobrir se o problema est relacionado aos conectores.

Teste 5

Em se tratando de cabos de pares tranados uma inspeo visual nos conectores pode ser feita facilmente. Assim, em alguns casos, mesmo que um testador de cabos no esteja disponvel, possvel encontrar falhas em conectores. A primeira dica que apenas os 13mm finais de suas terminaes podem ser destranados. Quando mais que 13mm so destranados, NEXT pode ser gerado. A segunda dica certificar-se de que os fios condutores esto todos em contato com os terminais metlicos do conector. A terceira dica desconectar e conectar o conector suspeito em uma porta de equipamento de rede e perceber se o conector encaixado com dificuldade e ainda se ao conect-lo ouve-se um pequeno estalo. Se o conector entrar na interface do equipamento com muita dificuldade, desconfie da crimpagem. Se voc no ouve um estalo, tambm desconfie. Busque tambm por pares separados. Eles geralmente so gerados quando as posies dos fios 4 e 6 no so trocadas entre si. Observe as cores das extremidades dos cabos. Se elas forem todas combinadas (fio branco/cor x sempre seguido pelo fio de cor x) porque existem pares separados. Sempre que suspeitar de conectores RJ-45 mal instalados analise os conectores em busca de possveis falhas. Se encontrar alguma falha muito provvel que esta seja a fonte de seu problema. Quanto maior o comprimento do cabo, a velocidade de operao e a sua utilizao, piores os efeitos negativos causados por deslizes durante a instalao de conectores. Portanto, pode acontecer que um conector cujas falhas so vistas a olho nu funcione normalmente. claro que ele no est de acordo com as especificaes que devem ser seguidas por uma boa estrutura de cabeamento, mas muitos conectores, por exemplo com mais de 13 mm destranados e desencapados, podem no causar mal algum. Por esta razo este no um teste confirmatrio. Estas so apenas algumas dicas que servem para aumentar ou diminuir as suspeitas com relao a um conector RJ-45.

50

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.2.5 Sugestes de tratamento

Instalar um novo conector, seguindo rigorosamente o padro a melhor soluo para este problema. Se estiver usando conectores RJ-45, crimp-lo novamente pode no solucionar o problema, pois necessrio a utilizao de crimpadores especiais para a realizao desta tarefa. Se problemas com conectores costumam acontecer com freqncia possvel que o crimpador que voc esta utilizando seja de m qualidade e a compra de um crimpador de melhor qualidade ento recomendada [LAN WIRING]. A Figura 4-4 mostra a seqncia de cores que deve ser seguida em cada uma das extremidades de um cabo (para cabos cruzados e cabos paralelos):

Figura 4-4: Terminao RJ-45 de ambas as extremidades para cabos cruzados e paralelos
Cabo paralelo Cabo cruzado

Pino RJ-45 1 Tx + 2 Tx 3 Rx + 6 Rx

Pino RJ-45 1 Rx + 2 Rx 3 Tx + 6 Tx

Pino RJ-45 1 Rx + 2 Rx 3 Tx + 6 Tx

Pino RJ-45 3 Tx + 6 Tx 1 Rx + 2 Rx

Figura 4-5: Terminao RJ-45 de ambas as extremidades para cabos cruzados e paralelos

Talvez voc no esteja conseguindo visualizar as cores dos fios na figura acima. Afinal, ela est em preto e branco! Vamos dar uma colher de ch pra voc. A seqncia de cores do cabo paralelo : extremidade 1: branco_verde, verde, branco_laranja, azul, branco_azul, laranja, branco_marrom, marrom. extremidade 2: idntica extremidade 1. Para o cabo cruzado a seqncia de cores : extremidade 1: branco_verde, verde, branco_laranja, azul, branco_azul, laranja, branco_marrom, marrom.
51

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

extremidade 2: branco_laranja, laranja, branco_verde, azul, branco_azul, verde, branco_marrom, marrom. Existem outras padronizaes que tambm so aceitas. Esta a padronizao EIA/TIA 568A que indicada pelas normas de cabeamento estruturado e deve ser usada prefrencialmente.

4.3 Descasamento de modo e/ou velocidade de operao 4.3.1 Descrio

Leia mais sobre Ethernet no apndice 1

O descasamento de modo de operao ocorre quando um lado de uma conexo Ethernet est configurado para trabalhar no modo half duplex e o outro em full duplex. Pode haver tambm descasamento de velocidade, quando um lado foi configurado para 100Mbps e o outro para 10Mbps. O modo e a velocidade de operao podem ser configurados manualmente pelo gerente da rede ou atravs da negociao automtica. A negociao automtica uma funo opcional do padro IEEE 803.2. Sua finalidade permitir que dispositivos de rede diretamente conectados se comuniquem e negociem entre si a velocidade e o modo de operao, de forma que sua comunicao seja a mais eficiente possvel. Existem padres para deteco das velocidades 10 Mbps, 100 Mbps e 1000 Mbps e para os modos de operao half e full duplex. O descasamento de velocidade ou modo de operao mais comum quando um ou os dois lados esto configurados para a negociao automtica, mas pode ocorrer tambm quando o administrador da rede modifica as configuraes de um lado da conexo e esquece de corrigir o outro lado. A idia da negociao automtica muito boa, mas na prtica ela no perfeita. A negociao automtica foi um dos ltimos itens a ser adicionado no padro, e antes dele ser aprovado, muitos fabricantes j haviam desenvolvido e implantado o seu prprio sistema de negociao automtica. Alm disso, no h padro para a deteco automtica quando a velocidade 100 Mbps. O resultado deste desacordo que uma interface pode detectar a velocidade e modo de operao do enlace de vrias formas diferentes, e freqente que elas no sejam compatveis entre si [KREIBICH]. Portanto, comum que a deteco automtica de velocidade ou modo de operao no funcione bem, principalmente entre equipamentos de fabricantes diferentes, sendo necessria a configurao manual. Outra causa possvel do descasamento quando um lado est configurado para a negociao automtica e o outro para operao full duplex, independente da velocidade. Neste caso, o lado que ir negociar encontrar a velocidade corretamente, mas ser configurado para half duplex (que o modo default quando a interface detecta que o outro lado no est configurado para a
52

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

negociao automtica), gerando assim, descasamento de modo de operao [KEIBRICH].

4.3.2 Sintomas
conectividade.

Quando o problema descasamento de velocidade o sintoma falta de Os usurios reclamaro que a rede ou parte dela no funciona ou que alguns servios no esto disponveis. Quando o descasamento do modo de operao existe conectividade, mas o desempenho da rede prejudicado e a reclamao ser de rede lenta. possvel que o problema de descasamento de modo de operao exista mas ningum o perceba, principalmente se ocorre em enlaces com pequena utilizao.

4.3.3 Sinais
Os tipos de erros iro variar dependendo do equipamento utilizado. Em geral, descasamento de modo de operao causa muitos tipos de erros em um enlace. Sinais indicativos de descasamento de modo de operao so:
Procedimento Nmero elevado de erros [KEIBRICH, BOURKE, TIPS-ETHERNET]. Os tipos de erros encontrados sero os mais diversos. Deve-se sempre suspeitar de uma taxa de erros que no esteja muitssimo prxima de zero.

10.1
Procedimento

Taxa de colises superior a 10%.

10.2
Procedimento

No lado da conexo que est operando em modo full duplex o protocolo CSMA/CD desabilitado, pois neste modo de operao colises nunca devem ocorrer. Como conseqncia, este equipamento ir transmitir sempre que desejar, podendo ser esta a causa de uma taxa elevada de colises. Como o lado full duplex ir transmitir sempre que desejar, sem verificar se o meio est ou no ocupado, uma transmisso pode ser iniciada pelo lado full duplex quando o lado half duplex j tiver transmitido mais que 512 bits de um quadro. Isto caracteriza uma coliso tardia. Portanto, descasamento de modo de operao pode ser a causa de colises tardias.

10.3

4.3.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Verificar modo de operao e velocidade configurados para o enlace com problema;

53

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Teste confirmatrio 1

A forma mais simples de se confirmar o descasamento de modo ou velocidade de operao verificar a configurao dos equipamentos ligados ao enlace suspeito. A interface de gerncia de comutadores Cisco, por exemplo, oferece o seguinte comando:
comutador> show port [mdulo[/porta]]

A sada deste comando mostra, dentre outras informaes, os erros detectados, o modo e a velocidade de operao. Pode-se tambm verificar o modo e a velocidade de operao de uma interface usando SNMP. A varivel dot3StatsDuplexStatus da MIB Ether-Like [RFC2665] informa o modo de operao de uma interface e ifSpeed do grupo Interfaces da MIB-II [RFC2233] a velocidade de operao. Quando placas de rede esto envolvidas pode ser mais complicado confirmar o descasamento. Algumas placas de rede podem ser configuradas manualmente para diversas velocidades e modos de operao. Outras sempre utilizaro a deteco automtica. No Windows, por exemplo, atravs do gerenciador de dispositivos, voc pode ver propriedades avanadas da placa de rede. Nelas voc encontrar o modo e a velocidade de operao da placa de rede.

4.3.5 Sugestes de tratamento

Se for confirmado o descasamento de modo de operao ou velocidade devido a erros de configurao manual, a soluo imediata corrigir a velocidade ou o modo de operao das interfaces envolvidas. Para um melhor desempenho, sempre que possvel use modo de operao full duplex. Se repetidores estiverem envolvidos, o modo de operao sempre deve ser half duplex, pois um repetidor no trabalha no modo full duplex. Em comutadores Cisco os seguintes comandos devero ser utilizados para solucionar o problema [CISCO-AUTO-NEGOTIATION]:
show port capabilities [mdulo[/porta]] set port speed [mdulo[/porta]] {4 | 10 | 16 | 100 | auto} show port [mdulo[/porta]] set port duplex [mdulo[/porta]] { full | half }

Por exemplo, para configurar a porta 1/1 como sendo 100 Mbps, full duplex execute:
comutador> (enable) set port speed 1/1 100
54

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

comutador> (enable) set port duplex 1/1 full

Tratando-se de mquinas com sistema operacional Windows, o modo e a velocidade de operao podem ser configurados, quando a placa de rede assim permitir13. No gerenciados de dispositivos do Windows, clique com o boto direito sobre a placa de rede que deve ser configurada. Escolha o item Propriedades. Na tabela Avanado voc poder modificar o modo e a velocidade de operao da placa de rede. Na Figura 4-6 a placa de rede est sendo configurada para o modo de auto-configurao.

Figura 4-6: Propriedades avanadas da placa de rede SiS 900 em uma mquina com sistema operacional Windows.

Quando o descasamento for provocado por falha na negociao automtica desconectar o cabo e conect-lo novamente vai provocar uma nova negociao e pode ser que a nova negociao seja bem sucedida. Se este problema estiver ocorrendo com freqncia aconselhvel que voc configure as interfaces envolvidas manualmente. O comportamento default das portas dos comutadores , geralmente, a negociao automtica, quando esta funcionalidade suportada. No entanto, uma boa prtica de gerncia programar manualmente o modo e a velocidade de operao das portas que estaro ligadas a equipamentos fixos (com pouca probabilidade de serem trocados), como por exemplo servidores e roteadores. Esta prtica elimina qualquer problema de negociao automtica que possa vir a ocorrer e assegura que o gerente da rede sempre sabe em que modo e velocidade as portas esto operando. Esta prtica assegura tambm que o melhor nvel de desempenho possvel ser escolhido (j que cabe ao gerente definir o modo e a velocidade de operao). Encontrar enlaces sem comunicao fcil. No entanto, descobrir enlaces que operam numa velocidade menor que a desejada j bem mais complexo. Por

13

Algumas placas de redes s podem ser configuradas para a negociao automtica.

55

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

isso, todo cuidado necessrio, principalmente quando se trata de enlaces vitais para a satisfao dos usurios da rede.

4.4 Equipamento de interconexo defeituoso 4.4.1 Descrio

Equipamentos de interconexo podem deixar de realizar sua tarefa e no mais ser capaz de interconectar dispositivos de rede. possvel que equipamentos que costumavam funcionar normalmente, de repente, passem a apresentar um comportamento anormal. A boa notcia que muitas vezes o equipamento aparenta estar com defeito, mas uma reinicializao restabelece sua operao normal. Estas instabilidades podem ser causadas, por exemplo, por quedas rpidas de energia ou erros de programao do sistema operacional do equipamento. No Brasil, o fornecimento de energia costuma ser de pssima qualidade, com oscilaes que realmente podem causar danos aos equipamentos da rede. Portanto, uma checagem da rede eltrica da organizao e das fontes de alimentao de energia dos equipamentos deve ser realizada com certa freqncia. aconselhvel tambm que os equipamentos mais crticos sejam alimentados por no-breaks de boa qualidade, de preferncia no-breaks online senoidais. A m notcia que outras vezes o problema mesmo no hardware do equipamento, nos seus chips de controle, sendo necessria a reposio dos elementos defeituosos. Na prtica, difcil listar todas as possveis causas de defeitos em equipamentos de interconexo. Eles chegam, muitas vezes, a passar a impresso de que tm um tempo de vida til, aps o qual comeam a apresentar comportamentos indesejveis. O problema de equipamentos com portas defeituosas reportado no problema
PLACA DE REDE OU PORTA DE EQUIPAMENTO DE INTERCONEXO DEFEITUOSAS.

4.4.2 Sintomas
Um equipamento de interconexo ou algumas de suas portas com defeito podem ser a causa de rede lenta ou falta de conectividade. Quanto mais prximo do backbone central estiver o equipamento, mais usurios sero afetados.

56

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.4.3 Sinais
Procedimento Equipamento no operacional.

10.4

Infelizmente no podemos tratar este sinal como um sinal diferencial. No procedimento 10.3 consideramos que um equipamento no est operacional se a comunicao com ele no for possvel. Portanto, a causa de um equipamento no estar operacional pode ser realmente defeito no equipamento, mas pode ser outra que no envolva o equipamento. Por exemplo, um cabo de rede rompido.
apresentam estado no operacional.

Procedimento

10.5

Quando o estado administrativo de uma interface est configurado para que ela seja operacional, mas ela no funciona, certamente existe algum problema. Em especial quando um grupo de interfaces falha, desconfie no apenas de problemas nas interfaces, mas no prprio equipamento de interconexo.
Interfaces

Para se ter uma idia relativa de quo saudvel est o seu equipamento de interconexo, voc pode medir a utilizao de seus recursos [PERF&FAULTCISCO]. Limiares de utilizao de recursos sendo excedidos podem ser indicativos de falhas no equipamento.
Procedimento Taxa elevada de utilizao de CPU.

Em geral, utilizao mdia de CPU

10.6
Procedimento

superior a 75% j deve ser investigada.

Taxa elevada de utilizao de memria.

10.7
Procedimento

Se a utilizao de memria do equipamento est diferente da utilizao habitual, sinal de que algo diferente est ocorrendo. Em roteadores, o limiar de advertncia para utilizao de memria 75%. Em hospedeiros deve-se medir no a utilizao de memria em si, mas a freqncia de page out. Neste caso, veja procedimento 10.8
um equipamento de interconexo defeituoso. O efeito negativo de um trfego alto de broadcast/multicast a saturao dos processadores dos equipamentos da rede.

Trfego alto de broadcast/multicast. Este tipo de trfego pode ser gerado por

10.9

4.4.4 Testes confirmatrios

RESUMO
T T T T
E S T E

DOS

TES TES

1 2 3 4

Analisar LEDs; Verificar configurao e estado do equipamento; Testar sistema de transmisso do equipamento; Substituir o equipamento sob suspeita; Se durante a realizao de um dos testes a seguir, algum comportamento anormal for verificado, reinicialize o equipamento e realize o teste confirmatrio novamente.

E S T E

E S T E

E S T E

57

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Teste confirmatrio 1

Analise os LEDs do equipamento suspeito. Os manuais dos equipamentos sempre trazem dicas de como analisar esses LEDs. Por exemplo, o manual pode informar que o LED status sempre deve estar aceso na cor verde. Se ele ficar piscando e apresentar alaranjada, sinal de que muitos quadros/pacotes esto sendo descartados devido a erros, ou se ficar vermelho sinal de que existe um problema grave no equipamento, etc. Pode acontecer de o problema ser confirmado atravs desta anlise, mas possvel que equipamentos de rede se tornem defeituosos e seus LEDs no indiquem problema algum.

Teste confirmatrio 2

Analise o equipamento sob suspeita. Verifique a temperatura do equipamento, se os ventiladores esto funcionando, se o fornecimento de energia est adequado, h quanto tempo o equipamento no foi reiniciado. Voc pode fazer isto utilizando um terminal de gerncia ou telnet. O manual do seu equipamento informa que comandos lhe daro estas informaes. Se o equipamento sob suspeita for um repetidor no gerencivel isto no ser possvel, mas por outro lado sua substituio muito fcil e, se ao substitu-lo os sinais e sintomas cessarem, o defeito foi confirmado. Em roteadores Cisco mais novos os comandos a seguir podem ajudar
roteador# show version roteador# show environment all

O estudo do padro de trfego de cada interface do equipamento sob suspeita (unicast/broadcast/multicast) tambm pode auxiliar na confirmao do problema. Trfegos de entrada e sada anormais (por exemplo, trfegos de entrada e sada idnticos) podem ser indicativos da existncia de um problema no equipamento. Se voc encontrou muitos limiares excedidos, temperatura fora do normal, fornecimento de energia inadequado, por exemplo, estabilizadores queimados, voc est bem perto de confirmar o problema.

58

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Em se tratando de equipamentos que operam alm da camada fsica (comutadores e roteadores) o erro pode estar sendo causado por erro de configurao do equipamento, em especial se ele foi reconfigurado ou inserido h pouco tempo na rede. Para realizar o teste a seguir ser necessrio ter em mos uma mquina com placa de rede e um cabo de redes sem defeito. A mquina e o cabo de teste sero conectados a uma ou mais portas dos equipamentos suspeitos. Lembre-se, portanto, de configurar a rede nesta mquina adequadamente. No apenas endereo IP e rota default, mas tambm modo e velocidade de operao para evitar o descasamento. Utilizando o cabo e a mquina de teste efetue o seguinte teste confirmatrio:

Teste confirmatrio 3

possvel que o equipamento esteja bem, mas uma ou mais interfaces estejam com defeito. Para testar as interfaces do equipamento veja os testes confirmatrios do problema PLACA DE
REDE OU PORTA DEFEITUOSAS. DE EQUIPAMENTO DE INTERCONEXO

A partir da mquina de teste, utilizando a ferramenta ping, devese tentar alcanar outros dispositivos da rede. Realize este teste conectado a mquina de teste em diversas portas do equipamento sob suspeita e enviando ping para outras mquinas da rede. Este teste serve para verificar se o equipamento est repassando os dados que recebe da forma correta, sem inserir erros. Se dados no foram perdidos, os tempos de respostas foram satisfatrios e voc conseguiu retorno de todas as mquinas para as quais enviou ping, bastante provvel que o equipamento no esteja com defeito.

Teste confirmatrio 4

Se factvel, substitua o equipamento sob suspeita por outro que esteja funcionando adequadamente. Ser necessrio configurar o novo equipamento corretamente, para que ele realize sua tarefa de interconexo como esperado. Use o baseline14 de configurao da

14 Leia mais sobre linha base de configurao na seo Sugestes de tratamento do problema VLANs no esto configuradas.

59

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

rede para realizar esta tarefa. Se os sinais e sintomas cessarem o equipamento estava realmente com defeito.

4.4.5 Sugestes de tratamento

Muitas vezes, solucionamos problemas em equipamentos simplesmente reiniciando-os. Se aps a reinicializao o problema persistir a sugesto estudar os manuais do equipamento em busca de dicas para este problema ou entrar em contanto com a assistncia tcnica especializada. Problemas em equipamentos de rede que requeiram sua reinicializao no devem ser observados freqentemente para o mesmo equipamento. Se, por exemplo, toda semana um certo comutador da empresa precisa ser reinicializado, uma investigao mais profunda deve ser iniciada. Comece investigando o sistema eltrico e de refrigerao do prdio. Se isso acontece muito raramente 1 ou 2 vezes por ano no h com o que se preocupar. aconselhvel ter sempre equipamentos de reserva (repetidores, comutadores, roteadores, conversores, etc.) para substituir equipamentos danificados enquanto so consertados. Neste momento, a documentao da rede e a linha base de configurao so de grande auxlio, pois nelas encontram-se as descries de como cada equipamento deve estar configurado e como eles se conectam aos demais dispositivos da rede. Recomenda-se tambm que os gerentes da rede estejam sempre atentos em relao ao sistema operacional dos equipamentos da rede. De tempos em tempos os fabricantes lanam novas verses, que corrigem erros de programao das verses anteriores. Muitas vezes, portanto, um equipamento parece estar defeituoso, mas na verdade o erro est no seu sistema operacional. Alm de erros que podem deixar o equipamento sem funcionar apropriadamente em determinadas condies, furos de segurana so constantemente descobertos, sendo tambm necessria a atualizao do software e reforando ainda mais a necessidade de se estar sempre atento s novas verses de sistemas operacionais que surgirem. Uma excelente prtica de gerncia de configurao organizar o que se chama de baseline traduzido aqui como linha base de configurao da rede. As configuraes de dispositivos devem ser guardados em arquivos (que formam a linha base) de forma a: permitir que um ou mais dispositivos semelhantes sejam configurados a partir de um arquivo de baseline armazenado; verificar se a configurao da rede inteira est de acordo com o baseline; reconfigurar a rede parcial ou totalmente a partir do baseline em caso de problema. A forma como a linha base vai ser salva em arquivos depende do modelo, fabricante e verso do sistema operacional do equipamento. Sempre que voc
60

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

realizar alguma modificao no equipamento atualize o arquivo que guarda suas configuraes. Em comutadores Cisco Catalyst srie 6000/6500 o seguinte comando pode ser utilizado:
console> (enable) copy config {tftp: | rcp:} [all]

Por exemplo, para salvar as configuraes de comutador1 no servidor TFTP 192.168.101.10 o seguinte comando poderia ser executado:
Console> (enable) copy config tftp:comut1.cfg IP address or name of remote host [192.168.101.10]? y Upload configuration to tftp:comut1.cfg (y/n) [n]? y ......... ......... ......... . / Configuration has been copied successfully. (10299 bytes). Console> (enable)

Em roteadores Cisco com IOS verso 12.0 ou superior, use os seguintes comandos para armazenar em um arquivo a configurao completa do roteador:
roteador# copy system:running-config {tftp: | ftp: | rcp:}

Por exemplo, para salvar a configurao de roteador1 no servidor 192.168.101.10 use o comando a seguir:
roteador1# copy system:running-config tftp: Remote host[]? 192.168.101.10 Name of configuration file to write [rtr1-confg]? <cr> Write file rtr1-confg on host 192.168.101.10?[confirm] <cr> ![OK]

O comando copy system citado acima substitui o comando write network em roteadores com IOS mais antigos. O comando write network vlido para o IOS 12.0, mas em outros IOSs mais novos ele no mais existir.

4.5 Placa de rede ou porta de equipamento de interconexo defeituosas 4.5.1 Descrio

Uma placa de rede uma placa adicionada a um computador para permitir que ele se conecte rede. Uma placa de rede que no est funcionando apropriadamente pode ser a causa de falta de conectividade ou de rede lenta. Alguns exemplos de defeitos em placas de rede Ethernet so: a placa no consegue ouvir a portadora (carrier sense) apropriadamente, causando um nmero excessivo de colises, inclusive colises tardias;
61

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

a placa comea a gerar quadros inteis. Dentre os quadros inteis gerados, coincidentemente, pode haver trfego de broadcast/multicast, que, em excesso, satura os processadores dos equipamentos de rede que devem processar todos os quadros de broadcast recebidos e causa a lentido da rede; a placa gera quadros maiores que o indicado pelo padro (1518 bytes). Interfaces de equipamentos de interconexo (portas de repetidores, comutadores e roteadores) tambm podem apresentar defeitos e causar os mesmos sinais e sintomas de placas de rede defeituosas.

4.5.2 Sintomas
Os sintomas de placa de rede ou porta de equipamento defeituosos so: falta de conectividade ou rede lenta. Muitos usurios podero ser afetados, depende da localizao da interface defeituosa. Se esta interface fizer parte do backbone, muitos usurios sero afetados. Se for a interface de uma mquina cliente, apenas este reclamar.

4.5.3 Sinais
Procedimento

10.1
Procedimento

[GUIA-ETHERNET]. Idealmente, as taxas de erros de um enlace so muito prximas de zero. Em enlaces metlicos aceita-se no pior caso at 1 erro a cada 109 bits transmitidos e em enlaces ticos 1 erro a cada 1012 bits transmitidos.
Taxa elevada de colises.

Taxa elevada de erros, em especial erros de CRC e de alinhamento

Uma taxa de colises superior a 10% deve ser

10.2
Procedimento

investigada.

10.3
Procedimento

Placas de redes ou portas de equipamentos defeituosos tambm podem ser a causa de colises tardias. As colises tardias no so eventos normais da rede, e qualquer indcio de colises tardias deve ser investigado.

10.9
Procedimento

Um trfego alto de broadcast/multicast pode ser gerado por uma placa de rede ou porta de equipamento defeituosos. O efeito negativo de um trfego alto de broadcast/multicast a saturao dos processadores dos equipamentos da rede, alm do aumento do consumo de largura de banda. A interface de rede defeituosa pode gerar trfego intil. Este trfego causar o aumento da utilizao do enlace em relao utilizao normalmente observada.
Existncia de quadros maiores que o tamanho mximo imposto pelo padro pode ser sinal de defeito em interfaces [GUIA-ETHERNET]. Aumento da utilizao do enlace.

10.10
Procedimento

10.11

62

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.5.4 Testes confirmatrios

Este problema oferece sintomas e sinais muito semelhantes aos problemas de cabeamento. Se a probabilidade destes dois tipos de problema ocorrer a mesma nenhuma modificao foi feita na rede recentemente e nenhum destes problemas ocorreu proximamente teste o cabo de rede antes de testar a interface. O teste da interface poder falhar caso o cabo de rede esteja com problema.

RESUMO

DOS

TES TES

Para confirmar que uma placa de rede est com defeito realize um dos testes a seguir:
T
E S T E

Certificar-se de que o driver correto da placa de rede est devidamente instalado e a configurao do software de rede apropriada; Substituir a placa suspeita por outra de teste; Substituir a mquina que abriga a placa suspeita por outra de teste; Para confirmar o defeito em interfaces de equipamentos de interconexo:

T T

E S T E

2 3

E S T E

T T T

E S T E

4 5 6

Troque a posio dos cabos nos equipamentos; Substitua o equipamento por outro; Teste as portas sob suspeita com ping; Se voc est desconfiado de uma placa de rede de um servidor ou estao cliente realize um dos trs testes confirmatrios a seguir:

E S T E

E S T E

Teste confirmatrio 1

Considere que o problema realmente est na placa de rede suspeita e tente solucion-lo antes de confirm-lo. Certifique-se de que o driver da placa de rede est corretamente instalado, que a configurao do software de rede apropriada, que no est havendo conflitos de endereos de interrupo na mquina e, de preferncia, realize tambm os testes contidos no disco de diagnstico da placa suspeita diag (veja a Seo SUGESTES DE TRATAMENTO para maiores detalhes). Os testes podem falhar, ou podem concluir que a placa estava mal instalada ou a rede mal configurada. Faa as devidas correes de acordo com o resultado de cada teste e verificao. Pode ser necessrio reinstalar a placa ou reconfigurar o software de rede. Aps as mudanas certifique-se de que o problema foi solucionado. Caso todos os testes indiquem que a placa est operando perfeitamente e ainda assim o problema
63

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

no foi resolvido, bastante provvel que a sua placa de rede esteja sem defeito e que o problema seja no cabo ou no equipamento conectado a ela.

Teste confirmatrio 2

Troque a placa de rede suspeita por outra que esteja funcionando adequadamente. Se os sinais apresentados antes da troca ainda permanecerem, o problema no com a placa. Se os sinais cessarem o problema de placa defeituosa foi confirmado.

Teste confirmatrio 3

Se no for possvel trocar a placa de rede por outra de teste, conecte o cabo que chega na placa de rede suspeita em uma mquina de teste e configure esta mquina com a mesma configurao de rede da mquina substituda. Se a mquina no possui endereo IP fixo e no conseguiu obter seu endereo atravs de um servidor DHCP ela estar sem endereo de rede. Neste caso, ,configure a mquina de teste com um endereo da rede qual ela ser conectada tomando o cuidado para no colocar um endereo IP em uso. Se os sinais e sintomas cessarem o problema , certamente, na mquina substituda, seja na placa de rede ou no driver da placa. Se voc no sabe se a taxa de erros do enlace ligado interface suspeita est elevada, o problema pode ser tambm no servidor DHCP. Se voc desconfia de interfaces equipamentos de interconexo, realize um dos seguintes testes:

Teste confirmatrio 4

Substitua o equipamento com porta sob suspeita por outro que certamente funcione, por exemplo, um equipamento de teste. A troca de um equipamento de interconexo por outro deve ser realizada com bastante cuidado. O equipamento de teste deve estar configurado de forma idntica ao equipamento que ser substitudo. Caso contrrio de nada valer a substituio. Se aps substituio do equipamento os sintomas e sinais cessaram, voc confirmou que o equipamento est com problemas. Leve o

64

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

equipamento em questo para o seu laboratrio e descubra se o defeito no equipamento mesmo ou em uma de suas interfaces.

Teste confirmatrio 5

Conecte o cabo de rede conectado porta sob suspeita em outra porta que esteja funcionando apropriadamente. Se VLANs/roteadores estiverem envolvidos necessrio tomar cuidado com as configuraes da rede. Se, com a troca, os sintomas e sinais cessarem, o problema foi confirmado.

Teste confirmatrio 6

Para realizar este teste voc necessitar de uma mquina e um cabo de testes. Conecte a mquina de teste com o cabo de teste em cada uma das portas do equipamento sob suspeita e tente alcan-lo a partir da mquina de teste com ping, por exemplo. Se o equipamento for um repetidor no gerencivel tente alcanar outro equipamento que tambm esteja conectado ao repetidor. Se, ao conectar a mquina de teste em uma porta do dispositivo suspeito, o LED correspondente porta no acender, quase certa a existncia de problema nesta porta (j que o cabo e a placa de rede utilizados so confiveis). Se alguma porta do dispositivo estiver com defeito o mesmo no ser alcanado atravs da porta ou ser observada uma perda de pacotes elevada (o ping mostra a porcentagem de pacotes perdidos). Suponha que voc esteja desconfiado das interfaces de rede que ligam os equipamentos 10.16.253.254 e 10.16.254.33. Voc ento configura a sua mquina de testes adequadamente e a conecta na porta do equipamento 10.16.254.33 sob suspeita (as configuraes de rede da mquina de testes devem ser semelhantes s configuraes de rede da interface substituda). A partir da sua mquina de testes envie ping para o equipamento 10.16.254.33. Se o resultado do ping informou perda de quadros ou se nada foi retornado, e voc tem certeza de que o equipamento est corretamente configurado, o problema foi confirmado. Se voc quiser, pode realizar este teste em outras portas do equipamento sob suspeita. Os tempos de resposta obtidos ao acessar o equipamento suspeito a partir de cada uma de suas portas devem ser praticamente os mesmos. Observe estes tempos de resposta ao receber as respostas dos pings em busca de comportamento anormal de alguma porta.
65

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Se voc no conseguiu confirmar a existncia de interfaces de rede com defeito, outros problemas tambm de nvel fsico podem estar ocorrendo. Por exemplo: descasamento de velocidade ou modo de operao, cabo de rede danificado ou rompido ou ainda conectores defeituosos ou mal instalados.

4.5.5 Sugestes de tratamento

Se o sistema operacional utilizado for Windows, antes de trocar a placa remova o driver e o software de rede (geralmente TCP/IP) instalados e instale-os novamente. Verifique se o problema foi corrigido. J aconteceu vrias vezes de placas de redes em mquinas Windows simplesmente pararem de funcionar e aps a reinstalao do driver e do software elas voltarem ao normal. Verifique se a placa de rede est apropriadamente conectada ao slot PCI ou ISA da mquina A seguir, execute (novamente) os testes de diagnstico da placa com defeito (geralmente chamam-se diag). Se os testes falharem a placa est realmente defeituosa. Caso contrrio, remova e instale novamente o driver apropriado da placa de rede para o sistema operacional utilizado e reinstale tambm o software de rede. Verifique se o driver instalado realmente corresponde placa conectada ao computador. O computador ter que ser aberto para que se identifique que tipo de placa est conectada. Se for uma placa de rede embutida ser necessrio ter em mos o manual da placa me da mquina e localizar o chip correspondente placa de rede. Se as sugestes anteriores no ajudaram a solucionar o problema troque a placa defeituosa por uma nova. Se foi detectado que uma porta de um equipamento de interconexo est com defeito deve-se testar as demais portas do equipamento e o prprio equipamento antes de chamar a assistncia tcnica especializada. A substituio do equipamento com portas defeituosas por outro ser necessria. Se problemas como este em (placas de rede, portas de equipamentos e equipamentos de interconexo) ocorrem com certa freqncia recomendado que se faa uma auditoria no sistema de alimentao de energia, pois comum que estes problemas ocorram devido a instalaes eltricas de m qualidade.

4.6 Interferncia no cabo 4.6.1 Descrio

O sinal transmitido atravs do cabo pode sofrer interferncias indesejveis e ser corrompido durante a transmisso. As duas fontes mais comuns de rudo so Interferncia Eletromagntica (EMI) e Interferncia de Freqncia de Rdio (RFI). Fontes comuns de EMI so motores, lmpadas florescentes e linhas de energia de corrente alternada. Exemplos de fontes de RFI so telefones celulares, rdio e TV [FIELD_TEST].
66

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Cabos de fibra tica so imunes a interferncia e cabos de par tranado, felizmente, so tambm muito resistentes a estes tipos de rudo. Portanto, este um problema pouco comum. Devido a esta forte resistncia a rudos os prprios padres de cabeamento, como por exemplo EIA/TIA 568A, no se preocupam em definir requisitos de medies de rudo [FIELD_TEST].

4.6.2 Sintomas
Se o cabo que est sofrendo interferncia faz parte do backbone muitos usurios podem ser afetados.
O principal sintoma rede lenta.

4.6.3 Sinais
Procedimento

10.1

A taxa de erros de um enlace deve ser muitssimo prxima de zero. Num enlace de par tranado, por exemplo, a quantidade de erros no deve ultrapassar 1 erro a cada 109 bits transmitidos. Para enlaces ticos aceita-se 1 erro a cada 1012 bits transmitidos. O tipo de erro que deve ser investigado quando h a suspeita de interferncia no cabo em enlaces Ethernet o erro de CRC.

Taxa elevada de erros [HAUGDAHL].

4.6.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Procure por possveis fontes de interferncia ao longo do cabo; Infelizmente, mesmo testadores de cabo com capacidade de medir o rudo no so vlidos [HAUGDAHL] para detectar interferncia no cabo.

Teste confirmatrio 1

Tente descobrir se existe, ao longo do cabo, algum elemento que possa estar causando a interferncia. Lmpadas fluorescentes, aparelhos de rdio. TV, ar condicionado e aspiradores de p so exemplos de equipamentos que podem causar interferncia no cabo. Uma vez localizado um elemento que possa estar causando a interferncia, tente reproduzir o problema artificialmente. Desligue-o ou afaste-o do cabo e teste o cabo para ver se a taxa de erros diminuiu. Ligue o equipamento no seu local original e teste o cabo em busca da taxa de erros. Se ao desligar ou afastar o equipamento a taxa de erros diminuir, a interferncia foi confirmada.

67

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.6.5 Sugestes de tratamento

Se o problema realmente interferncia a sugesto instalar o cabo em um caminho diferente [HAUGDAHL] ou retirar a fonte de interferncia de perto do cabo. Algumas fontes comuns de interferncia so apresentadas na descrio do problema.

4.7 Saturao de banda em segmentos Ethernet compartilhados 4.7.1 Descrio

Leia mais sobre Ethernet no apndice 1

Quando os equipamentos de uma rede Ethernet trabalham no modo de operao half duplex, o acesso ao meio compartilhado. Isto que dizer que quando algum fala, os demais devem ficar calados. Para proteger a integridade dos dados, antes de enviar quadros, as estaes certificam-se de que a rede no est em uso. No entanto, possvel que dois elementos da rede verifiquem, ao mesmo tempo, que no h atividade na rede e iniciem, ambos, a transmisso. O resultado uma coliso. A coliso detectada pelas estaes envolvidas, e aps um certo tempo aleatrio, elas retransmitem os dados. Se, na segunda tentativa de transmisso, ocorrer uma segunda coliso, o tempo mdio de espera para retransmisso dobrado e assim sucessivamente, a cada coliso. Minimizar colises , desta forma, uma tarefa crucial no projeto e gerncia de redes Ethernet. Apesar de colises serem eventos normais em enlaces Ethernet half duplex, quando em excesso, comeam a degradar o desempenho da rede. Uma taxa de colises elevada pode ser resultado da existncia de muito trfego no segmento compartilhado. Muitas mquinas ou aplicaes que requerem muitas transmisses de dados compartilhando o mesmo meio resultam em uma grande disputa por ele. Quando domnios de colises esto congestionados, o nmero de colises aumenta, mais retransmisses so necessrias, aumentando ainda mais a disputa pelo barramento, num crculo vicioso. Todos os equipamentos ligados a um repetidor fazem parte do mesmo domnio de colises. Cada porta de um comutador ou roteador define um domnio de colises. Desta forma, bem mais comum que este problema ocorra quando existem repetidores ligados entre si, e muitas mquinas ligadas nestes repetidores, formando um grande domnio de colises.

4.7.2 Sintomas
O principal sintoma de domnios de colises congestionados rede lenta. Todos os usurios conectados no domnio de colises congestionado sero afetados. Se a rede s est lenta para alguns servios possvel que os servidores estejam em domnios de colises congestionados.

68

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.7.3 Sinais
Procedimento

10.2
Procedimento

Este um dos sinais tpicos de saturao de banda em segmentos Ethernet compartilhados. Taxas de colises superiores a 10% devem ser investigadas.
Taxa de colises elevada. Utilizao de enlaces Ethernet compartilhados (half duplex) superior a 50% de sua capacidade. Para outras tecnologias onde no h compartilhamento ou

10.10

enlaces Ethernet operando no modo full duplex a utilizao pode chegar a 70% sem comprometer o desempenho do enlace.

4.7.4 Testes confirmatrios

Se o problema foi descoberto atravs de reclamaes dos usurios voc j deve ter descoberto se mais mquinas foram adicionadas recentemente no segmento sob suspeita ou novas aplicaes foram instaladas. Alm disso, j sabe se estas modificaes coincidem com o momento em que a rede comeou a ficar lenta. Se apenas a equipe de gerncia tiver autorizao para realizar tais modificaes, vocs tm controle sobre elas mesmo que o problema tenha sido percebido atravs do monitoramento da rede. Se nenhuma nova aplicao foi instalada, nenhuma nova mquina foi adicionada, algum outro problema pode estar levando a um domnio de colises congestionado. Uma placa de rede ou repetidor defeituosos, por exemplo, podem estar gerando dados inteis causando a sobrecarga do segmento e tornando a rede lenta. Nestes casos, alm de colises sero percebidos tambm erros, em especial CRC e alinhamento.

RESUMO
T T
E S T E

DOS

TES TES

1 2

Ver origem das colises; Verificar o estado do domnio de colises antes das modificaes, se possvel;

E S T E

Teste confirmatrio 1

Faa este teste conforme descrito na Seo 10.2.3. Ele s pode ser realizado com o auxlio de um analisador de protocolos. Se ele estiver instalado em um computador pessoal ser necessria tambm uma placa de rede especial para que erros e colises sejam vistas pela aplicao. Com ele, voc pode descobrir que existe uma estao especfica que sempre participa de colises. Como o teste envolve anlise de trfego voc pode descobrir tambm que uma estao responsvel por enviar muitos quadros com erros ou muito trfego de broadcast/muticast. Em todos estes casos o problema de saturao de banda em enlace compartilhado foi confirmado. No entanto, ele est sendo causado por outro
69

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

problema, provavelmente uma placa de rede ou equipamento defeituosos. Solucione este problema e conseqentemente o problema de saturao de banda ser resolvido. Os problemas EQUIPAMENTO DE INTERCONEXO DEFEITUOSO e PLACA DE REDE
OU PORTA DE EQUIPAMENTO DE INTERCONEXO DEFEITUOSAS

podem lhe ajudar. Caso voc no encontre uma estao culpada, e est observando utilizao dos enlaces e taxas de colises elevadas no domnio de colises em questo, o problema de saturao de banda em enlaces compartilhados foi confirmado e precisa ser solucionado. Para tal, ainda com o analisador de protocolos, descubra se existe trfego de uma determinada aplicao em excesso, que est causando a saturao. Se voc no possui um analisador de protocolos capaz de perceber erros e colises, o teste a seguir pode ser realizado.

Teste confirmatrio 2

Se novas mquinas tiverem sido adicionadas e/ou novas aplicaes tiverem sido instaladas nas mquinas clientes, tente simular o ambiente anterior s modificaes proibindo o uso da nova aplicao e/ou desligando as novas mquinas por alguns instantes enquanto voc verifica se o sintoma de rede lenta ainda percebido. Pode no ser possvel realizar este teste. Por exemplo, o sistema operacional das mquinas pode ter sido trocado e neste caso seria impossvel retornar situao anterior. interessante comparar a utilizao e a taxa de colises do segmento com e sem as novas mquinas e/ou aplicaes. Se com o ambiente anterior os sintomas e sinais deste problema no forem mais percebidos, possvel que o problema de saturao de banda em enlaces compartilhados esteja ocorrendo. No entanto, no se pode descartar problemas em nvel de aplicao (aplicaes com erros gerando trfego absurdo) ou equipamentos ou placas de redes defeituosas. Se novos equipamentos foram inseridos e neste teste foram desligados, teste-os. Se for comprovado que todos os equipamentos que tiveram que ser desligados esto funcionando adequadamente, mas a taxa de colises continua alta ao lado de uma elevada utilizao do segmento, o problema de domnio de colises congestionado foi confirmado.

70

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.7.5 Sugestes de tratamento

Ao projetar uma rede no coloque muitas estaes em um nico domnio de colises. Para obter o melhor desempenho deve-se segmentar a rede em domnios de colises mltiplos. Para redes 10Base-T e 100Base-TX, por exemplo, o nmero mximo aceitvel de estaes em um domnio de colises 1024. Para redes 10Base-2 e 10Base-5 este nmero cai para 30 e 100 respectivamente. No entanto, no regra geral que a largura de banda dos enlaces s se tornem saturadas quando este nmero atingido. perfeitamente factvel que com um nmero inferior de mquinas as larguras de bandas dos enlaces se tornem saturadas. Isto vai depender de quanto trfego cada mquina est gerando. Se for detectado que a largura de banda est saturada, necessrio re-projetar a rede e segment-la de forma mais apropriada para que o nmero de colises diminua. Equipamentos de interconexo que operam alm da camada fsica (comutadores e roteadores, por exemplo) separam domnios de colises. Portanto, a segmentao de domnios de colises deve ser feita inserindo comutadores ou roteadores na rede. Se servidores fizerem parte de domnios de colises congestionados o nmero de usurios afetados ser igual ao nmero de clientes do servidor, e este nmero pode ser bem grande e envolver at mesmo pessoas de fora da organizao. Portanto, uma boa prtica conectar servidores a comutadores, nunca a repetidores. Desta forma os servidores no precisaro disputar o barramento Ethernet com outros usurios para transmitir seus dados.

4.8 Tipo errado de cabo 4.8.1 Descrio

Dois tipos de erros em cabos de pares tranados so:
1.
Utilizar categoria de cabo inadequada;

A tecnologia de rede local mais bem aceita no mundo Ethernet. Com o surgimento de Fast Ethernet e Gigabit Ethernet, a migrao das redes Ethernet para Fast ou Gigabit Ethernet um passo natural da evoluo da maioria das redes locais. Comea-se substituindo os comutadores antigos por comutadores 10/100 Mbps ou por comutadores que ofeream algumas portas Ethernet e outras Fast Ethernet e substituindo os repetidores por comutadores (provavelmente os comutadores Ethernet substitudos). Alm disso, so adquiridas placas de rede 10/100 Mbps para os servidores. Aos poucos parte da rede opera a 100 Mbps e parte da rede a 10 Mbps. Em geral, o backbone o primeiro a migrar para a nova velocidade. Com o tempo, toda a rede passa a operar na nova velocidade. Para que a migrao seja completamente bem sucedida podem ser necessrios alguns ajustes na estrutura de cabeamento, no apenas com relao s regras de cabeamento, mas tambm com relao categoria dos cabos utilizados. O
71

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

padro 100Base-TX requer cabos de categoria 5 ou superior ou IBM STP (Shielded Twisted Pair) para funcionar em seu mais alto nvel de desempenho. A estratgia deste requisito minimizar a quantidade de retransmisses de quadros causadas por uma alta taxa de erros de bits. Ao migrar a rede para Fast Ethernet deve-se, portanto, substituir os cabos por outros de categoria adequada (quando cabos de categoria 3 estiverem em uso15). Caso contrrio, a rede poder sofrer problemas de desempenho, pois os cabos de pares tranados categoria 3 no suportam taxas de transmisso maior que 10Mbps.
2.
Utilizar cabos cruzados em vez de cabos paralelos ou vice versa;

Dois tipos de cabos de pares tranados so tipicamente utilizados em uma rede: cabos paralelos e cabos cruzados. A diferena entre eles est relacionada a como os condutores esto dispostos nos terminais metlicos do conector RJ-45 em cada extremidade do cabo. A Figura 4-4 (ver pgina 51) mostra como os condutores devem estar dispostos em ambas as extremidades de cabos paralelos e cruzados. Um cabo paralelo utilizado para conectar estaes finais a um equipamento de interconexo e cabos cruzados so utilizados para conectar dois equipamentos de interconexo entre si ou duas mquinas entre si.

4.8.2 Sintomas
Quando cabos cruzados ou paralelos so utilizados para interconectar equipamentos da rede erroneamente, o sintoma falta de conectividade.
falta de conectividade.

Quando a categoria de cabo errada utilizada o sintoma pode ser rede lenta ou O tamanho do cabo pode influenciar: cabos bem curtos podem causar rede lenta, enquanto cabos maiores levaro falta de conectividade.

4.8.3 Sinais
Procedimento

10.1

Quando cabos de categoria inadequada so utilizados o principal sinal uma taxa elevada de erros, em especial erros de alinhamento. Requisita-se a utilizao de certas categorias de cabo para operar em alta velocidade para minimizar a quantidade de erros de bits em um canal. Deve-se sempre suspeitar de uma taxa de erros que no esteja muito prxima de zero.

4.8.4 Testes confirmatrios

RESUMO DOS TES TES

15 No Brasil, em geral, no se chegou a aproveitar o cabeamento telefnico (categoria 3). O cabeamento inicial, na maioria das organizaes j iniciou com categoria 5, no sendo este problema comum por aqui.

72

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

T T

E S T E

1 2

Verificar LEDs dos equipamentos ligados ao cabo suspeito; Verificar com um testador de cabos ou visualmente se o cabo paralelo ou cruzado; Verificar categoria do cabo; Se o sintoma falta de conectividade realize o seguinte teste:

E S T E

E S T E

Teste confirmatrio 1

Diante da falta de conectividade localize os equipamentos aos quais o cabo sob suspeita est conectado e verifique os LEDs. Geralmente placas de rede e portas de repetidores e comutadores possuem LEDs que indicam se h ou no conectividade ponto-aponto. Se cabos cruzados estiverem sendo utilizados em vez de cabos paralelos (ou vice-versa) os LEDs dos equipamentos ligados ao cabo de tipo errado no acendero. Se os LEDs no acendem ao conectar o cabo de rede, realize o teste a seguir:

Teste confirmatrio 2

Verifique o tipo de cabo utilizado (se um cabo cruzado, ou um cabo paralelo). Cabos cruzados devem ser utilizados para a conexo mquina mquina e entre equipamentos de interconexo (por exemplo, repetidor repetidor, repetidor comutador) quando no existe porta de inverso em pelo menos um dos equipamentos. Diferenciar cabos cruzados de cabo paralelos observando a disposio dos condutores metlicos no conector uma tarefa simples: se a fiao for idntica em ambas as extremidades do cabo, voc est diante de um cabo paralelo, se for diferente, voc provavelmente possui um cabo cruzado. O ideal utilizar um testador de cabos, que indique o tipo de cabo e ainda realize testes para verificar se o cabo est com problemas. Geralmente as portas dos repetidores/comutadores/roteadores so numeradas e a porta identificada pelo maior valor possui ao lado o rtulo Uplink ou MDI/X e um boto que pode ser pressionado para cruzar ou descruzar o sinal. Isto significa que, utilizando esta porta, um cabo no paralelo pode ser usado para interligar dois equipamentos de interconexo entre si. Para interligar dois repetidores com um cabo cruzado, por exemplo,
73

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

conecte o cabo na porta uplink de um repetidor e no outro repetidor utilize uma porta comum. Na Figura 4-7 apresentada uma porta MDI/X de um repetidor.

Figura 4-7: Porta de inverso de um repetidor.

Se voc desconfia que cabos de categoria inadequada esto sendo utilizados, o teste a seguir deve ser realizado:

Teste confirmatrio 3

Verifique se o cabo sob suspeita possui categoria inferior a 5 e est sendo utilizado para conectar equipamentos Fast Ethernet. possvel identificar cabos de categoria inferior a 5 sem a utilizao de equipamentos de teste. Todos os cabos de categoria 5 possuem identificao gravada no prprio cabo pelo fabricante. Se o cabo sob suspeita no estiver identificado, este, com certeza, no um cabo de categoria 5 ou superior. Se estiver marcado leia a identificao. Provavelmente ele ser um cabo de categoria 5 ou superior. A Figura 4-8 apresenta a identificao de um cabo de categoria 5:. Mais uma vez, o ideal mesmo utilizar uma ferramenta para certificao do cabo suspeito. Verifique se ele pertence categoria mnima indicada pelo padro. Se ele no passar pelo teste o problema foi confirmado.

Figura 4-8: Marca no cabo de categoria 5.

74

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.8.5 Sugestes de tratamento

Troque o cabo errado por um tipo certo de cabo, confeccionado de acordo com o padro. A Figura 4-4 (pgina 51) indica o padro de cores para a confeco de cabos paralelos e cruzados de pares tranados. Se cabos de categoria inadequada esto sendo utilizados, substitua-os por cabos de categoria 5 ou superior. A fora de uma corrente depende do seu elo mais fraco. Da mesma forma, o desempenho de um sistema de cabeamento to bom quanto o desempenho do seu enlace mais lento e a categoria de desempenho correspondente menor categoria encontrada nos componentes. Para evitar problemas de desempenho ao migrar para tecnologias de rede mais velozes, realize a certificao de seu cabeamento e assegure-se de que voc possui um sistema categoria 5 ou superior.

4.9 Violao de regras de cabeamento Ethernet 4.9.1 Descrio

Leia mais sobre Ethernet no apndice 1

Ao projetar uma rede Ethernet ou ao adicionar novos equipamentos a uma rede j em operao, algumas regras de cabeamento devem ser consideradas. As regras definem basicamente o comprimento mximo de cada segmento, o nmero mximo de segmentos entre duas estaes finais e a quantidade mxima de estaes finais em cada domnio de colises. Como cada padro Ethernet (por exemplo, 10Base-TX, 100Base-TX) opera em velocidade e/ou meio de transmisso diferentes, os valores mximos para cada uma das regras de cabeamento podem variar dependendo do padro utilizado. Seguir as regras de cabeamento impostas pelo padro de fundamental importncia para que a rede tenha condies de oferecer o seu nvel mximo de desempenho. Caso os padres no sejam respeitados a rede continuar funcionando, porm com desempenho aqum do que lhe permitido. mais freqente que este problema seja causado por usurios. Em busca de uma nova conexo, um usurio simplesmente adiciona um repetidor em sua sala e no avisa aos responsveis pela rede.

4.9.2 Sintomas
O principal sintoma da violao de regras de cabeamento rede lenta. Entre as estaes mais distantes pode haver falta de conectividade devido atenuao do sinal.

75

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.9.3 Sinais
Procedimento

10.2

As regras de cabeamento informam o nmero mximo de estaes em cada domnio de colises. Quando esta regra violada a principal conseqncia uma taxa elevada de colises, pois um nmero elevado de estaes est competindo pelo meio. O problema, neste caso, idntico ao problema de saturao de banda em segmentos Ethernet compartilhados. Uma taxa de colises superior a 10% deve ser investigada.
Ocorrncia de colises tardias.

Procedimento

10.3

Este sinal existe quando so utilizados cabos com comprimento maior que o indicado pelas regras de cabeamento ou quando, entre duas estaes finais, existem mais repetidores que o nmero mximo indicado. Em uma rede que segue as regras de cabeamento e cujos componentes no apresentam defeito a taxa de colises tardias deve ser zero. Em outras palavras, qualquer ndice de colises tardias encontrado na rede indica um problema que deve ser investigado. Uma outra conseqncia da utilizao de cabos maiores que o sugerido pelo padro a atenuao do sinal (perda da fora do sinal devido resistncia eltrica do meio de transmisso).

Procedimento

10.11

4.9.4 Testes confirmatrios

RESUMO DOS TES TES

Verificar o que est fora de especificao:

T T
E S T E

1 2

muitos repetidores entre estaes, ou cabo comprido demais. Se a taxa de utilizao tambm est alta, mais provvel que exista um nmero muito grande de estaes finais em um domnio de colises. Esta disputa acirrada pelo meio ir levar a uma taxa elevada de colises. Este tipo de violao leva saturao da banda em segmentos Ethernet compartilhados. Portanto, deve-se realizar os testes confirmatrios do problema SATURAO DE BANDA EM SEGMENTOS ETHERNET COMPARTILHADOS. Os testes a seguir devem ser realizados se: 1) colises tardias estiverem ocorrendo na rede, 2) existir a suspeita de que cabos muito compridos esto sendo utilizados, ou 3) desconfia-se que o nmero de repetidores entre duas estaes finais no condiz com as regras de cabeamento. Se uma estao de gerncia indica a ocorrncia de colises tardias muito provvel que o cabeamento esteja fora de especificao, mas pode existir uma placa ou equipamento de rede defeituosos. Certifique-se de que o nmero mximo de repetidores entre duas estaes finais do domnio de colises est de acordo com as regras.

E S T E

76

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Teste confirmatrio 1

Descubra qual o nmero mximo de repetidores entre duas estaes finais do segmento. Quanto melhor documentada for a rede, mais simples, rpido e seguro sero a maioria dos testes. Se nenhuma documentao existe deve-se verificar fisicamente como a topologia do domnio de colises sob suspeita. Aproveite o trabalho e comece a documentar a sua rede. Se foi verificado que existem mais repetidores que o nmero mximo especificado entre duas estaes finais, o problema de violao do padro foi confirmado. Infelizmente, os usurios mais ousados podem inserir novos equipamentos na rede sem que a equipe de gerncia tome conhecimento.A documentao da rede lhe mostrar violaes causadas pela equipe de gerncia, mas no exclui a possibilidade de um usurio ter inserido um repetidor na rede para adicionar uma nova mquina em sua sala. Portanto, voc ter que realizar uma investigao para descobrir se isto ocorreu. Para verificar se existe algum cabo com comprimento maior que o mximo indicado no padro deve-se utilizar um testador de cabos.

Teste confirmatrio 2

Um testados de cabos TDR capaz de indicar o comprimento de um cabo metlico (par tranado, por exemplo). Para obter o comprimento de cabos de fibras ticas use um OTDR. Mais informaes sobre estes testadores podem ser encontradas no teste confirmatrio 3 do problema CABO ROMPIDO OU DANIFICADO. Aproveite o testador no apenas para verificar o comprimento do cabo, mas para realizar um teste completo no cabo. Assim, voc estar tambm excluindo ou confirmando a possibilidade problemas nos cabos e nos conectores. Se algum cabo muito comprido for encontrado, o problema de violao de regras de cabeamento est confirmado. No preciso testar todos os cabos do domnio de colises (exceto se est aproveitando a oportunidade para realizar a certificao do cabeamento). Os cabos sob maior suspeita so os cabos que foram adicionados mais recentemente. Se nenhuma violao foi encontrada e colises tardias ocorrem o problema certamente em algum hardware da rede (placa de rede ou outro equipamento de interconexo) ou nos conectores.
77

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.9.5 Sugestes de tratamento

Projete sua rede novamente de modo a obedecer os padres de cabeamento Ethernet. A nova soluo dever contar com repetidores que possuam um maior nmero de portas e/ou com mais comutadores e/ou roteadores. Em uma rede Ethernet 10Base-TX, o nmero mximo de repetidores entre dois equipamentos de dados terminais que participam do mesmo domnio de colises 4. O comprimento mximo aceitvel de cada cabo 100 metros. J em uma rede 100Base-TX podem existir no mximo dois repetidores entre dois equipamentos terminais de dados. O comprimento mximo do cabo entre dois repetidores diretamente conectados no deve ultrapassar 205 m. O comprimento do cabo entre um repetidor e uma estao final de no mximo 100 m. Violaes das regras de cabeamento so comuns quando a rede cresce aos poucos, principalmente com responsabilidade administrativa distribuda. Uma boa prtica de gerncia manter manual ou automaticamente a documentao da topologia fsica da rede, onde repetidores e equipamentos terminais tambm sejam apresentados. Esta prtica, alm de ser til na localizao da maioria dos problemas de rede tambm pode evitar violaes das regras de cabeamento. Manter essa documentao atualizada muito difcil, e quase impossvel quando se trata de redes muito grandes e muito dinmicas. O descobrimento automtico da topologia fsica da rede implementado por algumas ferramentas de gerncia, mas infelizmente, o descobrimento automtico s detecta equipamentos gerenciveis. Por isso, mesmo que ferramentas com descobrimento automtico de topologia estejam sendo utilizadas, se existirem equipamentos no gerenciveis na rede, deve-se ter o controle manual da documentao.

4.10 Referncias 4.10.1 Livros

[GUIA-ETHERNET] [HAUGDAHL] [LAN WIRING] [PERF&FAULTCISCO] Spurgeon, C. E. Ethernet O Guia Definitivo. Traduo Daniel Vieira, Editora Campus, 2000. Haugdahl, J. Scott. Network Analysis Troubleshooting. Addison Wesley, 2000 Trulove, J. LAN Wiring. McGraw-Hill, 1997. Maggiora, P. L. D., Elliot, C. E., Pavone Jr, R. L., Phelps, K. J., Thompson, J. M. Performance and Fault Management. Cisco Press. 2000. and

78

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

4.10.2 Recursos online (Internet)

[BOURKE] Bourke, Tony. The Not-So-Usual Suspect. http://www.hostingtech.com/nm/01_01_mismatch.html [CABLETESTIN G-NEXT] Near End Crosstalk (NEXT). http://www.cabletesting.com/CableTesting/Testing/Definition s/Definitions_NEXT.htm Configuring and Troubleshooting Half/Full Duplex Auto-Negotiation. Ethernet 10/100Mb

[CISCO-AUTONEGOTIATION]

http://www.cisco.com/warp/public/473/3.html [FIELD_TEST] An up-to-date review of physical layer measurements, cabling standards, troubleshooting practices and certification techniques. http://www.wwtc.edu/nsf/AAMI_San_Jose/Arne_WebSite/c abling/cableTestingHandbook.pdf [KREIBICH] Keibritch, Jay. Ethernet Auto-sensing: Adventures in manual configuration. Computing & Communications Services Office, Universidade de Illinois em Urbana-Champaign. http://wwwcommeng.cso.uiuc.edu/docs/autosense/autosense.html [STEINKE] Steinke, Steve. Troubleshooting Ethernet Problems. http://www.networkmagazine.com/article/NMG20000724S00 54 [TIPSETHERNET]

Tips on Troubleshooting Ethernet Errors. http://www.ncat.co.uk/Net_Lib/eth_errs.htm.

4.10.3 RFCs
[RFC2233] [RFC2665] McCloghrie, K., F. Kastenholz. The Interfaces Group MIB using SMIv2. Novembro, 1997. Flick, J., Johnson, J. Definitions of Managed Objects for the Ethernet-like Interface Types. Agosto de 1999.

4.10.4 Livros base

[CISCOINTERNETWORKING] Cisco Systems (Editor). Internetworking Technologies
79

C A P T U L O

P R O B L E M A S

D E

N V E L

F S I C O

Handbook. Cisco Press. Dezembro, 2000.

4.10.5 Outros recursos on-line

[CABLING_MISC]

Misc. Cabling Information. http://learn.wwtc.edu/aev/cabling/misc.htm

80

81

Captulo

5 Problemas de nvel de enlace

Neste captulo encontram-se 5 problemas que podem ocorrer em uma rede relacionados camada de enlace: Interface desabilitada, Problema com rvore de cobertura, Saturao de recursos devido a excesso de quadros de difuso, Tempo de envelhecimento de tabelas de endereos inadequado, Validade da cache ARP inadequada.

5.1 Interface desabilitada 5.1.1 Descrio

Com o auxlio de instrumentao adequada uma estao de gerncia SNMP ou um terminal de gerncia, por exemplo possvel desabilitar administrativamente uma interface de um equipamento de interconexo. Ao ser desabilitada administrativamente, uma interface fica inativa at que ela seja novamente habilitada. possvel que os gerentes da rede desabilitem interfaces que no esto sendo utilizadas no momento para evitar que usurios realizem modificaes topolgicas sem o conhecimento da equipe de gerncia. Ao desabilitar interfaces que no esto em uso voc impede que usurios introduzam novas mquinas ou equipamentos de interconexo, por exemplo, ou passem a utilizar portas que no esto sendo monitoradas. Por outro lado, essa prtica pode gerar confuso. Por exemplo, o prprio gerente pode esquecer que as interfaces vagas esto desativadas. Ele pode adicionar novas mquinas e esquecer de habilit-la. Talvez ele perca algum tempo tentando descobrir porque a rede no funciona para a nova mquina antes de se lembrar de habilitar a interface. Uma outra possibilidade a de sua equipe de gerncia ser alterada e os novos membros no saberem que as portas vagas esto desabilitadas. um problema simples, mas quando a rede no est funcionando ningum se lembra de olhar se a interface est ou no habilitada.

5.1.2 Sintomas
A interface desabilitada administrativamente ficar inativa e, portanto, o sintoma ser falta de conectividade. Qualquer que seja o equipamento ligado interface desativada no ter conectividade com outros membros da rede.
82

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

5.1.3 Sinais
Procedimento Inexistncia de trfego

10.10
Procedimento

de sada e de entrada na interface. Em outras palavras, a utilizao da interface desabilitada zero.

Interface administrativamente desabilitada.

10.13

Ao verificar o estado da interface, percebe-se que ela foi desativada manualmente pela equipe de gerncia da rede.

5.1.4 Testes confirmatrios

O sinal interface administrativamente desabilitada diferencial Portanto, se ele for percebido o problema j est confirmado.

5.1.5 Sugestes de tratamento

Aps descobrir que a interface est administrativamente desabilitada, decida se ela deve ser habilitada ou se houve uma mudana na rede e o cabo conectado a esta interface deve ser conectado a outra. Se a interface vai realmente ser utilizada, habilite-a via estao de gerncia SNMP (reconfigurando a varivel ifAdminStatus), atravs de um terminal de gerncia conectado ao equipamento ou telnet. Em comutadores Cisco, use os comandos a seguir para ativar e desativar operao de portas:
set port enable mod/port set port disable mod/port

Se for decidido que as interfaces que no esto sendo utilizadas devem ficar administrativamente desabilitadas para evitar problemas, recomendado que os cabos de rede estejam devidamente identificados, como descrito em [PERF&FAULT-CISCO], e que a documentao da rede seja suficiente para a deteco de mudanas realizadas por usurios. Por exemplo, a documentao da rede diz que as portas 6, 7 e 8 de um comutador no esto sendo utilizadas, mas ao observar o comutador o gerente v que um cabo est conectado porta 6. Leia mais sobre documentao de rede no apndice 5 e em [PERF&FAULT CISCO]. Se os usurios se sentem confortveis para constantemente modificar a topologia da rede sem o conhecimento dos gerentes, recomendado restringir o acesso de usurios aos equipamentos. Coloc-los em um local onde apenas pessoas autorizadas possam entrar uma boa medida.

83

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

5.2 Problema com rvore de cobertura 5.2.1 Descrio

Leia mais sobre o protocolo rvore de Cobertura no captulo 6

comum que enlaces de redundncia sejam criados entre comutadores para aumentar a confiabilidade da rede. Ao criar um enlace de redundncia entre dois comutadores, o protocolo de rvore de cobertura (PAC) deve ser configurado e habilitado. Este protocolo tem por objetivo evitar que quadros enviados atravs da rede sejam transmitidos indefinidamente pelos comutadores que esto em lao. Para realizar esta tarefa, o PAC define uma rvore que atravessa todos os comutadores da rede e fora o bloqueio de enlaces de redundncia para evitar os laos infinitos de quadros. Se um enlace que estava ativo se tornar indisponvel, o PAC reconfigura a rede reativando enlaces antes bloqueados. Abaixo so listadas algumas situaes que podem levar ao lao infinito de quadros entre comutadores: O PAC no est habilitado em todos os comutadores que participam do lao; Os algoritmos de rvore de cobertura implementados pelos comutadores no so compatveis entre si; Os parmetros configurados para a rvore de cobertura esto muito diferentes para cada comutador; Existe um problema fsico na rede que est causando perda ou atraso considervel de BPDUs (Bridge Protocol Data Unit) de configurao, causando a ativao de portas que deveriam estar bloqueadas; Este ltimo problema, na realidade, no de rvore de cobertura. um problema fsico que causa a perda de quadros de controle da rvore de cobertura.

5.2.2 Sintomas
O lao infinito de quadros entre comutadores ir levar rapidamente falta de conectividade.

5.2.3 Sinais
Procedimento

10.10

O lao infinito de quadros poder levar saturao da largura de banda dos enlaces. Ser percebida uma utilizao mais elevada que a utilizao medida normalmente.
Utilizao de enlaces elevada.

84

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Procedimento

Taxa de colises elevada.

10.2
Procedimento

A saturao da banda causar um aumento na taxa de colises nas portas half duplex onde existe trfego de entrada e de sada. Uma taxa de colises superior a 10% deve ser investigada. Alm da saturao de banda, quadros de difuso em excesso iro causar tempestades de quadros de difuso, e podero saturar tambm os processadores dos equipamentos de interconexo e hospedeiros envolvidos. Durante uma tempestade de quadros de difuso, numa rede com velocidade de 10 Mbps, as mquinas ligadas aos comutadores em paralelo recebero alguns milhares de quadros por segundo. Numa rede que opera a 100 Mbps este nmero cresce para algumas dezenas de milhares de quadros de difuso por segundo. Os equipamentos mais novos de rede so capazes de processar uns 3000 quadros de difuso por segundo sem degradar seu desempenho. O problema saturao de recursos devido a tempestades de difuso traz mais informaes sobre as conseqncias deste sinal.
Utilizao elevada de CPU. Tempestades de quadros de difuso podem causar nos equipamentos envolvidos (que recebem os quadros de difuso) altas taxas de utilizao de CPU. Taxas de CPU acima de 90% so alarmantes e devem ser investigadas.

10.9

Procedimento

10.6
Procedimento

10.14

Quando um comutador ainda no souber para qual de suas portas um quadro deve ser transmitido (a mquina destino ainda no se comunicou atravs deste comutador durante um certo tempo), ele enviar o quadro para todas as suas portas (enchente). Isto levar a uma tempestade de enchente. As tempestades de enchentes podero levar saturao da largura de banda dos enlaces e dos barramentos (backplane) dos equipamentos de rede envolvidos. Alguns comutadores possuem a funcionalidade de proteger a rede contra tempestades de quadros de difuso e enchentes (supresso de quadros de difuso e enchentes). Aps alcanar um certo limiar configurvel por exemplo, durante 1 segundo no mximo 100 quadros de difuso podero ser comutados o trfego de quadros de difuso suprimido. Se bem configurado, a tempestade de quadros de difuso (ou de enchentes) no chegar a ocorrer. No caso em que a supresso estiver habilitada, ser necessrio verificar se o limiar no est sendo atingido com freqncia.

5.2.4 Testes confirmatrios

RESUMO
T T T T
E S T E

DOS

TES TES

1 2 3 4

Verificar estado e configurao do PAC nos comutadores envolvidos; Verificar o algoritmo de rvore de cobertura utilizado pelos comutadores; Verificar dimetro mximo da rede comutada; Verificar o intervalo de tempo em que BPDUs de configurao so enviadas e se notificaes de mudana de topologia esto ocorrendo com freqncia;

E S T E

E S T E

E S T E

85

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Os testes a seguir devem ser realizados em todos os comutadores da rede que participam do lao.

Teste confirmatrio 1

Com um terminal de gerncia ou atravs de telnet16, verifique se o PAC est configurado e habilitado em todos os comutadores em questo. Se estiver desabilitado, provvel que exista um lao e que o problema seja confirmado. A tempestade de quadros de difuso e enchente causam saturao de recursos nos equipamentos de rede envolvidos e em hospedeiros. Ao tentar analisar o PAC em um comutador possvel que ele no responda aos comandos de gerncia (pois est com recursos como CPU, por exemplo, saturados). Neste caso, desconecte temporariamente o cabo de um dos enlaces de redundncia. Se os sinais e sintomas cessarem o problema est praticamente confirmado.. Para ter a certeza de que o PAC est desabilitado, verifique a configurao deste protocolo no comutador. Os comandos de verificao do PAC mudam dependendo do fabricante e do modelo do equipamento. Os manuais dos equipamentos informaro como esta verificao pode ser realizada. Em um comutador Cisco, por exemplo, o comando show spantree retorna informaes de configurao do PAC e ainda se ele est ou no habilitado. Abaixo segue um exemplo da resposta a este comando quando a rvore de cobertura no est configurada:
Sw-bb-vendas> show spantree Spanning tree disabled

Se o PAC estiver habilitado o retorno seria semelhante ao exemplo abaixo:

Sw-bb-vendas> show spantree Spanning tree enabled Designated Root Designated Root Priority Designated Root Cost Designated Root Port 00-50-1c-7a-8b-2e 32768 0 1/0

16 Pode ser que a largura de banda dos enlaces esteja saturada e voc no consiga chegar no equipamento atravs de telnet

86

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Root Max Age Forward Delay

20 sec 10 sec

Hello Time

2sec

Port,Vlan Vlan Port-State Cost Priority Fast-Start Group-method

-------1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1

---- ---------- ---1 1 1 1 1 1 1 1 forwarding blocking forwarding forwarding forwarding forwarding forwarding forwarding 10 10 10 10 10 10 10 10

------32 48 32 32 32 32 32 32

-------disabled disabled enabled enabled disabled disabled disabled disabled

------

Alm habilitar o PAC em todos os comutadores envolvidos, recomenda-se que eles tambm estejam configurados com os mesmos valores para cada um dos parmetros de configurao do protocolo (hello time, max age e forward delay). As informaes sobre o PAC em um comutador podem tambm ser recuperadas atravs de uma estao de gerncia SNMP. O grupo dot1dStp da MIB Bridge [RFC1493] traz informaes sobre o PAC e geralmente implementado pelos comutadores que suportam este protocolo. Pode no ser possvel recuperar estas informaes atravs da rede quando um problema com PAC estiver ocorrendo, uma vez que o sintoma falta de conectividade. As variveis dot1dStpHelloTime, dot1dStpForwardDelay e dot1dStpMaxAge informam os valores utilizados no momento pelo comutador para o hello time, forward delay e max age respectivamente. Alm destas variveis pode-se obter o estado e outras informaes sobre as portas de cada comutador atravs da tabela dot1dStpPortTable. Os valores de hello time, max age e forward delay configurados para o comutador (e que sero utilizados quando o comutador for a raiz da rvore) so encontrados respectivamente em: dot1dStpBridgeHelloTime, dot1dStpBridgeMaxAge e dot1dStpBridgeForwardDelay. Na Seo SUGESTES DE TRATAMENTO so dados valores tpicos para estes parmetros do PAC.

87

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Teste confirmatrio 2

Problemas tambm podem surgir quando algoritmos de rvore de cobertura distintos estiverem sendo utilizados pelos comutadores. Protocolos diferentes lidam de forma diferente com as BPDUs, podendo causar laos. Verifique em cada comutador que algoritmo de rvore de cobertura est sendo utilizado. provvel que esta informao seja encontrada nos manuais do comutador. Se mais de um algoritmo for encontrado o lao pode estar sendo causado por este descasamento. Os algoritmos implementados so o DEC e o IEEE, sendo este ltimo mais utilizado. Esta informao pode tambm ser recuperada atravs de uma estao de gerncia SNMP. A varivel dot1dStpProtocolSpecification da MIB Bridge informa que algoritmo de rvore de cobertura est sendo utilizado pelo comutador. Se o seu valor for 1 o algoritmo desconhecido, se for 2 o algoritmo o DEC e sendo 3 o algoritmo implementado pelo comutador o IEEE.

Teste confirmatrio 3

Outro parmetro que deve ser investigado o dimetro da rede comutada, isto , deve-se verificar o nmero mximo de comutadores entre duas estaes finais da rede comutada. Para que o PAC opere corretamente o dimetro da rede deve ser limitado. O IEEE recomenda um dimetro mximo de 7 comutadores. Mais informaes podem ser obtidas no padro IEEE 802.1D, onde o PAC definido. possvel que todos os sinais/sintomas de um lao estejam sendo verificados, apesar de o PAC estar habilitado em todos os comutadores envolvidos. Na prtica, a maioria dos problemas fsicos levam a uma rvore de cobertura instvel. Por exemplo, BPDUs de configurao podem ser perdidas devido a um cabo danificado, cabos com interferncia, conectores mal instalados, largura de banda compartilhada saturada ou equipamento defeituoso, gerando a transmisso infinita de quadros na rede. Na realidade todos os problemas que possam causar a perda ou atraso elevado de dados (e conseqentemente perda e atraso de BPDUs de configurao) podem levar o comutador secundrio a entrar no estado de aprendizagem e mais tarde no estado forwarding, causando os laos, pois na realidade a raiz principal ainda est em funcionamento. Se a raiz da rvore de cobertura, por exemplo, estiver muito ocupada, as BPDUs de configurao podem ser enviadas em intervalos bem maiores que o hello time configurado e causar o desbloqueio de portas que deveriam estar bloqueadas.
88

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Para entender melhor o comportamento do PAC em sua rede comutada realize o seguinte teste com o auxlio de um analisador de protocolos ou uma estao de gerncia SNMP:

Teste confirmatrio 4

Conecte um analisador de protocolos em um comutador que participa da rvore de cobertura. Capture quadros BPDUs durante alguns minutos. Para capturar apenas os quadros BPDUs defina um filtro que aceite tudo que tenha como origem ou destino o grupo bridge (endereo fsico 0180C2000000). Aps a captura verifique se:
1. as BPDUs de configurao esto sendo enviadas no intervalo configurado (hello time) os analisadores de protocolos geralmente informam o tempo que se passou entre a chegada de dois quadros consecutivos capturados. As BPDUs de configurao devem ser enviadas em intervalos regulares, definidos pelo hello time. Verifique de quanto em quanto tempo BPDUs de configurao so enviadas e compare este valor com o hello time configurado nos comutadores;

2. mudanas de topologia freqentes (Topology Change Notification BPDU) esto ocorrendo uma BPDU de mudana de topologia enviada quando um novo equipamento/hospedeiro adicionado rede, quando um equipamento j conectado ligado ou desligado, ou ainda quando h mudana de topologia fsica na rede (uma mquina estava ligada na porta 1 passou a ser ligada na porta 2, por exemplo). Se nenhuma destas situaes est ocorrendo, uma BPDU de configurao no enviada. Se for encontrado o nmero elevado de BPDUs de mudana de topologia em uma rede, aliado a um atraso significativo de BPDUs de configurao e nenhum dos testes anteriores acusou um problema de PAC, possvel que um problema fsico esteja ocorrendo na rede; Pode-se tambm provocar uma mudana (trocar a porta qual uma mquina estava conectada) e verificar se BPDUs de mudana de topologia so realmente transmitidas. possvel verificar se mudanas de topologia constantes esto ocorrendo com o auxlio de uma estao de gerncia SNMP. A varivel dot1dStpTimeSinceTopologyChange da MIB Bridge indica h quanto tempo (em centsimos de segundo) uma
89

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

notificao de modificao de topologia foi feita. Estude o comportamento desta varivel durante algum tempo 1h, por exemplo. Durante este tempo, certifique-se de que mquinas no estejam sendo inseridas ou retiradas (desligadas, por exemplo) da rede. Se for constatado um crescimento constante da varivel dot1dStpTimeSinceTopologyChange, algum problema est realmente ocorrendo. Se este ltimo teste revelou que BPDUs de configurao esto sendo enviadas em intervalos muito maiores que o hello time configurado (com alguns segundos de atraso, por exemplo), ou mudanas constantes de topologia so notificadas quando teoricamente no deveriam ser, possvel que algum problema fsico na rede esteja causando a instabilidade da rvore de cobertura, resultando em laos na rede.

5.2.5 Sugestes de tratamento

Se foi confirmado que alguns comutadores no estavam com PAC habilitado, configure-o e habilite-o. Em alguns comutadores o PAC j vem habilitado com a configurao default. No entanto, esta no uma regra geral. Se laos forem planejados necessrio verificar se o protocolo est realmente habilitado para evitar este problema. Se foi confirmado que algoritmos de rvore de cobertura incompatveis estavam sendo utilizados, trate de reconfigurar os comutadores para apenas um algoritmo seja utilizado em todos eles. Se os parmetros de rvore de cobertura configurados em cada comutador so muito diferentes entre si modifique-os. Recomenda-se que os valores de max age, forward delay e hello time sejam idnticos para todos os comutadores que participam da rvore, pois isto evitar configuraes problemticas. A tabela abaixo apresenta os valores recomendados em [IEEE802.1D] para os parmetros do PAC referenciados acima. Parmetro Bridge Hello Time Bridge Max Age Bridge Forward Delay Valor recomendado 2.0 20.0 15.0 Variao permitida 1.0 10.0 6.0 40.0 4.0 30.0

Tabela 5-1: Valores recomendados para alguns parmetros do PAC.

Com os parmetros default a rvore de cobertura ir funcionar, mas pode-se modificar certos parmetros para certificar-se de que, por exemplo, a raiz e a raiz secundria so comutadores conhecidos, centrais e no sobrecarregados e portas mais velozes tm custos menores que portas mais lentas. Estas configuraes podem ser realizadas com o auxlio de um terminal de gerncia ou com auxlio do SNMP. Para alterar a prioridade de um comutador ou o custo de suas portas:
90

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

atravs da interface de linha de comando com o auxlio de telnet ou um terminal de gerncia em cada equipamento comandos diferentes devero ser executados para configurar o PAC. Em um comutador Cisco Catalyst 6000 a prioridade do comutador pode ser modificada com o comando set spantree priority. Veja mais informaes sobre como proceder no manual do seu equipamento; utilizando SNMP e a MIB Bridge ao modificar o valor da varivel dot1dStpPriority da MIB Bridge modifica-se a prioridade do comutador. A varivel dot1dStpPortPathCost da tabela dot1dStpPortTable pode ser alterada para se alterar o custo das portas do comutador.

5.3 Saturao de recursos devido a excesso de quadros de difuso 5.3.1 Descrio

Um quadro de difuso endereado a todas as estaes que participam do mesmo domnio de difuso do emitente. Muitos protocolos de rede e aplicaes em uma rede local dependem do envio de quadros de difuso para funcionar apropriadamente. Por exemplo: ARP, DHCP e NETBIOS. Os domnios de difuso so limitados por roteadores e VLANs. Comutadores (onde VLANs no esto configuradas) no separam domnios de difuso e, portanto, transmitem um quadro de difuso recebido para todas as suas portas. Uma tempestade de quadros de difuso ocorre quando um nmero elevado de quadros de difuso est trafegando na rede (milhares de quadros de difuso por segundo). Em um domnio de difuso, quanto maior o nmero de estaes e a quantidade de protocolos e aplicaes que dependem do envio de quadros de difuso, maior a quantidade desses quadros e maior a probabilidade da ocorrncia de tempestades de quadros de difuso. Tempestades de quadros de difuso podem ser causadas no apenas por excesso de mquinas ou de trfego de difuso em um domnio de difuso, mas tambm devido a erros tais como: problema com protocolo rvore de cobertura (ver pgina 84); tempo de envelhecimento da cache ARP muito pequena em muitas mquinas da rede (ver pgina 96) defeitos em equipamentos e placas de rede (ver pginas 56 e 61); aplicaes com erro de programao.

91

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

5.3.2 Sintomas
mais comum que o excesso de quadros de difuso tornem a rede lenta. No entanto, dependendo da quantidade destes quadros, os usurios podem reclamar de falta de conectividade.

5.3.3 Sinais
Procedimento

10.9

Quantidade excessiva trfego de quadros de difuso. Tipicamente, uma mquina envia em mdia um quadro de difuso a cada 10 segundos. Em um domnio de difuso com 1600 mquinas, por exemplo, seria normal um trfego de difuso em torno de 160 quadros por segundo. Quando este nmero cresce para milhares de quadros de difuso por segundo, uma tempestade de quadros de difuso est ocorrendo. Os processadores de equipamentos mais modernos conseguem processar alguns milhares de quadros de difuso por segundo sem comprometer o desempenho da rede.

Alguns comutadores possuem a funcionalidade de suprimir o trfego de difuso. Eles podem ser configurados para aceitar at uma certa quantidade de quadros de difuso por segundo (limiar), e descartar os demais quadros. Neste caso, deve-se observar se o limiar estabelecido est sendo constantemente alcanado.
Procedimento Utilizao alta de CPU.

10.6

Uma quantidade excessiva de quadros de difuso trafegando na rede pode saturar os processadores de equipamentos de interconexo e hospedeiros. Durante tempestades de quadros de difuso intensas, a utilizao de CPU dos equipamentos da rede ir crescer bastante em relao ao normal, e poder chegar a alcanar 99/100%. Em geral, taxas mdias de utilizao de CPU superiores a 75% j devem ser investigadas.
Aumento da utilizao de enlaces.

Procedimento

10.10

Tempestades de quadros de difuso aumentam a utilizao dos enlaces que participam do domnio de difuso onde a tempestade est ocorrendo. Ser observado um aumento da utilizao dos enlaces em relao ao trfego normal da rede. Considerando quadros de difuso de 64 Kbps, se 1000 quadros de difuso trafegam a rede por segundo, a largura de banda consumida por eles : 1000 x 64 x 8 = 512 Kbps.

5.3.4 Testes confirmatrios

O sinal quantidade excessiva de trfego de difuso diferencial. Se alguns milhares de quadros de difuso esto trafegando na rede por segundo, a tempestade de quadros de difuso j foi confirmada. Como citado anteriormente, tempestades de quadros de difuso podem ter vrias causas. Dentre elas encontram-se: problemas com o protocolo rvore de cobertura, tempo de envelhecimento da cache ARP muito pequena, problemas de hardware, aplicaes com erros de programao e ataques de negao de servio. O teste descrito nesta Seo tem por objetivo auxiliar a encontrar a causa real do problema.

92

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

RESUMO
T
E S T E

DOS

TES TES

Examinar os tipos de quadros de difuso que esto trafegando e qual a sua origem;

Teste confirmatrio 1

Quando uma tempestade de quadros de difuso estiver ocorrendo, capture os quadros de difuso da rede em questo com um analisador de protocolos. Dicas para a realizao deste teste podem ser encontradas nos procedimentos 9.1 e 10.9. Aps capturar os quadros decodifique-os e tente responder as seguintes questes: 1. os quadros de difuso so, em sua maioria, provenientes de alguma mquina especfica ou so originrios de diversas mquinas da rede? 2. qual o protocolo de nvel superior dos quadros de difuso? Por exemplo, so todos (ou quase todos) ARP? Ou no h um protocolo de nvel superior que se sobressaia em relao aos outros? Se a maioria dos quadros vem de uma mquina especfica da rede, a placa de rede desta mquina pode estar defeituosa. Veja o problema PLACA DE REDE OU PORTA DE EQUIPAMENTO DE INTERCONEXO DEFEITUOSAS na pgina 61. Se os quadros de difuso capturados, carregam quase sempre dados de um mesmo protocolo de camada superior ou aplicao, provvel que o problema seja na configurao do protocolo, ou erros de programao de aplicaes. Quando o mesmo quadro de difuso trafega na rede indefinidamente, o problema com o protocolo rvore de cobertura. Veja PROBLEMA COM RVORE DE COBERTURA na pgina 84. Se no foi possvel encontrar um padro, isto , os quadros de difuso vm das mais diversas origens e carregam dados de diversos protocolos, bem provvel que o domnio de difuso esteja super povoado.

5.3.5 Sugestes de tratamento

Se foi confirmada a existncia de tempestades de quadros de difuso na rede devido a um domnio de difuso congestionado, deve-se quebrar o domnio de
93

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

colises em vrios domnios menores configurando VLANs nos comutadores ou inserindo roteadores na rede.

5.4 Tempo de envelhecimento de tabelas de endereos inadequado 5.4.1 Descrio

Leia mais sobre comutadores no apndice 4

Um comutador mantm uma tabela, chamada tabela de endereos, que informa atravs de qual de suas portas uma mquina (identificada pelo seu endereo fsico) pode ser alcanada. Esta tabela inicia-se vazia, e medida que as mquinas se comunicam atravs do comutador, ela vai sendo povoada, atravs de uma tcnica chamada backward learning17. Cada entrada na tabela de endereos informa a porta que d acesso a uma certa mquina da rede. Quando o comutador recebe um quadro de uma mquina, a entrada correspondente na tabela de endereos atualizada. Se uma maquina da rede no se comunica atravs do comutador durante um certo tempo (chamado tempo de envelhecimento), a entrada na tabela de endereos correspondente mquina em questo removida. Ao receber um quadro destinado a um certo endereo fsico, o comutador procura em sua tabela de endereos atravs de que porta o quadro deve ser enviado. Se no encontrar esta informao na tabela de endereos, o quadro enviado para todas as portas do comutador (flooding, traduzido aqui como enchente). Em uma rede comutada com muitas mquinas, quando o tempo de envelhecimento configurado em um comutador for muito pequeno, enchentes sero realizadas com bastante freqncia, gastando largura de banda da rede desnecessariamente. Por outro lado, quando o tempo de envelhecimento for muito grande e o protocolo rvore de Cobertura no estiver ativado, entradas na tabela de endereos podem se tornar obsoletas. Como conseqncia, mquinas podem ficar incomunicveis por um certo perodo de tempo, at que a tabela de endereos seja ajustada. A tabela de endereos ajustada quando a mquina que sofreu modificao se comunica atravs do comutador, ou quando acaba o tempo de envelhecimento. Quando o protocolo de rvore de Cobertura estiver habilitado, BPDUs de mudana de topologia sero enviadas sempre que alguma mudana ocorrer na rede. Sendo assim, em redes totalmente comutadas, mesmo que o tempo de

17 Ao receber um quadro atravs de uma de suas portas, emitido por uma mquina origem A, o comutador aprende atravs de que porta a mquina A pode ser alcanada, e adiciona esta informao na sua tabela de endereos.

94

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

envelhecimento esteja grande18, a tabela de endereos ser rapidamente atualizada.

5.4.2 Sintomas
Quando os comutadores estiverem configurados com tempo de envelhecimento muito pequeno, os usurios podero reclamar de rede lenta. Se o tempo de envelhecimento estiver muito grande, o sintoma ser conectividade intermitente.

5.4.3 Sinais
Procedimento

10.14

Quando o tempo de envelhecimento for muito pequeno, o sintoma principal ser ocorrncia muito freqente de enchentes. As enchentes podem ser verificadas visualmente (atravs dos LEDs do comutador), da mesma forma como ser verificam tempestade de quadros de difuso. Quase todos os LEDs acendem de um vez, indicando que um quadro foi enviado por enchente ou difuso. Em grande quantidade, as enchentes iro causar o aumento da utilizao dos enlaces em relao utilizao normalmente verificada.

Procedimento

10.10

5.4.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Verificar valor configurado para tempo de envelhecimento de tabelas de endereo;

Teste confirmatrio 1

Pode-se verificar o valor do tempo de envelhecimento da tabela de endereos de um comutador com o auxlio de uma estao de gerncia SNMP. A varivel dot1AgingTime da MIB Bridge [RFC1493] informa o perodo de validade dos endereos em segundos (um valor entre 10s e 106s). Esta varivel pode ser utilizada para recuperar o valor da validade e tambm para configurar um novo valor.

18 Se existirem repetidores ligados aos comutadores e uma mquina for transferida de um repetidor para outro, mesmo que o PAC esteja habilitado a atualizao da tabela de endereos no ser imediata.

95

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Pode-se tambm verificar e atualizar o tempo de envelhecimento com o auxlio de um terminal de gerncia ou de telnet. Os comandos a serem executados dependem do modelo e do fabricante do equipamento. Em um comutador Cisco srie 6000, por exemplo, o tempo de envelhecimento pode ser configurado/recuperado da seguinte forma com os comandos:
show cam agingtime [vlan] set cam agingtime [vlan] <aging_time_em_segs>

Por exemplo, para configurar um tempo de envelhecimento de 5 minutos na VLAN 1, o seguinte comando deve ser executado:
console> (enable) set cam agingtime 1 300

5.4.5 Sugestes de tratamento

Este problema no ocorre comumente. Para ele vir a afetar a rede, necessrio que existam milhares de mquinas numa rede comutada, onde os comutadores esto configurados com tempo de envelhecimento muito pequeno (algumas poucas dezenas de segundos), ou, que mudanas sejam muito freqentes e o tempo de envelhecimento configurado esteja muito alto. O tempo de envelhecimento recomendado no padro IEEE 802.3D 300 segundos, isto , 5 minutos, sendo este o valor default do tempo de envelhecimento na maioria dos equipamentos.

5.5 Validade da cache ARP inadequada 5.5.1 Descrio

Leia mais sobre ARP no apndice 7

Em redes TCP/IP, o protocolo ARP utilizado para mapear endereos lgicos em endereos fsicos. ARP usado apenas em redes que suportem envio de quadros de difuso, como por exemplo, Ethernet. Todos os endereos mais recentemente mapeados so armazenados temporariamente em uma tabela, chamada cache ARP. O funcionamento do protocolo de resoluo de endereos simples: quando uma estao deseja encontrar o endereo fsico correspondente a um determinado IP ela procura em sua cache ARP. Se o mapeamento desejado no for encontrado na cache ARP, a estao envia um quadro de difuso ARP, solicitando estao com o IP em questo que informe seu endereo fsico. Cada entrada da cache ARP vlida durante um certo tempo, chamado tempo de validade da cache ARP. Se o tempo de validade da cache ARP for muito longo e houver mudanas na rede, a cache conter informaes incorretas e quadros podero ser encaminhados para o destino errado. As mudanas que
96

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

podem levar a uma cache ARP incorreta so: troca de placa de rede de equipamentos, substituio de um equipamento por outro com mesma configurao IP e modificao de endereo IP de equipamentos. Alm disso, se o servio DHCP estiver sendo utilizado, uma mquina cliente pode ter um certo endereo IP em um dia e no dia seguinte outro endereo IP. Portanto, aps o vencimento do tempo de validade da cache ARP, as entradas desta tabela expiram. Se o perodo de validade da cache ARP for muito pequeno, muitos quadros de difuso ARP estaro trafegando na rede, consumindo recursos de equipamentos de interconexo e hospedeiros e podendo tornar a rede lenta. No comum que o problema com tempo de validade de cache ARP ocorra. Os sistemas operacionais vm com valores default para o tempo de validade da cache ARP. Este problema s ocorrer se estes valores forem modificados para outros valores inadequados em alguma estao de trabalho.

5.5.2 Sintomas
Quando o perodo de validade for muito pequeno, os usurios podem sentir a rede lenta. Muitos quadros de difuso estaro trafegando na rede, pois um mapeamento deve ocorrer sempre (ou quase sempre) que duas mquinas desejam se comunicar. Em mquinas onde o perodo de validade for muito grande, os usurios podero sentir falta de conectividade durante determinado perodo de tempo com outras mquinas quando houver mudanas na rede. Por exemplo, na cache ARP de uma mquina, o endereo IP 10.10.10.1 mapeado para 4445.5354.ab00. Esta entrada ficar vlida durante algumas horas. No entanto, a placa de rede de 10.10.10.1 apresentou problemas e teve que ser substituda. At que o tempo de validade da cache ARP vena, esta mquina no poder se comunicar com a mquina 10.10.10.1.

5.5.3 Sinais
Procedimento

10.15
Procedimento

Se o perodo de validade da cache ARP for muito pequeno, uma quantidade excessiva de quadros de difuso ARP poder estar trafegando na rede. Em geral, o nmero de quadros de difuso ARP por segundo bem menor que o nmero de mquinas no mesmo domnio de difuso. Como conseqncia do sinal anterior, poder ser observado um sutil aumento na utilizao dos enlaces que fazem parte do domnio de difuso, uma vez que o nmero de quadros de difuso ARP enviados aumenta. Quadros de difuso ARP so pequenos, por isso o aumento da utilizao dos enlaces pode ser imperceptvel.

10.10

97

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

5.5.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Descobrir estaes que esto gerando muitos quadros ARP; Verificar valor configurado para tempo de validade da cache ARP nas mquinas suspeitas; Quando o sintoma for falta de conectividade temporria com algumas mquinas, um ou mais usurios iro reclamar. Realize o teste confirmatrio 2 nas mquinas envolvidas. Quando o sintoma for rede lenta, e houver suspeita de que o tempo de validade da cache ARP est muito pequeno, realize o teste confirmatrio 1 antes de realizar o teste confirmatrio 2.

E S T E

Teste confirmatrio 1

No procedimento ANALISANDO

TRFEGO DE DIFUSO

ARP (Seo

USANDO UM ANALISADOR DE PROTOCOLOS) voc encontrar dicas

mais precisas de como realizar este teste. Com um analisador de protocolos capture os quadros ARP que trafegam na rede e tente responder a seguinte questo: existe uma ou mais mquinas que so responsveis pelo envio da maioria dos quadros ARP que trafegam na rede, ou todas as mquinas, de forma mais ou menos homognea, esto enviando quadros ARP? Se for detectada que uma ou algumas poucas mquinas esto enviando muitos quadros ARP, verifique a validade da cache ARP configurada para estas mquinas. Caso contrrio, mais provvel que exista um nmero muito grande de mquinas em um domnio de difuso, mas ainda possvel que todas as mquinas tenham tido seus tempo de validade da cache ARP alterados. Para obter o tempo de validade da cache ARP, realize o teste confirmatrio 2. Cada sistema operacional oferece um meio diferente para se configurar o tempo de validade da cache ARP. O teste abaixo considera apenas os sistemas operacionais Windows NT, Windows 2000 e Linux Slackware.

Teste confirmatrio 2

No Windows NT/2000, use um editor de registro (regedit.exe) para procurar o valor do tempo de validade da cache ARP. No editor, procure os parmetros de registro chamados ArpCacheLife e ArpCacheMinReferencedLife. Se estes
98

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

parmetros existirem, verifique o valor estabelecido. Caso o parmetro no exista, o valor default estar valendo, e no provvel que esteja ocorrendo algum problema com tempo de validade da cache ARP. Valores como alguns poucos segundos (1 segundo, por exemplo) ou milhares de segundos (12400 segundos) podem ser a causa do problema. No Linux, procure no arquivo /usr/src/linux/net/ipv4/arp.c o valor estabelecido para base_reachable_time. Para entender melhor o cdigo veja a definio de neigh_table e neigh_parms em /usr/src/linux/include/net/neighbours.h. O valor default 30 segundos. Se um outro valor foi encontrado, esta modificao pode ser um problema se for um valor muito grande, ou muito pequeno. Em comutadores Cisco srie 6000 o comando abaixo lhe informar o tempo de validade da cache ARP do equipamento:
Console> (enable) show arp

Se os valores default forem configurados, e ainda assim os sinais/sintomas persistirem, o problema no validade de cache ARP inadequada.

5.5.5 Sugestes de tratamento

Recomenda-se que o tempo de validade da cache ARP permanea com o valor default implementado pelos fabricantes de sistemas operacionais. Abaixo encontram-se dicas de como modificar o valor do tempo de validade da cache ARP no Linux Slackware (ncleo 2.2.16) e no Windows NT e 2000. No Linux, o tempo o de validade randmico, variando entre
base_reachable_time/2 e 3*base_reachable_time/2. Modificando-se o valor de base_reachable_time em /usr/src/linux/net/ipv4/arp.c e recompilando o

de validade da cache ARP. Em /usr/src/linux/include/net/neighbour.h esto definidas as estruturas neigh_table e arp_parms. Esta ltima contm parmetros de configurao ARP, dentre eles o base_reachable_time. Baseado nas definies deste arquivo, pode-se encontrar mais facilmente o valor de base_reachable_time em arp.c. No Windows NT e 2000, os parmetros de registro chamados ArpCacheLife e ArpCacheMinReferencedLife so configurados com valores default durante a instalao do Windows. Quando ArpCacheLife no modificado, entradas da cache ARP so removidas sempre que passarem 2 minutos sem serem utilizadas. O ArpCacheMinReferencedLife informa o tempo mnimo que uma entrada da cache ARP utilizada deve permanecer vlida na cache, sendo 600 segundos (10 minutos) o valor default. Se estes parmetros no forem encontrados do registro, significa que os valores default esto sendo utilizados. Para considerar novamente os valores default, exclua os parmetros de sistema mencionados acima e reinicialize o sistema.
99

ncleo,

modifica-se

tempo

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

Em comutadores Cisco srie 6000 use o comando abaixo para modificar o tempo de validade da cache ARP:

Console> (enable) set arp agingtime <agingtime_em_segs>

5.6 Referncias 5.6.1 Livros

[PERF&FAULT-CISCO] Maggiora, P. L. D., Elliot, C. E., Pavone Jr, R. L., Phelps, K. J., Thompson, J. M. Performance and Fault Management. Cisco Press. 2000.

5.6.2 Recursos online (Internet)

[CISCO-STP] Understanding Spanning-Tree Protocol. http://www.cisco.com/univercd/cc/td/doc/product/rtrmg mt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm Padro IEEE 802.1D. Part 3: Media Access Control (MAC) Bridges. http://standards.ieee.org/getieee802/download/802.1D1998.pdf

[IEEE802.1D]

5.6.3 RFCs
[RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K. Definitions of Managed Objects for Bridges. Julho, 1993

5.6.4 Livros base

Comer, D. Internetworking with TCP/IP: Principles, Protocols, and Architectures. Volume 1. Quarta edio. Prentice Hall, 2000. Cisco Systems (Editor). Internetworking Technologies Handbook. Cisco Press. Dezembro, 2000. Tanenbaum, A. Computer Networks. Tercecira edio. Prentice Hall, 1996.

100

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

E N L A C E

101

Captulo

6 Problemas de nvel de rede

Neste captulo encontram-se 14 problemas que podem ocorrer em uma rede relacionados camada de rede: Tabela de rotas de hospedeiros incorretas, Endereo IP de hospedeiro incorreto, Hospedeiro com mscara de rede incorreta, Cliente DNS mal configurado, Servidor DHCP mal configurado, Rotas estticas mal configuradas, Equipamento inserido em VLAN incorreta, VLANs no esto configuradas, Comutadores no conseguem trocar informaes sobre VLANs entre si, Ambiente RIP-1 com VLSM e/ou redes no contguas, Dimetro RIP com mais de 15 roteadores, Roteadores RIP-2 no enviam ou recebem pacotes RIP-1, Trfego RIP saturando largura de banda, Filtro IP no permite a passagem de trfego RIP (UDP 520).

6.1 Tabela de rotas de hospedeiros incorretas 6.1.1 Descrio

Seja esttica ou dinamicamente, um roteador default deve ser configurado em hospedeiros. Quando o hospedeiro deseja se comunicar com outra mquina que no faz parte de sua rede local (no tem mesmo prefixo e mscara de rede que ele), os dados desta comunicao devem ser entregues ao roteador default. Se o roteador default estiver sendo configurado manualmente, erros de digitao podem ocorrer e causar o problema. Pode-se ainda esquecer de configurar o roteador default de um hospedeiro, o que tambm bastante problemtico. Se o roteador default estiver sendo configurado dinamicamente, atravs de um servidor DHCP, a configurao do escopo no servidor pode estar incorreta, causando o problema. Se o hospedeiro puder se comunicar diretamente com mais de um roteador, a tabela de rotas do hospedeiro pode se tornar incompleta. Idealmente, deveramos configurar o hospedeiro para usar o roteador que oferea o melhor caminho para cada destino.

6.1.2 Sintomas
Quando a tabela de rotas de um hospedeiro estiver com rota default incorreta ou inexistente, a conseqncia para os usurios que s haver conectividade com mquinas da mesma sub-rede. Os usurios de mquinas com este
102

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

problema diro que a rede s funciona internamente, que eles no conseguem navegar em sites fora da organizao (ou do departamento). Um agravante pode ainda existir: se o servidor de nomes estiver em outra sub-rede, ele no ser alcanvel, e o usurio da mquina com erro no conseguir nem mesmo se comunicar com mquinas da mesma sub-rede atravs dos nomes das mquinas.

6.1.3 Sinais
Procedimento

11.8

Se um hospedeiro estiver com a tabela de rotas incompleta, ele receber do seu roteador default mensagens ICMP de redirecionamento. O roteador default envia essas mensagens para a mquina com tabela de rotas incompleta, para inform-la que existe um caminho melhor para certos destinos.

6.1.4 Testes confirmatrios

RESUMO DOS TES TES

Se a configurao for manual:

T
E S T E

Verifique o endereo IP do roteador default configurado; Se a configurao do roteador default for dinmica:

E S T E

Verifique a configurao do escopo em questo no servidor DHCP; Se o escopo estiver correto:

E S T E

Verifique a configurao de cliente DHCP no hospedeiro;

Teste confirmatrio 1

O cliente de um hospedeiro reclamou. Ele citou justamente os sintomas descritos anteriormente. Voc est desconfiado que o roteador default est incorreto ou no foi configurado nesta mquina cliente. Olhe na documentao da rede qual o endereo do roteador default para a mquina em questo. Na prpria mquina verifique qual o roteador default configurado. Dicas para realizar este teste podem ser encontradas no 11.13. Se voc observar que o endereo do roteador default est incorreto ou no existe ou ainda que a tabela de rotas do hospedeiro est incompleta, o problema foi confirmado.

103

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Teste confirmatrio 2

Este teste deve ser realizado se as mquinas com problema obtm as configuraes de rede atravs de um servidor DHCP. Se o escopo do servidor DHCP estiver incorreto, todas as mquinas clientes apresentaro o mesmo erro seja o endereo do roteador default incorreto, seja qualquer outro erro. Verifique a configurao do escopo no servidor DHCP. Comumente, so definidos em um escopo: a faixa de endereos IPs a serem alocados aos clientes, o endereo IP do roteador default, a mscara de sub-rede e o endereo IP do servidor de nomes do domnio. Para acessar o gerenciador do servidor DHCP em servidores Windows NT clique em: Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. No Windows 2000, no menu Iniciar escolha Programas > Ferramentas Administrativas > DHCP. Em ambos os sistemas operacionais surgir um programa que serve de interface para a gerncia do servidor DHCP. A interface destes programas bem semelhante interface do Windows Explorer. Navegue no painel esquerdo e no painel direito sero apresentadas as configuraes do escopo DHCP correspondente. No Linux Slackware verifique as configuraes do servidor DHCP no arquivo /etc/dhcpd.conf. A opo routers define o endereo do roteador default.

Teste confirmatrio 3

Veja nas mquinas clientes envolvidas se as configuraes do protocolo TCP/IP foram obtidas dinamicamente ou no. No Windows NT, clique com o boto direito do mouse sobre o cone Ambiente de Rede e escolha o item Propriedades. Escolha a tabela Protocolos, selecione o protocolo TCP/IP e pressione o boto Propriedades. Verifique se a mquina est configurada para obter um endereo IP automaticamente, ou se as configuraes de rede so estticas. Verifique tambm as configuraes avanadas. Se um servidor DHCP que vai oferecer todas as configuraes de rede (incluindo roteador default, IP do servidor de nomes e mscara de rede) nenhuma configurao manual precisa ser feita. No Linux Slackware as configuraes das interfaces de rede localizam-se no arquivo /etc/rc.d/rc.intet1. Caso a mquina seja
104

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

cliente DHCP, neste arquivo no sero encontradas as configuraes TCP/IP, mas sim a ativao do cliente DHCP. Com este teste voc pode descobrir mquinas que deveriam ser clientes DHCP, mas esto com configuraes estticas incorretas.

6.1.5 Sugestes de tratamento

Para solucionar o problema configure o roteador default corretamente. Se a configurao de rede do hospedeiro for manual, modifique a configurao do roteador manualmente. No Windows isto feito a partir do Painel de Controle de Rede. Este painel obtido como descrito no teste confirmatrio 3. Selecione o protocolo TCP/IP e clique no boto Propriedades. Uma janela, que permite configurar a rede TCP/IP aparecer. Selecione a orelha Gateway e configure o endereo correto do roteador default. Caso voc tenha descoberto que o escopo DHCP est incorreto, ser necessrio corrigi-lo. Em servidores Windows NT clique em: Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. Clique com o mouse sobre o escopo desejado e no menu Escopo, selecione o item Propriedades. Para visualizar e modificar o endereo do roteador default escolha no menu Opes DHCP o item Escopo e verifique as configurao do roteador default (opo 003 router). Modifique o endereo do roteador default apropriadamente. Em seguida reinicie o servidor DHCP para que a nova configurao seja levada vista. Em servidores Windows 2000, no menu Iniciar escolha Programas > Ferramentas Administrativas > DHCP. Abra a rvore correspondente ao escopo em questo (no painel esquerdo). Sobre o item Opes do Escopo clique com o boto direito do mouse. Surgir um menu. Escolha o item Propriedades. Modifique a opo 003 Router para corrigir o problema. Por fim, reinicialize o servidor DHCP. Em servidores DHCP Linux modifique o arquivo /etc/dhcpd.conf. Na linha que inicia com option routers corrija o endereo do roteador default. Em seguida tambm ser necessrio reiniciar o servidor DHCP:
# /etc/rc.d/init.d/dhcpd restart

Ou:
# kill TERM <no. do processo dhcpd>19 # dhcpd

19

Este nmero pode ser obtido com o comando # ps ae | grep dhcpd.

105

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.2 Endereo IP de hospedeiro incorreto 6.2.1 Descrio

Primeira mente, vamos definir o que consideramos um endereo IP incorreto. Existem trs situaes: o prefixo de rede do endereo est incorreto. O endereo deveria ser 192.168.1.2 e na realidade foi configurado como 193.168.1.2; o endereo de rede de dois hospedeiros igual, causando IPs duplicados na rede; esqueceram de configurar o endereo IP do hospedeiro bastante incomum, mas possvel. As mquinas clientes que tiverem com endereo IP incorreto no conseguiro se comunicar corretamente na rede.

6.2.2 Sintomas
Se o endereo IP da mquina est incorreto o usurio da mquina reclamar de falta de conectividade. Veja um exemplo: a mquina pc-2, que deveria ter o endereo 192.168.1.2, foi configurado com o endereo 193.168.1.2. O endereo do roteador default 192.168.1.254. Com estas informaes, a tabela de rotas do hospedeiro mais ou menos assim:
Rede destino 193.168.1.0 0.0.0.0 Mscara 255.255.255.0 0.0.0.0 Interface Eth0 Eth0 Custo 1 1 End. do roteador 193.168.1.2 192.168.1.254

O que ocorrer quando o usurio de pc-2 tentar usar o servio que est na mquina 192.168.1.10? pc-2 pensa que esta ser uma entrega indireta e que deve enviar os dados desta comunicao para o roteador default. No entanto, pc-2 fica isolado ao perceber que o roteador default tambm no faz parte da mesma rede local que ele. pc-2 simplesmente no saber para quem enviar os dados. A comunicao entre pc-2 e 192.168.1.3 tambm no ser possvel. pc-2 acha que ser uma entrega indireta. Enfim, nada funcionar. Se o endereo IP da mquina estiver duplicado os usurios das mquinas com IP duplicado sentiro conectividade intermitente. Em sistemas operacionais mais novos (Windows ME e 2000, por exemplo) endereos IP duplicados so rapidamente detectados e as interfaces de redes envolvidas desativadas. Uma mensagem de erro apresentada ao usurio informando que a interface foi desativada por ter detectado IP duplicado. Clientes DHCP tambm detectam quando recebem do servidor um endereo IP duplicado e solicita-o outro endereo. Quando pelo menos duas mquinas so configuradas com o mesmo endereo IP, a seguinte situao ocorrer: nas caches ARP das outras mquinas que se
106

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

comunicam com a mquina em questo diretamente e dos roteadores, ora o endereo est apontando para o MAC de uma mquina, ora para o de outra. Suponha, por exemplo, que ambos os usurios das mquinas com IP duplicado resolveram visitar um determinado site fora da organizao. Ambas as mquinas usam o mesmo roteador default. Quando a primeira mquina falar com o roteador ficar registrado na cache ARP do roteador que determinado MAC corresponde ao IP duplicado. Imediatamente depois, quando a segunda mquina falar, a tabela ARP do roteador ser modificada. Em seguida, um datagrama chega no roteador destinado primeira mquina com IP duplicado que falou com o roteador, mas ele ser entregue segunda mquina, pois na cache ARP do roteador o MAC da segunda mquina que est registrado. Desta forma, os usurios das mquinas com IP duplicado ora conseguiro se comunicar atravs da rede, ora no.

6.2.3 Sinais
Procedimento

11.1
Procedimento

Quando existem mquinas com mesmo IP na rede, sero encontradas pelo menos duas respostas mesma requisio ARP. Isso ocorrer porque todas as mquinas que possuem o mesmo IP respondero ao quadro de difuso ARP que requisita o endereo fsico correspondente ao IP em questo. Quando mquinas forem configuradas com IP incorreto (erro de digitao, por exemplo) podero ser encontrados na rede quadros de difuso enviados por mquinas de outra sub-rede. No domnio de difuso de pc-2, onde todas as mquinas possuem prefixo de rede 192.168.1, sero encontrados quadros de difuso enviados pela mquina 193.168.1.2.

11.12

6.2.4 Testes confirmatrios

Se voc descobriu que existe mais de uma resposta mesma consulta ARP j est confirmado que existem IPs duplicados em sua rede. Mesmo tendo confirmado o problema, caso exista mais de 1 servidor DHCP em sua rede, o teste confirmatrio 2 pode ser aplicvel ao seu caso. Caso este sinal diferencial no tenha sido percebido, realize o teste confirmatrio 1.

RESUMO
T
E S T E

DOS

TES TES

Verifique o endereo IP configurado nas mquinas clientes; Se voc descobrir que existem IPs duplicados na rede:

E S T E

Se existir mais de um servidor DHCP na rede, certifique-se de que as faixas de endereos de cada um no se sobrepem;

107

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Teste confirmatrio 1

Em muitos casos, o prprio sistema operacional detectar a duplicidade de endereos, estando o problema de IPs duplicados confirmado. Se voc j verificou que existem duas respostas ARP mesma requisio, o problema de IPs duplicados tambm j foi confirmado. Se voc desconfia que houve erro de digitao ao configurar o endereo IP de uma mquina cliente ou ele no foi configurado, ser necessrio verificar a configurao de rede desta mquina. Se ela for cliente DHCP veja se no h erros de configurao no escopo DHCP. Em mquinas Windows use o programa ipconfig ou winipcfg. Eles lhe retornaro configuraes de rede das mquinas, incluindo o endereo IP configurado. Em mquinas Linux use o comando ifconfig a. Este comando apresenta informaes sobre todas as interfaces da mquina.

Teste confirmatrio 2

Se existir mais de um servidor DHCP20 na rede, assegure-se de que a faixa IP configurada em cada servidor diferente, para evitar IPs duplicados na rede. Este teste, dependente da implementao do servidor DHCP utilizada. Para acessar o gerenciador do servidor DHCP no Windows NT clique em Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. Clique com o mouse sobre o escopo desejado e no menu Escopo, selecione o item Propriedades. Surgir uma janela informando a faixa de endereos IPs configurada, a mscara de rede, os endereos reservados e o tempo de concesso escolhido. No Windows 2000 clique em Iniciar > Programas > Ferramentas Administrativas > DHCP. Navegue no escopo em questo no item Pool de Endereos e ver os valores de cada item no painel direita.

20 No Windows 2000 possvel criar um cluster de servidores DHCP. Neste caso, este teste no necessrio.

108

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

No Linux, a faixa de endereos definida no arquivo /etc/dhcpd.conf. Veja as linhas que comeam com a palavra range.

6.2.5 Sugestes de Tratamento

Se voc confirmou a existncia de endereos IP duplicados na rede, reconfigure os endereos IP das mquinas envolvidas para que no mais apresentem endereos iguais ou incorretos. Em mquinas Windows voc deve entrar no Painel de Controle de Rede, escolher o tipo de rede TCP/IP e clicar no boto Propriedades. Modifique o endereo IP da mquina. Em mquinas Linux Slackware voc dever modificar arquivo de inicializao rc. No Linux Slackware o arquivo /etc/rc.d/rc.inet1 contm as configuraes da rede. Modifique o endereo IP das mquinas envolvidas (ou de pelo menos uma delas) para corrigir o problema. No Red Hat e nos sistemas Linux baseados no sistema de inicializao System V modifique o arquivo de configurao da interface envolvida no problema (que est com IP duplicado). No diretrio /etc/sysconfig/network-scripts existe um arquivo de configurao para cada interface da mquina. Os nomes destes arquivos comeam sempre com ifcfg-, seguidos do nome do dispositivo. Se voc deseja modificar o endereo IP da interface eth0, ento edite o arquivo ifcfg-eth0 e modifique o endereo configurado na linha que se inicia com IPADDR. Aps modificar o endereo de rede de uma interface reinicialize21 a mquina para que a nova configurao seja carregada e tambm para certificar-se de que as modificaes corretas foram feitas e o problema foi resolvido. Se o problema era no escopo DHCP, certifique-se de que endereos de mquinas servidoras (geralmente endereos fixos e muitas vezes configurados manualmente) no esto sendo fornecidos a clientes DHCP. Em mquinas Windows NT, por exemplo, clique em Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. Em seguida clique com o mouse sobre o escopo desejado e no menu Escopo, selecione o item Propriedades. Surgir uma janela informando a faixa de endereos IPs configurada, a mscara de rede, os endereos reservados e o tempo de concesso escolhido. Veja se todos os endereos reservados esto corretamente configurados.

21 No Windows, ao tentar fechar o Painel de Controle de Rede voc ser4 automaticamente questionado se quer reiniciar a mquina.

109

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.3 Hospedeiro com mscara de rede incorreta 6.3.1 Descrio

Leia mais sobre mscaras de rede no apndice 7

Mscaras de rede IP so nmero formados por 32 bits. A mscara de rede de um hospedeiro est incorreta quando: ela maior do que deveria ser, ou menor do que a mscara correta. Costuma-se representar mscaras de rede por quatro nmeros decimais (entre 0 e 255) separados por um ponto (.). Suponha, por exemplo, que a mscara de rede de pc-2 (128.128.10.2) deveria ser 255.255.254.0. Em bits este nmero 11111111111111111111111000000000 (23 dgitos 1 seguidos de 9 dgitos 0). Suponha que por falta de ateno a mscara de pc-2 foi configurada para 255.255.255.0. Em bits esta mscara : 11111111111111111111111100000000. Este um nmero maior que a mscara correta apresentada anteriormente, no ? Pois bem, este um exemplo de que voc pode erroneamente configurar uma mscara de rede maior para seu hospedeiro. Devido a este erro, pc-2 acha que faz parte da rede local 129.128.10.0/255.255.255.0, quando na realidade pc-2 pode se comunicar diretamente com todas as mquinas da rede 128.128.10.0/255.255.255.0 (128.128.10-11.0). Quando pc-2 tentar falar com a mquina 128.128.11.2 vai tentar fazer uma entrega indireta, isto , vai entregar os dados para o roteador default, quando na realidade uma entrega direta poderia ser realizada. Mscaras de rede menores tambm podem ser configuradas por erro. Considere novamente pc-2, cuja mscara de rede correta 255.255.254.0. Ao configurar pc-2 voc, por descuido configurou a mscara de rede 255.255.0.0. Em bits, esta mscara 11111111111111110000000000000000. Um nmero bem menor que a mscara correta! Neste caso, pc-2 tenta fazer entregas diretas a mquinas que no fazem parte de sua rede local. Por exemplo, pc-2 tentar fazer uma entrega direta mquina 128.128.1.1.

6.3.2 Sintomas
Se a mscara de sub-rede de um hospedeiro est com o nmero de bits 1 menor que o correto, o usurio desta mquina sentir falta seletiva de conectividade, pois no haver conectividade para algumas redes. No exemplo acima, por exemplo, excetuando-se a rede 128.128.10.0/23 o usurio de pc-2 no conseguir se comunicar com outras mquinas pertencentes rede 128.128.0.0/16. A mquina com mscara incorreta tentar fazer uma entrega direta a estas mquinas e no conseguir. O usurio, em gera; dir que alguns servios no esto funcionando. Se a comunicao com o servidor de nomes for impossibilitada devido ao erro, de mscara o usurio reclamar que a rede no funciona, j que a maioria dos servios acessada atravs dos nomes dos servidores.
110

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Caso a mscara de rede esteja com um valor maior que o correto, tudo poder funcionar bem, depende de quem o roteador default. No exemplo de mscara com valor maior apresentado na seo anterior, pc-2 vai tentar fazer entregas indiretas a mquinas com prefixo de rede 128.128.11. Para tal, o roteador default ser utilizado. Neste exemplo, o roteador default alcanvel, pois tem prefixo 128.128.10. Assim, nenhum sintoma seria percebido pelos usurios, mas alguns sinais seriam ainda percebidos pelo gerente. Mas, se o roteador default tivesse prefixo 128.128.11? O usurio da mquina no conseguiria se comunicar com quaisquer mquinas, exceto com mquinas com prefixo de rede 128.128.10. Portanto, quando a mscara de rede est configurada com um valor maior que o correto, o usurio da mquina poder reclamar de falta de conectividade, ou
que s consegue se comunicar com algumas mquinas da rede local.

6.3.3 Sinais
Procedimento

11.8
Procedimento

Quando a mscara de sub-rede est configurada com um valor maior que o correto, vrias mensagens ICMP REDIRECT sero encontradas na rede. O roteador default envia essas mensagens para a mquina com problema, para inform-la que ela poderia ter feito uma entrega direta. Alm disso, podero ser encontradas nas tabelas de rotas de hospedeiros com mscara maior que a mscara correta, rotas especficas para outros hospedeiros, e no apenas rotas para redes, como se espera. Essas rotas so aprendidas pelo hospedeiro atravs das mensagens ICMP REDIRECT mencionadas no sinal anterior.
trafegaro na rede requisies ARP, sem a resposta correspondente.

11.13
Procedimento

11.2

Quando a mscara de rede est com um valor menor que o valor correto, A mquina com mscara de rede incorreta pensa que mquinas de outras redes fazem parte de sua rede local e tentar fazer uma entrega direta.

6.3.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Verifique a mscara do hospedeiro; Se a mscara obtida atravs de um servidor DHCP verifique a configurao do escopo no servidor DHCP;

E S T E

Teste confirmatrio 1

Em mquinas Windows use o programa ipconfig ou winipcfg. Eles lhe retornaro configuraes de rede das mquinas, incluindo a mscara de rede configurada.

111

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Em mquinas Linux use o comando ifconfig a. Este comando apresenta informaes sobre todas as interfaces da mquina. Se a mscara de rede configurada estiver incorreta o problema foi confirmado. Se esta mquina est obtendo suas configuraes de rede dinamicamente atravs de um servidor DHCP, realize o teste confirmatrio 2.

Teste confirmatrio 2

Voc descobriu que um ou mais clientes DHCP esto com mscara de rede incorreta. Verifique no servidor DHCP a configurao do escopo envolvido. Em servidores Windows NT clique em: Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. Selecione o escopo desejado e no menu Escopo, selecione o item Propriedades. A mscara de rede configurada est correta? Em servidores Windows 2000, no menu Iniciar escolha Programas > Ferramentas Administrativas > DHCP. Clique com o boto esquerdo do mouse sobre o escopo desejado e escolha o item Propriedades. A mscara de rede est correta? Em servidores Linux veja a configurao DHCP no arquivo /etc/dhcpd.conf. A linha que inicia com option subnet-mask define a mscara de rede. Ela est correta?

6.3.5 Sugestes de tratamento

Se as configuraes de rede do hospedeiro com mscara incorreta foram definidas manualmente, simplesmente corrija. Em mquinas Windows entre no Painel de Controle de Rede, escolha redes TCP/IP e pressione o boto Propriedades. Modifique a mscara de rede para o valor correto. Em clientes Linux Slackware modifique o arquivo /etc/rc.d/rc.inet1. Ele contm as configuraes da rede. Modifique a mscara de sub-rede para o valor correto. No Red Hat e nos sistemas Linux baseados no sistema de inicializao System V modifique o arquivo de configurao da interface envolvida no problema (que est com mscara de rede incorreta). No diretrio /etc/sysconfig/networkscripts existe um arquivo de configurao para cada interface da mquina. Estes arquivos comeam sempre com ifcfg-, seguidos do nome do dispositivo. Se voc deseja modificar a mscara de rede da interface eth0, ento edite o arquivo
112

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

ifcfg-eth0 e modifique o endereo configurado na linha que se inicia com NETMASK. Aps modificar a mscara para o valor correto reinicie o sistema operacional, seja ele qual for. Se o escopo DHCP estava erroneamente configurado, ser necessrio modificlo e em seguida reiniciar o servidor DHCP. Em servidores Windows entre no Gerenciador DHCP como mostrado no teste confirmatrio 2 e modifique a mscara de rede para o valor correto. Em seguida reinicie o servidor DHCP. Em servidores DHCP Linux corrija a mscara de rede no arquivo /etc/dhcpd.conf (linha iniciada por option subnet-mask). Em seguida reinicie o servidor DHCP:
# /etc/rc.d/init.d/dhcp restart

Ou:
# kill TERM <no. do processo dhcpd>22 # dhcpd

6.4 Cliente DNS mal configurado 6.4.1 Descrio

Para que a rede de uma mquina cliente funcione apropriadamente necessrio que seja configurado nela o endereo do servidor de nomes a ser utilizado quando necessrio. Quando o endereo do servidor de nomes no especificado ou est incorreto, o servio de nomes no funcionar para a mquina em questo. Como grande parte dos servios de rede so acessados atravs de nomes de mquinas, o usurio da mquina com configurao de cliente DNS incorreta no conseguir acessar vrios servios de rede.

6.4.2 Sintomas
Grande parte dos servios de rede utilizados por usurios so acessados atravs dos nomes servidores. Quando o cliente DNS est apontando para um servidor de nomes errado ou no referencia servidor de nomes algum, a resoluo de nomes no funcionar para a mquina em questo. Portanto, a partir desta mquina no ser possvel acessar servios atravs dos nomes dos servidores, apenas de seus endereos IP.

22

Este nmero pode ser obtido com o comando # ps ae | grep dhcpd.

113

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Nestes casos, a reclamao tpica do usurio da mquina com cliente DNS mal configurado ser de que a rede no est funcionando. Um usurio mais avanado pode utilizar endereos IP em vez de nomes e descobrir que o
servidor responde quando se utiliza o seu IP, mas no responde quando o nome utilizado.

6.4.3 Sinais
Procedimento

11.14

Servios so acessados via endereo IP e no so acessados atravs do nome do servidor. A partir da mquina cliente com erro de configurao no

possvel acessar certos servios atravs do nome do servidor, mas o mesmo servidor acessado atravs de seu endereo IP. Um cliente mais avanado, como citado na Seo SINTOMAS, pode observar este sinal.

6.4.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Verifique o endereo IP do servidor de nomes configurado na mquina cliente; Se a mquina cliente for cliente DHCP verifique se o servidor DHCP est com escopo incorreto.

E S T E

Teste confirmatrio 1

O usurio da mquina certamente lhe informar o problema. Este teste bastante simples: consiste apenas em verificar a configurao do cliente DNS na mquina do usurio reclamante. No procedimento ANALISANDO A CONFIGURAO DE REDE EM UM HOSPEDEIRO voc encontrar dicas de como realizar este teste.

Teste confirmatrio 2

Se a mquina com erro de configurao for cliente DHCP, quase certo o erro de configurao do escopo DHCP. Este teste pode ser realizado conforme descrito no teste confirmatrio 2 do problema TABELA DE ROTAS DE HOSPEDEIROS INCORRETAS No entanto, voc estar procurando aqui no o endereo do roteador default, mas o endereo IP do servidor DNS.

114

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.4.5 Sugestes de tratamento

Corrija o erro de configurao do cliente DNS apropriadamente. No Windows veja as propriedades de configurao do protocolo TCP/IP e corrija o endereo IP do servidor DNS. No Linux corrija o erro reeditando o endereo IP do servidor DNS no arquivo /etc/resolv.conf. Se o erro era no escopo do servidor DHCP, corrija-o e reinicie o servidor. Veja dicas de como corrigir o escopo do seu servidor DHCP nas sugestes de tratamento do problema TABELA DE ROTAS DE HOSPEDEIROS INCORRETAS. Mas lembre-se que neste momento voc no procurar nem modificar o endereo do roteador default, mas do servidor de nomes.

6.5 Servidor DHCP mal configurado 6.5.1 Descrio

Leia mais sobre DHCP no apndice 9

Um ou mais servidores DHCP mal configurados podem causar erros de configurao de endereamento em hospedeiros em uma rede TCP/IP. Abaixo so listados alguns problemas que podem surgir quando se utiliza o servio DHCP: O escopo est mal definido, podendo oferecer configuraes erradas ou incompletas aos clientes DHCP; o Em um escopo DHCP so definidos parmetros de configurao de rede que sero passados para os clientes DHCP. Configuraes obrigatrias so: a faixa de endereos IPs que sero concedidos aos clientes, a mscara de sub-rede e o tempo de concesso. Outras opes comumente configuradas so os endereos IPs do roteador default e do(s) servidor(es) DNS. Este problema j foi indiretamente citado nos problemas de configurao de rede em hospedeiros apresentados anteriormente; Existe mais de um servidor DHCP na rede onde esto definidos escopos com faixas de endereos IPs sobrepostos, causando IPs duplicados na rede; o comum que uma organizao opte por possuir mais de um servidor DHCP. Assim, se um falhar, outro pode ainda estar funcionando. Infelizmente, no existe um protocolo padronizado que permita o espelhamento de um servidor DHCP. Cada servidor dever ter sua prpria configurao. Muito cuidado deve ser tomado para no configurar escopos sobrepostos em servidores diferentes; o O Windows 2000 oferece o servio de cluster para alguns servios, dentre eles, DHCP. Neste caso, muitos servidores DHCP coexistem em uma rede e se apresentam como se
115

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

fossem apenas um, oferecendo um servio de mais alta disponibilidade; o Alguns servidores e clientes DHCP mais novos (os do Windows ME e 2000, por exemplo) se protegem contra endereo IP duplicado, no permitindo que isto ocorra. Desta forma, mesmo que os servidores DHCP estejam com escopos sobrepostos, no sero observados IPs duplicados na rede. Isto torna a deteco e localizao dos escopos sobrepostos mais difcil. Por outro lado, as verses mais antigas do DHCP no tm esta proteo, possibilitando a ocorrncia deste problema mais facilmente devido a um descuido durante a configurao dos servidores DHCP. Portanto, um cuidado redobrado deve ser tomado quando mltiplos servidores DHCP coexistem em ambientes mais antigos; O valor do tempo de concesso de um endereo pode estar inadequado; o O tempo de concesso o tempo durante o qual o cliente DHCP pode utilizar o endereo que lhe foi fornecido pelo servidor. De tempos em tempos (sempre que se passa a metade do tempo de concesso), o cliente tenta renovar seu contrato, o que pode ou no ser aceito pelo servidor. No existe um tempo de concesso ideal, devendo este se adequar ao comportamento da rede. Mais detalhes em SUGESTES DE TRATAMENTO. O nmero de mquinas ativas na rede maior que o nmero de endereos IP disponveis no servidor DHCP; o A conseqncia deste fato que um hospedeiro ir solicitar suas configuraes de rede e elas no sero enviadas pelo servidor, uma vez que no existem mais endereos disponveis; o Um tempo de concesso pequeno reduz um pouco os efeitos deste problema, mas tem a desvantagem de diminuir o poder de rastreamento. Com um tempo de concesso de 1 hora, por exemplo, mais difcil e se o log do servidor DHCP no estiver habilitado praticamente impossvel descobrir com firmeza qual era a mquina que possua determinado IP h dois dias. O servio DHCP, por algum motivo, no foi inicializado, ou foi interrompido; o Os clientes no obtero resposta sua requisio DHCP e ficaro sem configurao de rede; Se um agente de repasse estiver em uso, certificar-se de que no existe filtro IP barrando a passagem do trfego DHCP;

116

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Os endereos IPs dos servidores DHCP esto incorretos no agente de repasse;

6.5.2 Sintomas
Quando o servidor DHCP est com o escopo mal configurado todos os hospedeiros configurados atravs do servidor sero afetados. Esse problema leva a configuraes de rede erradas ou incompletas em hospedeiros. Por exemplo, quando o escopo DHCP do servidor est configurado com o roteador default incorreto, os clientes DHCP sero configurados com um endereo de roteador default errado, e apresentaro determinados sintomas. Na Seo SINTOMAS dos problemas TABELA DE ROTAS DE HOSPEDEIROS INCORRETAS, ENDEREO IP DE HOSPEDEIRO INCORRETO, HOSPEDEIRO COM MSCARA DE REDE INCORRETA e CLIENTE DNS MAL CONFIGURADO so apresentados os sintomas para cada um dos erros de configurao possveis de ocorrer. Se o tempo de concesso estiver muito pequeno, no existiro sintomas, apenas alguns sinais. Por outro lado, em uma rede muito dinmica, onde mquinas entram e saem da rede em pequenos intervalos de tempo, um tempo de concesso muito grande pode levar falta de endereos IP. A conseqncia percebida pelos usurios ser falta de conectividade durante um certo tempo para as mquinas que no conseguirem obter suas configuraes de rede de imediato. Suponha um tempo de concesso de 20 horas e um escopo contendo 32 IPs. Nas primeiras 5 horas de funcionamento do servidor DHCP 20 mquinas so ligadas e 20 IPs concedidos a elas pelo servidor. Duas destas vinte mquinas foram logo desligadas. Passadas as primeiras 5 horas, 14 novas mquinas foram inseridas na rede. O servidor, no entanto, pensa que apenas 12 IPs esto disponveis. Durante as prximas 15 horas 2 mquinas ficaro sem conectividade. Passadas as 15 horas, o tempo de concesso dos primeiros IPs concedidos (para as mquinas que foram desligadas) expirar. S ento as 2 mquinas obtero suas configuraes de rede. Este exemplo ilustrado na Figura 6-1. Os demais problemas citados na seo anterior levam falta de conectividade, uma vez que os hospedeiros no obtero suas configuraes de rede.

117

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Figura 6-1: Exemplo do funcionamento do servidor DHCP

6.5.3 Sinais
Quando o escopo est incorretamente configurado, os sinais dependem do tipo de erro existente. Os sinais percebidos so os mesmos apresentados na Seo S I N A I S dos problemas TABELA DE ROTAS DE HOSPEDEIROS INCORRETAS, ENDEREO IP DE HOSPEDEIRO INCORRETO, HOSPEDEIRO COM MSCARA DE REDE INCORRETA e CLIENTE DNS MAL CONFIGURADO. Em resumo, os sinais apresentados sero:
Procedimento

11.2
Procedimento

Quando a mscara de rede estiver configurada com um valor menor que o valor real trafegaro na rede requisies ARP, sem a resposta correspondente. Alm disso, podero ser encontradas nas tabelas de rotas de hospedeiros, rotas especficas para outros hospedeiros. Isto tambm ocorrer quando a tabela de rotas do hospedeiro estiver incompleta. Quando a mscara de rede estiver configurada com um valor maior que o valor correto ou a tabela de rotas estiver incompleta, vrias mensagens ICMP REDIRECT sero encontradas na rede; Quando existirem IPs duplicados na rede sero encontradas pelo menos duas respostas mesma requisio ARP; Quando o endereo do servidor de nomes de domnio estiver incorreto ou no estiver configurado servios sero acessados via endereo IP e no sero acessados atravs do nome do servidor. Comumente, o cliente DHCP renova o aluguel de seu IP mantendo o mesmo endereo IP. Mesmo que o tempo de concesso de um endereo IP j tiver expirado, o servidor DHCP, em princpio no oferecer este IP a um outro cliente. Mas, quando a quantidade de endereos IP pequena em relao
118

11.13
Procedimento

11.8
Procedimento

11.1
Procedimento

11.14
Procedimento

11.6

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

quantidade de mquinas na rede, o servidor DHCP pode ser obrigado a reutilizar um endereo IP cujo tempo de concesso expirou. Antes de oferecer este endereo o servidor certifica-se de que o cliente que o possui no o est mais utilizando. Quando o cliente DHCP que originalmente possua o endereo IP requisit-lo novamente, o servidor responder ao cliente com uma mensagem DHCPNAK, indicando que no pode mais oferecer este endereo ao cliente. Portanto, em redes onde o nmero de mquinas maior que o nmero de endereos IP a serem alocados, encontraremos constantemente mensagens DHCPNAK.
Procedimento

11.5

Quando todos os endereos IPs do servidor j tiverem sido distribudos entre os clientes e um novo cliente requisitar suas configuraes de rede, o servidor DHCP informar a falta de endereos IPs ao administrador da rede atravs de mensagens escritas nos logs do servidor DHCP. Este um sinal diferencial que confirma a falta de endereos IPs para serem distribudos pelo servidor DHCP aos seus clientes. Se existir um filtro IP barrando o trfego DHCP (UDP 67 para servidor e UDP 68 para clientes), nenhuma requisio externa de clientes DHCP ser encontrada na rede; Se o servidor DHCP no estiver ativado ou os endereos dos servidores DHCP estiverem incorretamente configurados em um agente de repasse DHCP,
trafegaro na rede mensagens DHCP REQUEST sem resposta de qualquer servidor DHCP. Aps requisies DHCP espera-se que o(s) servidor(es) DHCP

Procedimento

11.7
Procedimento

11.4

retorne(m) mensagens do tipo DHCPOFFER.

6.5.4 Testes confirmatrios

Como apresentado na Seo DESCRIO, so vrias as causas do mal funcionamento da alocao dinmica de IPs utilizando servidores DHCP. Muitas vezes, a causa do mau funcionamento pode ser descoberta atravs dos sintomas/sinais observados. Se voc, por exemplo, encontrou nos logs do servidor que no existem mais IPs disponveis, um problema j foi confirmado. Antes de cada teste descrito a seguir apresentado um breve resumo de como a rede se comporta se estiver com o problema que ser testado. Infelizmente no existe uma MIB DHCP (ainda!) e todos os testes so dependentes de um analisador de protocolos ou do tipo de servidor DHCP utilizado.

RESUMO
T T T
E S T E

DOS

TES TES

1 2 3

Verifique se o servidor DHCP est em execuo; Verifique a configurao do escopo definido no servidor DHCP; Verifique a configurao de rede enviada para os clientes pelo servidor DHCP (com um analisador de protocolos); Verifique as configuraes do agente de repasse DHCP;
119

E S T E

E S T E

E S T E

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

E S T E

Se existir um filtro IP, certifique-se de que ele permite a passagem do trfego DHCP; Se os clientes DHCP no estiverem conseguindo se comunicar com o servidor DHCP, todos eles ficaro sem configuraes de rede. Certifique-se, primeiramente, que o servidor DHCP est em execuo:

Teste confirmatrio 1

No Windows verifique se o servidor DHCP est em execuo e certifique-se de que ele est sendo iniciado sempre automaticamente. No Windows 2000 escolha Iniciar > Programas > Ferramentas Administrativas > Servios. Clique com o boto direito do mouse sobre o Servidor DHCP e escolha o item Propriedades. Verifique se o servio est habilitado e sendo automaticamente iniciado. No Windows NT o Gerenciados de Servios pode ser obtido atravs do Painel de Controle. No Linux, certifique-se de que o dhcpd est em execuo com o comando:
# ps.-ae | grep dhcpd

Certifique-se tambm de que ele est sendo iniciado automaticamente. Em um Linux Slackware os comandos a seguir lhe informaro se o servio DHCP est sendo iniciado automaticamente e em que script de inicializao.
# grep dhcp /etc/rc.d/rc*

Se nenhum script de inicializao est iniciando o servio DHCP voc confirmou o problema. Caso voc encontre um arquivo que inicie o servio DHCP certifique-se de que este arquivo est realmente sendo executado durante a inicializao da mquina. Em mquinas Linux baseadas no System V como Red Hat, por exemplo a verificao um pouco diferente. Verifique se em algum diretrio rc existe um link iniciado com a letra S que aponta para o arquivo /etc/rc.d/init.d/dhcpd.
# grep dhcp /etc/rc.d/*/S*

Se as configuraes de rede de todos os clientes DHCP esto apresentando problemas, provvel que o escopo configurado no servidor DHCP esteja incorreto ou incompleto. Realize o teste confirmatrio a seguir.

120

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Teste confirmatrio 2

Verifique a configurao do escopo no servidor DHCP. Comumente, so definidos em um escopo os seguintes itens: a faixa de endereos IPs a serem alocados aos clientes, o endereo IP do roteador default, a mscara de sub-rede e o endereo IP do servidor de nomes do domnio23. Eventualmente, podem ser destacados endereos IPs dentro da faixa configurada que no podem ser alocados a clientes, isto , esto reservados para mquinas com IP fixo. Analise as configuraes do servidor DHCP e certifique-se de que ela est correta. Para acessar o gerenciador do servidor DHCP no Windows NT clique em Iniciar > Programas > Ferramentas Administrativas > Gerenciador DHCP. Clique com o mouse sobre o escopo desejado e no menu Escopo, selecione o item Propriedades. Surgir uma janela informando a faixa de endereos IPs configurada, a mscara de rede, os endereos reservados e o tempo de concesso escolhido. Para visualizar outras opes escolha no menu Opes DHCP o item Escopo e verifique as configuraes das opes escolhidas. Para visualizar as configuraes necessrio que o servidor esteja em execuo. No Windows 2000 clique em Iniciar > Programas > Ferramentas Administrativas > DHCP. Navegue no escopo em questo (interface semelhante ao Windows Explorer) e ver os valores de cada item no painel direita. No Linux verifique as configuraes do servidor DHCP no arquivo /etc/dhcpd.conf. Se existir a suspeita de IPs duplicados na rede realize os testes confirmatrios problema ENDEREO IP DE HOSPEDEIRO INCORRETO. Um teste interessante tambm verificar que valores de configurao de rede os clientes DHCP esto recebendo do servidor. Este teste apresentado no teste confirmatrio 3 abaixo.

Teste confirmatrio 3

Com um analisador de protocolos capture os pacotes DHCP trocados entre servidor e os clientes. Obtenha dicas de como

23 Outras configuraes mais especficas de ambientes Windows podem tambm ser repassadas. Por exemplo, endereo IP do servidor WINS.

121

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

conectar o analisador de protocolos e criar o filtro DHCP no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Quando um cliente solicita seus parmetros de rede ao servidor, ele enviar um quadro de difuso do tipo DHCPDISCOVER com endereo fonte igual a 0.0.0.0. O servidor DHCP responder com um pacote DHCPOFFER, que j informa um possvel IP para o cliente. O cliente responde com um DHCPREQUEST, e o servidor ento lhe envia um DHCPREPLY, que informa o valor de todas as opes configuradas no escopo em uso (IP do roteador default, do servidor de nomes, por exemplo). Analise os pacotes DHCPREPLY enviados pelo servidor, pois neles esto contidas todas as configuraes de rede passadas para o cliente DHCP. Voc pode encontrar com este teste configuraes que passaram despercebidas no teste confirmatrio 1.

Teste confirmatrio 4

Se um agente de repasse DHCP estiver em uso, certifique-se de que ele est corretamente configurado. Isto , se o IP do servidor DHCP est correto. Em um roteador Cisco srie 7500, por exemplo, use o comando a seguir para ver quais os servidores DHCP conhecidos pelo roteador:
roteador# show dhcp server

Teste confirmatrio 5

Se existir um filtro IP entre os clientes e o servidor DHCP, tenha certeza de que permitida a entrada e sada de trfego UDP nas portas 67 e 68.

6.5.5 Sugestes de tratamento

Uma vez encontrado o problema de configurao do servidor DHCP ou do agente de repasse, refaa a configurao solucionando o problema. Em geral, a soluo ser mais simples que a localizao exata do problema com o servio DHCP. Se voc descobriu que o servio DHCP no est sendo iniciado automaticamente a correo tambm clara: configure o servio para que ele seja iniciado automaticamente. No Windows isto pode ser feito com o auxlio
122

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

do Gerenciador de Servios do Windows (Iniciar > Programas > Ferramentas Administrativas > Servios no Windows 2000 ou cone Servios no Painel de Controle do Windows NT). Configure o servio corretamente, de forma que ele fique em execuo e seja iniciado automaticamente. Para certificar-se de que suas correes esto corretas, reinicialize a mquina onde o servidor est instalado e em seguida veja se o servio DHCP est em execuo. No Linux Slackware o servio DHCP deve ser ativado no arquivo /etc/rc/rc.inet2. Se o servidor DHCP informou atravs de seus logs que no tinha mais IPs para oferecer aos clientes ou for observada a presena constante de mensagens DHCPNAK na rede, obtenha/configure mais endereos IP para seu escopo. Diminuir o tempo de concesso tambm pode ajudar. Talvez seja necessrio passar a utilizar endereos privativos. Desta forma, no ser necessrio solicitar a quem competir (seu provedor, por exemplo) uma nova faixa de endereos IP. Veja um exemplo: em curtos intervalos de tempo mquinas saem e entram em sua rede. O tempo de concesso est em 5 horas. Com este tempo de concesso, por algumas horas o servidor DHCP pode pensar que todos os endereos esto alocados, embora algumas mquinas nem participem mais da rede. Quando novas mquinas forem inseridas na rede, no haver mais (do ponto de vista do servidor) IPs para estas mquinas, e elas ficaro sem configurao de rede. Se o tempo de concesso for menor, o servidor DHCP perceber mais rapidamente que determinadas mquinas no esto mais na rede e a falta de endereos IPs ocorrer em menor nmero. Como exemplificado acima, o valor configurado para o tempo de concesso importante para o melhor funcionamento da alocao dinmica de IPs em uma rede. Infelizmente, no existe um nmero mgico que represente o melhor tempo de concesso. Cada rede possui suas caractersticas prprias, e o tempo de concesso deve ser configurado com base nessas caractersticas. Se o nmero de mquinas em uma rede maior que o nmero de IPs disponveis, um tempo de aluguel menor (1 hora, por exemplo) mais interessante. Nos casos em que o nmero de mquinas menor que o nmero de IPs disponvel, o tempo de aluguel pode ser maior, chegando at a meses. Faa uma anlise levando em considerao a quantidade de mquinas clientes em sua rede e a quantidade de endereos IPs disponveis. Veja outros exemplos e uma anlise mais detalhada sobre o tempo de concesso de um servidor DHCP em [DHCP_FAQ]. Uma outra questo que pode ser levada em considerao a facilidade de rastreamento diante de incidentes de segurana. Uma das mquinas da sua rede pode ter sido invadida. O invasor instalou nela um cdigo malicioso que executado para invadir servidores de outra organizao. O administrador da organizao que sofreu a tentativa de invaso informar o IP da mquina da qual partiu o ataque e a data e hora da tentativa. De posse destas informaes voc tentar descobrir que mquina est invadida. Quando o nmero de endereos IPs disponveis maior que o nmero de mquinas, comum que cada cliente DHCP continue alocando sempre o mesmo IP. No entanto, possvel que um outro IP seja alocado ao cliente. Se o tempo de concesso for maior um ms, por exemplo voc sabe que durante, pelo menos um ms
123

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

uma mquina est sempre com o mesmo IP. Se o tempo de concesso for menor uma hora, por exemplo ser mais difcil identificar que mquina estava com determinado IP em um certo dia.

6.6 Rotas estticas mal configuradas 6.6.1 Descrio

Leia mais sobre roteamento no apndice 8

Em algumas organizaes as tabelas de rotas ou parte delas so construdas manualmente, pelo gerente da rede. A construo esttica das tabelas de rotas dos roteadores tem suas vantagens e desvantagens. Nela, nenhuma largura de banda precisa ser consumida para a troca de informaes de roteamento entre roteadores. Alm disso, o processador dos roteadores no empregado para a construo das tabelas de rotas, ficando livre para outras atividades. Por outro lado, o gerente que configura as rotas estticas precisa conhecer bastante a topologia da rede e atualizar o roteamento sempre que uma nova rede for adicionada. Neste problema so apresentados erros que comumente ocorrem quando rotas esto sendo estaticamente configuradas nos roteadores da rede. Alguns problemas subseqentes analisaro alguns erros quando o protocolo RIP est sendo utilizado para a construo dinmica das tabelas de rotas dos roteadores. Rotas estticas mal configuradas levam a tabelas de rotas incorretas, que podem causar laos lgicos entre roteadores e falta de rotas. A Figura 6-2 mostra um exemplo de lao lgico entre roteadores. O pessoal do Departamento de Recursos Humanos no consegue comunicao com o Departamento de Finanas nem de Vendas. Os dados originados no Departamento de Finanas ou Vendas com destino ao Departamento de Marketing circularo entre roteador1 e roteador2 at que o TTL se esgote. Alm de laos entre roteadores, a m configurao das rotas pode levar a tabelas de rotas incompletas. Uma tabela de rotas est incompleta quando um roteador recebe um datagrama, mas no sabe para onde envi-lo por no existir em sua tabela de rotas uma entrada que o informe para onde enviar o datagrama. Considere, por exemplo, que o comando
# route add net 192.168.10.0 netmask 255.255.255.0 gw 192.168.13.1

devesse ser executado em um roteador para adicionar uma certa rota24. No entanto, por erro de digitao, o comando executado foi
# route add net 192.168.19.0 netmask 255.255.255.0 gw 192.168.13.1.

24 Este comando informa que datagramas com destino rede 192.168.10.0/255.255.255.0 devem ser entregues ao roteador 192.168.13.1.

124

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Alguns dos possveis efeitos colaterais deste descuido so: erroneamente, os datagramas com destino rede 192.168.19.0/24 sero enviados para o roteador 192.168.13.1. Eles deveriam, por exemplo, seguir a rota default; o roteador no saber para onde enviar os datagramas destinados a mquinas da rede 192.168.10.0/24 ou, se existir rota default, ela ser utilizada; este comando pode sobrescrever a rota correta para a rede 192.168.19.0/24.

Figura 6-2: exemplo de lao entre roteadores

Por fim, um cuidado especial deve ser tomado ao configurar buracos negros (black holes). Suponha que sua organizao possui uma classe B de endereos. Voc quebrou esta faixa em vrias sub-redes. No entanto, nem todas as subredes possveis esto sendo utilizadas. Ento voc configura o seu roteador para jogar fora os datagramas com destino a sub-redes que no esto em uso isto um buraco negro. Configuraes incompletas de buracos negros podem ser a causa de problemas. Ao configur-los em um ambiente esttico (que no utiliza protocolos de construo dinmica de tabela de rotas), obrigatria a insero das rotas para as sub-redes em uso. Caso contrrio os datagramas destinados a elas cairo erroneamente no buraco negro. Um exemplo de erro deste tipo apresentado no teste confirmatrio 3 da Seo TESTES CONFIRMATRIOS.
125

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.6.2 Sintomas
Em geral, todas as situaes de erro de configurao de rotas levam a destinos inalcanveis. Os usurios reclamaro de falta de conectividade para uma ou mais redes.

6.6.3 Sinais
Procedimento

11.9

Quando laos lgicos existirem, muitas mensagens ICMP Time Exceeded (ICMP tipo 11, cdigo 0) trafegaro na rede. Cada vez que um datagrama passa por um roteador, o valor do campo TTL decrementado de 1. Se um roteador est processando um datagrama e percebe que o TTL zero, ele deve descartar o datagrama. Aps o descarte, ele deve notificar a mquina que originou o datagrama com uma mensagem ICMP de tempo excedido. Portanto, quando existe um lao lgico entre roteadores, os datagramas circularo no lao at que o TTL chegue a zero, sendo descartados e mensagens ICMP Time Exceeded so enviadas s origens dos datagramas. Mensagens desse tipo idealmente no so encontradas na rede.
Quando faltam entradas na tabela de rotas de um roteador, Destination Unreachable Messages (ICMP tipo 3, cdigo 0) so encontradas na rede. Se um roteador receber um datagrama e no souber para onde envi-lo, ele

Procedimento

11.10

descartar o datagrama e transmitir uma mensagem ICMP Destination Unreachable para a mquina origem do datagrama. O ideal que mensagens deste tipo no existam na rede. Idealmente, a varivel ipOutNoRoutes (da MIB-2) no constantemente incrementada. Ela tem seu valor aumentado sempre que uma das seguintes situaes ocorre: quando datagramas so descartados porque no existem rotas que possam ser seguidas por ele; quando o roteador default para onde o datagrama deveria ser enviado no est operacional. Portanto, o crescimento rpido indicar erros na tabela de rotas.
do valor da varivel ipOutNoRoutes

Procedimento

11.11

pode

6.6.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Localize o erro. Quais os roteadores que provavelmente esto mal configurados? Analise as tabelas de rotas dos roteadores envolvidos; Verifique a configurao de buracos negros;
126

T T

E S T E

2 3

E S T E

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Teste confirmatrio 1

Para localizar o problema, a melhor ferramenta a ser utilizada o traceroute (tracert no Windows). Esta ferramenta mostra todo o percurso seguido por datagramas IP desde a origem at o destino. Com esta ferramenta pode-se detectar rapidamente laos e analisar o caminho seguido pelos datagramas IP. Quando o erro se trata de falta de rotas, o traceroute permite a identificao do roteador alm do qual a comunicao no mais existe. Ao suspeitar de erro de roteamento, conecte-se em uma mquina e execute o traceroute direcionado a outra mquina. Analise a sada. A rota seguida a esperada? Existem laos? O datagrama chega no destino? Os exemplos a seguir ilustram dois tipos comuns de erros: o primeiro mostra um lao entre roteadores e o segundo um destino inalcanvel. Considere novamente o exemplo da Figura 6-2. O gerente de vendas da empresa liga para o gerente da rede e reclama que no consegue usar a aplicao de cadastro de vendedores. Aps alguns segundos de conversa o gerente de vendas diz que a rede est funcionando normalmente, s no consegue usar esta aplicao. O gerente de rede deduz que no h comunicao entre o Departamento de Vendas e o Departamento de Recursos Humanos, onde est a aplicao de cadastro de vendedores. O gerente de redes ento se conecta em uma mquina do Departamento de Vendas e direciona um traceroute para o servidor da aplicao em questo, obtendo a seguinte sada:
# traceroute n 192.168.6.10 1 2 3 4 5 6 ... 0.132 ms 0.231 ms 0.214 ms 0.254 ms 0.235 ms 0.301 ms 0.211 ms 0.165 ms 0.189 ms 0.213 ms 0.198 ms 0.255 ms 0.217 ms 0.153 ms 0.344 ms 0.222 ms 0.210 ms 0.278 ms 192.168.1.254 192.168.2.254 192.168.1.254 192.168.2.254 192.168.1.254 192.168.2.254

Como se v acima, um lao entre os roteadores 192.168.1.254 e 192.168.2.254 foi identificado Em uma outra situao de erro (no mais considerando o exemplo da Figura 6-2), a sada poderia ser:
# traceroute n 192.168.6.10 127

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

1 2 3 4 5 ...

0.132 ms 0.231 ms 0.214 ms !H !H !H !H

0.211 ms 0.165 ms 0.189 ms !H !H

0.217 ms 0.153 ms 0.344 ms

192.168.13.1 192.168.15.3 192.168.17.3

Neste exemplo, o datagrama no vai alm do roteador 192.168.17.3, sendo possvel que uma ou mais rotas estejam faltando neste roteador, ou que rotas incorretas tenham sido configuradas nos roteadores anteriores. O caminho percorrido pelos datagramas o esperado? Se for, o problema na tabela de rotas dos roteadores envolvidos no lao, ou do roteador que no sabe para onde enviar o datagrama. Se o caminho seguido pelos datagramas no foi o esperado, a tabela de rotas do roteador a partir do qual o caminho desviado deve estar com problemas.

Teste confirmatrio 2

Uma vez localizado o erro de roteamento, a prxima atividade a ser realizada analisar as tabelas de rotas dos roteadores que ficaram sob suspeita. Este j na realidade o primeiro passo para a correo do problema. No exemplo apresentado anteriormente, seria interessante examinar as tabelas de rotas dos roteadores 192.168.2.254 e 192.168.2.253 no caso em que o lao foi detectado e do roteador 192.168.17.3 no outro caso. Esta anlise pode ser feita atravs de um terminal de gerncia ou com o auxlio de uma estao de gerncia SNMP. O PROCEDIMENTO 11.3 mostra como analisar a tabela de rotas de um roteador. Analise as tabelas de rotas dos roteadores sob suspeita para confirmar o erro de roteamento. Para realizar esta tarefa a equipe de gerncia deve saber qual seria a tabela de rotas correta. Em outras palavras, a equipe deve entender perfeitamente a topologia da rede e qual o roteamento desejado. Caso contrrio, novos erros podem ser introduzidos.

128

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Teste confirmatrio 3

Se buracos negros tiverem sido configurados, certifique-se de que todas as sub-redes em uso tm uma rota configurada. Se voc esquecer de inserir as rotas para as sub-redes que esto em uso, os datagramas enviados para elas sero perdidos no buraco negro. O exemplo a seguir ilustra a situao. Considere uma organizao que possui uma classe B de endereos IP. Internamente, esta classe foi dividida em diversas sub-redes classe C: a sub-rede do backbone e sub-redes dos diversos departamentos. No entanto, apenas os 10 primeiros endereos esto sendo utilizados. O gerente da rede cria ento, no roteador de entrada do backbone um buraco negro para evitar que datagramas com IP destino inexistente circulem na rede. A Figura 6-3 ilustra a rede mencionada neste exemplo. Em um roteador Cisco 7507, por exemplo, basta criar a interface lgica null0 e executar o comando
roteador# ip route 155.190.0.0 255.255.0.0 null0

A partir de ento, todos os datagramas destinados a uma sub-rede de 155.190.0.0/16 para a qual no exista uma rota especfica sero jogados no buraco negro. Portanto, antes de adicionar a rota para o buraco negro, rotas para sub-redes em uso devem ser adicionadas. Por descuido, o gerente da rede citada no exemplo da Figura 6-3 adicionou as rotas para 9 redes, mas esqueceu da rede 155.190.3.0/24. Resultado: a comunicao entre mquinas da rede 155.190.3.0/24 e outras mquinas no ser possvel sempre que roteador-ext for um n intermedirio.

Figura 6-3: mapa da rede mencionada no exemplo de buraco negro 129

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.6.5 Sugestes de tratamento

Aps a deteco e localizao do erro, corrija a tabela de rotas incorreta. Essa correo deve ser realizada com cuidado, e mudanas s devem ser realizadas quando a equipe de gerncia estiver certa de que a modificao correta. O ideal que esta correo seja feita por duas pessoas juntas, para que a possibilidade de introduo de novos erros seja a mnima possvel. Se voc tem que atualizar tabelas de rotas mais de uma vez por ms, ou se em sua rede existirem enlaces de redundncia, o ideal que voc comece a usar um protocolo de construo dinmica de tabela de rotas tal como RIP ou OSPF.

6.7 Equipamento inserido em VLAN incorreta 6.7.1 Descrio

Leia mais sobre VLANs no apndice 12

Em um ambiente de VLANs configuradas por portas, os seguintes cuidados devem ser tomados: ao transferir um membro da VLAN de uma porta para outra do comutador, certifique-se de que ele continuar pertencendo VLAN apropriada; quando for inserir um novo membro na VLAN, verifique se ele foi inserido na VLAN correta, isto , foi conectado em uma porta que participa da VLAN apropriada. Da mesma forma, quando as VLANs so configuradas por endereo MAC, os seguintes cuidados devem ser tomados: ao mudar o endereo MAC de um membro da VLAN, o novo endereo deve ser cadastrado na VLAN e o antigo desconsiderado; quando novas mquinas so inseridas na rede, o endereo MAC deve ser cadastrado na VLAN apropriada; Considere a configurao das VLANs da Figura 6-4. Nesta figura, duas VLANs so configuradas: as primeiras 4 portas de comutador1 (da esquerda para a direita) fazem parte da VLAN 1 e as demais portas da VLAN 2. Certo dia, os servios oferecidos por servidor1 no estavam disponveis. Maria, que era nova na equipe de gerncia, antes de tentar isolar o problema corretamente, resolveu simplesmente conectar o servidor a outra porta do comutador. Servidor1 foi, ento, conectado porta 4 do comutador, que pertence VLAN 1. A topologia da rede passou a ser a apresentada na Figura 6-5. Com esta mudana, servidor1 ficou incomunicvel, pois est conectado VLAN incorreta. O roteamento para a rede 192.168.2.0/24 e, conseqentemente, para servidor1, sempre levar VLAN 2, impossibilitando qualquer comunicao dos clientes com o servidor, que agora est participando fisicamente da VLAN 1.
130

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Figura 6-4: VLANs configuradas por porta

Figura 6-5: Nova disposio das mquinas.

Em um ambiente de VLANs configuradas por porta ou por endereo MAC, sempre que uma nova mquina for inserida na rede, o gerente deve certificar-se de que a mquina ser conectada na VLAN correta. Caso contrrio, a mquina ser inserida em uma VLAN default e no se comunicar com outras mquinas da rede apropriadamente. possvel tambm que este problema ocorra quando as VLANs por porta ou por MAC estiverem sendo configuradas erro de configurao. Existe ainda uma ltima possibilidade: um usurio mesmo troca, sem comunicar gerncia, a posio do cabo no comutador ou sua placa de rede. Este o pior caso, pois a modificao foge do controle do time de gerncia.
131

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.7.2 Sintomas
O sintoma deste problema sempre falta de conectividade ou indisponibilidade de alguns servios, mas as reclamaes vindas dos usurios podem ser diferentes, dependendo do tipo de equipamento transferido de uma VLAN para a outra e de como este equipamento est configurado: Sendo uma mquina cliente, o usurio desta mquina poder sentir: o falta de conectividade o a falta de conectividade ocorrer em duas situaes: 1) quando o endereo IP da mquina configurado estaticamente, e 2) quando o endereo IP da mquina dinmico, mas a partir da nova VLAN nenhum servidor DHCP alcanvel; o no conseguir mais utilizar alguns servios o o endereo IP da mquina configurado dinamicamente. Na nova VLAN um servidor DHCP concedeu mquina cliente novas configuraes de rede. A mquina continuar com conectividade, mas no poder utilizar os servios que s eram permitidos para a antiga configurao de rede. Por exemplo, a maioria dos servidores POP s aceitam clientes que possuem endereos dentro de uma certa faixa de endereos IP; Sendo um repetidor ou outro comutador onde esto ligadas mquinas clientes: o Idem anterior. No entanto a reclamao partir de vrios usurios e no apenas de um. Portanto, vrios usurios iro reclamar de falta de conectividade ou de no conseguirem mais utilizar alguns servios;. Sendo um servidor: o os usurios do servidor reclamaro que no conseguem mais utilizar os servios oferecidos por ele. Em geral, servidores possuem endereos configurados estaticamente, portanto, o servidor no ser mais alcanvel ao mudar de VLAN; Sendo um roteador: o se o roteador em questo o responsvel pelo roteamento entre as VLANs, a VLAN da qual o roteador no mais participa passa a ficar incomunicvel. Os membros desta VLAN s iro se comunicar entre si; o se o roteador em questo d acesso a outras redes, os usurios destas redes reclamaro de falta de conectividade com uma ou mais redes.

132

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.7.3 Sinais
Os sinais estaro espalhados em vrias VLANs e at nas mquinas afetadas pela modificao. Na VLAN original25, sero percebidos os seguintes sinais:
Procedimento Requisies ARP trafegam sem resposta. Com a mudana, a mquina passa a fazer parte fisicamente de outra VLAN, onde os quadros de difuso de sua VLAN original no chegam. Por isto, sempre que algum desejar falar com esta mquina, requisies ARP sero enviadas (seja pelo roteador ou por membros da VLAN original) e nenhuma resposta ser dada. Este sinal ser mais visvel quando a mquina em questo for um servidor e mquinas clientes tentarem utilizar seus servios.

11.2

Procedimento

11.10

O roteador conectado VLAN onde a mquina deveria estar inserida no mais conseguir falar com ela. Sero enviadas para todos os que desejam falar a mquina em questo mensagens ICMP Host Unreachable. Quando um roteador tenta fazer uma entrega direta de um datagrama ao destinatrio e percebe que este est inalcanvel, ele envia uma mensagem ICMP Destination Unreachable (tipo 3, cdigo 1) origem do datagrama informando o fato. Esta mensagem diz que o equipamento final ao qual o datagrama foi endereado no alcanvel no momento. Se a mquina envolvida na modificao tem suas configuraes de rede obtidas estaticamente, na VLAN onde a mquina foi inserida erroneamente o sinal ser o seguinte:

Procedimento

11.12

Trfego de difuso cujo endereo origem no faz parte do conjunto de endereos configurados nas mquinas da VLAN. Muitos servios de rede

dependem do envio de quadros de difuso. Quando uma mquina est inserida na VLAN incorreta, encontraremos nesta VLAN quadros de difuso enviados por uma mquina que no deveria fazer parte desta Esta mquina tem prefixo de rede diferente das demais mquinas da VLAN. Se a mquina que foi conectada em outra VLAN tiver suas configuraes rede obtidas atravs de um servidor DHCP, outros sinais podem ser observados na mquina em questo e na VLAN onde ela foi inserida:

Procedimento

11.13

Se existir um servidor DHCP ou um agente de repasse DHCP na VLAN onde a mquina foi erroneamente inserida, a mquina continuar obtendo dinamicamente suas configuraes de rede26. No entanto, as configuraes recebidas so de outra sub-rede, isto , um endereo IP de outra faixa de endereos, um outro roteador default, e possivelmente outro servidor de nomes e outra mscara de rede. A mquina, que deveria fazer parte de uma determinada rede, vai apresentar configuraes de outra rede.

25

Considere VLAN original a VLAN da qual a mquina deveria estar participando.

26 Para tornar o servio DHCP mais seguro, pode-se amarrar endereos lgicos a endereos fsicos. Neste caso, a configurao de rede tambm no ser obtida, pois o MAC da nova mquina inserida no est configurado no servidor DHCP.

133

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Procedimento

11.13

Se na VLAN onde a mquina foi erroneamente inserida no existir um servidor DHCP ou um agente de repasse DHCP, a mquina no obter qualquer configurao de rede, apresentar o endereo 0.0.0.0 como seu endereo de rede, endereo de servidor de nomes e mscara de rede.

6.7.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Voc tem um ambiente de VLANs configuradas por portas ou por endereo MAC? Caso a VLAN seja configurada por porta:

E S T E

Verifique a disposio das mquinas nas portas do comutador. Alguma modificao foi realizada? Se a VLAN for configurada por endereo MAC:

E S T E

Verifique se o endereo MAC de algum equipamento membro da VLAN foi modificado (uma mquina inteira ou uma placa de rede foi substituda);

Teste confirmatrio 1

Muito provavelmente, os usurios iro reclamar. Se voc observou os sinais e sintomas descritos nas sees anteriores, e se os usurios que se queixaram esto em um ambiente de VLANs configuradas por porta ou por endereo MAC, este problema pode estar ocorrendo. Voc ou a equipe de gerncia realizou alguma troca que pode ter causado o problema? Se alteraes foram feitas, realize o teste confirmatrio 2 (para VLANs definidas por porta) ou o teste confirmatrio 3 (para VLANs configuradas por endereo MAC). Se voc tem um ambiente de VLANs configuradas por MAC ou por porta, mas voc ou a equipe de gerncia no realizou modificaes que possam ter causado o problema, ainda assim, este problema pode estar ocorrendo. No raro que usurios mais audaciosos realizem trocas que causem este problema. Por algum motivo, o usurio no est conseguindo ler seus emails. Ele acha que a rede no est funcionando. O que ele faz? Levanta-se de sua cadeira, vai at o equipamento de interconexo onde sua mquina est ligada e v que existem algumas portas vazias. Ele simplesmente transfere o cabo de sua mquina para uma dessas portas vazias. Quando vai testar a modificao v que a rede continua sem funcionar e ento resolve ligar para o gerente da rede para fazer sua reclamao. Por esta razo, importante
134

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

conversar calmamente com os usurios e coletar deles o mximo de informaes. Se for possvel que usurios realizem esta troca, isto , se os usurios tm acesso aos comutadores, realize o teste confirmatrio 2. Se voc tem VLANs configuradas por endereo MAC e permitido aos usurios a substituio de suas placas de rede por outras, realize o teste confirmatrio 3.

Teste confirmatrio 2

Com o auxlio da documentao da rede, verifique se os cabos de rede esto conectados nas portas corretas do comutador. Em uma rede bem documentada, todos os cabos so identificados e no prprio comutador onde as VLANs estiverem configuradas existir alguma etiqueta informando quais portas pertencem a quais VLANs. Se sua rede no estiver bem documentada, verifique a configurao das VLANs no prprio comutador. Na maioria dos comutadores Cisco, por exemplo, voc pode verificar a configuraes das VLANs com o comando:
Console> show vlan

Se os cabos tambm no estiverem identificados voc vai ter que descobrir de onde vem cada cabo manualmente para se certificar de que esto conectados nas devidas portas. Anote quais os LEDs do comutador esto acesos. Desconecte o cabo de uma mquina que est conectada ao comutador e verifique qual o LED que apagou quando o cabo foi desconectado. Realize este teste para cada um dos equipamentos conectados ao comutador e aproveite para identific-los e atualizar sua documentao.

Teste confirmatrio 3

Considerando VLANs definidas por MAC, se voc ou sua equipe realizou alguma das seguintes alteraes, o problema foi confirmado. substituio de membro da VLAN por outro. Por exemplo, o usurio foi presenteado com uma mquina nova; substituio de placa de rede. A placa antiga apresentou defeito, por exemplo, e voc teve que substitu-la. Ao final da
135

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

substituio, a rede no funciona, e voc est pensando que a placa nova; Se voc desconhece a ocorrncia de alguma destas alteraes, certifique-se de que os usurios no as realizaram. menos comum que usurios troquem suas placas de rede, pois eles geralmente no tm conhecimento em redes suficiente para tal ato. Alm disso, uma boa prtica de gerncia que esta tarefa s seja permitida a membros da equipe de gerncia com a devida permisso. Mas, quando se trata de usurio, tudo possvel. mais comum que usurios adquiram novas mquinas e no consigam mais utilizar a rede. Enfim, converse com os usurios afetados em busca de mudanas que possam ter causado o problema. Se mquinas ou placas de rede foram substitudas o problema foi confirmado.

6.7.5 Sugestes de tratamento

Se o problema ocorreu devido a um descuido da prpria equipe de gerncia durante a configurao das VLANs, simplesmente corrija o erro. Se o problema foi causado pela equipe de gerncia provvel que a sua rede no esteja bem documentada. Por exemplo, no exemplo apresentado na Seo DESCRIO, se existisse uma etiqueta no comutador informando quais VLANs esto configuradas e que portas pertencem a cada uma delas, talvez a troca no tivesse sido realizada. Ou, se no comutador ou na mquina cliente fosse informado quais mquinas participam de cada VLAN por MAC, a substituio de uma mquina sem o recadastramento da mesma na VLAN apropriada ocorreria com menos freqncia. Para evitar inserir novos problemas ao tentar solucionar um problema, como ocorreu no exemplo apresentado, organize a documentao da sua rede. Mais informaes sobre documentao de rede podem ser encontradas no Apndice 5 e em [PERF&FAULT CISCO]. Se foi um usurio o causador do problema e se voc percebe que os usurios esto constantemente realizando modificaes sem o seu conhecimento, comece a pensar em uma forma de proibir o acesso de usurios a equipamentos de interconexo, lacre as mquinas, desabilite administrativamente as portas de comutadores vagas e proba que certas configuraes (como as configuraes de rede) possam ser realizadas por eles. Comece a pensar tambm em oferecer um servio de gerncia mais eficaz, pois essa pode ser uma dica de que os usurios no confiam no desempenho e agilidade de sua equipe de gerncia e acham que podem resolver o problema mais rapidamente que vocs.

136

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.8 VLANs no esto configuradas 6.8.1 Descrio

Ver mais sobre VLANs no apndice 12

Considere a seguinte situao: Maria, suporte tcnico de redes, chega na sala da gerncia e, imediatamente, o telefone toca: reclamaes Uma das sub-redes da empresa no est funcionando segundo um certo usurio. Ela observa atravs da ferramenta de gerncia que realmente a reclamao procede: roteadores, enlaces e comutadores esto todos com alarme crtico. Enquanto ela observava a ferramenta de gerncia outros 4 telefonemas de reclamaes so recebidos. Maria, ainda inexperiente, quer logo resolver o problema. Ela descobre que a causa do problema um determinado comutador, pois seus LEDs esto indicando a existncia de algo anormal, segundo a documentao do comutador. Maria, prontamente, reinicializa o comutador, com esperanas de que ele voltar ao normal. No entanto, os LEDs continuam indicando problemas. Enquanto isso, mais telefonemas Maria, j desesperada, resolve substituir o comutador defeituoso por outro que est funcionando corretamente. E assim o faz. Ela esqueceu, no entanto, de verificar na documentao da rede se no comutador substitudo existiam VLANs configuradas. E, para seu azar, existiam. Aps substituir o comutador Maria achou que tinha resolvido o problema, mas alguns usurios continuavam reclamando. Quando o chefe de Maria chegou, ele explicou o que havia acontecido: Maria no considerou a possibilidade de existncia de VLANs no comutador e o substituiu. No entanto, o comutador defeituoso possua trs VLANs configuradas por porta as primeiras 8 portas faziam parte da VLAN 1, as 8 portas seguintes da VLAN 2 e as demais da VLAN 3. Quando Maria substituiu o comutador por outro sem configurao apropriada de VLANs, ela trouxe vrias mquinas, de sub-redes diferentes, para uma mesma VLAN, isto , para um mesmo domnio de difuso. Com isso os quadros de difuso de uma subrede passam a ser recebidos tambm pelas mquinas da outra sub-rede. Servios que se utilizam de quadros de difuso, como DHCP, por exemplo, comearam a apresentar um comportamento estranho. No caso apresentado acima, cada uma das VLANs tem seu prprio servidor DHCP. Em todas as VLANs, algumas mquinas tm configurao de rede fixa e outras obtm suas configuraes atravs de DHCP. O problema pode ocorrer em mquinas que tm a rede configurada dinamicamente. Pode ocorrer de uma mquina de uma determinada sub-rede requisitar sua configurao de rede (via endereo de difuso) e receber primeiro a resposta de um servidor DHCP de outra sub-rede. Neste caso, a mquina at continuar se comunicando na rede, no entanto no conseguir acessar alguns servios que s so permitidos s mquinas que possuem certos endereos IP. Na realidade, a troca de um comutador por outro sem a preocupao em trazer toda a configurao do antigo comutador para o novo problemtica tambm em outros sentidos. Por exemplo, o novo comutador pode no estar com o
137

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Protocolo rvore de Cobertura habilitado o que pode causar problemas. O endereo IP do novo comutador pode no estar configurado, ou ser diferente (provavelmente ser) do endereo do antigo comutador. A aplicao de gerncia, por exemplo vai acusar que o comutador est no operacional. Em resumo, o nico equipamento que podermos substituir sem realizar qualquer verificao de configurao um repetidor no gerencivel. At nos repetidores gerenciveis precisamos configurar pelo menos o IP correto para que a estao de gerncia consiga falar com ele.

6.8.2 Sintomas
VLANs limitam domnios de difuso. Quando todas as mquinas de vrias VLANs diferentes so inseridas erroneamente numa nica VLAN, dependendo da quantidade de mquinas que passam a fazer parte do mesmo domnio de colises e dos servios oferecidos e utilizados por elas, a grande quantidade de trfego de difuso pode tornar a rede lenta. No entanto, o problema mais grave ocorre quando servios que dependem de difuso so utilizados. A seguir mostramos um exemplo do que pode ocorrer com o servio DHCP. possvel que dois ou mais servidores DHCP passem a coexistir no mesmo domnio de difuso. Se no existir a associao entre endereo MAC e endereo IP configurados em cada servidor DHCP, quando um cliente DHCP solicitar suas configuraes de rede duas situaes podem ocorrer: 1. Por coincidncia o servidor DHCP correto responde primeiro. A mquina cliente adquire as configuraes de rede corretas e tudo funciona bem. Neste caso, nenhuma reclamao ser feita; 2. Outro servidor DHCP responde requisio do cliente DHCP e oferece ao cliente certas configuraes de rede. Neste caso, possvel que haja: 2.1. muitos servios que o cliente requisitar s so permitidos a clientes que possuem endereo IP dentro de uma certa faixa. Ento, os usurios reclamaro que no conseguem acessar certos servios. Por exemplo, os usurios no conseguiro ler e receber mensagens, pois os servidores SMTP e POP geralmente no aceitam conexes de qualquer cliente, apenas de clientes que possuem certos endereos IP27;
no funcionamento de certos servios

2.2.

as configuraes oferecidas pelo servidor DHCP so incompletas. O cliente DHCP esperava receber, dentre outros parmetros o roteador default, mas o servidor
falta de conectividade

27 Se existe apenas um servidor de cada servio para toda a organizao, ou pelo menos para todos os usurios das VLANs que foram unidas, ento este sintoma no existir;

138

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

que respondeu no estava configurado para oferecer este parmetro; Estas so algumas situaes levantadas. Agora imagine a quantidade de servios que dependem de quadros de difuso. O logon Windows um outro servio que pode comear a apresentar problemas. Enfim, diversas reclamaes podem surgir, dependendo de quais servios so utilizados.

6.8.3 Sinais
Procedimento Quantidade excessiva trfego de quadros de difuso.

10.9

A quantidade de quadros de difuso que trafegam em um domnio de difuso depende da quantidade de mquinas no domnio de difuso e dos servios oferecidos. aceitvel que uma mquina envie aproximadamente 1 quadro de difuso a cada 10 segundos. Sendo assim, em um domnio de difuso com N mquinas, ser normal que trafeguem na rede, aproximadamente, N/10 quadros de difuso por segundo. Em um domnio com 1000 mquinas, por exemplo, o trfego mdio de difuso ser de aproximadamente 100 quadros de difuso por segundo. Os processadores de equipamentos mais modernos conseguem processar alguns milhares de quadros de difuso por segundo sem comprometer o desempenho da rede. Mas, em geral, estabelecemos limiares bem menores para a quantidade de quadros de difuso por segundo encontrados em uma rede. Alguns comutadores possuem a funcionalidade de suprimir o trfego de difuso. Eles podem ser configurados para aceitar at uma certa quantidade de quadros de difuso por segundo (limiar), e descartar os demais quadros, e neste caso, deve-se observar se o limiar estabelecido no est sendo constantemente alcanado.

Procedimento

Utilizao alta de CPU.

10.6

Uma quantidade excessiva de quadros de difuso trafegando na rede pode saturar os processadores de equipamentos de interconexo e hospedeiros. Com o aumento vertiginoso da quantidade de quadros de difuso, a taxa de utilizao da CPU dos equipamentos de interconexo e hospedeiros ir crescer bastante em relao ao normal, e poder chegar a alcanar 99/100%. Em geral, taxas mdias de utilizao de CPU superiores a 75% j devem ser investigadas.
Saturao da largura de banda.

Procedimento

10.10

A quantidade excessiva de quadros de difuso aumenta a utilizao dos enlaces que participam do domnio de difuso. Ser observado um aumento da utilizao dos enlaces em relao ao trfego normal da rede. Com um trfego de difuso de 1000 quadros por segundo, considerando quadros de difuso de 64 bytes, o trfego de difuso de 1000 x 64 x 8 = 512 Kbps.

Procedimento

11.12

Mquinas que fazem parte de uma determinada sub-rede passam a receber quadros de difuso de mquinas de outra sub-rede. Isto ocorrer quando

existirem mquinas que tm configuraes de rede estticas. Por exemplo, sem a configurao correta de VLANs, a mquina 128.128.10.1 da sub-rede 128.128.10.0/24, que pertencia a uma determinada VLAN, passa a receber quadros destinados ao endereo de difuso 128.128.11.255, que de outra subrede e originalmente pertencia a outra VLAN.
139

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Procedimento

11.13

Quando as configuraes de rede das mquinas so obtidas dinamicamente, possvel encontrar mquinas que deveriam fazer parte de uma sub-rede com configuraes de outra sub-rede. Isto ocorrer quando mais de um servidor DHCP passar a existir no mesmo domnio de colises e o servidor errado responder requisio do cliente.

6.8.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Houve a substituio de algum comutador? O novo comutador est com as VLANs corretamente configuradas?

E S T E

Teste confirmatrio 1

Este problema s28 ocorrer quando algum mais provavelmente um membro da equipe de gerncia substituir um comutador por outro sem considerar a possibilidade da existncia de VLANs. muito improvvel que um usurio faa isto, portanto, este um problema de rpida e fcil localizao. Os sintomas do problema sero percebidos pelos usurios afetados, que reclamaro. A equipe de gerncia deve, ento se perguntar, se alguma substituio de comutador foi feita que possa ter causado o problema. Caso a resposta a esta questo seja positiva, realize o teste confirmatrio 2.

Teste confirmatrio 2

Se no comutador antigo estavam configuradas VLANs e no novo no, ou outras VLANs estavam configuradas, o problema foi confirmado. Verifique no novo comutador se as VLANs esto adequadamente configuradas. Para visualizar as configuraes de VLAN em comutadores Cisco Catalyst srie 6000 use o comando:
console> (enable) show vlan

Comutadores mais antigos, Cisco Catalyst 1900, por exemplo, as VLANs configuradas podem ser vistas escolhendo-se, no menu

possvel tambm que o comutador apresente problemas e por isso as VLANs sejam desconfiguradas, mas este j um problema de nvel fsico (EQUIPAMENTO DE INTERCONEXO DEFEITUOSO) que acarretou a desconfigurao das VLANs.
28

140

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

principal, a opo Virtual Lan. Em comutadores IBM 8271712 escolha a opo Switch Management. No nvel de gerncia de VLANs selecione a opo Setup. Uma tabela informando de que VLAN cada porta participa apresentada. Analise as configuraes de VLAN do comutador. Elas esto corretas? Caso a resposta seja negativa o problema foi confirmado.

6.8.5 Sugestes de tratamento

A soluo para este problema configurar as VLANs. Esta seo nem deveria existir para este problema, no fossem as seguintes importantes dicas:
Documente sua rede.

Por exemplo, nos comutadores onde VLANs esto configuradas, anexe etiquetas que informem quais so as VLANs e suas configuraes. Assim, quando algum tiver que substituir um comutador por outro vai lembrar das VLANs e configur-las no novo comutador.

Uma excelente prtica de gerncia de configurao, j mencionada no problema EQUIPAMENTO DE INTERCONEXO DEFEITUOSO, organizar a linha base de configurao da rede (veja mais informaes na pgina 60). Se a linha base de configurao existisse, ao substituir um comutador por outro ela seria usada, e nenhum erro ocorreria.

6.9 Comutadores no conseguem trocar informaes sobre VLANs entre si 6.9.1 Descrio
Aprenda mais sobre VLANs no apndice 12

VLANs limitam domnios de difuso. Na teoria, uma VLAN pode atravessar vrios comutadores. Por exemplo, uma VLAN por porta pode envolver portas de vrios comutadores diferentes. Quando uma VLAN atravessa muitos comutadores, necessrio que eles saibam como trocar entre si informaes sobre as VLANs. Quando um comutador recebe um quadro de difuso, ele precisa saber a que VLAN o quadro pertence para ento enviar este quadro a todos os membros da VLAN. Alm disso, necessrio que o comutador saiba que existem membros da VLAN em outros comutadores, e envie para estes comutadores os quadros de difuso recebidos dos membros da VLAN. Quando a VLAN definida por endereo IP, a identificao da VLAN j carregada implicitamente no quadro, atravs do prprio endereo IP da estao que o enviou. No entanto, quando se trata de VLANs definidas por porta ou endereo MAC a identificao da VLAN deve ser realizada explicitamente [VLAN-REPORT]. Isto , de alguma forma um comutador precisa identificar a que VLAN um quadro pertence.
141

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Considere as VLANs 1 e 2 definidas na Figura 6-6.

Figura 6-6: VLANs que atravessam comutadores.

Comutador1 e comutador2 precisam se comunicar para trocar informaes sobre as VLANs definidas neles. Cada um precisa saber que parte dos membros de cada VLAN definida est conectada diretamente e parte est conectada no comutador vizinho. Alm disso, quando comutador1 vai enviar um quadro para comutador2, preciso que ele identifique a que VLAN o quadro pertence. Quando quadros de difuso so enviados em um ambiente de VLANs, apenas os membros da mesma VLAN de quem originou o quadro de difuso devem receb-lo. a que reside o problema: se comutador1 e comutador2 no estiverem conversando a mesma lngua, eles no entendero que parte da VLAN 1 est conectada em um comutador e parte em outro. O mesmo ocorre com a VLAN 2. Quando pc-1 enviar um quadro de difuso, apenas pc-3, que tambm est diretamente conectado a comutador1, receber o quadro. Comutadores podem trocar entre si informaes sobre VLANs de trs formas distintas: mantendo uma tabela via sinalizao, TDM e etiquetamento de quadros, sendo a ltima a tcnica mais utilizada [VLAN-REPORT]. Nesta abordagem, a identificao da VLAN adicionada nos quadros que iro atravessar enlaces entre comutadores. Estes enlaces que ligam comutadores (ou comutadores e roteadores) passam a se chamar troncos e carregam o trfego de vrias VLANs distintas entre comutadores e roteadores. No exemplo da Figura 6-6 o enlace que liga comutador1 e comutador2 um tronco pelo qual trafegam dados da VLAN 1 e da VLAN 2. A variedade de tipos de VLANs e de formas de comunicao entre comutadores para a troca de informaes sobre VLANs levaram cada fabricante de comutadores a desenvolver sua prpria soluo para VLANs. A conseqncia que a soluo de VLANs de um fabricante quase sempre no compatvel com a de outro fabricante. Isto obriga os consumidores que desejam configurar VLANs que atravessam mltiplos comutadores a comprar produtos de um nico fabricante.
142

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Para solucionar este problema de interoperabilidade a IEEE props o padro 802.1Q, que segue a abordagem do etiquetamento de quadros. A maioria dos novos comutadores j adota este padro. Este problema mais comum quando comutadores mais antigos so usados (ou se a configurao do tronco no estiver correta). Em comutadores Cisco mais novos, por exemplo, dois tipos de codificao esto disponveis: o ILS (Inter-Switch Link), que proprietrio da Cisco, e o 802.1Q, que o padro. Quando VLANs que atravessam vrios comutadores so definidas e os comutadores envolvidos no sabem trocar entre si informaes sobre as VLANs, todos os servios que dependem de difuso ficam comprometidos. Abaixo seguem exemplos do que ocorre com alguns servios que se utilizam do envio de quadros de difuso. O servio ARP, de mapeamento de endereos lgicos em endereos fsicos, depende do envio de quadros de difuso. Devido falta de comunicao entre os comutadores, a troca de informaes entre membros de uma mesma VLAN que esto conectados em comutadores diferentes no ser possvel exceto se o mapeamento endereo lgico endereo fsico for estaticamente configurado nos membros das VLANs. Mais adiante ser dado um exemplo deste caso. Um outro servio importante que pode ser prejudicado o DHCP. Considere que servidor2 o servidor DHCP dos membros da VLAN 2. Como conseqncia da falta de interoperabilidade entre comutador1 e comutador2 no que diz respeito a VLANs, pc-1, que um cliente DHCP no poder obter suas configuraes de rede.

6.9.2 Sintomas
O sintoma percebido pelos usurios depende de que servios baseados em quadros de difuso esto sendo utilizados pelos membros das VLANs. No exemplo da Figura 6-6, o usurio de pc-1 reclamaria de falta de conectividade ou, em linguagem de usurio, que a rede no est funcionando, j que ele no consegue obter suas configuraes de rede. Um outro sintoma pode ser o no funcionamento de alguns servios mesmo que eles no sejam baseados no envio de quadros de difuso. Este sintoma ocorrer na seguinte situao: 1) servidor e cliente pertencem mesma VLAN, mas esto conectados em comutadores distintos; 2) os comutadores no esto conseguindo trocar informaes sobre VLANs entre si; 3) baseado em suas configuraes de rede o cliente sabe que deve fazer uma entrega direta ao servidor e 4) o cliente sabe apenas o endereo lgico do servidor. O protocolo ARP dever ser utilizado pelo cliente, que deseja descobrir o endereo fsico do servidor. Veja o exemplo a seguir: Considere que servidor2 tambm servidor POP. Para se conectar a servidor2, pc-3 precisa, primeiro saber qual o endereo fsico do servidor. Para tal, o
143

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

protocolo ARP ser utilizado. No entanto, apenas pc-1 receber o quadro de difuso ARP. Sem resposta, a conexo entre pc-3 e servidor2 no ser possvel. Considere a mesma situao envolvendo, no entanto, duas mquinas clientes. Neste caso, o sintoma ser falta de conectividade entre mquinas clientes. Se voc tem uma rede Microsoft e no estiver utilizando servidor WINS29, alguns clientes reclamaro de no conseguir efetuar o logon na rede. Uma outra reclamao ser de no conseguir navegar em todas as mquinas da rede30. Isto se deve ao fato de que nas redes Microsoft, tanto o servio de logon quanto o de navegao em outras mquinas da rede so baseados no envio de quadros de difuso. Por exemplo, para encontrar o controlador de domnio primrio (servidor que autenticar os usurios na rede) os clientes enviam um quadro de difuso na rede. Se o controlador de domnio primrio estiver em outro comutador, o quadro de difuso enviado pelo cliente no chegar no controlador, e o cliente no poder ser autenticado. Provavelmente o cliente ser informado de que o controlador de domnio primrio no pde ser encontrado, ou no existe. Considerando, por exemplo, que servidor1 controlador de domnio primrio, o usurio de pc-5 no conseguir sequer efetuar logon na rede e o usurio de pc-2 e pc04 no enxergaro pc-5 como mquina de seu ambiente de rede. Os servios mais comuns foram escolhidos para serem dados como exemplo nesta seo. No entanto, outros sinais podem surgir, dependendo dos servios oferecidos em sua rede e de como ela est configurada.

6.9.3 Sinais
Assim como os sintomas, os sinais que podem ser identificados dependem de que servios dependentes do envio de quadros de difuso esto configurados nas VLANs. Os sinais abaixo consideram os servios ARP, DHCP.
Procedimento

11.2
Procedimento

Como mostrado em exemplo anterior, os quadros de difuso que carregam requisies ARP s sero enviados para os membros da VLAN que esto conectados no mesmo comutador. Desta forma, sero encontradas na rede
requisies ARP sem resposta. Requisies DHCP sem resposta do servidor DHCP.

11.4

Este caso tambm foi ilustrado com um exemplo anteriormente. Se o servidor e o cliente DHCP participam da mesma VLAN mas esto em comutadores distintos, se os comutadores no estiverem trocando informaes sobre VLANs adequadamente, o servidor no receber a requisio ARP do cliente, que ficar sem resposta.

29 Quando voc configura um servidor WINS em seu domnio e configura as estaes de trabalho para utiliz-lo (via DHCP ou manualmente), o logon e a navegao em outras mquinas da rede passam a ser um processo que no envolve envio de quadros de difuso.

30 Ao abrir uma janela do Windows Explorer e clicando no cone Toda a rede, um usurio pode navegar em outras mquinas da rede Microsoft.

144

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Procedimento

11.13

Clientes DHCP sem as configuraes de rede. Este sinal, na realidade uma conseqncia do sinal anterior. Como o cliente DHCP no conseguiu falar com o servidor DHCP, o cliente DHCP ficar sem suas configuraes de rede e apresentar o endereo 0.0.0.0 seu como endereo IP e mscara de rede.

6.9.4 Testes confirmatrios

RESUMO
T T T
E S T E

DOS

TES TES

1 2 3

Voc configurou VLANs que atravessam mais de um comutador? Os comutadores envolvidos pertencem a fabricantes distintos? Qual o protocolo utilizado para troca de informaes sobre VLANs entre os comutadores?

E S T E

E S T E

Teste confirmatrio 1

Este problema s ocorrer quando VLANs so estendidas por mais de um comutador. Os comutadores mais antigos no suportam ainda os novos padres propostos e ainda trocam informaes sobre VLANs utilizando solues proprietrias. Se voc acabou de configurar VLANs que abrangem mais de um comutador e est observando os sintomas e sinais descritos anteriormente, grandes chances existem de voc estar utilizado comutadores que no conseguem trocar informaes sobre VLANs entre si.

Teste confirmatrio 2

Verifique se os comutadores envolvidos so do mesmo fabricante. Caso no sejam, as chances deste problema estar ocorrendo so maiores.

Teste confirmatrio 3

Verifique o tipo de codificao utilizada nos troncos. Em comutadores Cisco mais novos execute o comando:
Console> (enable) show trunk

145

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Ele lhe mostrar, dentre outras informaes, quais os troncos configurados e que tipo de codificao esto utilizando. Verifique o tipo de codificao dos troncos em todos os comutadores e roteadores que participam das VLANs. Se os tipos de codificao no forem compatveis o problema foi confirmado. Considere novamente o exemplo Figura 6-6. Voc teria que se conectar em comutador1 e verificar a configurao dos troncos existentes. Em seguida fazer os mesmo com comutador2.

6.9.5 Sugestes de tratamento

Infelizmente, as sugestes de tratamento para este problema so bastante caras: voltar atrs, isto , no estender VLANs por mais de um comutador; comprar novos comutadores que suportem o padro 802.1Q; utilizar apenas os comutadores de um mesmo fabricante. Em comutadores Cisco Catalyst srie 6000 o seguinte comando dever ser utilizado na configurao de um tronco 802.1Q em uma porta:
set trunk mod/port [on | desirable | auto | nonegotiate] dot1q

O comando a seguir configura um tronco 802.1Q na porta 1 do mdulo 1 de um comutador Cisco [CISCO-VLAN-TRUNKS]:
Console> (enable) set trunk 1/1 desirable dot1q

Se voc ainda no comprou os comutadores, mas j est planejando configurar VLANs que atravessam mltiplos comutadores, leve em conta este problema ao escolher os comutadores que sero adquiridos. Compre comutadores que j suportem o padro ou compre todos os comutadores de um mesmo fabricante.

6.10 Ambiente RIP-1 com VLSM e/ou redes no contguas 6.10.1 Descrio
Leia mais sobre RIP no captulo X

O protocolo RIP-1 foi projetado para ser usado com endereos que pertenam s classes A (mscara 255.0.0.0), B (mscara 255.255.0.0) ou C (mscara 255.255.255.0) definidas. Por esta razo, as mensagens RIP-1 no trazem consigo informaes de mscaras de sub-redes. No entanto, com o tempo, subredes e super-redes comearam a ser utilizadas para um melhor aproveitamento dos endereos IP e para diminuir a as tabelas de rotas dos roteadores. Isto leva a existncia de redes com mscaras que no pertencem a nenhuma das classes, ou ainda a redes que, por exemplo, teoricamente deveriam ter mscara de uma certa
146

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

classe, mas tm outra mscara (configurao de sub-redes). Como as mensagens RIP-1 no trazem consigo informaes de mscaras de rede, um roteador RIP-1 s est autorizado a enviar o anncio de uma rota se ele tiver certeza de que os roteadores que recebero o anncio sabero aplicar a mscara de rede correta rota anunciada [RFC 2453]. Para tal, ao compor suas mensagens de atualizaes de roteamento, um roteador RIP-1 realiza alguns testes para certificar-se de que os recipientes da mensagem sabero inferir a mscara de rede de cada rota corretamente. Em resumo31, os roteadores que participam de sub-redes semelhantes (com mesmo prefixo classe A, B ou C e mesma mscara de sub-rede) sub-rede a ser anunciada, recebero o anncio para a sub-rede. No entanto, para os roteadores que no participam de uma sub-rede semelhante, as rotas para as sub-redes sero sumariadas em uma nica rota para a rede classe A, B ou C ou nada ser anunciado. Ao receber mensagens de atualizao RIP-1, muitos roteadores aplicam a mesma mscara de rede configurada na interface que recebeu a atualizao de roteamento [RFC 2453]. Os exemplos a seguir esclarecero melhor o problema.
Leia mais sobre endereamento no apndice 8

Figura 6-7: Rede com VLSM (Variable Length Subnet Mask).

Na Figura 6-7, roteador1, roteador2 e roteador3 participam, cada um, de uma ou mais sub-redes semelhantes da rede 128.128.0.0/16. As mscaras de todas as sub-redes so iguais, com valor 255.255.255.0. Desta forma, roteador2 poder enviar para roteador1 e roteador3 anncios de rotas das sub-redes 128.128.2.0 e 128.128.8.0. Roteador1 e roteador3 aplicaro rota recebida de roteador2 a mesma mscara das interfaces que receberam a atualizao de roteamento. No entanto, para roteador4, roteador2 nada anunciar sobre suas sub-redes, uma vez que este no est certo de que roteador4 ser capaz de inferir corretamente

Em [CISCO-RIP-BEHAVIOR, CISCO-RIP-VLSM E CISCO-RIPDISCONTIGUOUS] apresentada uma viso mais detalhada do comportamento de um roteador
31

RIP ao enviar e receber mensagens de atualizaes de rotas.

147

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

as mscaras de suas sub-redes. Quando roteador4 receber um datagrama destinado rede 128.128.1.0/24, por exemplo, no saber para onde enviar, exceto se existir uma rota default configurada e esta rota coincidir com a rota que deveria ser utilizada. Como conseqncia de seu modo de operao, o protocolo RIP-1 tambm no apropriado para ser utilizado em redes no contguas. Se a rede que ligasse roteador2 e roteador4 no tivesse o prefixo 128.128 fosse, por exemplo, 200.128.1.0/24 estaria configurada a no contigidade. Duas sub-redes de mesmo prefixo classful passam a ser separadas por uma outra rede, com um prefixo diferente. Neste caso, roteador2 anunciaria para roteador4 a rota para a rede 128.128.0.0. Em resumo, s faz sentido que um roteador propague uma rota com mscara M e prefixo de rede P por uma interface que tambm tenha mscara M e prefixo de rede P. Se a mscara for outra e o prefixo for P nada ser anunciado e se a mscara for M, mas o prefixo for outro a rota ser sumariada para a rota classe A, B ou C.

6.10.2 Sintomas
difcil prever o comportamento do roteamento em um ambiente RIP-1 com VLSM e/ou redes no contguas. Em geral, os usurios reclamaro de falta de conectividade para uma ou mais redes. No exemplo da Figura 6-7, os usurios das LANs 128.128.1.0/24 e 128.128.6.0/24 reclamariam de falta de conectividade entre si.

6.10.3 Sinais
Procedimento

11.10

Quando VLSMs so configuradas em um ambiente RIP-1, as tabelas de rotas ficaro incompletas. Neste caso, para alguns destinos, o roteador no saber qual o prximo roteador para o qual o datagrama deve ser enviado. Na Figura 6-7, por exemplo, roteador4 no saber rotear pacotes destinados rede 128.128.2.0/24, pois devido existncia de mscaras de sub-redes variveis, roteador2 no anunciou esta rede para roteador4. Se existir rota default, ela ser usada sempre que a rota especfica para um certo destino no for encontrada. Se nenhuma rota default estiver configurada, o roteador no saber para onde enviar o datagrama, sendo este descartado. Aps descartar o datagrama, o roteador transmitir uma mensagem ICMP Destination Unreachable para a mquina origem do datagrama. Portanto, em um ambiente RIP-1 com VLSMs,
mensagens Destination Unreachable (ICMP tipo 3, cdigo 0) provavelmente trafegaro na rede. O ideal que mensagens deste tipo no existam na rede.

6.10.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Voc tem um problema de roteamento?

148

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

T T

E S T E

2 3

Existem VLSMs ou sub-redes descontinuadas em sua rede?

Verifique a tabela de rotas dos roteadores ligados a sub-redes com mscara varivel ou que ligam redes descontinuadas.

E S T E

Teste confirmatrio 1

provvel que os usurios das redes prejudicadas reclamem. Conecte-se em uma mquina de uma das redes atingidas pelo problema e direcione um traceroute para uma mquina na outra rede. Se o seu teste revelar que faltam rotas nos roteadores (!H na sada do traceroute) ou que os datagramas esto seguindo por um caminho inesperado voc realmente est com problema de roteamento e o teste confirmatrio 2 deve ser realizado. Caso contrrio, a falta de conectividade observada provavelmente devido a erros em camadas superiores.

Teste confirmatrio 2

Como gerente da rede voc deve conhecer o caminho que o datagrama deve seguir entre cada uma das sub-redes. Neste caminho existem redes no contguas ou sub-redes com mscaras diferentes (VLSMs)? Uma documentao de rede atualizada vai ajudar a responder esta questo. Tendo encontrado mscaras distintas para sub-redes ou redes descontinuadas, o problema est confirmado. Caso a documentao da rede no esteja atualizada, segue abaixo algumas dicas de como confirmar mais rapidamente este problema. Como os demais problemas RIP apresentados, este problema passa a existir quando alguma mudana efetuada na rede. Se nada foi modificado na rede e de repente surgirem reclamaes, voc tem um problema, mas no este! Se antes tudo funcionava bem e aps uma modificao problemas passaram a existir, comece a desconfiar do que foi modificado (lembre-se da metodologia apresentada no Captulo 3). Abaixo so listadas algumas situaes que podem levar a este problema. 1) voc acrescentou uma nova sub-rede em um ambiente RIP-1 a mscara desta nova sub-rede no tem o mesmo comprimento das mscaras das demais sub-redes; 2) voc est reavaliando a utilizao dos endereos IP da organizao (que utiliza RIP-1) e resolveu modificar algumas
149

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

mscaras para um melhor aproveitamento de endereos voc no lembrou de manter fixo o comprimento das mscaras das sub-redes e de no configurar redes descontinuadas; Verifique primeiro as ltimas modificaes realizadas! Se for descoberto que pelo menos uma mscara de sub-rede diferente das demais ou que existem redes descontinuadas, o problema foi confirmado. Se voc tinha um ambiente onde as tabelas de rotas eram construdas estaticamente e est migrando para um ambiente RIP1, voc realmente ter que descobrir e certificar-se de que no existem VLSMs e redes descontinuadas. Verifique nos roteadores o endereo configurado em cada uma de suas interfaces e aproveite para organizar melhor a documentao de sua rede! Aps ter confirmado a existncia de VLSMs e/ou redes descontinuadas com o teste confirmatrio 2, se voc ainda tiver dvidas, pode realizar o seguinte teste:

Teste confirmatrio 3

Verifique a tabela de rotas dos roteadores ligados a VLSMs ou redes no contguas. No exemplo da Figura 6-7, voc deveria analisar a tabela de rotas dos roteadores roteador4 e roteador2, e verificaria que roteador4 no sabe como chegar na rede 128.128.6.0/24 e que roteador4 no sabe chegar em nenhuma das sub-redes, exceto na que est diretamente conectada a ele. Certifique-se de que a rota desejada realmente no est presente na tabela de rotas. Esta anlise pode ser feita atravs de um terminal de gerncia ou com o auxlio de uma estao de gerncia SNMP. Veja PROCEDIMENTO 11.3.

6.10.5 Sugestes de tratamento

Para solucionar este problema o ideal seria adquirir roteadores que suportem RIP-2, ou mudar de protocolo e passar a utilizar OSPF, por exemplo, para a construo dinmica das tabelas de rotas. Caso nenhuma destas solues seja possvel e RIP-1 tenha realmente que ser utilizado, voc ainda tem duas sadas: modificar as mscaras das sub-redes para um valor nico em toda a rede; configurar algumas rotas estticas em seus roteadores de forma que o problema seja solucionado. Por exemplo, na Figura 6-7, voc poderia
150

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

inserir em roteador4 rotas estticas para as sub-redes 128.128.1.0/24, 128.128.2.0/24, 128.128.3.0/24, 128.128.4.0/24, 128.128.5.0/24 e 128.128.8.0/24.

6.11 Dimetro RIP com mais de 15 roteadores 6.11.1 Descrio

Leia mais sobre RIP no apndice 8

O protocolo RIP limita o dimetro mximo de uma rede a 15 roteadores. Isto , em um ambiente RIP, duas redes s conseguem se comunicar se existirem menos de 16 roteadores no caminho entre elas. Essa limitao se deve ao fato de que um valor de mtrica especfico deveria ser escolhido para indicar um destino inalcanvel, e o valor 16 foi escolhido. Este problema no ocorre com freqncia, pois necessrio que a rede possua um dimetro de 16 roteadores entre duas sub-redes, no sendo esta uma topologia comum. Considere a rede apresentada na Figura 6-8. Observe que roteador15 anunciar a roteador16 que chega na LAN do Departamento de Produo com mtrica 15. Roteador16 adicionar 1 a este valor, pois ele est a uma distncia de 1 hop de roteador15 e considerar a LAN do Departamento de Produo inalcanvel e no incluir a rota em sua tabela de roteamento. Desta forma, as mquinas da LAN do Departamento de Produo no conseguem de comunicar com as mquinas do Almoxarifado. O mesmo ocorre em roteador1 em relao LAN do Almoxarifado. Nas configuraes mais simples do RIP, comum usar mtricas que simplesmente informam quantos roteadores o datagrama ir atravessar at chegar no destino (hop counts). Em configuraes mais complexas, uma mtrica pode ter outros significados, como por exemplo, o custo de enviar datagramas por determinados caminhos, ou o atraso sofrido, etc. Nestes casos, possvel que mtricas de valor 16 sejam atingidas mesmo que o dimetro mximo da rede no chegue a este valor.

151

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Leia mais sobre endereamento no apndice 7

Figura 6-8: exemplo de rede com distncia maior que 15 entre duas sub-redes

6.11.2 Sintomas
as redes.

Os usurios das redes envolvidas iro reclamar de falta de conectividade entre No exemplo apresentado na seo anterior, os usurios do Departamento de Produo iriam reclamar que no conseguem acessar a aplicao de controle de estoque que est na LAN do Almoxarifado.

6.11.3 Sinais
Procedimento

11.10

As rotas com mtrica 16 no so anunciadas nem inseridas nas tabelas de rotas dos roteadores, tornando-as incompletas. Se existir rota default, ela ser usada sempre que a rota especfica para um certo destino no for encontrada. Se nenhuma rota default estiver configurada, o roteador no saber para onde enviar o datagrama, sendo este descartado. Aps descartar o datagrama, o roteador transmitir uma mensagem ICMP Destination Unreachable para a mquina origem do datagrama. Portanto, em um ambiente RIP onde mtricas 16 so encontradas, mensagens Destination Unreachable (ICMP tipo 3, cdigo 0) provavelmente trafegaro na rede. O ideal que mensagens deste tipo no existam na rede.

152

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.11.4 Testes confirmatrios

RESUMO
T
E S T E

DOS

TES TES

Analise o caminho seguido por um datagrama entre as duas redes. A partir de qual roteador o caminho desviado ou no existem rotas? Como est a tabela de rotas do roteador localizado no teste anterior? Sua tabela de rotas est realmente incompleta? De acordo com a topologia da rede existem mais de 15 roteadores entre duas sub-redes?

E S T E

E S T E

Teste confirmatrio 1

A conseqncia deste problema a falta de conectividade entre duas ou mais redes. Ao suspeitar da existncia de mais de 15 roteadores entre as redes, ou de mtricas RIP superiores a 15, conecte-se em uma mquina de uma das redes envolvidas e direcione um traceroute a uma mquina da outra rede envolvida. Considere novamente o exemplo ilustrado na Figura 6-8. O gerente do Departamento de Produo liga para o gerente de redes e diz que desde o dia anterior no consegue utilizar a aplicao de controle de estoque. O gerente de redes sabe que esta aplicao est implantada no Almoxarifado, e comea a realizar seus testes para descobrir e confirmar o problema. No dia anterior o roteador5 foi adicionado na rede, e o gerente de redes desconfia que a distncia entre as duas redes tornou-se 16 hops. Ele se conecta em uma mquina do Departamento de Produo e direciona um traceroute para o BD do Almoxarifado. A sada foi a seguinte:
# traceroute n 192.168.16.2 1 2 0.132 ms !H !H 0.211 ms !H 0.217 ms 192.168.1.1

Esta sada indica que o roteador1 no sabe para onde enviar datagramas destinados rede do Almoxarifado. Conectando-se em uma mquina do Almoxarifado e direcionando um traceroute para uma mquina do Departamento de Produo obtm-se uma sada semelhante:
# traceroute n 192.168.1.2 1 0.132 ms 0.211 ms 0.217 ms 153 192.168.16.1

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

!H

!H

!H

Isto significa que o roteador16 tambm no possui rota para a rede 192.168.1.0/24 (LAN do Departamento de Produo). Este teste serve tambm para negar a existncia deste problema. Se o roteador1 conhecesse a rota para a rede 192.168.16.0/24, e mais adiante um outro roteador por exemplo, o roteador5 estivesse com sua tabela de rotas incompleta, o problema no seria o apresentado neste captulo. Se existirem rotas default nos roteadores elas sero utilizadas, e, neste caso, ou a rota default coincidir com a rota que deveria ser seguida ou o datagrama comear a caminhar por um caminho incorreto. No primeiro caso, at possvel que uma grande coincidncia faa com que o problema no seja percebido. Considere, por exemplo, que a rota default do roteador1 o roteador2, e que a rota default do roteador16 o roteador15. Neste caso, apesar das redes estarem a mais de 15 hops de distncia, elas continuaro se comunicando. No segundo caso, simples deduzir que no existe rota para o destino especificado e que a rota default est sendo utilizada.

Teste confirmatrio 2

Observe a tabela de rotas do roteador a partir do qual o caminho foi desviado ou no existe rota. Certifique-se de que a rota desejada realmente no est presente na tabela de rotas, que o RIP est habilitado e funcionando apropriadamente. Esta anlise pode ser feita atravs de um terminal de gerncia ou com o auxlio de uma estao de gerncia SNMP. Veja procedimento apresentado na Seo 11.3.

Teste confirmatrio 3

Analise a topologia de sua rede. Se voc usa RIP e existem mais de 15 roteadores entre duas sub-redes, o problema est confirmado. Se a documentao da topologia da rede estiver desatualizada, o traceroute pode novamente auxiliar na confirmao do problema. Considere novamente o exemplo da Figura 6-8. O gerente da rede no est bem certo sobre o caminho que os datagramas devem percorrer ao sarem da LAN do Departamento de Produo para a LAN do Almoxarifado. Mas ele sabe que, saindo da LAN do
154

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Departamento de produo, o datagrama deve passar por roteador1 e logo aps por roteador2 e roteador3. O gerente, ento, conectou-se via telnet ou atravs de um terminal de gerncia em roteador2, que o segundo roteador pelo qual o datagrama deveria passar. Dele, o gerente direcionou um traceroute para uma mquina da LAN do Almoxarifado. A sada do traceroute foi a seguinte:
# traceroute n 192.168.16.2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0.132 ms 0.231 ms 0.214 ms 0.254 ms 0.235 ms 0.301 ms 0.226 ms 0.219 ms 0.132 ms 0.231 ms 0.214 ms 0.231 ms 0.231 ms 0.301 ms 0.282 ms 0.211 ms 0.165 ms 0.189 ms 0.213 ms 0.198 ms 0.255 ms 0.209 ms 0.159 ms 0.211 ms 0.165 ms 0.189 ms 0.199 ms 0.229 ms 0.302 ms 0.209 ms 0.217 ms 0.153 ms 0.344 ms 0.222 ms 0.210 ms 0.278 ms 0.245 ms 0.218 ms 0.217 ms 0.153 ms 0.344 ms 0.243 ms 0.235 ms 0.265 ms 0.287 ms 192.168.3.1 192.168.4.1 192.168.5.1 192.168.6.1 192.168.7.1 192.168.8.1 192.168.9.1 192.168.10.1 192.168.11.1 192.168.12.1 192.168.13.2 192.168.14.1 192.168.15.1 192.168.16.1 192.168.16.2

Este resultado informa que entre roteador2 e a LAN do Almoxarifado existem 14 roteadores. Somando o roteador1 e o roteador2, obtm-se 16 roteadores entre as duas LANs e o problema est ento confirmado. Se voc ou sua equipe de gerncia modificou os custos de suas interfaces e as mtricas RIP no equivalem ao nmero de roteadores entre duas redes, verifique se a soma dos custos RIP entre as duas redes envolvidas leva a mtricas maiores que 15. Se levar o problema foi confirmado.

155

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.11.5 Sugestes de tratamento

Se as mtricas utilizadas em cada interface j esto configuradas com valor 1, duas solues so possveis: reprojetar a rede de forma que entre duas sub-redes no existam mais de 15 roteadores; passar a utilizar outro protocolo de roteamento interior, como OSPF, por exemplo. Se os custos RIP tiverem sido modificados, reduza os valores de forma a no mais existirem mtricas maiores que 15. Se as mtricas RIP foram modificadas e no indicam o nmero de roteadores entre duas redes, mais interessante que reduzir as mtricas seria passar a utilizar outro protocolo de roteamento interno, baseado em um algoritmo de estado de enlace, como OSPF, por exemplo. Idealmente, uma estao de gerncia oferece o servio de descobrimento automtico de topologia. Com o descobrimento automtico, a documentao da topologia da rede no ficar desatualizada. O protocolo de descobrimento de topologia Cisco (Cisco Discovery Protocol CDP) pode ser utilizado em conjunto com SNMP com a finalidade de descobrir automaticamente quem so os vizinhos de um equipamento. O protocolo CDP pode ser ativado em todos os equipamentos da Cisco. As informaes descobertas so representadas por objetos da CISCO-CDP-MIB, podendo ser obtidas via SNMP. Se a estao de gerncia oferecer o servio de descobrimento automtico de topologia, a adio de novos roteadores ser rapidamente percebida.

6.12 Roteadores RIP-2 no enviam ou recebem pacotes RIP1 6.12.1 Descrio

Leia mais sobre RIP no apndice 8

Este problema s poder ocorrer se, em uma rede, alguns roteadores j suportam RIP-2 e outros ainda permaneam implementando apenas RIP1. Geralmente, por default, as interfaces de um roteador RIP-2 so configuradas para: 1) receber pacotes RIP-1 e RIP-232 e 2) enviar pacotes RIP-2 atravs do endereo de difuso. No entanto, esta configurao pode ser alterada. Veja algumas situaes que causaro problemas:

32 Mensagens RIP-2 tm o mesmo formato de mensagens RIP. A nica diferena entre elas que as mensagens RIP-2 usam octetos no utilizados do campo de endereo das mensagens RIP1 para enviar a mscara da sub-rede.

156

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

se os ns que implementam RIP-2 forem configurados para anunciar suas rotas atravs do endereo multicast 224.0.0.9, os ns RIP-1 no recebero essas atualizaes de roteamento. Estes roteadores s recebem mensagens RIP destinadas ao endereo de difuso. Isto causar tabelas de rotas incompletas; os roteadores RIP-2 podem ser configurados para receber apenas pacotes RIP-2 via endereo de multicast. Sendo assim, eles no recebero os pacotes RIP-1, que so transmitidos para o endereo de difuso. Na Figura 6-9, o roteador1 implementa RIP-2, enquanto os demais implementam RIP-1. As configuraes default de roteador1 foram modificadas, e ele s envia e recebe pacotes RIP-2 (usando endereo de multicast). Os anncios enviados por roteador1 no sero recebidos por roteador2 e roteador3, e, conseqentemente, eles no sabero como rotear pacotes destinados LAN do Setor de Vendas. Da mesma forma, roteador1 no considerar os anncios de rotas do roteador2 e do roteador3. Em um ambiente misto, necessrio ter em mente que todas as limitaes do RIP-1 (no suportar VLSM e supernetting, por exemplo) devem ser consideradas.

Figura 6-9: ambiente misto, com dois roteadores RIP-1 e um roteador RIP-2

6.12.2 Sintomas
Os usurios reclamaro de falta de conectividade para uma ou mais redes. No exemplo apresentado anteriormente, os usurios da LAN do Departamento de Vendas reclamaro que no conseguem acessar as pginas dos demais departamentos. Ou ainda, os usurios do Departamento de Marketing se chatearo por no estarem conseguindo ver as estatsticas de venda da empresa.

157

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.12.3 Sinais
Procedimento

11.10

Os ns RIP-1 no recebero as informaes de roteamento anunciadas pelos ns RIP-2 que estiverem utilizando endereamento multicast. possvel tambm que os ns RIP-2 no estejam aceitando os pacotes RIP-1 enviados por difuso. Portanto, as tabelas de rotas dos roteadores ficaro incompletas. Se existir rota default, ela ser usada sempre que a rota especfica para um certo destino no for encontrada. Se nenhuma rota default estiver configurada, o roteador no saber para onde enviar o datagrama, sendo este descartado. Aps descartar o datagrama, o roteador transmitir uma mensagem ICMP de destino inalcanvel para a mquina origem do datagrama. Portanto, em um ambiente RIP misto onde os ns RIP-2 s enviam e recebem pacotes RIP-2 atravs de endereamento multicast, mensagens ICMP de destino inalcanvel (ICMP tipo 3, cdigo 0) provavelmente trafegaro na rede. O ideal que mensagens deste tipo no existam na rede.

6.12.4 Testes confirmatrios

Este um problema de configurao, e no vai ocorrer sem que algo esteja sendo modificado na rede. Portanto, sempre que, em um ambiente RIP misto, um novo n RIP estiver sendo inserido ou as configuraes RIP estiverem sendo alteradas, alguns cuidados devem ser tomados. Ver a Seo SUGESTES DE TRATAMENTO. Alteraes que tornem o ambiente RIP misto tambm devem ser executadas com cautela.
T T
E S T E

1 2

Localize os roteadores com maior probabilidade de estarem mal configurados; Verifique que tipo de pacote RIP as interfaces destes roteadores aceitam receber e para que endereo elas enviam mensagens RIP;

E S T E

Teste confirmatrio 1

Neste teste voc vai procurar quais so os roteadores que esto enviando e/ou recebendo apenas pacotes RIP-2 via multicast. Estes roteadores ficam sob suspeita e devem passar pelo teste confirmatrio 2. Apenas roteadores RIP-2 podem ficar sob suspeita. Isto ocorre porque apenas eles so capazes de enviar e receber pacotes RIP-1 e RIP-2. J os ns RIP-1 s sabem falar RIP-1 mesmo; no h, portanto, o que ser configurado. Comumente, ambientes RIP-1 vo sendo atualizados para se tornar ambientes RIP-2 atravs da substituio de roteadores RIP1 por roteadores que suportem RIP-2, ou atravs da insero de novos roteadores que j suportem a mais nova verso do protocolo RIP. Neste caso, o novo roteador RIP-2 fica sob suspeita.
158

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Num caso mais raro, em que o ambiente era completamente RIP2 e um novo roteador RIP-1 teve que ser inserido, os antigos roteadores RIP-2 que ficam sob suspeita. Por fim, o gerente da rede pode configurar que tipo de pacote RIP as interfaces de seu roteador RIP-2 iro enviar e processar (ver Seo SUGESTES DE TRATAMENTO). Se estas configuraes foram alteradas em um roteador, este fica sob suspeita. Para ilustrar esta busca, observe novamente o exemplo da Figura 6-9. Considere que roteador1 e roteador2 j existiam, e que roteador3 foi adicionado rede. Esta situao no leva a problema algum (exceto se ele j existia antes!), pois o ambiente j era misto e um roteador RIP-1 foi inserido. Considere agora que roteador2 e roteador3 (ambos suportam apenas RIP-1) j existiam na rede, e que roteador1 (que implementa RIP-2) foi adicionado para incluir na rede da empresa a LAN do Departamento de Vendas. Diante deste quadro, roteador1 torna-se suspeito e deve ter a sua configurao RIP analisada, como mostra o teste confirmatrio a seguir.

Teste confirmatrio 2

Examine que tipos de pacotes RIP as interfaces dos roteadores sob suspeita esto configuradas para enviar e receber. Esta anlise pode ser feita de duas formas:
1. Atravs de uma interface de linha de comando

Os comandos a serem executados iro depender do fabricante e do modelo do roteador em questo. Em alguns roteadores Cisco, por exemplo, os comandos a seguir apresentam na tela os tipos de pacotes enviados e aceitos pela interface:
roteador> show ip rip send version roteador> show ip rip receive version

O comando seguinte mostra toda a configurao corrente do roteador e pode tambm ser utilizado:
roteador# show running-config
2. Com o auxlio de uma estao de gerncia SNMP

159

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Duas variveis da tabela rip2IfConfTable (extenses da MIB RIP verso 2 [RFC 1724]) auxiliaro esta anlise: rip2IfConfSend e rip2IfConfReceive. Nesta tabela existe uma entrada para cada interface RIP do roteador. O objeto rip2IfConfSend informa que tipo de pacote RIP o roteador envia pela interface em questo. Alguns valores possveis so:
doNotSend (1)

nenhum pacote RIP enviado pela

interface;
ripVersion1 (2)

envia atualizaes RIP compatveis com a RFC 1058 (especificao do RIP-1);

rip1Compatible (3)

envia atualizaes RIP-2 atravs do envia atualizaes RIP-2 atravs de

endereo de difuso;
ripVersion2 (4)

endereo de multicast; Se em alguma interface que se comunica diretamente com pelo menos um n RIP-1 o valor ripVersion2 for encontrado o problema (ou parte dele) foi confirmado. O objeto rip2IfConfReceive indica que verses de atualizaes RIP so aceitas pela interface. Quatro valores so possveis: rip1 (1), rip2 (2), rip1OrRip2 (3) ou doNotReceive (4). Se o valor rip2 for encontrado em interfaces que se comunicam diretamente com pelo menos um n RIP-1, o problema foi confirmado.

6.12.5 Sugestes de tratamento

Este problema pode ser corrigido de duas formas: compre roteadores que implementem RIP-2 e torne seu ambiente completamente RIP-2; configure os roteadores RIP-2 para enviarem atualizaes de roteamento para o endereo de difuso e aceitarem pacotes RIP-1 destinados ao endereo de difuso. Esta configurao, mais uma vez, pode ser realizada de duas formas:
A
T R A V S U M A L I N H A D E C O M A N D O

D E D E

I N T E R F A C E

Os comandos a serem executados dependem do fabricante e do modelo do roteador. Em um roteador Cisco, por exemplo, a configurao correta das interfaces diretamente conectadas a ns RIP-1 pode ser realizada, por exemplo, com os seguintes comandos:
roteador1# ip rip send version 1 2
160

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

roteador1# ip rip receive version 1 2

Tambm possvel escolher aceitar receber ou enviar apenas pacotes RIP-1.

roteador1# ip rip send version 1 roteador1# ip rip receive version 1
C
O M O A U X L I O D E U M A D E G E R N C I A E S T A O

As variveis rip2IfConfSend e rip2IfConfReceive da tabela rip2IfConfTable devem ter seu valor modificado da seguinte forma nas interfaces que esto diretamente conectadas a ns RIP-1: o valor da varivel rip2IfConfSend deve ser modificado para o valor rip1Compatible; o valor da varivel rip2IfConfReceive deve ser configurado com o valor rip1OrRip2.

S N M P

6.13 Trfego RIP saturando largura de banda 6.13.1 Descrio

Leia mais sobre RIP no apndice 8

Periodicamente (de 30 em 30 segundos), cada roteador RIP envia uma cpia de sua tabela de rotas para todos os outros roteadores diretamente conectados a ele. Uma tabela de rotas contm uma entrada para cada rede da organizao com a qual o roteador possa se comunicar direta ou indiretamente. Desta forma, a quantidade de informao enviada por um roteador diretamente proporcional quantidade de redes interligadas na organizao. Sendo assim, dependendo da quantidade de redes e da capacidade dos enlaces, possvel que o volume de trfego RIP seja to grande que chegue a saturar os enlaces com menor largura de banda.

Considere, por exemplo, a rede da Figura 6-10. Considere tambm que cada um dos roteadores apresentados nela (exceto os roteadores da clnica e rt-creche), em mdia, est conectado direta ou indiretamente a 350 outras redes. Nesta inter-rede existem portanto, 22x350 = 7700 redes. Isto significa que na tabela de rotas dos roteadores, existem pelo menos 7700 entradas. Como os roteadores esto com o protocolo RIP ativado, a cada 30 segundos cada roteador envia para os roteadores diretamente conectados a ele informaes de roteamento que consistem, nada mais nada menos, nas 7700 entradas de toda a sua tabela de rotas. Se voc fizer os clculos desconsiderando os dados de controle da camada de enlace, chegar seguinte concluso: a cada 30 segundos um roteador envia 163,8 KB de dados para os demais roteadores ligados a ele. Isto resulta em um trfego mdio de aproximadamente 43,7 Kbps. Quase 70% da largura de banda do enlace entre rt-14 e rt-clinica est sendo gasto com informaes do protocolo RIP, consumindo praticamente toda a largura de banda do enlace que liga a rede do hospital da empresa rede da empresa. Se rt-creche estivesse falando RIP com os demais roteadores, o enlace rt-8 rt-creche tambm estaria congestionado devido ao trfego RIP.
161

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.13.2 Sintomas
Os usurios reclamaro de rede lenta. Os mdicos e funcionrios da clnica apresentada na Figura 6-10 reclamariam de rede lenta e todas as aplicaes hospedadas na clnica apresentariam um tempo de resposta muito grande se utilizadas fora dela.

Figura 6-10: Inter-rede com 7700 redes conectadas por roteadores.

6.13.3 Sinais
Procedimento

10.10

A razo da preocupao com altas taxas de utilizao que aps uma certa taxa de utilizao, um pequeno aumento da utilizao implica em um grande aumento do tempo de resposta.

Taxa de utilizao de enlaces de longa distncia33 superior a 70%.

6.13.4 Testes confirmatrios

RESUMO DOS TES TES

33 Enlaces de redes locais, tm maior capacidade, no sendo provvel a sua saturao devido ao trfego RIP.

162

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

E S T E

Quantas redes esto interligadas? Milhares? Existem enlaces de baixa velocidade? Qual o trfego RIP gerado pelos roteadores?

E S T E

Teste confirmatrio 1

Muito provavelmente os usurios reclamaro de rede lenta. Se a rede foi crescendo aos poucos, a percepo de rede lenta por parte dos usurios foi tambm aumentando aos poucos, at chegar a um ponto insuportvel. Se a sua ferramenta de gerncia estiver apresentando dados como tempo de ping, por exemplo, voc notar o aumento gradual desta estatstica se compar-la aos seus valores antigos. A documentao da rede poder ajudar a responder s seguintes questes: Quantas redes esto interligadas em sua inter-rede? Existem roteadores RIP ligados a enlaces de baixa velocidade em sua inter-rede? Se em sua inter-rede existem mais de 8 mil redes interligadas, e se existem tambm enlaces de baixa capacidade, como 64 kbps, por exemplo, comece a desconfiar deste problema. Se necessrio conecte-se nos roteadores ligados a enlaces de baixa capacidade e verifique o tamanho de suas tabelas de rotas. O procedimento apresentado na Seo 11.3 ensina como obter tabela de rotas de roteadores. Em um roteador Linux voc pode descobrir facilmente quantas entradas existem na tabela de rotas com o comando:
# netstat nr | wc -l

Teste confirmatrio 2

Para descobrir quanta largura de banda o trfego RIP est consumindo, substitua a varivel n-entradas da equao abaixo pelo nmero de entradas RIP nas tabelas de rotas dos roteadores.

163

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

A quantidade aproximada de trfego RIP gerada por um roteador 34:

Trfego de 1 roteador = (n-entradas x 4256) bps 25 x 30

Onde: 4256 a quantidade de bits em um datagrama que contm uma mensagem RIP com anncio para 25 redes, que o mximo permitido por mensagem RIP. Utilizando a equao acima voc pode descobrir o trfego RIP de um enlace. Se ele estiver muito alto o problema foi confirmado. Na realidade, no uma boa prtica de gerncia que voc permita que mais de 5% da capacidade de um enlace seja desperdiada com informaes de roteamento. O ideal, portanto, que de tempos em tempos, voc monitore a quantidade largura de banda usada para o trfego de informaes de roteamento nos enlaces mais lentos.

6.13.5 Sugestes de tratamento

Protocolos baseados no algoritmo vetor-distncia como o caso do RIP tm a seguinte desvantagem: a cada 30 segundos cada roteador tem que enviar para os demais roteadores conectados diretamente a ele toda a sua tabela de rotas, tendo ela sofrido ou no modificaes. Por outro lado, protocolos baseados no algoritmo de estado de enlace, como o caso do OSPF, no trazem esta desvantagem. Os roteadores OSPF trocam apenas informaes de roteamento que sofreram modificaes. A melhor soluo em longo prazo para este problema seria passar a usar um protocolo baseado no algoritmo de estado de enlace. OSPF o mais utilizado atualmente. Caso voc no ache esta soluo factvel, poder aumentar a largura de banda do enlace, isto , em vez de pagar por um enlace de 64 Kbps, passe a pagar por um de 128 Kbps.

6.14 Filtro IP no permite a passagem de trfego RIP (UDP 520) 6.14.1 Descrio
possvel que filtros de pacotes IP estejam configurados nos roteadores que implementam RIP. Os roteadores RIP trocam informaes de roteamento
34 Na realidade, o trfego RIP gerado um pouco maior, pois estes clculos esto desconsiderando os gastos com dados de controle da camada de enlace.

164

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

atravs da porta UDP 520. Se existirem filtros IP barrando a entrada ou a sada de dados nesta porta, os roteadores RIP no podero trocar as informaes de roteamento, causando tabelas de rotas incompletas. Para exemplificar este problema, considere a rede apresentada na Figura 6-11. Note que um filtro IP est configurado em roteador1. Este filtro no est permitindo a passagem do trfego UDP 520 entre os roteadores roteador1 e roteador2. Portanto, os roteadores roteador2 e roteador3 no sabero como encaminhar pacotes destinados LAN do Departamento de Finanas, e roteador1 no saber chegar s demais LANs da empresa.

Figura 6-11: Ambiente RIP com filtro IP configurado no roteador1

6.14.2 Sintomas
falta de conectividade para uma rede, vrias redes ou todas as outras redes. No exemplo anterior, certamente, o pessoal

Os usurios reclamaro de

de finanas reclamar que a rede s funciona internamente (falta de conectividade para todas as demais redes) e provvel que os diretores da empresa fiquem bastante chateados por no estarem conseguindo utilizar a aplicao de controle financeiro (falta de conectividade para uma rede) ou consultar o cadastro dos funcionrios.

6.14.3 Sinais
Procedimento

11.10

Quando filtros de pacotes barram a passagem do trfego RIP, as tabelas de rotas dos roteadores (que dependem desta troca de informaes) ficaro incompletas. Se existir rota default, ela ser usada sempre que a rota especfica para um certo destino no for encontrada. Se nenhuma rota default estiver configurada, o roteador no saber para onde enviar o datagrama, sendo este descartado. Aps descartar o datagrama, o roteador transmitir uma mensagem ICMP Destination Unreachable para a mquina origem do datagrama. Portanto, em um ambiente RIP onde existem filtros de pacotes que barram o trfego UDP na porta 520,
165

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

mensagens Destination Unreachable (ICMP tipo 3, cdigo 0) provavelmente trafegaro na rede. O ideal que mensagens deste tipo no existam na rede.

Procedimento

11.9

Sendo roteados com base nas tabelas incompletas dos roteadores, laos lgicos podem ser formados. A formao dos laos vai levar existncia de mensagens ICMP de TTL excedido na rede. Idealmente estas mensagens no devem ser encontradas.

6.14.4 Testes confirmatrios

RESUMO
T T
E S T E

DOS

TES TES

1 2

Localize os roteadores nos quais filtros de pacotes esto configurados; Verifique se a sada e entrada de trfego UDP na porta 520 so permitidos pelos filtros.

E S T E

Teste confirmatrio 1

Este, assim como os demais problemas RIP apresentados neste livro, um problema de configurao. Neste caso porm, o problema no de configurao do RIP, mas do filtro IP de um roteador que implementa RIP. Caso um filtro IP seja configurado em um roteador e este filtro esteja barrando o trfego UDP na porta 520, aps, no mximo, 180 segundos da ativao do filtro, as tabelas de rotas dos roteadores ficaro incompletas. Portanto, se ao configurar filtros IP em um ambiente RIP o os sintomas e/ou sinais descritos anteriormente forem percebidos, considere a possibilidade do trfego RIP estar sendo barrado. Localize os roteadores onde filtros IP foram configurados e ativados ultimamente e realize neles o teste confirmatrio 2.

Teste confirmatrio 2

Examine a configurao do filtro IP em cada roteador selecionado no teste confirmatrio 1. Os comandos a serem executados dependem do fabricante e do modelo do roteador em questo. Em um roteador Cisco, utilize o comando show access-list para analisar todas as listas de acesso configuradas. Em um roteador Linux o comando para a criao e visualizao das regras configuradas depende do pacote de filtragem instalado.
166

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Atualmente, o filtro configurado com um dos seguintes comandos: iptables, ipchains ou ipfwadm. Os comandos abaixo mostram as regras de entrada e de sada para configuraes realizadas com iptables, ipchains e com ipfwadm.
# iptables L n | more # ipchains L -n| more # ipfwadm L n | more

Caso exista uma regra que no esteja permitindo a entrada ou a sada de trfego UDP na porta 520, o problema foi confirmado.

6.14.5 Sugestes de tratamento

O filtro IP de um roteador RIP, qualquer que seja a verso do protocolo RIP, deve sempre permitir a entrada e a sada de trfego UDP na porta 520. Ao confirmar o problema modifique as regras do filtro para permitir a passagem do trfego RIP. Em um roteador Cisco, as regras de filtragem so configuradas atravs de comandos access-list. Considerando que os roteadores do exemplo apresentado na Seo DESCRIO so fabricados pela Cisco, o problema solucionado com os seguintes comandos:
roteador1# no access-list 101 deny udp any any eq 520 roteador1# access-list 101 permit udp 192.168.4.1 0.0.0.0 any eq 520 roteador1# access-list 101 permit udp 192.168.4.2 0.0.0.0 any eq 520

O primeiro comando serve para negar a regra antes configurada que barrava o trfego RIP. O segundo comando permite a transmisso de pacotes RIP de roteador1 para qualquer destino. O ltimo comando permite que roteador1 aceite o trfego RIP proveniente de roteador2. Uma regra mais genrica (e mais insegura) que poderia substituir as duas ltimas regras :
roteador1# access-list 101 permit udp 192.168. 0.0.255.255 any eq 520

A regra resultante do comando acima indica que permitida a passagem de trfego UDP na porta 520 de qualquer fonte para qualquer destino. Se roteador1 fosse um Linux, e a interface que o liga a roteador2 fosse eth1, um dos seguintes conjuntos de regras deveria ser adicionado ao arquivo de configurao do filtro IP:
/sbin/ipchains A input p udp s 192.168.4.1/32 d 0/0 520 i eth1 j ACCEPT /sbin/ipchains A output p udp s 192.168.4.2/32 d 0/0 520 i eth1 j \ ACCEPT

ou
/sbin/ipfwadm I a accept P udp S 192.168.4.2/32 D 0/0 520 /sbin/ipfwadm O a accept P udp S 192.168.4.1/32 D 0/0 520

167

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

Em um filtro IP menos seguro os endereos das interfaces poderiam ser trocados por 0/0.

6.15 Referncias 6.15.1 Recursos online (Internet)

[VLAN-REPORT] The Virtual LAN Technology Report. http://www.3com.com/other/pdfs/solutions/en_US /20037401.pdf [CISCO-DESIGN] Designing Switched LAN Internetworks. http://www.cisco.com/univercd/cc/td/doc/cisintwk /idg4/nd2012.htm [CISCO-RIP-BEHAVIOR] Behavior of RIP and IGRP When Sending and Receiving Updates. http://www.cisco.com/warp/public/105/54.html [CISCO-RIPDISCONTIGUOUS]

Why Doesn't RIP or IGRP Support Discontiguous Networks? http://www.cisco.com/warp/public/105/55.html

[CISCO-RIP-VLSM]

Why Don't RIP and IGRP Support Variable-Length Subnet Mask? http://www.cisco.com/warp/public/105/53.html

[CISCO-VLAN-TRUNKS]

CONFIGURING ETHERNET VLAN TRUNKS. http://www.cisco.com/univercd/cc/td/doc/product /lan/cat6000/sft_6_1/configgd/e_trunk.htm Wobus, J., Lemon, T., Droms, R. DHCP FAQ. http://www.dhcp-handbook.com/dhcp_faq.html

[DHCP_FAQ]

6.15.2 RFCs
[RFC 1724] [RFC 2453] Malkin, G., Baker, F. RIP Version 2 MIB Extension. Novembro, 1994. Malkin, G. RIP Version 2. Novembro, 1998.

168

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

R E D E

6.15.3 Livros base

[COMER] Comer, D. Internetworking with TCP/IP: Principles, Protocols, and Architectures. Volume 1. Quarta edio. Prentice Hall, 2000. Doyle, J. Routing TCP/IP, Volume 1: CCIE Professional Development. Cisco Press. Setembro, 1998. Sportack, M. IP Routing Fundamentals. Cisco Press. Fevereiro, 1999. Lemon, T. Droms, R. The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services. Pearson Higher Education. Outubro, 1999. Alcott, N. DHCP for Windows 2000. OReilly. Janeiro, 2001. Maggiora, P. L. D., Elliot, C. E., Pavone Jr, R. L., Phelps, K. J., Thompson, J. M. Performance and Fault Management. Cisco Press. 2000.

[CISCO-ROUTINGTCP/IP] [CISCO-IP-ROUTING] [DHCP-HANDBOOK]

[DHCP-WIN-2000] [PERF&FAULT-CISCO]

169

Captulo

7 Problemas de nvel de aplicao

Neste captulo encontram-se 9 problemas que podem ocorrer em uma rede relacionados camada de aplicao, em especial aos protocolos DNS (Domain Name Service) e SMTP (Simple Mail Transfer Protocol): O servio de nomes no est habilitado, DNS: descasamento de registros A e PTR em arquivos de zonas, Inconsistncia entre registros dos servidores DNS primrio e secundrios, O TTL default de uma zona DNS no est configurado, DNS: TTL e outros campos do registro SOA com valores inadequados, Falta . aps nomes totalmente qualificados em registros DNS, Filtro IP barrando trfego DNS, Servidor de correio eletrnico com repasse totalmente aberto e Servidor de correio eletrnico com repasse totalmente fechado.

7.1 O servio de nomes no est habilitado 7.1.1 Descrio

Aprenda mais sobre o servio de nomes no apndice 10

A implementao do servio de nomes mais utilizada no mundo o BIND. Esta implementao tipicamente executada em ambientes Unix-like. O programa servidor de nomes chama-se named. Outra implementao que j comea a ser bastante utilizada a da Microsoft, que pode ser executada no Windows NT/2000 Server. Neste caso, o programa servidor chama-se dns.exe. Se o servidor de nomes de sua organizao no estiver em execuo, o seu servio de resoluo de nomes no funcionar. O servidor de nomes idealmente iniciado automaticamente durante a prpria inicializao do sistema operacional onde o servidor est instalado. Se, por exemplo, o programa named de um servidor de nomes primrio no estiver em execuo, um servidor de nomes secundrio ser utilizado pelos clientes (se estiver configurado neles). No entanto, quando o servidor secundrio no consegue falar com o primrio durante um certo tempo, ele desiste de ser secundrio, e o servio de nomes realmente no mais funcionar. Se o servidor de nomes no estiver em execuo nos servidores secundrios, o domnio ficar sem servidor de nomes secundrio, e nenhum servidor de nomes estar disponvel quando houver algum problema com o servidor de nomes primrio

170

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

A seguinte situao levaria a este problema: voc atualiza o BIND para uma verso mais nova e o named instalado em um diretrio diferente do anterior (por exemplo, o named anterior estava em /usr/sbin e o novo est em /usr/local/bin). Alm disso, para economizar o disco do seu servidor, voc remove named anterior. Tudo estaria bem, se voc no tivesse esquecido de um detalhe: modificar o arquivo de inicializao do sistema operacional onde o named ativado para chamar o novo servidor. Apesar de no ser uma boa prtica, aps a atualizao voc pode iniciar o novo named manualmente. E assim feito. Aps um boot o servio de nomes simplesmente no mais funcionar. Portanto, se voc atualizar a verso do BIND para uma mais nova lembre-se de verificar se a nova verso vai ser iniciada automaticamente.

7.1.2 Sintomas
Geralmente, os usurios acessam os servios da rede atravs dos nomes dos servidores. Por exemplo, ningum navega atravs de endereos IP, e sim atravs de nomes. Qual o endereo IP do servidor Web da Cisco? No sabe, no ? O site da Cisco acessado atravs do nome do servidor Web: www.cisco.com. Na maioria das vezes, servidores so acessados atravs de seu nome, e no de seu endereo IP. O mapeamento de um nome em um endereo IP e vice-versa realizada pelos servidores de nomes. Se o servidor de nomes de sua organizao no estiver em execuo, a resoluo no funcionar, e no ser possvel para seus usurios acessarem outras mquinas atravs de seus nomes. Todos os servios acessados atravs dos nomes dos servidores ficaro indisponveis. Durante a navegao, por exemplo, o prprio navegador alertar o usurios sobre o erro de DNS. Portanto, em geral, a reclamao dos usurios ser de que a rede no est funcionando.

7.1.3 Sinais
Procedimento

11.10

Imagine o que acontece quando o servidor de nomes no est ativado. Solicitaes de resoluo de nomes chegaro porta UDP/53 e nenhum processo estar disponvel para tratar a solicitao. Ento a mquina destino enviar mquina que solicitou o servio uma mensagem ICMP Port Unreachable (tipo 3, cdigo 3). Portanto, quando o servio de nomes no estiver habilitado, os clientes recebero mensagens ICMP Port Unreachable sempre que tentarem utilizar o servio de resoluo de nomes. De todas as mquinas da rede, percebemos que h conectividade com outras mquinas atravs de seu IP, mas no atravs de seu nome.

Procedimento

11.14

7.1.4 Testes confirmatrios

RESUMO DOS TES TES

171

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

E S T E

Verifique se o processo servidor de nomes est em execuo nos servidores de nomes primrio e secundrios; Certifique-se de que o servidor de nomes est sendo iniciado durante a inicializao da mquina servidora de nomes;

E S T E

Teste confirmatrio 1

Este teste confirmatrio depende de que implementao do servio de nomes est sendo utilizada. Como o BIND a implementao mais utilizada no mundo, este teste considera apenas ela. Os sinais/sintomas de falhas no servio de nomes so bastante fortes e por isso elas so rapidamente localizadas, seja pelos administradores da rede, seja pelos usurios. Na mquina servidora de nomes, verifique se o processo servidor de nomes est em execuo. Em outras palavras, verifique se o named ou dns.exe est em execuo. Em um servidor Linux utilize o seguinte comando:
# ps ae | grep named

No Windows NT e 2000 verifique quais os processos que esto em execuo e verifique se o seu servidor de nomes (dns.exe) est no ar. Voc pode ver os processos em execuo pressionando as teclas CTRL + ALT + DEL simultaneamente e logo aps pressionando o boto Gerenciador de Tarefas. Dentre outros dados, este gerenciador apresenta todos os processos em execuo na mquina. Se for constatado que o servidor de nomes no est em execuo o problema foi confirmado parcialmente. Realize o teste confirmatrio 2. Caso contrrio, o problema foi negado. Estude melhor os sinais e sintomas do problema, possvel que existam erros nos arquivos de configurao do BIND (veja outros problemas relacionados ao servio de nomes).

Teste confirmatrio 2

Verifique se o processo named est sendo habilitado durante a inicializao da mquina servidora de nomes. Se no estiver o problema foi confirmado. Caso contrrio, provvel que o named no execute devido a erros detectados nos seus arquivos de
172

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

configurao em algumas verses do BIND o servidor pra a execuo quando encontra erros nos arquivos de configurao. Em mquinas Linux Slackware35, geralmente o servio de nomes iniciado no arquivo /etc/rc.d/rc.inet2, onde todos os servios bsicos de rede so ativados. Certifique-se de que o named est sendo iniciado neste arquivo ou em outro arquivo. O seguinte comando ir lhe auxiliar nesta procura:
# grep named /etc/rc.d/rc*

Se os comandos que ativam o named estiverem comentados ou no existirem, o problema foi confirmado. Se o comandos que iniciam o named existem, e no esto comentados, verifique se o caminho para o processo named est correto. Se no estiver o problema foi confirmado. Caso contrrio, provvel que o BIND no entre em execuo por ter encontrado erros nos arquivos de configurao. Em mquinas Linux baseadas no System V como Red Hat, por exemplo a verificao um pouco diferente. Verifique se no diretrio /etc/rc.d/rc3.d (ou rc5.d36) existe um link iniciado com a letra S que aponta para o arquivo /etc/rc.d/init.d/named.
# grep named /etc/rc.d/*/S*

Em seguida, verifique se o arquivo /etc/rc.d/init.d/named existe e se o servidor chamado o correto. Em um servidor Windows NT, no menu Iniciar, escolha: Configuraes > Painel de Controle > Servios. Surgir uma janela que apresenta informaes tais como estado atual (esto ou no em execuo) e modo de inicializao (se automtica, manual ou se est desativada) sobre cada um dos servios instalados. Se o servidor DNS no estiver sendo iniciado automaticamente, o problema foi confirmado. No Windows 2000, o Gerenciador de Servios pode ser obtido da seguinte forma: no menu Iniciar, escolha: Programas > Ferramentas Administrativas > Servios. O servidor DNS deve estar sendo iniciado automaticamente, caso contrrio o problema foi confirmado.

35

Inicializao parecida com o sistema BSD. Para as mquinas que trabalham em ambiente grfico.

36

173

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.1.5 Sugestes de tratamento

Este um problema de fcil e rpida soluo, quando no est sendo causado por outro problema. Algumas verses do BIND no entram em execuo quando encontram erros nos arquivos de configurao. O servio de nomes deve ser ativado durante a inicializao do servidor de nomes. Como voc j percebeu, o arquivo que deve ser configurado para iniciar o named depende do sistema operacional que voc est utilizando. Em mquinas Linux Slackware, ative o named no arquivo /etc/rc.d/rc.inet2. Considere que o named est instalado no diretrio /usr/sbin. Ento as seguintes linhas no arquivo rc.inet2 poderiam ser adicionadas (ou descomentadas):
if [ -x /usr/sbin/named ]; then echo -n " named " /usr/sbin/named fi

A partir do prximo boot o named ser ativado automaticamente. Se o named no estiver ativado no momento, ative-o com o seguinte comando:
# /usr/sbin/named

O caminho para o processo named pode ser outro, depende de onde o named est instalado37. Se voc preferir reinicie a mquina para certificar-se de que o problema foi solucionado Aps a ter reiniciado o servidor de nomes, verifique se ele est em execuo:
# ps ae | grep named

Se voc atualizou o BIND para uma nova verso e o named foi instalado em um diretrio diferente do diretrio onde estava o named anterior, simplesmente corrija o caminho para o named no arquivo rc onde ele estiver sendo ativado. Em Linux Slackware isto ser feito em /etc/rc.d/rc.inet2. Em mquinas com inicializao baseada em System V, crie um link simblico (cujo nome inicie com a letra S) para /etc/rc.d/init.d/named no diretrio /etc/rc.d/rc3.d38:
# cd /etc/rc.d/rc3.d # ln -s S45named ../init.d/named

Voc pode iniciar o servidor de nomes manualmente com o comando:

# /etc/rc.d/init.c/named start

37

O comando type named ir lhe informar em que diretrio o named est instalado.

38 Se a mquina onde est seu servidor opera em ambiente grfico, o link simblico deve ser criado no diretrio /etc/rc.d/rc5.d.

174

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

Em mquinas Windows NT, no menu Iniciar escolha Configuraes > Painel de Controle > Servios. Selecione o servio Servidor DNS e pressione o boto Inicializao. Escolha o tipo de inicializao Automtica e pressione OK. Se o servidor DNS no estiver em execuo, pressione o boto Iniciar para ativ-lo manualmente. A partir do prximo boot o servio de nomes ser iniciado automaticamente. Em mquinas com sistema operacional Windows 2000, no menu Iniciar escolha Programas > Ferramentas Administrativas > Servios. Selecione o servio Servidor DNS e pressione o boto direito do mouse sobre ele. Surgir um menu. Nele escolha o item Propriedades. Surgir uma janela que lhe permitir configurar o tipo de inicializao para o servio selecionado. Escolha Automtica. Se o servio no estiver ativado no momento clique com o boto direito do mouse sobre ele e escolha Iniciar para ativ-lo manualmente. A partir do prximo boot ele ser ativado automaticamente.

7.2 DNS: descasamento de registros A e PTR em arquivos de zonas 7.2.1 Descrio

Leia mais sobre DNS no apndice 10

O servio de nomes de domnio responsvel por realizar mapeamento direto de um nome para um IP e mapeamento reverso de um IP para um nome. Infelizmente, no BIND39 a configurao do mapeamento direto e reverso no feita no mesmo registro, nem no mesmo arquivo de zona. necessrio um registro Internet Address (IN A) para o mapeamento direto e um registro Internet Pointer (IN PTR) para o reverso. Os registros IN A ficam no arquivo de zonas de mapeamento direto, enquanto os registros IN PTR ficam no arquivo de zona de mapeamento indireto. Por exemplo, para configurar que o IP da mquina pc-1.exemplo.com.br 192.168.1.1 sero necessrios dois registros. O registro seguinte deve ficar no arquivo de zona direto:
pc-1 IN A 192.168.1.1 ; no arquivo de mapeamento direto

E o registro abaixo no arquivo de zona reverso:

1 IN PTR pc-1.exemplo.com.br ; no arquivo de mapeamento reverso

Isto significa que ao modificar registros IN A no arquivo de mapeamento direto, necessrio efetuar as modificaes correspondentes nos registros IN PTR do arquivo de configurao de mapeamento reverso. O ideal seria que existisse apenas um registro e um arquivo tanto para o mapeamento direto quanto para o reverso. Se fosse assim, as situaes de erro expostas a seguir no existiriam:

39

A implementao do servio de nomes mais utilizada no mundo.

175

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

voc pode adicionar um registro A e esquecer do mapeamento reverso, no adicionando o registro PTR correspondente; o Em geral, adicionar o registro A (de mapeamento direto) intuitivo [DNS&BIND], afinal, a funo mais famosa do servio de nomes mapear nomes em IPs. Por outro lado, adicionar o registro PTR correspondente j no to intuitivo assim, podendo ser uma tarefa facilmente esquecida. por um descuido, voc pode ter registros A e PTR que no casam; o Como o mapeamento reverso muitas vezes esquecido, aps atualizaes em registros A voc pode esquecer de corrigir tambm o registro PTR correspondente, e acabar causando um descasamento entre estes registros. situaes inversas apesar de muito mais raras tambm podem ocorrer: esquecer de adicionar o registro IN A ou esquecer de modificlo aps inserir ou alterar um registro IN PTR. Este descasamento de registros A e PTR seja pela inexistncia de um deles, seja por erro de configurao poder causar problemas de autenticao mquina envolvida no descasamento [DNS&BIND]. Suponha, por exemplo que os registros da mquina pc-1 apresentados acima estivessem descasados, ou que o registro PTR no existisse. Ento, o usurio de pc-1 poderia ser prejudicado. Muitos servios de rede, como por exemplo FTP, ssh, telnet e rsh, podem ser compilados ou configurados para agir de forma muito segura (modo paranico): ao receber uma requisio de abertura de conexo de um cliente, o servidor recupera o IP cliente e tenta descobrir qual o nome correspondente a este IP (mapeamento reverso); se o mapeamento reverso tiver sido realizado com xito, o servidor tenta descobrir o IP correspondente ao nome que acabou de ser descoberto (mapeamento direto); se o mapeamento direto levar ao mesmo IP do cliente que solicitou a abertura de conexo com o servidor, esta ser aceita; se o mapeamento direto levar a outro IP a conexo ser negada; se o mapeamento reverso no for possvel o servidor no aceitar a conexo solicitada. Alguns servidores podem ser configurados/compilados de forma menos rgida e mesmo que o mapeamento reverso no seja possvel (passo b), a conexo ser estabelecida. No entanto, o cliente ter que esperar um certo tempo antes de ver que sua conexo foi aceita. Portanto, quando os registros A e PTR que definem IP/nome de uma determinada mquina esto descasados ou um dos dois no existe, alguns
176

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

servios podem no funcionar para usurios que usam esta mquina, ou ainda o usurio ter que esperar um algum tempo pelo estabelecimento das conexes com os servidores. A correspondncia correta entre registros A e PTR deve existir sempre, em qualquer que seja a implementao DNS utilizada. Alguns servidores DNS podem dar uma mozinha e lhe lembrar do registro PTR. No gerenciador do servidor DNS do Windows 2000, por exemplo, a tela para inserir ou modificar registros de endereo oferece a opo de ter o registro PTR correspondente criado ou modificado automaticamente.

7.2.2 Sintomas
O usurio da mquina envolvida no erro de configurao de DNS reclamar que alguns servios no funcionam. No exemplo da seo anterior, o usurio de pc-1 poderia reclamar que no consegue usar telnet, FTP ou ssh para alguns destinos. Neste caso a reclamao pode ser tambm que precisam esperar algum tempo quando vo se conectar a certos servidores.

7.2.3 Sinais
Procedimento

12.5

Resoluo direta de um nome de mquina no casa com a resoluo reversa no servidor de nomes primrio do domnio. Este sinal ser percebido

em duas situaes: os registros IN A e IN PTR existem, mas no so compatveis entre si. Por exemplo, no arquivo de configurao do mapeamento direto o endereo IP de pc-1.exemplo.com.br 192.168.1.1, mas no arquivo de mapeamento reverso o endereo 192.168.1.1 aponta para a mquina pc1.exemplo.com.br; um dos registros no existe, tornando o mapeamento direto possvel enquanto o reverso no existe ou vice-versa.

7.2.4 Testes confirmatrios

O sinal apresentado na seo anterior diferencial. Portanto, se ele for encontrado a existncia do problema est confirmada.

7.2.5 Sugestes de tratamento

Se o problema foi confirmado corrija o arquivo de configurao adequado. Lembre-se de aumentar o nmero de srie do arquivo modificado. Em seguida reinicialize o servidor DNS. No servidor DNS BIND, corrija os arquivos necessrios com o editor de texto de sua preferncia. Incremente o nmero de srie dos arquivos modificados e reinicie o servidor. Voc pode reiniciar o named de diversas formas. Em verses 9.x o comando rndc pode ser utilizado. No BIND 8.x o comando
177

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

correspondente ao rndc o ndc. No entanto, o BIND deve estar devidamente configurado para ser controlado por eles.
# rndc reload # ndc reload

Em todas as verses:
# kill HUP <nmero do processo named>

O nmero do processo named pode ser encontrado com um dos seguintes comandos:
# ps ae | grep named
(em

sistemas baseados no BSD),

# ps ef | grep named (sistemas baseados no System V) # cat /var/run/named.pid

possvel que com o comando ps voc encontre vrios processos named em execuo. Envie o sinal HUP apenas para o processo pai (o processo named com menor pid). No servidor DNS do Windows 2000 entre no gerenciador do DNS (Iniciar > Programas > Ferramentas Administrativas > DNS) e modifique os registros apropriados para corrigir o descasamento.

7.3 Inconsistncia entre registros dos servidores DNS primrio e secundrios 7.3.1 Descrio
Leia mais sobre DNS no apndice 10

Cada arquivo de configurao de nomes tem um nmero de srie associado a ele. Este nmero de srie utilizado para manter a consistncia dos dados armazenados pelo servidor de nomes primrio e secundrios. Ao modificar um arquivo de configurao de nomes no servidor de nomes primrio, o nmero de srie associado a este arquivo deve ser aumentado. Os servidores escravos (secundrios) comparam o nmero de srie dos arquivos que esto no servidor principal com os nmeros de srie correspondentes em seus arquivos. Se o nmero de srie do servidor principal for maior que o nmero de srie dos arquivos locais, os servidores escravos fazem a transferncia da zona com nmero de srie maior, pois neste caso, o arquivo novas configuraes foram feitas. Nas verses do BIND40 anteriores 8, o comportamento padro do servidor secundrio o seguinte: aps a inicializao e sempre que se passar um intervalo de tempo igual ao tempo de refresh configurado no SOA, o servidor secundrio busca os nmeros de srie dos arquivos do servidor principal. Quando o

40

Uma das implementaes do servio de nomes mais usadas no mundo atualmente.

178

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

nmero de srie de uma zona do servidor primrio for maior que o do servidor secundrio, as informaes desta zona sero transferidas para o servidor secundrio, garantindo a consistncia dos dados dos servidores. Nas verses mais novas do BIND (8 e 9), o servidor de nomes primrio envia para os servidores escravos mensagens de notificao sempre que reinicializado. Ao receber uma mensagem de notificao, os servidores secundrios agem como se o tempo de refresh tivesse expirado: comparam os nmeros de srie e efetuam a transferncia das zonas cujos nmeros de srie cresceram. Assim, o servidores secundrios no precisam esperar que o intervalo de refresh passe para que eles busquem modificaes nos arquivos de configurao de nomes do servidor principal. O fato que, em qualquer verso do BIND, informaes s so copiadas do servidor primrio para os secundrios quando estes verificam que o nmero de srie do arquivo no servidor primrio maior. Desta forma, se voc modificar um arquivo de configurao de nomes do servidor primrio e esquecer de aumentar seu nmero de srie, os servidores secundrios no consideraro as modificaes feitas. Como o nmero de srie no aumentou, os servidores secundrios acham que esto com informaes atualizadas. Quando os servidores de nomes secundrios forem consultados, eles podero oferecer respostas erradas, causando diversos efeitos colaterais. Os efeitos dessa inconsistncia dependem do tipo de modificao feita e do servidor envolvido. Por exemplo, se a modificao era apenas a troca do endereo IP de uma certa mquina cliente local no servidor de nomes interno, as conseqncias no sero drsticas. O usurio desta mquina pode, por exemplo, no conseguir acessar alguns servios. J se o endereo IP do servidor Web da organizao foi modificado no servidor de nomes externo, as conseqncias sero mais desastrosas: quando o servidor secundrio for consultado, o antigo IP do servidor Web ser oferecido, e o site de sua empresa no ser visto, pois ele estar em outra mquina. Outro caso em que as conseqncias so de maiores propores ocorre quando informaes sobre um novo sub-domnio so inseridas ou modificadas. O servidor secundrio nada saber! Uma ltima observao: os servidores de nomes secundrios anteriores verso 8, como citado anteriormente, s procuram novas verses dos arquivos de configurao do servidor primrio de tempos em tempos. Portanto, durante algum tempo, os servidores de nomes escravos podem realmente ficar desatualizados, apesar do nmero de srie ter sido incrementado. Assim, se voc est utilizando verses antigas do BIND ou configuradas para no notificar os servidores escravos de modificaes nos nmeros de srie41, no queira que os servidores escravos estejam atualizados to logo voc modifique os arquivos do

41

Diretiva notify

no arquivo /etc/named.conf.

Mais informaes em [DNS&BIND].

179

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

servidor primrio. Eles s estaro atualizados aps um ou mais intervalos de refresh42.

7.3.2 Sintomas
Como j mencionado anteriormente, os sintomas percebidos pelos usurios dependem do tipo de modificao que foi realizada e em que servidor. Em geral, a reclamao ser de indisponibilidade de alguns servios. Se o esquecimento ocorrer quando os dados do servidor de nomes pblicos da organizao tiverem sido atualizados, pessoas de fora da organizao podero tambm reclamar que alguns servios no esto funcionando. Quando se trata de navegao na Internet o prprio navegador d dicas de que algo est errado com o DNS. Quando no for possvel resolver o nome do servidor, ou quando o IP resultante da resoluo for incorreto, o navegador passar algum tempo localizando a mquina ou tentando abrir a pgina. No Internet Explorer, por exemplo, aps esse tempo, uma pgina de erro apresentada, contendo mensagens como: No possvel encontrar <nome-da-maquina> ou A pgina no pode ser exibida ()
No possvel encontrar o servidor ou ocorreu um erro de DNS.

7.3.3 Sinais
Procedimento

12.1
Procedimento

Os servidores primrio e secundrios retornaro respostas diferentes a uma mesma consulta DNS. Os servidores secundrios no consideram as

modificaes de configurao mais recentes. Portanto, ao realizar consultas envolvendo estas modificaes, as respostas dos servidores primrio e secundrios sero incompatveis. Percebemos que h conectividade atravs dos endereos IPs das mquinas envolvidas no erro, mas no atravs de seus nomes de domnio.

11.14

7.3.4 Testes confirmatrios

O sinal apresentado na seo anterior diferencial, portanto, voc pode confirmar o problema seguindo os passos do VERIFICANDO CONSISTNCIA DE DADOS NOS SERVIDORES DNS PRIMRIO e secundrios (pgina 343). Lembre-se que, se o servidor primrio no estiver notificando os escravos ao ser reiniciado, os servidores escravos levaro realmente algum tempo (tipicamente ser no mximo o tempo de refresh) para perceber a modificao.

42 Um servidor escravo pode ser configurado para atualizar seus dados com base nos dados de outro servidor escravo. Assim, pode ser necessrio duas vezes o tempo de refresh para ele perceber a modificao.

180

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.3.5 Sugestes de tratamento

Uma boa prtica de configurao utilizar nmeros de srie no seguinte formato [RFC1912]:
YYYYMMDDnn

Os dgitos YYYY indicam o ano da modificao, MM indicam o ms, DD o dia e nn a quantidade de vezes que o arquivo foi modificado no dia. Por exemplo, se no dia trinta de janeiro de 2002 voc est modificando o arquivo named.zone pela terceira vez, o nmero de srie que voc colocaria nele seria: 2002013003. Voc acabou de descobrir que esqueceu de modificar o nmero de srie de um certo arquivo de configurao de nomes. Para solucionar o problema mude o nmero de srie deste arquivo como se ele tivesse sido modificado agora. Se hoje 29 de janeiro de 2002, mude o nmero de srie do arquivo em questo para 2002012901. Em seguida, reinicialize o servidor de nomes primrio como apresentado na pgina 177. O servidor DNS do Windows 2000 incrementa o nmero de srie automaticamente quando voc modifica alguma configurao de zona usando a interface de gerenciamento do DNS (Iniciar > Programas > Ferramentas Administrativas > DNS). No entanto, ele no seguir a prtica de associar o nmero de srie data da modificao.

7.4 O TTL default de uma zona DNS no est configurado 7.4.1 Descrio
Leia mais sobre DNS no apndice 10

Antes de entender este problema preciso entender o que o TTL (Time to Live) default de uma zona. Veja o exemplo seguinte: Considere os servidores de nomes do domnio exemplo.com.br e do domnio cisco.com. Eles sero chamados aqui ns.exemplo.com.br e ns.cisco.com43. Quando um usurio do domnio exemplo.com.br deseja visitar a pgina www.cisco.com, o servidor de nomes ns.exemplo.com.br consultado: ns.exemplo.com.br, qual o endereo IP correspondente ao nome www.cisco.com?. Como ns.exemplo.com.br no sabe resolver este nome localmente e esta resoluo tambm no se encontra em sua cache, ele consulta um dos servidores raiz configurado em seu arquivo de dicas.

43 Na realidade, neste exemplo, sempre que voc vir o nome ns seguido do nome do domnio, considere que esta a mquina servidora de nomes do domnio.

181

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

O servidor raiz tambm no sabe quem www.cisco.com44, mas ele sabe quem o servidor do domnio .com e fornece esta informao para ns.exemplo.com.br, que em seguida, consulta um dos servidores ns.com. Este servidor informa a ns.exemplo.com.br que no sabe quem www.cisco.com, mas sabe quem o servidor do domnio cisco.com. Ao consultar ns.cisco.com, o servidor de nomes ns.exemplo.com.br pode obter uma resposta positiva, ou uma resposta negativa. Em caso de resposta positiva, ns.cisco.com informa para ns.exemplo.com.br o endereo IP de www.cisco.com, e informa tambm por quanto tempo esta informao pode ser utilizada com segurana por ns.exemplo.com.br. A este tempo d-se o nome de TTL default. O servidor ns.exemplo.com.br ir armazenar esta resoluo positiva em uma cache durante o tempo correspondente ao TTL default fornecido. Durante este tempo, sempre que um cliente do servidor ns.exemplo.com.br consult-lo para resolver o nome www.cisco.com, o servidor utilizar a informao que est em sua cache. possvel que TTLs sejam configurados para cada registro individualmente. Assim, se o TTL default de uma zona X e o TTL de um registro Y, este registro ser armazenado em outros servidores durante um tempo igual a Y. Neste caso o TTL default no quem dita o tempo de armazenamento do registro na cache. O mesmo cuidado que se deve ter com o valor do TTL default vale para TTLs de registros individuais. Pode ocorrer tambm que a resposta consulta seja negativa. Este o segundo caso mencionado acima. ns.cisco.com, por alguma razo, no foi capaz de resolver o nome www.cisco.com, apesar de ser o servidor de nomes deste domnio. As respostas negativas, assim como as positivas, tambm so armazenadas em uma cache durante um tempo chamado TTL de respostas negativas.

Figura 7-1: Exemplo do funcionamento do servio de nomes.

44 Alguns servidores raiz respondem por domnios de genricos de alto nvel (tais como edu, com, gov e mil) [DNS&BIND].

182

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

A partir da verso 8.2 do BIND, a forma de configurar o TTL default foi modificada [DNS&BIND]. Nas verses anteriores a esta, o TTL default era configurado no ltimo campo do registro SOA. No entanto, o significado deste campo foi alterado e ele passou a definir o TTL de respostas negativas. Assim, a partir desta verso, o TTL default passou a ser configurado atravs da diretiva $TTL. Se o TTL default no estiver devidamente configurado atravs da diretiva $TTL as verses do BIND superiores verso 8.2 alertaro o problema no arquivo de logs e uma das seguintes situaes ocorre: o named no entra em execuo, ou entra em execuo mas no resolve os nomes locais, ou ainda funciona normalmente. Na data da publicao deste livro, a verso mais nova do BIND a 9.2. Por questes de compatibilidade com as implementaes mais antigas, o BIND 9.2 funcionar mesmo sem a diretiva $TTL. O ltimo campo do registro SOA como antigamente ser utilizado para definir o TTL default. Mas o BIND 9.2 ir indicar o erro em seu arquivo de logs e o named-checkzone tambm alertar sobre o problema. Em resumo, se 1) voc utiliza a implementao BIND do DNS, 2) a verso em operao est entre 8.2 (inclusive) e 9.2 e 3) voc esqueceu de configurar o TTL default de uma zona com a diretiva $TTL, o seu servidor de nomes poder no resolver nomes locais ou simplesmente no ser executado. Se voc utiliza outras verses do BIND ou outras implementaes do DNS no se preocupe com este problema. Este um problema intimamente relacionado implementao BIND. No servidor DNS do Windows 2000 o TTL default ainda configurado no registro SOA, no campo minimum TTL. mais provvel que este problema ocorra quando voc estiver migrando de uma verso do BIND mais antiga para uma mais nova.

7.4.2 Sintomas
Em muitas organizaes tem-se um servidor de nomes interno, responsvel pela resoluo dos nomes locais, e um servidor de nomes externo, que responde pelos nomes de domnio pblico da organizao. Quando o servidor de nomes interno estiver sem a configurao do TTL default, os usurios reclamaro que:
no conseguem acessar os servios locais, mas conseguem acessar a Internet. No entanto, como no h resoluo de nomes locais, alguns servios

mesmo quando o servidor no for uma mquina local. Quando um cliente FTP, por exemplo, tenta conectar-se ao servidor FTP, este tenta a resoluo reversa de nomes a partir do IP do cliente45. Sem a resposta do servidor de nomes, por questes de segurana, a conexo no ser estabelecida. o mesmo que ocorre quando os registros A e PTR no casam (problema apresentado na pgina 175).

como telnet, ssh e FTP podem no funcionar,

45 Nem todos os servidores tm este mesmo comportamento, s os que so compilados ou configurados para agir assim modo paranico.

183

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

a rede no est funcionando.

Ao tentar navegar na Internet, por exemplo, o prprio navegador apresentar uma pgina de erro indicando erro de DNS.
no esto na organizao podem reclamar. Elas diro oferecidos pela sua organizao no esto funcionando.

Quando o servidor de nomes externo est com este problema, pessoas que que os servios Por exemplo, no esto conseguindo navegar no site, efetuar transferncia de arquivos nem enviar/receber e-mails de usurios internos. O prprio navegador informa o erro de DNS.

7.4.3 Sinais
Procedimento

12.2

Quando a diretiva $TTL no est presente no arquivo de configurao, o BIND alerta o gerente com uma mensagem no arquivo de log. No BIND 9.2, por exemplo, a mensagem No default TTL set using SOA minimum instead. Ser indicado no arquivo de log tambm o arquivo onde o TTL default no est configurado.

7.4.4 Testes confirmatrios

O sinal apresentado na seo anterior confirmatrio. Se ele foi encontrado nenhum teste adicional precisa ser realizado.

7.4.5 Sugestes de tratamento

A diretiva $TTL deve ser inserida no arquivo de configurao onde o TTL default no foi configurado antes do registro SOA. Todos os arquivos de configuraes de nomes (mapeamento direto, reverso e local) devem ter a diretiva $TTL. Veja o exemplo a seguir:
$TTL 86400 @ IN

SOA

ns.exemplo.com.br. root.exemplo.com.br. ( 200201231 ; Serial 8h ; Refresh 8 Horas 2h ; Retry 2 Horas 2w ; Expire 2 Semanas 2h) ; Minimum TTL 2 Horas

Nos arquivos de configurao de zonas do BIND tudo que vem aps um ponto e vrgula (;) considerado comentrio. Neste exemplo, o TTL default 86400 segundos, que equivale a 1 dia. Ao TTL de respostas negativas foi atribudo o valor de 2 horas. O TTL default deve ser escolhido de acordo com a freqncia de mudanas em mapeamentos nome IP em sua rede. Para uma melhor sintonizao do seu servidor DNS leia o problema TTL E OUTROS CAMPOS DO REGISTRO SOA COM VALORES INADEQUADOS. Ao inserir a diretiva $TTL nos arquivos de zonas onde ela no existia lembre-se de reiniciar o servidor DNS:
184

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

# kill HUP <nmero do processo named>46

Para evitar este problema (e outros problemas com BIND), sempre que modificar algum dos arquivos de configurao de nomes ou que atualizar a verso do BIND para uma mais nova, verifique a sintaxe dos arquivos de configurao de nomes. Esta verificao pode ser realizada com a ferramenta named-checkzone, que instalada com o named. A sintaxe de utilizao desta ferramenta 47:
# named-checkzone <nome do arquivo a ser verificado>

Por exemplo, considere que o arquivo /var/named/named.zone contm configuraes de nomes locais do domnio exemplo.com.br. Ento, para verificar se este arquivo est correto execute48:
# named-checkzone /var/named/named.zone

Esta ferramenta tambm pode (e deve!) ser utilizada para verificar os demais arquivos de configurao de nomes do servidor (reverso e local). Caso a diretiva $TTL no exista em um destes arquivos de configurao, o namedcheckzone informar claramente.

7.5 DNS: TTL e outros campos do registro SOA com valores inadequados 7.5.1 Descrio
Leia mais sobre DNS no apndice 10

No problema O TTL DEFAULT DE UMA ZONA DNS NO EST CONFIGURADO (pgina 181) o significado do TTL (Time to Live) default j foi apresentado. Em resumo, quando um cliente solicita a um servidor DNS que resolva um nome no local, o servidor ir iniciar a busca a partir de um servidor de nomes raiz49. At que o nome seja resolvido, outros servidores sero consultados. Finalmente, o servidor responsvel pelo domnio a que o nome em questo pertence consultado e o nome resolvido. Alm de informar o mapeamento nome IP (ou IP nome), o servidor deste domnio informa tambm por quanto tempo este mapeamento vlido. Este tempo chamado TTL default50. O servidor que

46

Este nmero pode ser obtido com o comando # ps ae | grep named.

47 No BIND 9.2 o aplicativo named-checkzone precisa ainda receber o nome do domnio a ser checado. O comando ento :

# named-checkzone <domnio> <arquivo a ser verificado>

48

No BIND 9.2 o comando seria: # named-checkzone exemplo.com /var/named/named.zone

49

Na realidade isto ocorrer apenas se a resoluo solicitada no estiver armazenada na cache do servidor.

50 possvel que TTLs sejam configurados para cada registro individualmente. Assim, pode ser que o tempo de armazenamento de um registro em outro servidor no seja o TTL default e sim o TTL configurado para o registro individualmente.

185

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

recebe a resposta armazena-a em uma cache local durante um intervalo de tempo igual ao TTL recebido. Durante este tempo, se outros clientes solicitarem a resoluo do mesmo nome, o servidor no mais precisar busc-lo externamente, ele utilizar os dados da cache. como se um servidor de nomes, ao responder uma consulta a outro servidor de nomes, dissesse: amigo, confie nesta resposta por x segundos. Por favor, durante este tempo no venha me fazer esta mesma pergunta novamente!. Alm do TTL default existem outros valores de tempo que devem ser definidos no registro SOA. Dentre eles encontram-se51: intervalo de refresh e o TTL de respostas negativas. Quando algum destes campos est com um valor inadequado, voc pode enfrentar alguns problemas com o servio DNS. Antes de continuar, veja o que cada um destes campos significa: Refresh de quanto em quanto tempo o servidor secundrio verifica se o nmero de srie do servidor primrio foi alterado (caso em que o secundrio faz uma nova transferncia de zona); TTL de respostas negativas se um servidor de nomes no for capaz de resolver o nome (ou o IP) de uma mquina do seu domnio, a resposta negativa tambm ser armazenada em uma cache. O TTL de respostas negativas indica por quanto tempo a resposta negativa oferecida por este servidor de nomes deve ser armazenada na cache de outros servidores DNS. Apenas servidores DNS mais novos so capazes de armazenar respostas negativas. Ao escolher o TTL para seus dados voc deve, na realidade, optar entre desempenho e consistncia [DNS&BIND]. Um TTL bem pequeno vai assegurar que outros servidores no armazenaro em cache dados sobre seu domnio por muito tempo, e sero obrigados a consult-lo, garantindo que mudanas logo sero percebidas por todos. Por outro lado, isto aumenta o nmero de pesquisas realizadas nos servidores de nomes de sua organizao, podendo sobrecarreg-los, tornando a resoluo de nomes mais lenta. J com um TTL maior, os seus servidores de nomes no ficaro to sobrecarregados. No entanto, os dados sobre os nomes de seu domnio armazenados em outros servidores podem ficar inconsistentes por um longo tempo. Isto se deve ao fato de que outros servidores de nomes armazenaro informaes sobre nomes do seu domnio por mais tempo. Neste caso, o problema mais grave percebido quando so realizadas modificaes em registros que definem nome endereo de servidores. O servio pode ficar indisponvel por um longo perodo um perodo inaceitvel. Em resumo, TTLs muito grandes podem gerar inconsistncia de dados, resultando em mapeamentos incorretos e interrupo de servios. Quando o TTL muito pequeno o que pode ocorrer uma quantidade muito grande de requisies de resolues de nomes aos servidores DNS de sua organizao, podendo seu desempenho ficar prejudicado.
Existem ainda outros campos que sero citados apenas na seo SUGESTES DE TRATAMENTO.

51

186

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

Um intervalo de refresh muito grande tambm pode causar inconsistncia de dados entre o servidor primrio e os secundrios. Se o servidor primrio estiver configurado para notificar os secundrios sobre mudanas em arquivos de zonas52 no h problema. Mas, quando o servidor primrio no oferece esta funcionalidade ou no est configurado para tal, os servidores secundrios podem passar bastante tempo armazenando informaes inconsistentes. Imagine um site com mudanas dirias em arquivos de zonas. Se o intervalo de refresh for 2 dias e o servidor primrio no estiver configurado (ou capacitado) para notificar os secundrios sobre mudanas, os servidores secundrios podem ficar desatualizados por at 2 dias. O resultado o mesmo que ocorre quando voc muda um arquivo de uma zona e esquece de incrementar o seu nmero de srie (ver problema INCONSISTNCIA ENTRE REGISTROS DOS SERVIDORES DNS PRIMRIO E SECUNDRIOS). Os servidores DNS secundrios oferecero respostas erradas aos clientes. Se o TTL de respostas negativas for muito grande maior que um dia, por exemplo as respostas negativas oferecidas pelo seu servidor DNS podem ficar armazenadas em outros servidores de nomes por muito tempo, podendo deixar alguns servios sem funcionar. Note que quando o valor do TTL default ou intervalo de refresh est muito grande, os problemas s ocorrero quando algum registro for modificado, em especial, um registro que defina o mapeamento nome endereo IP de um servidor. J quando estes valores so muito pequenos, o problema pode ser percebido independente de modificaes terem sido realizadas. Quanto mais sobrecarregado estiver o servidor, mais perceptvel ser o sintoma. Em se tratando de servidores pouco consultados, o problema de desempenho pode nem ser percebido.

7.5.2 Sintomas
Se o servidor DNS do domnio pblico estiver com TTL default ou TTL de respostas negativas muito grande e modificaes em registros de servidores forem realizadas, usurios de outros domnios podem no conseguir acessar alguns servios. Lembre-se: este sintoma ser percebido apenas quando alteraes que envolvem nomes/endereos de servidores forem realizadas no servidor DNS. Se voc mudou o IP do servidor Web, SMTP ou FTP, por exemplo, usurios externos e internos podem no conseguir navegar nas pginas Web do seu site, enviar mensagens para seus usurios ou fazer transferncia de arquivos durante um bom tempo. Se o TTL default estiver muito pequeno muitas requisies de resolues de nomes chegaro ao servidor DNS. O servidor de nomes pode ficar sobrecarregado, ou ainda enlaces de menor capacidade podem ficar saturados. Os usurios internos e/ou externos podem reclamar de lentido na rede ou no

52

Nas verses 8.2.3 e superiores do BIND, por default, servidores primrios enviam mensagens de notificao aos servidores secundrios de uma zona quando ela modificada. Os servidores BIND v8 anteriores verso mencionada anteriormente precisam ser explicitamente configurados para tal (opo notify yes). Verses anteriores 8 no suportam a notificao [DNS&BIND].

187

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

Na realidade a lentido pode estar sendo causada pela sobrecarga dos servidores de nomes ou pela saturao de enlaces. Se o intervalo de refresh est muito pequeno os servidores secundrios iro realizar pesquisas SOA no servidor primrio muitas vezes, podendo aumentar ainda mais carga de requisies e a utilizao de enlaces. No entanto, se apenas o intervalo de refresh est muito pequeno, mais provvel que a sobrecarga no seja observada. Suponha que o intervalo de refresh de uma zona 5 minutos e existem 2 servidores secundrios. A cada 5 minutos pelo menos 2 pesquisas SOA sero realizadas no servidor primrio. Quando o tempo de refresh est muito grande e modificaes em registros de servidores so realizadas, os servidores DNS secundrios podero ficar desatualizados por algum tempo, oferecendo respostas erradas e deixando alguns servios indisponveis.

acesso aos servios.

7.5.3 Sinais
Procedimento

10.6

Se o TTL default estiver muito pequeno e o nmero de requisies ao servidor de nomes for muito grande, possvel que o servidor DNS apresente uma utilizao elevada de CPU. O limiar de advertncia para utilizao de CPU 75%.

Procedimento

10.10

Se o TTL default estiver muito pequeno, o nmero de requisies ao servidor de nomes for muito alta e existirem enlaces de pequena capacidade entre o servidor sobrecarregado e os seus clientes, provvel que estes enlaces fiquem saturados antes mesmo que o servidor fique sobrecarregado. Nestas circunstncias, possvel encontrar enlaces de menor capacidade (longa distncia, em geral) saturados devido ao trfego DNS. O limiar para utilizao de enlaces de acesso no compartilhado 70%. Quando o intervalo de refresh for muito grande
os servidores primrio e secundrios podero retornar respostas diferentes a uma mesma consulta DNS durante algum tempo. Isto tambm ocorrer se voc modificar algum

Procedimento

12.1

arquivo no servidor primrio e esquecer de incrementar o nmero de srie associado ao arquivo.

7.5.4 Testes confirmatrios

RESUMO DOS TES TES

Se o sintoma rede lenta:

T
E S T E

Verifique o valor do TTL default e do intervalo de refresh nos arquivos de zonas dos servidores DNS primrios; Se o sintoma indisponibilidade de servios:

188

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

E S T E

Modificaes em registros do servidor primrio foram realizadas? Verifique o TTL default e os valores do SOA configurados.

Teste confirmatrio 1

Infelizmente, no existem testes especficos aplicativos a serem utilizados, por exemplo que definam com clareza quando o TTL default ou qualquer outro valor do registro SOA esto muito pequenos. Se voc est observando utilizao alta de CPU nos servidores DNS de uma zona verifique que processo est consumindo mais CPU. Se o maior consumidor de CPU for o servidor de nomes ou enlaces de longa distncia estiverem saturados, verifique o valor do TTL default e do tempo de refresh no servidor primrio. O TTL default, geralmente, varia entre algumas horas e alguns dias (menos que uma semana). Se voc observar um valor bem menor que uma hora, por exemplo, desconfie que esta a causa do problema. Aumente o valor do TTL default e verifique tambm os valores do SOA alterando-os para um valor mais adequado, se necessrio. Se com esta alterao os sintomas e sinais cessaram o problema foi confirmado. Se o valor do TTL default est adequado 12 horas, por exemplo a causa da lentido na rede outra.

Teste confirmatrio 2

Se aps modificar um registro que define o nome ou o endereo de um servidor foi observada indisponibilidade do servio oferecido por ele, o problema est praticamente confirmado. Verifique o valor do TTL default da zona a que o servidor pertence no servidor de nomes primrio desta zona. Se ele estiver muito grande uma semana, por exemplo o problema foi confirmado. Na realidade, sempre que modificaes em registros de servidores forem realizadas alguns cuidados devem ser tomados (ver Seo SUGESTES DE TRATAMENTO). Caso contrrio, o servio oferecido pelo servidor cujo nome/IP foi modificado ficar indisponvel durante um certo tempo, no mximo igual ao TTL default ou ao TTL explcito do registro modificado.

189

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.5.5 Sugestes de tratamento

Existem outros valores do registro SOA alm dos citados anteriormente que no devem ser esquecidos. A seguir dada uma breve descrio de cada um deles: Retry se o servidor secundrio no conseguir falar com o servidor primrio aps o intervalo de refresh, de quanto em quanto tempo ele ficar tentando falar com o servidor primrio para verificar se precisa ou no ser atualizado; Expirao quando o servidor secundrio no consegue falar com o primrio, por quanto tempo ele ainda considerar vlidas suas informaes e continuar oferecendo a clientes respostas relacionadas ao domnio. Como citado anteriormente, voc deve fazer uma escolha entre desempenho e consistncia. Mas, em [RFC1912, RFC2308, DNS&BIND] alguns valores tpicos so recomendados para o TTL default e demais campos do registro SOA: TTL default valores tpicos variam algumas horas e 5 dias. No entanto, voc deve escolher um valor condizente com a quantidade de atualizaes feitas no servidor de nomes. Valores maiores que 1 dia so menos freqentes. Na dvida, escolha um TTL default de 12 horas ou 1 dia; Refresh voc pode escolher um tempo pequeno (20 minutos a 2 horas) se voc no tem preocupao com um aumento de pesquisas no servidor primrio e da utilizao dos enlaces. Pode escolher um valor maior, quando conexes mais lentas e de longa distncia so utilizadas. No recomendado que se use um valor maior que 1 dia; Retry geralmente uma frao do tempo de refresh. Se o tempo de refresh for 2 horas, por exemplo, o tempo de retry pode ser 30 minutos. Expire 1 a 4 semanas so os valores sugeridos. Este valor deve ser maior que o maior tempo possvel de durao de uma falha em sua rede. Ele deve ser maior que o tempo de refresh, para evitar que os dados do servidor secundrio expirem antes dele ter a oportunidade de fazer uma nova cpia; TTL de respostas negativas valores entre 1 e 3 horas tm se mostrado razoveis. Valores maiores que 1 dia so problemticos. Se voc usa a implementao BIND do servio DNS, modifique o registro SOA e a diretiva TTL dos arquivos de configuraes de zonas. Configure neles valores mais adequados. Abaixo seguem valores tpicos:
$TTL 86400 @ IN ; 86400 Segundos (1 dia)4 SOA ns.exemplo.com.br. root.exemplo.com.br. ( 200201231 ; Serial 4h ; Refresh 4 Horas
190

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

1h 2w 2h)

; Retry 1 Hora ; Expire 2 Semanas ; TTL neg. 2 Horas

Para modificar valores do registro SOA no Windows 2000 escolha Iniciar > Programas > Ferramentas Administrativas > DNS. Expanda o servidor de nomes e clique com o boto direito do mouse sobre a zona cujo SOA voc deseja modificar. Escolha o item Propriedades. Escolha a tabela Start of Authority (SOA) e modifique os valores configurados para corrigir o problema. Ao modificar o TTL default e outros valores do registro SOA lembre-se de reiniciar o servidor DNS. No Linux isto pode ser feito com o comando kill:
# kill HUP <nmero do processo named>

Em geral, modificaes em registros que envolvem mquinas clientes so bem mais freqentes. O problema grave ocorre quando so realizadas modificaes em registros que envolvem servidores, por exemplo, mudar o endereo IP do servidor Web da empresa. Se o TTL for grande, outros servidores DNS podem utilizar o mapeamento nome endereo antigo armazenados em cache por muito tempo, impossibilitando aos clientes o acesso ao servio Web. Para resolver este problema lembre-se que os valores do TTL default e de TTLs explcitos no so imutveis. Voc pode escolher um valor adequado, mas pode modific-lo quando necessrio. A seguir vai uma dica do que fazer para no sofrer indisponibilidade de servios ao modificar algum registro que envolva definio de endereos de servidores: algum tempo antes de realizar a modificao do IP do servidor diminua o TTL default ou o TTL explcito dos registros que sero modificados. Com isso, garante-se que outros servidores DNS iro armazenar dados sobre seu domnio na cache por menos tempo, e percebero mais rapidamente as mudanas que ocorrerem. Alterar o TTL imediatamente antes de realizar a troca de IP no vale. Voc tem que diminuir o TTL com mais antecedncia. Pelo menos com uma antecedncia igual soma do intervalo de refresh e do TTL utilizados. Este tempo necessrio para que os dados de seu domnio armazenados na cache de outros servidores DNS expirem e eles consultem o seu servidor novamente. Os resultados das novas consultas j informao um TTL menor. Alm disso, os servidores secundrios tambm sero atualizados e passaro a fornecer um TTL pequeno. Suponha que voc precise mudar o endereo IP do servidor Web. Se seu TTL default 1 dia e o intervalo de refresh 2 horas, voc deve diminuir o TTL default ou o TTL explcito dos registros de nomes do servidor Web pelo menos 26 horas antes de realizar a troca do IP no servidor Web. Diminua o TTL default para o tempo mximo durante o qual o servio em questo pode ficar indisponvel. Altere o TTL para 30 minutos, por exemplo. Assim, ao alterar o IP do servidor Web o servio ser interrompido por no mximo 30 minutos.

191

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.6 Falta . aps nomes totalmente qualificados em registros DNS 7.6.1 Descrio
Leia mais sobre DNS no apndice 10

Todos os nodos na rvore de nomes de domnio podem ser identificados por um FQDN. Esta a abreviao de Fully Qualified Domain Name (nome de domnio totalmente qualificado). O nome mail.exemplo.com.br, por exemplo, um nome de mquina totalmente qualificado. Ele indica o caminho que deve ser percorrido desde a raiz da rvore de nomes de domnio at se chegar a ele. Nomes no totalmente qualificados so nomes relativos a algum nodo da rvore de nomes de domnio inferior raiz. Por exemplo, o nome de mquina mail. Este nome no interpretado com relao raiz, como os FQDNs, mas sim em relao a algum sub-domnio inferior a ela. Neste exemplo, este nome interpretado com relao ao nodo exemplo.com.br. Nos arquivos de zonas DNS os nomes de mquinas podem estar escritos em sua forma completa (FQDNs) ou no. Quando um nome termina com um . (ponto) o servidor considera que ele um FQDN. Caso contrrio o servidor DNS interpreta-o como sendo relativo zona sendo configurada. Neste caso o nome da zona adicionado automaticamente aps o nome configurado no arquivo. Suponha que voc est configurando o mapeamento direto do domnio exemplo.com.br. Voc deseja configurar o nome de um servidor Web, que www.exemplo.com.br. Uma das seguintes linhas deve ser inserida no seu arquivo de zonas:
www IN A 200.120.10.100

ou
www.exemplo.com.br. IN A 200.120.10.100

O nome www encontrado na primeira linha ser interpretado pelo servidor DNS como um nome relativo ao domnio exemplo.com.br. Suponha que voc resolveu utilizar em seus arquivos de zonas nomes completamente qualificados (a segunda linha descrita no exemplo anterior). No entanto, voc esqueceu de colocar o . No final do nome de uma mquina. A linha resultante foi:
www.exemplo.com.br IN A 200.120.10.100

Devido a este erro, o servidor de nomes nada saber sobre a mquina www.exemplo.com.br. Para ele, www.exemplo.com.br.exemplo.com.br o nome da mquina cujo endereo IP 200.120.10.100. Como conseqncia no ser possvel estabelecer uma conexo com o servidor Web atravs de seu nome. Quando o ponto esquecido na definio de nomes totalmente qualificados de servidores o problema mais grave, pois os servidores envolvidos no podero ser acessados pelo seu nome. Se o ponto for esquecido aps o nome do
192

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

servidor SMTP indicado em um registro MX, por exemplo, voc poder ter problemas com o servio de Correio Eletrnico. Um outro problema mais srio ocorre quando o ponto esquecido na definio de sub-domnios. Nenhum nome do sub-domnio envolvido no erro de configurao poder ser resolvido. Considere novamente o arquivo de configurao do domnio exemplo.com.br. O que acontece se o sub-domnio gerencia.exemplo.com.br for configurado da seguinte forma:
gerencia.exemplo.com.br server.gerencia.exemplo.com.br. IN IN NS A server.gerencia.exemplo.com.br. 200.120.11.53

O servidor DNS do domnio exemplo.com.br pode ser consultado a respeito de um nome do sub-domnio gerencia. No entanto, no exemplo acima o servidor DNS nada sabe sobre o sub-domnio gerencia.exemplo.com.br. O sub-domnio que ele conhece o gerencia.exemplo.com.br.exemplo.com.br. Neste caso, o mundo no saber como resolver nomes deste sub-domnio. Se o ponto tivesse sido esquecido ao definir quem o servidor de nomes do sub-domnio, como abaixo, o servidor DNS reconheceria o sub-domnio, mas no saberia informar o endereo IP do servidor DNS responsvel por ele.
gerencia.exemplo.com.br. IN NS A server.gerencia.exemplo.com.br 200.120.11.53 server.gerencia.exemplo.com.br. IN

Quando os nomes envolvidos identificam mquinas clientes, os usurios destas mquinas podem no conseguir acessar certos servios (ver problema DNS: DESCASAMENTO DE REGISTROS A E PTR EM ARQUIVOS DE ZONAS). O ponto pode ser esquecido em quaisquer registros dos arquivos de zonas. Sempre que voc escrever um FQDN e esquecer do ponto final, estar inserindo erros de configurao em seu servidor DNS, pois ele estar interpretando os dados de forma incorreta.

7.6.2 Sintomas
A reclamao geral ser indisponibilidade de servios. Como j citado, quando o ponto for esquecido aps um nome de servidor ou de um sub-domnio, o problema fica mais grave. Esquecer o ponto ao definir nomes e endereos de mquinas clientes nos arquivos levar aos mesmos sintomas apresentados no problema da pgina 175: o usurio da mquina envolvida reclamar que alguns servios no esto funcionando ou que precisam esperar algum tempo antes de ter conectividade com os servidores. Usurios de fora da organizao tambm podem reclamar quando o erro existir na configurao de zonas pblicas. Eles podem no conseguir acessar as pginas Web de seu site ou no conseguir enviar mensagens para usurios de sua organizao.

193

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.6.3 Sinais
Procedimento

12.6

Os sinais apresentados dependem de onde o ponto foi esquecido. Quando se esquece o ponto no fim de um FQDN em um registro IN A, o resultado ser que alguns nomes locais s podem ser resolvidos quando de acrescenta o nome do domnio duas vezes. Considerando o exemplo dado na Seo DESCRIO, o nome www poder ser resolvido quando se pergunta ao servidor quem www.exemplo.com.br.exemplo.com.br, mas no quando se pergunta quem www.exemplo.com.br. Se, por exemplo, o ponto foi esquecido em um registro IN PTR, o mapeamento reverso vai levar a um nome de mquina com o nome do domnio mais domnio in-addr.arpa. Por exemplo, o mapeamento reverso de 200.120.10.100 levar a www.exemplo.com.br.10.120.200.inaddr.arpa. Respostas incorretas tambm ser oferecidas quando o ponto for esquecido em registros MX e NS.

7.6.4 Testes confirmatrios

O sinal apresentado na seo anterior diferencial. Isto significa que se ele for encontrado o problema est confirmado.

7.6.5 Sugestes de tratamento

A soluo para este erro bastante simples e clara: acrescente o ponto onde ele foi esquecido ou passe a utilizar nomes relativos ao domnio (exceto no arquivo dede mapeamento reverso). A segunda opo bem mais interessante: alm de no correr o risco de esquecer o ponto, voc precisar escrever menos e poder mudar o nome do domnio sem precisar modificar muitas configuraes no servidor de nomes. No esquea de modificar o nmero de srie do arquivo modificado e de reinicializar o servio de nomes para que as novas configuraes tenham efeito. Nos arquivos de mapeamento reverso, a utilizao de nomes completos obrigatria. O domnio reverso default no o domnio da organizao, e sim um domnio do tipo x.in-addr.arpa. O domnio reverso default de um servidor que mapeia endereos da rede 200.120.10.0/24 10.120.200.in-addr.arpa. Portanto, se voc utilizar nomes relativos ao domnio default, os mapeamentos reversos levaro a nomes de mquinas do domnio x.in-addr.arpa. Se voc usa o servidor DNS do Windows 2000 e atualiza os dados de seu domnio atravs do Gerenciador DNS (Iniciar > Programas > Ferramentas Administrativas > DNS), problemas deste tipo ocorrero com menos freqncia. A interface grfica oferecida no deixa que o nome completo da mquina seja inserido, apenas o nome relativo zona sendo configurada. Os arquivos gerados pelo servidor usam sempre nomes relativos nos registros IN A e acrescenta automaticamente o nome do domnio direto nos registros IN PTR. Se voc est modificando os arquivos de zonas manualmente, a probabilidade de erro maior.

194

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

Sempre que adicionar ou modificar algum registro em arquivos de zonas lembre-se de testar a modificao. Por exemplo, suponha que voc adicionou mais um servidor Web (www1.exemplo.com.br) nos arquivos de zona. Imediatamente aps reiniciar o servio DNS, teste-o:
root# nslookup > www1 Server: Address: Name: 200.120.10.53 200.120.10.53#53

www1.exemplo.com.br

Address: 200.120.10.101 > 200.120.10.101 Server: Address: 200.120.10.53 200.120.10.53#53 name = www1.exemplo.com.br.

101.10.120.200.in-addr.arpa

Este teste comprova que as modificaes realizadas foram corretas e que o servidor j as reconhece.

7.7 Filtro IP barrando trfego DNS 7.7.1 Descrio

Leia mais sobre DNS no apndice 10

Se existir um filtro IP barrando o trfego DNS em sua organizao voc enfrentar srios problemas. Um filtro pode estar barrando o trfego entre seu servidor DNS e os clientes DNS deste servidor, entre servidor primrio e servidores secundrios ou entre servidores DNS internos de sua organizao e servidores DNS que no pertencem a sua organizao. O primeiro caso bastante raro, pois no comum que exista um filtro IP entre os clientes DNS e o servidor destes clientes. Mas, se existir e no estiver permitindo a passagem do trfego DNS, o resultado drstico: os clientes DNS no conseguiro se comunicar com o servidor e nenhum nome ser resolvido para os clientes. Servidores secundrios precisam se comunicar com os servidores primrios de tempos em tempos em busca de modificaes nos arquivos de zonas. Se modificaes foram realizadas no servidor primrio, uma transferncia das zonas modificadas feita. Alm disso, alguns servidores DNS esto configurados para notificar os servidores secundrios quando modificaes em zonas forem realizadas. Se um filtro IP barra a comunicao entre servidores primrio e secundrios, os servidores secundrios no conseguiro se comunicar com o primrio e aps algum tempo deixaro de ter autoridade para resolver nomes do domnio que no pode ser atualizado, at que a comunicao seja novamente possvel. Por fim, possvel que exista um filtro IP mal configurado barrando o trfego entre servidores internos da organizao e servidores de outras organizaes. A
195

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

conseqncia ser que nomes no locais nunca podero ser resolvidos pelo servidor de nomes da organizao. Em muitas organizaes, a arquitetura DNS apresentada na Figura 7-2 empregada. Nesta arquitetura existe um servidor DNS externo, responsvel pela resoluo dos nomes pblicos da organizao e um servidor DNS interno. As mquinas clientes da organizao usam o servidor DNS interno, que est protegido por um firewall. Nenhum servidor DNS fora da organizao precisa consultar o servidor DNS interno. No entanto, o servidor DNS interno precisa se comunicar com o servidor DNS externo para resolver nomes para seus clientes DNS. Este um exemplo em que existe um filtro IP entre servidores DNS.

Figura 7-2: Arquitetura DNS de separao de funo.

O servio DNS usa as portas TCP/53 e UDP/53. A maioria das pesquisas feitas por clientes destinada porta UDP/53 do servidor DNS. No entanto, mensagens UDP so restritas a um tamanho de 512 bytes. Portanto, pesquisas cujas respostas so maiores que este tamanho so novamente realizadas via o protocolo TCP [RFC1035, RFC2181]. Alm disso, transferncias de zonas so feitas utilizando o protocolo TCP, que confivel. Desta forma, no basta permitir apenas a passagem de trfego UDP/53 para os servidores DNS. preciso tambm permitir o trfego TCP/53. Nas verses mais antigas do BIND (anteriores a 8.1) um servidor de nomes de domnio sempre usava a porta de sada UDP 53 para consultar outros servidores. No entanto, a partir desta verso, uma porta entre 1024 e 65535 escolhida randomicamente pelo servidor DNS. Se um filtro IP estiver configurado para aceitar consultas externas apenas se a origem estiver na porta UDP (ou TCP) 53, o trfego entre servidores de nomes vai ser barrado.

7.7.2 Sintomas
Se o filtro IP no permite a comunicao entre o servidor DNS da organizao e outros servidores DNS (inclusive o servidor externo), a resoluo de nomes no locais no ser possvel. Os usurios reclamaro que no conseguem acessar qualquer servio fora da organizao. Provavelmente reclamaro que no conseguem acessar pginas na Internet e no conseguem receber nem enviar mensagens de/para usurios externos. O navegador vai informar ao
196

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

usurio um erro de DNS. No Internet Explorer, por exemplo, aps algum tempo, uma pgina de erro apresentada, contendo mensagens como: No possvel encontrar <nome-da-maquina> ou A pgina no
pode ser exibida () No possvel servidor ou ocorreu um erro de DNS. encontrar o

Quando o trfego DNS entre o servidor primrio e os secundrios barrado (por exemplo o trfego TCP/53 no permitido entre eles) os servidores secundrios ficaro desatualizados e aps um certo tempo (expirao) no mais respondero pelo domnio. Os clientes DNS destes servidores ficaro sem resoluo de nomes e reclamaro que a rede no est funcionando, j que a maioria dos servios acessada atravs do nome do servidor. O mesmo ocorre quando o trfego DNS barrado entre o servidor DNS e os clientes DNS. O navegador dos usurios informar o erro de DNS. Se o filtro estiver barrando o trfego do servidor DNS que resolve nomes pblicos da organizao, usurios externos se queixaro de no conseguir acessar os servios de sua organizao: enviar e-mails, por exemplo.

7.7.3 Sinais
Procedimento

12.4
Procedimento

Consultas DNS sem resposta. Duas situaes podem ocorrer: 1) a prpria consulta barrada por um filtro IP e no chegar at o servidor DNS destino ou 2) a resposta dada no passa pelo filtro IP, no podendo chegar at o cliente ou servidor que solicitou a consulta.

12.3
Procedimento

A resoluo de nomes externos no funciona. Este pode ser um sinal de que o trfego DNS entre seu servidor de nomes e servidores de nomes de outras organizaes (ou at mesmo o servidor de nomes externo da organizao) est sendo barrado por um filtro IP.
Nos servidores secundrios mensagens no arquivo de logs indicam que no foi possvel a comunicao com o servidor principal. Este pode ser um

12.2

sinal de que o trfego entre servidores secundrios e principais est sendo barrado por um filtro IP.

7.7.4 Testes confirmatrios

Este problema causa os mesmos sinais do problema O SERVIO DE NOMES NO EST HABILITADO. Antes de realizar o teste a seguir, certifique-se de que o servidor de nomes est em execuo. Isto pode ser feito como descrito nos testes confirmatrios da pgina 171 ou pode ser feito simplesmente com o comando a seguir:
# telnet <IP do servidor DNS> 53

Se o servidor DNS responder, ele est em execuo.

RESUMO

DOS

TES TES

197

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

E S T E

Localize os filtros IP da organizao localizados entre servidores DNS e verifique se eles permitem a passagem do trfego DNS;

Teste confirmatrio 1

Se existirem filtros IP entre os servidores de nomes de sua organizao ou entre eles e servidores DNS fora da organizao, verifique a configurao do filtro. As regras que devero estar contidas no filtro IP sendo analisado dependem de onde o filtro se localiza. Ele est entre o servidor de nomes interno e o externo? Entre o servidor primrio e secundrios? Voc precisa conhecer o trfego DNS que dever passar pelo filtro e analisar se as regras de filtragem esto corretas. Lembre-se que servidores DNS mais novos usam uma porta no bem conhecida (entre 1024 e 65535) para realizar consultas em outros servidores, enquanto os mais antigos usam a porta de sada UDP/53. Considere ainda que, algumas consultas que geram respostas maiores que 512 bytes se tornam consultas TCP. Se voc perceber que no permitida a passagem do trfego para a porta TCP/53 ou UDP/53 de servidores ou desta porta para portas no bem conhecidas de clientes ou outros servidores, o problema foi confirmado. Considere novamente o exemplo apresentado na Figura 7-2. Voc percebeu que os servidores de nomes internos no conseguem resolver nomes no locais. Voc resolveu analisar as regras do filtro IP no firewall e percebeu que a passagem do trfego com destino porta UDP/53 no est sendo permitida. Resultado: os servidores DNS internos no conseguem se comunicar com os servidores de nomes externos para resolver nomes no locais. Para verificar as regras de filtragem em um ambiente Linux usando ipchains ou iptables use um dos seguintes comandos:
# ipchains L n | more # iptables L n | more

Em um roteador Cisco com listas de acesso configuradas use o comando:

roteador# show access-list

198

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.7.5 Sugestes de tratamento

Se o problema foi confirmado, corrija as regras de filtragem do firewall. Lembrese que tanto o trfego TCP/53 quando UDP/53 devem ser permitidos. Analise que tipo de trfego DNS vai atravessar o filtro IP (entre servidor primrio e secundrios, entre servidores interno e externos, entre servidores e clientes) e reajuste as regras do filtro para corrigir o problema. mais comum que o firewall barre o trfego entre servidores internos e servidores externos (que no esto sob sua administrao), ou que voc esquea de permitir a passagem do trfego TCP/53. Abaixo so ilustradas estas situaes mais comuns de ocorrncia deste problema e como solucion-las: 1. filtro IP s permite a passagem de trfego DNS quando a porta origem e a porta destino so UDP/53 (ou TCP/53). Voc atualizou a verso do BIND dos servidores DNS e agora eles usam portas no bem conhecidas (isto , maiores que 1023) para consultar outros servidores. O trfego entre os servidores da organizao e servidores fora dela ser barrado. a) opo 1: configure o servidor de nomes para novamente usar apenas a porta fonte 53 ao consultar outros servidores. Para tal adicione a opo em destaque a seguir nos servidores de nomes da sua organizao:
options { directory "/var/named"; query-source address * port 53; };

Com esta opo o servidor de nomes passa a novamente usar a porta origem 53 ao consultar outros servidores. Note que esta soluo especfica da implementao BIND. b) opo 2: reconfigure as regras do filtro IP para permitir a comunicao entre servidores DNS internos, porta UDP(TCP)/1024-65535 e servidores externos porta UDP(TCP)/53. Em um filtro IP Linux que usa ipchains adicione as seguintes regras:
DNS = 192.168.1.53 # endereo IP de um servidor DNS any = 0.0.0.0/0.0.0.0 ipchains -A forward -s $DNS 1024-65535 -d $any 53 -p tcp \ -j ACCEPT ipchains -A forward -s $DNS 1024-65535 -d $any 53 -p udp \ -j ACCEPT ipchains -A forward -s $any 53 -d $DNS 1024-65535 -p tcp \ -j ACCEPT ipchains -A forward -s $any 53 -d $DNS 1024-65535 -p udp \ -j ACCEPT

Em um filtro IP Linux que usa iptables as regras so as seguintes:

DNS = 192.168.1.53 # endereo IP de um servidor DNS any = 0.0.0.0/0.0.0.0 iptables -A FORWARD -p tcp -s $any sport 53 -d $DNS \ --dport 1024:65535 -j ACCEPT

199

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

iptables -A FORWARD -p tcp -s $any sport 53 -d $DNS \ --dport 1024:65535 -j ACCEPT iptables -A FORWARD -p tcp -s $DNS sport 1024:65535 -d \ $any --dport 53 -j ACCEPT iptables -A FORWARD -p udp -s $DNS sport 1024:65535 -d \ $any --dport 53 -j ACCEPT

As regras descritas acima devem ser definidas para cada um dos servidores internos, no apenas para o servidor cujo IP DNS. Elas devem substituir a antiga regra que permitia a passagem de trfego quando as portas fonte e destino eram 53. Se o filtro est configurado em um roteador Cisco substitua as antigas regras pelas regras a seguir na lista de acesso adequada:
access-list access-list access-list access-list 102 102 102 102 permit permit permit permit tcp udp tcp udp <DNS1> <DNS1> any eq any eq gt 1023 any eq domain gt 1023 any eq domain domain <DNS1> gt 1023 domain <DNS1> gt 1023

Onde: 102 o exemplo o nmero da lista de acesso sendo configurada. No seu caso use o nmero da sua lista de acesso. Listas de acesso estendidas (como as apresentadas) so identificadas por nmeros entre 100 e 199 ou entre 2000 e 2699; <DNS1> deve ser substitudo pelo endereo IP de um servidor de nomes interno. As regras apresentadas devem existir para todos os servidores de nomes internos. As regras apresentadas acima so aplicveis em um firewall que separe os servidores internos da organizao (que servem aos clientes DNS locais) dos servidores DNS externos (que respondem pelos nomes pblicos). Caso voc no esteja utilizando esta arquitetura DNS, adicione tambm regras que permitam que servidores DNS fora da organizao consultem seus servidores DNS. Neste caso, seus servidores que estaro utilizando a porta 53 e os demais uma porta no conhecida ou a porta 53 (protocolos UDP ou TCP). c) opo 3: adquira um firewall que conhea protocolos de camada de aplicao. Este firewall pode ser configurado para permitir a passagem de mensagens para o servidor de nomes apenas se os dados contidos nas mensagens so do protocolo DNS. Exemplo de um firewall que conhece protocolos de aplicao o FireWall-1 da Checkpoint. 2. Voc acabou de configurar o filtro IP e esqueceu de adicionar a regra para permitir a passagem do trfego TCP/53. Adicione a regra para permitir a passagem deste trfego. Os comandos a serem executados so bastante semelhantes aos comandos apresentados na opo 2 de soluo da situao anterior.

200

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.8 Servidor de correio eletrnico com repasse totalmente aberto 7.8.1 Descrio
Leia mais sobre o servio de correio eletrnico no apndice 11

Diz-se que um servidor SMTP (Simple Mail Transfer Protocol) est com repasse (relay) aberto (tambm chamado third-party relay e relay inseguro) quando ele aceita transmitir uma mensagem de qualquer remetente na Internet para qualquer destinatrio na Internet. Um servidor SMTP s deve aceitar transmitir um e-mail para um destino nas duas seguintes situaes: o destino um usurio de um domnio para o qual o servidor est configurado para oferecer o servio SMTP. Por exemplo, o servidor mail.exemplo.com.br est provavelmente configurado para fazer entregas de mensagens a usurios do domnio exemplo.com.br, como por exemplo, maria@exemplo.com.br; o endereo IP do cliente que enviou a mensagem (independente dos destinatrios) faz parte da faixa de endereos configurados como clientes SMTP do servidor. Servidores de correio com repasse aberto so geralmente explorados por spammers pessoas que enviam e-mails no solicitados em grande quantidade. Por que spammers usam servidores SMTP com repasse aberto [MAPS-TSI]? Porque ao usar um servidor de correio com repasse inseguro o spammer pode enviar quantas mensagens quiser, para quaisquer destinatrios, sem custos e no completo anonimato. A organizao que possui um servidor SMTP com repasse aberto bastante prejudicada: ela tem seus recursos computacionais e de rede roubados e, alm disso, o nome dela que aparece nas mensagens-lixo enviadas pelos spammers. Servidores SMTP com repasse aberto podem ser denunciados a organizaes que lutam contra o spam. Nestas organizaes existem bancos de dados onde so cadastrados os servidores que, comprovadamente, esto com repasse aberto. O MAPS (Mail Abuse Prevention System), por exemplo, uma organizao sem fins lucrativos cujo principal objetivo defender o sistema de correio eletrnico da Internet de spammers [MAPS]. O MAPS Relay Spam Stopper (RSS) [MAPS-RSS] uma base de dados baseada em nomes de domnio DNS onde esto listados servidores com repasse aberto. No Brasil no existe um rgo que regulamente ou puna sites com repasse aberto [ANTISPAM-BR]. No entanto, servidores brasileiros podem perfeitamente ser cadastrados em listas negras internacionais, como o MAPS RSS, por exemplo. A tendncia atual que cada vez mais cada organizao se proteja de spammers no possuindo servidores SMTP com repasse aberto e no aceitando e-mails de servidores SMTP abusivos. Os servidores de correio eletrnico podem ser configurados para consultar bancos de dados de servidores com repasse inseguro e no aceitar mensagens vindas de servidores que esto nestas listas negras. Com isso, mensagens vindas de um site abusivo sero sempre barradas, tenham sido elas enviadas ou no por spammers. Percebe o que ocorrer se seu
201

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

servidor SMTP estiver cadastrado em uma base de dados de repasses abertos? Usurios de organizaes que usam esta base de dados no recebero mensagens de usurios de sua organizao.

7.8.2 Sintomas
usurios locais reclamaro que no conseguem enviar mensagens para certos destinos (usurios cujo servidor SMTP esto configurados para consultar as

Se seu site for cadastrado em bases de dados de repasses abertos os

listas negras de repasse aberto onde o seu servidor est cadastrado). Alm disso, as mensagens enviadas podem retornar para os remetentes com mensagens de
erro que indicam que o seu servidor SMTP est cadastrado em uma lista negra antispam.

Por exemplo, considere que o servidor mail.exemplo.com.br est cadastrado no MAPS RSS. Considere tambm que o servidor mail.cisco.com est configurado para consultar a base de dados MAPS RSS e no aceitar mensagens dos servidores que esto listados nela como inseguros. Os e-mails enviados de maria@exemplo.com.br para cris@cisco.com no sero entregues a Cris. Alm disso, o servidor SMTP da Cisco devolver a Maria a mensagem que ela transmitiu anexada a uma mensagem de erro do MAPS RSS. No contedo deste e-mail haver um link para a pgina http://work-rss.mailabuse.org/rss/enduser.html. O administrador da rede receber por e-mail avisos de outras organizaes ou de organizaes que lutam contra spam alertando-o sobre repasse aberto. Em geral essas mensagens so destinadas a postmaster@domnio ou abuse@domnio.

7.8.3 Sinais
Procedimento O servidor SMTP aceita fazer a entrega de mensagens sempre,

12.8

mesmo quando o endereo IP do cliente SMTP que solicitou a entrega da mensagem no da rede interna e o destinatrio no um usurio local. Considere o servidor SMTP mail.exemplo.com.br. Ele deveria aceitar apensa fazer entregas solicitadas por clientes da rede local (192.168.1.0/24) ou entregas de mensagens destinadas a usurios da rede local (maria@exemplo.com.br, por exemplo). Se mail.exemplo.com.br aceitar entregar um e-mail para um cliente na mquina 200.120.1.2 para cris@cisco.com, certamente, o servidor SMTP em questo est com repasse aberto.

7.8.4 Testes confirmatrios

O sinal apresentado na seo anterior confirmatrio, no sendo necessrios outros testes adicionais.

202

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.8.5 Sugestes de tratamento

Para corrigir o problema o servidor SMTP com repasse aberto dever ser atualizado para uma verso mais segura, ou deve ter sua configurao alterada para tornar-se um servidor com repasse seguro. As implementaes mais novas do sendmail (v8.9 e superior), assim como a implementao qmail do servio SMTP negam repassar qualquer mensagem por default. Isto lhe obriga a configurar corretamente o servidor para aceitar repassar as mensagens de/para usurios locais, isto , configurar o repasse seletivo. A melhor sugesto para corrigir este problema atualizar o seu servidor SMTP para a verso mais nova possvel e configur-lo corretamente com repasse seletivo (ver Seo SUGESTES DE TRATAMENTO do problema SERVIDOR DE CORREIO ELETRNICO COM REPASSE TOTALMENTE FECHADO (pgina 205). Se a atualizao no for possvel voc ter que alterar algumas configuraes do servidor SMTP para torn-lo seguro. Em [MAPS-TSI-FIX] encontram-se informaes sobre como proceder para resolver o problema de repasse aberto em diversas implementaes do servidor SMTP. Verifique qual a implementao e verso do seu servidor SMTP e proceda como descrito neste documento. Ao receber mensagens que denunciam servidores SMTP sob sua administrao de estarem com repasse aberto aja imediatamente: teste se o servidor est realmente com este problema e, sendo ele confirmado, corrija-o o mais rapidamente possvel. No espere entrar em uma lista negra ou comear a receber mais de 10 reclamaes por dia para comear a agir. Alm do MAPS, existem outras organizaes que lutam contra spam. Dentre elas encontram-se: ORDB (Open Relay DataBase), Osirusoft (OsiruSofts Open Relay Spam Stopper) e Fabel (Fabel - bne mail relays). Ao fechar um repasse aberto, verifique nas listas destas organizaes se o seu servidor est cadastrado como repasse aberto. Se estiver notifique-as da correo para que o seu servidor seja removido dos bancos de dados de servidores SMTP com repasse aberto. Aps a notificao o seu servidor vai ser testado por cada organizao onde ele estava cadastrado e s ser retirado da lista negra se os testes indicarem que ele no mais est com repasse aberto. O SpamCop.net e Network Abuse Clearinghouse so organizaes que oferecem servios de reportagem de servidores SMTP com repasse aberto. interessante que voc cadastre seu endereo nestas organizaes, para que reclamaes sobre servidores em seu domnio sejam enviadas ao endereo correto. Se voc receber mensagens no solicitadas pode usar estas organizaes para denunciar o servidor que permitiu o envio destas mensagens.

203

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.9 Servidor de correio eletrnico com repasse totalmente fechado 7.9.1 Descrio
Leia mais sobre o servio de correio eletrnico no apndice 11

Com o intuito de diminuir a quantidade de spam enviado por servidores SMTP com repasse (relay) totalmente aberto, as novas implementaes do servio SMTP vm, por default, com repasse totalmente fechado. O servidor s aceita transmitir mensagens de um usurio que esteja usando a mquina onde o servidor est instalado (o localhost). Alguns servidores ainda permitem que mensagens para usurios locais sejam enviadas, outros no. A implementao qmail, desde suas verses mais antigas, j vem negando o repasse por default. As verses 8.9 e superiores do sendmail, uma das implementaes mais usadas do servio SMTP, tambm j apresentam este comportamento por default. Se voc vai atualizar a verso do seu servidor SMTP ou vai passar a utilizar outra implementao fique atento a este fato. S coloque a nova verso em funcionamento quando tiver certeza absoluta de que o servidor no ir negar transmitir mensagens enviadas por ou destinadas aos prprios usurios locais.

7.9.2 Sintomas
Os usurios no podero enviar e-mails, exceto se estiverem na mquina onde o servidor SMTP est instalado. Como os usurios usaro outras mquinas, eles reclamaro que no conseguem enviar mensagens, sejam elas locais ou no. Alguns servidores, por default, aceitam enviar mensagens destinadas a usurios locais, outros no. Mas, nenhum deles transmitir mensagens destinadas a usurios no locais. No cliente SMTP mensagens de erro sero apresentadas aos usurios. No Outlook Express da Microsoft, por exemplo, a seguinte mensagem ser passada: A mensagem no pde ser enviada porque um de seus destinatrios foi recusado pelo servidor.

7.9.3 Sinais
Procedimento

12.7

O servidor SMTP no aceita enviar mensagens destinadas a usurios no locais, exceto para clientes usando a prpria mquina onde o servio est

instalado. Ao tentar usar o servio de qualquer outra mquina voc observar o erro que indica repasse denied.

7.9.4 Testes confirmatrios

O sinal apresentado na seo anterior confirmatrio. Se ele for observado nenhum teste adicional precisa ser realizado.
204

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

7.9.5 Sugestes de tratamento

A configurao de repasse seletivo depende da implementao do servio SMTP em uso. A seguir sero dadas dicas de como corrigir o problema em implementaes sendmail e qmail. No sendmail verses 8.8 e superiores, adicione o nome ou o IP das mquinas que podem ser clientes do servidor SMTP no arquivo /etc/mail/relaydomains. Informaes sobre outras configuraes encontram-se em [CONTROLLED-SMTP-RELAYING]. Por exemplo, suponha que voc deseja que todos os usurios da rede 192.168.1.0/24 possam usar o servidor SMTP. Ento, insira a seguinte linha no arquivo relay-domains:
192.168.1

Em seguida reinicie o sendmail. Apenas as verses 8.7 e superiores aceitam o sinal HUP.
# killall HUP sendmail

Ou, para os sistemas que no suportam o comando killall:

# kill -HUP <nmero do processo do sendmail53>

O qmail s aceita mensagens destinadas a mquinas listadas no arquivo /var/qmail/control/rcpthosts. Quando terminamos de instalar o qmail, este arquivo contm o nome da mquina local. Se o arquivo rcpthosts no existir, o qmail vai passar a ser repasse aberto. Para ser mais seletivo realize os passos a seguir: 1. voc precisar usar um TCP wrapper (inetd ou tcpserver, por exemplo). Se voc usa o inetd, a primeira ao modificar a linha correspondente ao servio SMTP (iniciada com smtp) no arquivo de configurao do inetd (/etc/inetd.conf). A nova linha deve ser a seguinte:
smtp stream tcp nowait qmaild /usr/local/bin/tcpd /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd

A linha foi quebrada acima em duas, mas no arquivo inetd.conf tudo isso deve ficar em apenas uma linha. 2. reinicie o servio inetd:
# kill HUP <nmero do processo inetd>

3. por fim, insira as seguintes linhas no arquivo /etc/hosts.allow:

tcp-env: 192.168.1. : setenv = RELAYCLIENT tcp-env: 0.0.0.0

A primeira linha configura a varivel de ambiente RELAYCLIENT com um valor nulo para os clientes SMTP cujo endereo pertence rede 192.168.1.0/24. Quando esta varivel existe o arquivo rcpthosts ignorado. Com isto, clientes

53

Pode ser obtido com o comando # ps ae | grep sendmail.

205

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

nestas mquinas podem usar o servio SMTP para enviar mensagens para quaisquer destinos. A segunda linha permite que o servio seja acessado por outros usurios que no pertencem rede local (outros servidores de correio eletrnico, por exemplo), mas neste caso apenas mensagens destinadas a usurios dos domnios cadastrados como locais sero transmitidas. Estas configuraes so explicadas na FAQ do servidor qmail [QMAIL-FAQ]. Consulte-as para saber como proceder quando o tcpserver estiver sendo usado. Nunca atualize e ponha no ar uma nova verso ou nova implementao do servio SMTP sem antes ter lido algo sobre ela. Descubra se ela vem, por default, com repasse totalmente aberto ou totalmente fechado. Qualquer que seja o comportamento do servidor, voc ter que modific-lo. Certamente, voc no quer um servidor que se nega a enviar mensagens sempre, e tambm no quer um que envie mensagens de quaisquer remetentes para quaisquer destinatrios. Em geral, voc quer configurar um repasse seletivo: o servidor aceita enviar mensagens externas apenas para clientes em determinadas mquinas. Se voc estiver com dvidas sobre a nova verso ou a nova implementao, teste o novo servidor em uma mquina de testes. Organize os passos que devem ser seguidos at que ele se comporte como voc deseja. O servio SMTP importante, to importante quanto (ou mais importante) o servio Web. No corra o risco de interromp-lo, exceto se estritamente necessrio o servidor foi invadido, por exemplo.

7.10 Referncias 7.10.1 Livros

[DNS&BIND] Albitz, P. Liu, C. DNS and BIND. Quarta Edio. OReilly. Abril, 2001.

7.10.2 Recursos online (Internet)

[ANTISPAM-BR] Como denunciar e reclamar? http://www.antispam.org.br/denunciar.html [CONTROLLEDSMTP-RELAYING] [MAPS] Allowing controlled SMTP relaying in Sendmail 8.9. http://www.sendmail.org/tips/relaying.html. Site do Mail Abuse Prevention System (MAPS). http://www.mail-abuse.org/ [MAPS-RSS] Site do MAPSSM Relay Spam Stopper (RSS).
206

C A P T U L O

P R O B L E M A S

D E

N V E L

D E

A P L I C A O

http://work-rss.mail-abuse.org/rss/index.html [MAPS-TSI] Rosenthal, C. What is Third-Party Mail Relay? http://mail-abuse.org/tsi/ar-what.html [MAPS-TSI-FIX] Rosenthal, C., Falk, J. D. How Can I Fix the Problem? http://mail-abuse.org/tsi/ar-fix.html. [QMAIL-FAQ] FAQ do servidor SMTP qmail. http://www.qmail.org/qmail-manualhtml/misc/FAQ.html

7.10.3 RFCs
[RFC1035] [RFC1912] [RFC2181] [RFC2308] Mockapetris, V. Domain names - implementation and specification. Novembro, 1987. Barr, D. Common DNS Operational and Configuration Errors. Fevereiro, 1996. Bush, R., Elz, R. Clarifications to the DNS Specification. Julho, 1997. Andrews, M. Negative Caching of DNS Queries. Maro, 1998.

7.10.4 Livros base

[DNS-WIN-2000] [SENDMAIL] Larson, M., Liu, C. DNS on Windows 2000. Segunda edio. OReilly. Setembro, 2001. Costales, B. Allman, E. Sendmail. Segunda Edio. OReilly. Janeiro, 1997.

207

Captulo

8 Os ndices Invertidos

Neste captulo apresentamos dois ndices invertidos: o ndice invertido de sintomas e o ndice invertido de sintomas e sinais. Estes ndices podem lhe ajudar a criar sua lista de hipteses (ver Seo 3.4 DESENVOLVA HIPTESES na pgina 36).

8.1 ndice invertido de sintomas

O ndice invertido de sintomas leva em considerao apenas os sintomas de um problema. Ele interessante quando voc no consegue coletar sinais de um problema. O ndice invertido de sintomas apresentado na Tabela 8-1.
Sintoma: Rede lenta

Cabo rompido ou danificado Conector defeituoso ou mal instalado Descasamento de modo de operao Equipamento de interconexo defeituoso Saturao de banda em segmentos Ethernet compartilhados Placa de rede ou porta de equipamento de interconexo defeituosos Violao de regras de cabeamento Ethernet Tipo errado de cabo Interferncia no cabo Saturao de recursos devido a excesso de quadros de difuso Tempo de envelhecimento de tabelas de endereos inadequado Validade da cache ARP inadequada VLANs no esto configuradas Trfego RIP saturando largura de banda TTL e outros campos do registro SOA com valores inadequados
Sintoma: Falta de conectividade54

54 A falta de conectividade pode ser completa ou seletiva. No ltimo caso, os usurios podem sentir falta de conectividade apenas para alguns servidores, o que ser traduzido por eles como indisponibilidade de alguns servios. Portanto, se os usurios reclamarem de indisponibilidade de alguns servios, acrescente a sua lista os problemas cujo sintoma falta de conectividade.

208

C A P T U L O

N D I C E S

I N V E R T I D O S

Cabo rompido ou danificado Descasamento de modo ou velocidade de operao Equipamento de interconexo defeituoso Placa de rede ou porta de equipamento de interconexo defeituosos Conector defeituoso ou mal instalado Tipo errado de cabo Interface desabilitada Problema com rvore de cobertura Saturao de recursos devido a excesso de quadros de difuso Validade da cache ARP inadequada Endereo IP de hospedeiro incorreto Hospedeiro com mscara de rede incorreta Servidor DHCP mal configurado Rotas estticas mal configuradas (em roteadores) Equipamento inserido em VLAN incorreta VLANs no esto configuradas Comutadores no conseguem trocar informaes sobre VLANs entre si Ambiente RIP-1 com VLSM e/ou redes no contguas Dimetro RIP muito grande Roteadores RIP2 no enviam ou recebem pacotes RIP1 Filtro IP no permite a passagem de trfego RIP (UDP 520) O servio de nomes no est habilitado O TTL default de uma zona no est configurado Filtro IP barrando trfego DNS
Sintoma: Conectividade intermitente

Conector defeituoso ou mal instalado Tempo de envelhecimento de tabelas de endereos inadequado Endereo IP de hospedeiro incorreto Servidor DHCP mal configurado
Sintoma: Falta de conectividade com algumas mquinas da rede local

O TTL default de uma zona no est configurado

Sintoma: Indisponibilidade de alguns servios

Equipamento inserido em VLAN incorreta VLANs no esto configuradas Comutadores no conseguem trocar informaes sobre VLANs entre si O nmero de srie no foi aumentado TTL e outros campos do registro SOA com valores inadequados Descasamento de registros A e PTR em arquivos de zonas DNS Falta . aps nomes totalmente qualificados em registros DNS
Sintoma: Precisa esperar algum tempo para que a conexo com o servidor seja

209

C A P T U L O

N D I C E S

I N V E R T I D O S

estabelecida Descasamento de registros A e PTR em arquivos de zonas DNS

Sintoma: No consegue enviar e-mails

Servidor de correio eletrnico com repasse totalmente fechado

Sintoma: No consegue enviar e-mails para certos destinos

Servidor de correio eletrnico com repasse totalmente aberto Tabela 8-1: ndice invertido de sintomas.

8.2 ndice invertido de sintomas e sinais

Na Tabela 8-2 apresentamos o ndice invertido de sintomas e sinais de problemas.
Sintoma: Rede lenta Sinais: Taxa elevada de erros

Cabo rompido ou danificado Descasamento de modo e/ou velocidade de operao Interferncia no cabo Conector defeituoso ou mal instalado Placa de rede ou porta de equipamento de interconexo defeituosas Tipo errado de cabo
Sintoma: Falta de conectividade Sinais: Taxa elevada de erros

Cabo rompido ou danificado Conector defeituoso ou mal instalado Placa de rede ou porta de equipamento de interconexo defeituosas Tipo errado de cabo
Sintoma: Conectividade intermitente Sinais: Taxa elevada de erros

Interferncia o cabo Conector defeituoso ou mal instalado

Sintoma: Rede lenta Sinais:

Taxa elevada de erros Taxa elevada de colises

Descasamento de modo e/ou velocidade de operao Placa de rede ou porta de equipamento de interconexo defeituosas Conector defeituoso ou mal instalado
Sintoma: Falta de conectividade Sinais:

Taxa elevada de erros 210

C A P T U L O

N D I C E S

I N V E R T I D O S

Taxa elevada de colises Placa de rede ou porta de equipamento de interconexo defeituosas Conector defeituoso ou mal instalado
Sintoma: Rede lenta Sinais:

Taxa elevada de erros Taxa elevada de colises Ocorrncia de colises tardias

Descasamento de modo e/ou velocidade de operao Placa de rede ou porta de equipamento de interconexo defeituosos
Sintoma: Rede lenta ou falta de conectividade Sinais:

Equipamento no operacional Interfaces no operacionais Utilizao de memria elevada Utilizao de CPU elevada Trfego de broadcast/multicast elevado

Equipamento de interconexo defeituoso

Sintoma: Rede lenta Sinais:

Taxa de colises elevada Utilizao de enlaces elevada

Saturao de banda em segmentos Ethernet compartilhados

Sintoma: Rede lenta ou falta de conectividade Sinais:

Taxa elevada de erros Taxa de colises elevada Ocorrncia de colises tardias Quadros muito longos Trfego elevado de broadcast/multicast Aumento da utilizao de enlaces

Placa de rede ou porta de equipamento de interconexo defeituosas

Sintoma: Falta de conectividade, rede lenta ou conectividade intermitente Sinais:

Nmero elevado de erros Taxa elevada de colises NEXT e atenuao

Conector defeituoso ou mal instalado

Sintoma: Rede lenta Sinais:

Taxa elevada de colises Ocorrncia de colises tardias Atenuao

Violao de regras de cabeamento Ethernet

Sintoma: Rede lenta

211

C A P T U L O

N D I C E S

I N V E R T I D O S

Sinais:

Taxa elevada de colises Ocorrncia de colises tardias

Violao de regras de cabeamento Ethernet Placa de rede ou porta de equipamento de interconexo defeituosas Descasamento de modo e/ou velocidade de operao
Sintoma: Falta de conectividade Sinais:

Inexistncia de trfego Estado administrativo down

Interface desabilitada
Sintoma: Falta de conectividade Sinais:

Utilizao elevada de CPU Tempestade de enchente Tempestade de quadros de difuso Taxa elevada de colises Utilizao elevada de enlaces

Problema com rvore de cobertura Saturao de recursos devido a excesso de quadros de difuso
Sintoma: Rede lenta ou falta de conectividade Sinais:

Trfego de broadcast elevado Aumento da utilizao de enlaces Utilizao elevada de CPU

Saturao de recursos devido a excesso de quadros de difuso

Sintoma: Rede lenta ou conectividade intermitente Sinais:

Ocorrncia freqente de enchentes Aumento na utilizao de enlaces

Tempo de envelhecimento de tabelas de endereos inadequado

Sintoma: Rede lenta (tempo pequeno) ou falta de conectividade temporria (tempo

grande)

Sinais:

Aumento da utilizao de enlaces Trfego de difuso ARP elevado

Validade da cache ARP inadequada

Sintoma: Conectividade intermitente Sinais: Duas respostas mesma requisio ARP

Endereo IP de hospedeiro incorreto

Sintoma: Falta de conectividade Sinais: Quadro de difuso enviados por mquinas de outra sub-rede

Endereo IP de hospedeiro incorreto Servidor DHCP mal configurado

Sintoma: Falta de conectividade total ou para algumas mquinas da rede local

212

C A P T U L O

N D I C E S

I N V E R T I D O S

Sinais:

Trfego de mensagens ICMP de redirecionamento Rotas especficas para outros hospedeiros Requisies ARP sem resposta

Hospedeiro com mscara de rede incorreta Servidor DHCP mal configurado

Sintoma: Conectividade apenas com mquinas da rede local Sinais: Trfego de mensagens ICMP de redirecionamento

Tabela de rotas de hospedeiros incorretas Hospedeiro com mscara de rede incorreta

Sintoma: Falta de conectividade ou conectividade intermitente Sinais:

Mensagens no log indicam falta de IPs; Existe conectividade via IP, mas no via nome DNS de mquina; Trfego de mensagens DHCPNAK; Nenhuma requisio externa de clientes DHCP; Requisies ARP sem resposta; Trfego de mensagens ICMP de redirecionamento; Quadro de difuso enviados por mquinas de outra sub-rede; Rotas especficas para outros hospedeiros; DHCPREQUEST ou DISCOVER sem resposta.

Servidor DHCP mal configurado

Sintoma: Falta de conectividade Sinais:

Trfego de mensagens ICMP de TTL excedido; Trfego de mensagens ICMP de destino inalcanvel; Crescimento rpido de ipOutNoRoutes.

Rotas estticas mal configuradas

Sintoma: Falta de conectividade ou indisponibilidade de alguns servios Sinais:

Requisies ARP sem resposta; ICMP de destino inalcanvel; Trfego de difuso originado em outra sub-rede; Mquina com configuraes de outra sub-rede; Cliente DHCP com endereo IP 0.0.0.0.

Equipamento inserido em VLAN incorreta

Sintoma: Rede lenta, indisponibilidade de alguns servios ou falta de conectividade Sinais:

Trfego de difuso elevado; Utilizao de CPU elevada; Utilizao de enlaces elevada; Trfego de difuso originado em outra sub-rede; Mquina com configuraes de outra sub-rede.

VLANs no esto configuradas 213

C A P T U L O

N D I C E S

I N V E R T I D O S

Sintoma: Falta de conectividade ou indisponibilidade de alguns servios Sinais:

Requisies ARP sem resposta; DHCPREQUEST ou DISCOVER sem resposta; Cliente DHCP com endereo IP 0.0.0.0.

Comutadores no conseguem trocar informaes sobre VLANs entre si

Sintoma: Falta de conectividade Sinais: Trfego de mensagens ICMP de destino inalcanvel.

Equipamento inserido em VLAN incorreta Ambiente RIP-1 com VLSM e/ou redes no contguas Dimetro RIP muito grande Roteadores RIP2 no enviam ou recebem pacotes RIP1 Filtro IP no permite a passagem de trfego RIP (UDP 520)
Sintoma: Rede lenta Sinais: Utilizao elevada de enlaces.

Trfego RIP saturando largura de banda Saturao de banda em segmentos Ethernet compartilhados
Sintoma: Falta de conectividade Sinais:

Trfego ICMP de porta inalcanvel; Existe conectividade via IP, mas no via nome DNS de mquina.

O servio de nomes no est habilitado

Sintoma: Indisponibilidade de alguns servios Sinais: Existe conectividade via IP, mas no via nome DNS de mquina.

O nmero de srie no foi aumentado TTL e outros campos do registro SOA com valores inadequados Falta . aps nomes totalmente qualificados em registros DNS
Sintoma: Indisponibilidade de alguns servios Sinais:

Existe conectividade via IP, mas no via nome DNS de mquina; Servidores primrio e secundrios retornam respostas diferentes mesma consulta.

O nmero de srie no foi aumentado TTL e outros campos do registro SOA com valores inadequados
Sintoma: Falta de conectividade apenas para a rede local ou completa Sinais:

Existe conectividade via IP, mas no via nome DNS de mquina; Log do servidor DNS indica no default TTL.

O TTL default de uma zona no est configurado

Sintoma: Rede lenta Sinais:

Existe conectividade via IP, mas no via nome DNS de mquina; Servidores primrio e secundrios retornam respostas diferentes mesma consulta.

214

C A P T U L O

N D I C E S

I N V E R T I D O S

TTL e outros campos do registro SOA com valores inadequados

Sintoma: Falta de conectividade Sinais:

Existe conectividade via IP, mas no via nome DNS de mquina; Resoluo de nomes externos no funciona; Logs dos servidores secundrios; Consultas DNS sem resposta.

Filtro IP barrando trfego DNS

Sintoma: Alguns servios no funcionam ou precisam esperar muito tempo para que a

conexo seja estabelecida

Sinais: Resoluo direta no casa com resoluo reversa.

Descasamento de registros A e PTR em arquivos de zonas DNS

Sintoma: Indisponibilidade de alguns servios Sinais:

Existe conectividade via IP, mas no via nome DNS de mquina; Resolues do nomes duplicados do domnio.

Falta . aps nomes totalmente qualificados em registros DNS

Sintoma: No conseguem enviar mensagens para certos destinos Sintoma: Administrador recebe reclamaes Sinais: Servidor aceita fazer entrega sempre.

Servidor de correio eletrnico com repasse totalmente aberto

Sintoma: No conseguem enviar mensagens Sinais: Servidor no aceita repassar mensagens at mesmo para usurios locais.

Servidor de correio eletrnico com repasse totalmente fechado Tabela 8-2: ndice invertido de sintomas e sinais.

215

Parte II Catlogo de problemas

Captulo

9 Procedimentos gerais

Os trs primeiros procedimentos (apresentados no Captulo 9) no so referenciados em problema algum. Por esta razo, so chamados procedimentos gerais. Eles informam como conectar um analisador de protocolos, como obter uma interface de linha de comando e como localizar problemas utilizando ping e traceroute. Estes procedimentos so, na realidade, procedimentos de apoio aos demais procedimentos.

9.1 Utilizando um analisador de protocolos

Em geral, o uso bsico de um analisador de protocolos envolve trs passos: conectar o analisador no local apropriado; criar filtros de captura que selecionem apenas o trfego de interesse; capturar quadros e em seguida decodific-los. Neste procedimento abordaremos de forma geral cada uma destas etapas.

9.1.1 Conectando o analisador de protocolos

Quando desejamos capturar o trfego de um enlace usando um analisador de protocolos, precisamos, primeiro, conectar o analisador adequadamente. Antes de irmos adiante, importante falarmos um pouco sobre hubs (traduzidos em todo este livro como repetidores) e comutadores. Um repetidor um dispositivo eletrnico que opera no nvel fsico. Ele replica todo o sinal que chega em quaisquer de suas portas para todas as outras portas. Assim, quando conectamos um analisador de protocolos em um repetidor, o analisador ser capaz de capturar o trfego de todos os enlaces ligados ao repetidor. Um comutador, por sua vez, opera em nvel de enlace. Um comutador mantm em sua memria uma tabela de endereos que traz mapeamentos de endereos MAC em portas do comutador55. Quando um comutador recebe um quadro
55 A tabela de endereos de um comutador povoada da seguinte forma: quando o comutador recebe um quadro atravs de uma de suas portas, ele olha o endereo origem do quadro. Sabendo a porta por onde o quadro chegou o comutador simplesmente adiciona (ou atualiza) sua tabela de endereos com estas novas informaes.

217

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

atravs de uma de suas portas ele verifica o endereo MAC destino do quadro. Em seguida ele pesquisa em sua tabela de endereos para qual de suas portas o quadro deve ser enviado. Se o mapeamento MAC porta desejado for encontrado em sua tabela de endereos, o quadro transmitido apenas para a porta indicada na tabela de endereos. Apenas se o mapeamento no for encontrado na tabela de endereos o comutador enviar o quadro para todas as suas portas (flooding, traduzido aqui como enchente). Assim, quando conectamos um analisador de protocolos em um comutador, ele no ser capaz de capturar o trfego de todas as portas do comutador. O analisador capturar apenas os quadros de difuso do domnio de difuso ao qual est conectado, os quadros destinados a ele prprio e os quadros enviados por enchentes. Um outro ponto que tambm deve ser levado em conta a configurao das VLANs em um comutador. VLANs limitam domnios de difuso. comum que na configurao default de um comutador todas as suas portas faam parte da mesma VLAN, chamada de VLAN default. Assim, se nenhuma outra VLAN for definida pelo administrador da rede, todas as portas do comutador faro parte do mesmo domnio de difuso, e assim, ao conectar o analisador em quaisquer de suas portas, todos os quadros de difuso sero capturados pelo analisador. Se outras VLANs forem definidas no comutador, um analisador conectado ao comutador ser capaz de capturar apenas os quadros de difuso do domnio de difuso definido pela VLAN a que ele o analisador pertencer. Por tudo j citado, podemos concluir que com o surgimento dos comutadores e em especial com sua ampla utilizao, tornou-se mais difcil analisar o trfego entre dois equipamentos da rede. Para deixar clara a diferena entre conectar um analisador de protocolos em um comutador e em um repetidor, veja a Figura 9-1 e a Figura 9-2 a seguir, retiradas de [CISCO-SPAN]. Nessas figuras, voc deseja capturar o trfego entre dois equipamentos ou duas redes A e B.

Figura 9-1: Analisador de protocolos conectado a um repetidor (hub).

Na Figura 9-1, o analisador est conectado a um repetidor. O trfego originado na mquina A com destino mquina B transmitido para todas as portas do repetidor. O analisador conectado no repetidor ser capaz, portanto, de capturar todo o trfego entre as mquinas A e B. J na Figura 9-2, o trfego entre as mquinas A e B estar restrito s portas do comutador onde as mquinas A e B

218

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

esto conectadas56. Sendo assim, um analisador conectado ao mesmo comutador ao qual esto conectadas as mquinas A e B no ser capaz de capturar o trfego entre estas mquinas.

Figura 9-2: Analisador de protocolos conectado a um comutador (switch).

Para facilitar nossa vida, os comutadores mais novos oferecem uma funcionalidade conhecida como espelhamento de porta, monitorao de porta ou Switched Port Analyzer (SPAN). Podemos configurar os comutadores que oferecem esta funcionalidade para espelhar todo o trfego de uma ou mais portas em uma outra porta, qual conectamos o analisador de protocolos.

Figura 9-3: Comutador com funo de espelhamento ativada.

Na Figura 9-3, retirada de [CISCO-SPAN], o comutador foi configurado para espelhar todo o trfego da porta ligada mquina B na porta ligada ao analisador de protocolos. Desta forma, o analisador de protocolos, apesar de estar conectado em um comutador, poder enxergar todo o trfego entre as mquinas A e B. Leia mais detalhes sobre a funo de espelhamento e como configur-la em comutadores Cisco em [CISCO-SPAN].

56 Isto ocorrer to logo o comutador aprenda atravs de que portas as mquinas A e B so alcanveis. Quando a mquina A transmitir um quadro pela primeira vez, o comutador aprender atravs de que porta a mquina A pode ser alcanada. O mesmo ocorrer com a mquina B.

219

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Quando desejamos analisar o trfego entre dois equipamentos entre os quais existem apenas comutadores, a opo mais elegante usar a funo de espelhamento em um dos comutadores ligados aos equipamentos em questo. Mas, se a funo de espelhamento no for oferecida pelos comutadores existentes entre os dois equipamentos, podemos ainda usar um repetidor auxiliar, como mostrado na Figura 9-4. A utilizao de um repetidor auxiliar envolve uma srie de cuidados. O mais importante deles que devemos assegurar que com a insero do repetidor no causaremos descasamento de modo de operao na rede. Idealmente, enlaces que envolvem apenas comutadores e/ou roteadores devem operar no modo full duplex. Um repetidor, ao contrrio, s capaz de trabalhar no modo half duplex. Assim, a insero do repetidor auxiliar pode causar descasamento de modo de operao. Para evitar este problema voc deve configurar as portas dos equipamentos A e B ligadas ao repetidor para trabalharem no modo half duplex, ou configur-las para o descobrimento automtico do modo de operao. No ltimo caso certifique-se de que o modo de operao half duplex foi configurado em ambas as portas dos equipamentos ligadas ao repetidor. Outro cuidado que devemos tomar evitar o descasamento de velocidade de operao. Quando usamos um repetidor auxiliar para conectar o analisador, alm do descasamento de modo e velocidade de operao, o seguinte problema pode surgir: o trfego, antes transportado por um canal full duplex, pode saturar o enlace que agora trabalha em modo half duplex. Se este for o caso a soluo adquirir um splitter. Ligue os equipamentos A e B ao splitter atravs de enlaces operando no modo full duplex e conecte o analisador de protocolos a outra porta do splitter. Com este equipamento voc pode monitorar trfego de enlaces full duplex. Apenas a funo de monitorao passiva (sem gerao de trfego pelo analisador) pode ser realizada quando um splitter tiver sendo usado. Veja a ilustrao na Figura 9-5. Ao terminar a anlise do trfego, o repetidor auxiliar deve ser removido e as configuraes originais de modo e velocidade de operao devem ser restauradas nas portas dos equipamentos s quais o repetidor foi conectado. Esta uma forma alternativa e menos elegante de conectar um analisador em um ambiente totalmente comutado. Se j existir um repetidor entre os equipamentos cujo trfego se deseja analisar, basta conectar o analisador neste repetidor.

220

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Figura 9-4: Conectando o analisador em um repetidor auxiliar.

Figura 9-5: Conectando o analisador atravs de um splitter.

Muitas vezes desejamos analisar o trfego que entra e/ou sai da organizao. Em geral, existe um roteador de borda, que tem conexo com o mundo um enlace de longa distncia e conexo com um roteador ou um comutador interno. Na Figura 9-6 mostramos um enlace por onde passa todo o trfego originado ou destinado Internet. Ao conectar um analisador que enxergue o trfego deste enlace como mostrado anteriormente, podemos analisar o trfego originado e destinado a redes externas.

Figura 9-6: Enlace por onde passa todo o trfego de entrada e sada da organizao. 221

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

9.1.2 Criando e selecionando filtros de captura

Uma vez conectado o analisador em local apropriado, passamos para o passo dois: criar ou escolher filtros de captura para selecionar o trfego capturado. Neste passo, utilizaremos como exemplo o analisador de protocolos Sniffer Pro v.3.5, da Network Associates. Em todos os procedimentos onde falamos sobre analisadores de protocolos usamos este analisador como exemplo. A utilizao bsica deste analisador de protocolos bastante intuitiva. Mostraremos aqui apenas algumas de suas funcionalidades bsicas. Se o filtro desejado j foi criado, basta selecion-lo na lista de opes em destaque na Figura 9-7.

Figura 9-7: Lista para seleo de filtro no Sniffer Pro v. 3.5.

Novos filtros de captura podem ser criados selecionando o item Define Filter do menu Capture. Quando escolhemos este item a caixa de dilogo de definio de filtro exibida na Figura 9-8 apresentada.

Figura 9-8: Janela para definio de filtro de captura no Sniffer Pro v. 3.5.

O filtro Default j existente captura todo o trfego. Se voc deseja criar um novo filtro, na janela de definio de filtro pressione o boto Profiles. A caixa de dilogo apresentada na Figura 9-9 surgir. Ento escolha criar um novo filtro pressionando o boto New. Em seguida, informe o nome do novo filtro de captura. Ao criar filtros de captura escolha nomes sugestivos, que lhe lembrem que tipo de trfego o filtro est configurado para capturar. Esta prtica vai lhe ajudar a escolher rapidamente o filtro que voc deseja quando muitos filtros j tiverem sido definidos. Nomear um filtro de captura com o nome filtro_1, por exemplo, no uma boa prtica. Por exemplo, se voc estiver criando um filtro para
222

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

capturar o trfego DHCP entre dois equipamentos, chame este filtro de DHCP.

Figura 9-9: caixa de dilogo para a gerncia de perfis de captura do Sniffer pro v. 3.5.

A mesma janela apresentada na Figura 9-8 surgir, mas agora o filtro selecionado em Settings For o novo filtro que voc acabou de criar. Se voc deseja apenas modificar um filtro j existente, selecione-o no painel Settings For e modifique-o como desejar usando as tabelas da janela de definio de filtro como descrito a seguir. No Sniffer, assim como na maioria dos analisadores mais sofisticados, podemos criar filtros baseados em: endereos destino e origem dos quadros, tanto em nvel de enlace (endereos MAC), quanto em nvel de rede (endereos lgicos IP, IPX, etc.); padres de dados. Neste caso, podemos selecionar um quadro j capturado com um certo padro, por exemplo, uma mensagem ICMP do tipo 3, e criar um filtro com este padro. Apenas mensagens ICMP tipo 3 (destino inalcanvel) sero capturadas pelo filtro; protocolos conhecidos. Por exemplo, podemos facilmente criar um filtro que capture apenas quadros que contenham dados do protocolo DNS. A criao de filtros baseados em endereos e protocolos mais simples e em todos os procedimentos usaremos apenas estes tipos de filtros. Para criar filtros baseados no endereo origem e/ou destino dos quadros ou datagramas, escolha a tabela Address na janela de definio de filtro. Nesta tabela, escolha o tipo de endereo no qual voc quer basear o filtro. Na verso do Sniffer utilizada possvel escolher entre endereos de Hardware, IP ou IPX. Nesta tabela de endereos existe um painel contendo endereos conhecidos do tipo de endereo escolhido, que podem ser usados na definio do filtro.
223

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Por exemplo, se voc deseja criar um filtro que capture apenas quadros cujo endereo destino de difuso nvel 2, selecione o tipo de endereo Hardware, informe que quadros de qualquer endereo (any) para o endereo de difuso fsico Broadcast(FFFFFFFFFFFF) devem ser considerados. Este endereo faz parte da lista de endereos fsicos conhecidos. Arraste-o para a tabela de endereos. Veja como ficou a configurao do filtro na Figura 9-10. Para criar filtros que capturem quadros de um ou mais protocolos, selecione a tabela Advanced Filter da janela de definio de filtro e escolha o protocolo desejado. Na Figura 9-11 mostramos a configurao de um filtro que captura apenas dados do protocolo DHCP. Na realidade voc pode escolher quantos protocolos desejar. Por exemplo, voc pode criar um filtro que capture dados do protocolo DHCP e DNS simultaneamente. Alm disso, voc pode combinar a filtragem baseada em endereos com a filtragem baseada em protocolos e padres de dados para formar um s filtro. perfeitamente possvel criar um filtro que capture apenas quadros contendo dados do protocolo DHCP originados em uma determinada mquina o servidor DHCP, por exemplo.

Figura 9-10: Configurando filtro baseado em endereos.

Em outros analisadores a criao de filtros no ser muito diferente. Em alguns analisadores, alguns filtros j vm criados por default. Quando criamos um filtro, ele fica selecionado e se imediatamente depois iniciarmos uma captura ele ser usado.

224

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Figura 9-11: Definindo o protocolo cujos dados sero capturados.

9.1.3 Capturando e decodificando quadros

Enfim, chegamos ao ltimo passo: capturar quadros e decodificar os quadros capturados. Mais uma vez, utilizaremos o analisador de protocolos Sniffer Pro v. 3.5, da Network Associates, como exemplo. Aps selecionar o filtro desejado, existem vrias maneiras de iniciar uma captura no Sniffer. Dentre elas, encontram-se: pressione a tecla F10; pressione o boto em destaque na Figura 9-12; no menu Capture escolha o item Start.

Figura 9-12: pressione este boto para iniciar uma captura no Sniffer pro v. 3.5.

Da mesma forma, podemos encerrar a captura de diversas maneiras: pressione a tecla F9; pressione o boto em destaque na Figura 9-13; no menu Capture escolha o item Stop and display.

225

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Figura 9-13: Pressione este boto para encerrar uma captura no Sniffer Pro v. 3.5.

Ao encerrar a captura a janela mostrada na Figura 9-14 ser apresentada. Para ver os quadros capturados escolha a tabela Decode.

Figura 9-14: Janela apresentada aps o encerramento de uma captura.

Nas demais tabelas desta janela encontramos outras informaes bastante interessantes, como por exemplo as mquinas que mais transmitiram dados durante a captura.

9.1.4 Outras funes interessantes do Sniffer

Nem sempre precisamos capturar dados para descobrir sinais na rede. Quando o Sniffer comea a monitorar um enlace, ele apresenta estatsticas deste enlace em um painel. Veja este painel na Figura 9-15. Na tabela Details podemos ver outros detalhes do trfego sendo monitorado. Veja o painel de detalhes na Figura 9-16. Estes painis so bastante interessantes, e podem nos revelar rapidamente os sinais de um problema.

Figura 9-15: Painel de monitorao do Sniffer. 226

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

Figura 9-16: Painel com estatsticas de monitorao detalhadas do Sniffer.

Uma outra funcionalidade interessante do Sniffer a de amostragem histrica (History Samples). O Sniffer pode gerar para voc um grfico que mostre certo tipo de trfego no tempo. Podemos solicitar ao Sniffer, por exemplo, que gere um grfico da quantidade de quadros de difuso por segundo. Para gerar este grfico o Sniffer no precisa estar capturando quadros, apenas monitorando. Na Figura 9-17 apresentamos a janela para a configurao da amostragem histrica no Sniffer.

Figura 9-17: Janela para configurao da amostragem histrica no Sniffer.

Na Figura 9-17 podemos ver os tipos de grficos que o Sniffer pode gerar. Pressionando o boto em destaque nesta mesma figura, podemos configurar grficos que mostram mltiplas estatsticas, por exemplo, utilizao e erros/s. Os passos a seguir podem lhe auxiliar a configurar o Sniffer a gerar um grfico para voc: selecione o item History Samples no menu Monitor, ou pressione o boto apresentado na Figura 9-18 no menu do Sniffer. A janela de amostras ser aberta; na janela para a configurao da amostragem histrica informe o limiar para a estatstica escolhida e o tipo do grfico a ser gerado (se grfico em linha, colunas, etc.). Nesta janela voc pode tambm modificar o esquema das cores. Por default, quando o limiar for excedido o grfico ficar vermelho;
227

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

para criar um grfico que apresente mltiplas medidas (de Jabbers/s e Oversizes/s, por exemplo), pressione o boto Add Multiple History apresentado em destaque na Figura 9-17. A janela para a configurao de um grfico com mltiplas medidas surgir; na tabela geral escolha um nome para o grfico (Jabbers/s e Oversizes/s, por exemplo) e o tipo do grfico (linha, colunas, etc.). Na tabela de seleo exclua os itens que j esto selecionados por default (Packets/s, Utilization(%) e Error/s) e insira os itens Oversizes/s e Jabbers/s. Pressione o boto OK para salvar estas configuraes; clique com o boto direito do mouse sobre o history samples que voc acabou de configurar. No menu que surgir escolha o item Start Sample. O grfico comear a ser traado. Ele ser atualizado a cada 15 segundos e caso voc no finalize a amostragem manualmente, ela ser encerrada aps 15 horas.

Figura 9-18: Boto History Samples.

Tudo o que falamos aqui so apenas funcionalidades bsicas do Sniffer. No Sniffer existem muitas outras funcionalidades interessantes e mais sofisticadas que no exploramos. Se fossemos falar sobre cada funo interessante do Sniffer teramos que escrever outro livro. Cabe a voc e a sua equipe aprender a usar funcionalidades mais sofisticadas do seu analisador de protocolos a fim de obter dele as informaes e o comportamento desejado.

9.1.5 Sobre analisadores de protocolos

Existem dois tipos de analisadores de protocolos: os analisadores dedicados e analisadores instalados em um computador pessoal. Os analisadores dedicados vm em um hardware dedicado para a tarefa de anlise. Eles so bastante caros, mas bastante profissionais e sofisticados. Estes analisadores de protocolos revelam informaes detalhadas sobre a interface Ethernet, incluindo quadros com erros e ocorrncia de colises. mais barato usar analisadores instalados em computadores pessoais, mas neste caso, para que o analisador possa detectar erros fsicos e colises ser necessrio comprar um adaptador de rede especial. Por exemplo, o analisador de protocolos Sniffer da Network Associates (NAI), pode ser instalado em um computador pessoal com sistema operacional Windows ME. Ele funciona com praticamente todos os drivers de placas de rede. No entanto, apenas adaptadores avanados da NAI suportam todas as caractersticas do analisador, inclusive deteco de erros da camada fsica e colises [SNIFFER_PRO-INSTALL]. Drivers comuns no repassam a informao
228

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

das camadas fsica e de enlace para o resto do sistema operacional. Assim, o analisador no toma conhecimento dos erros ocorridos.

9.2 Acessando a interface de linha de comando de um equipamento de interconexo

Em muitos outros procedimentos deste livro citamos comandos que podem ser executados em uma interface de linha de comando de um equipamento. Neste procedimento mostraremos como podemos obter acesso a esta interface em roteadores, comutadores e repetidores. Existem duas formas de acessar a interface de linha de comando de um equipamento: atravs da porta de terminal (console) do equipamento; atravs de uma sesso de telnet para o equipamento. Alguns repetidores menos sofisticados no oferecem uma interface de linha de comando. A seguir detalharemos cada uma destas formas de acesso.

9.2.1 Acesso atravs da porta console

Excetuando-se alguns repetidores mais pobres, todos os demais equipamentos de interconexo de rede tm uma interface, chamada geralmente console ou management, onde podemos conectar um terminal atravs de um cabo EIA/TIA232 (RS-232). Se voc no possuir um terminal para conectar nesta interface, pode conectar um computador com software emulador de terminal como, por exemplo, Hyper Terminal e pcplus. Ao conectar o terminal na porta RS/232, pressione a tecla Return. Ser solicitado a voc um login e uma senha para ter acesso interface de linha de comando. Na realidade, nem todos os equipamentos pedem login. Voc ver mais adiante que equipamentos Cisco pedem apenas a senha. Aps fornecer o que pedido, voc poder usar a interface de linha de comando do equipamento.

9.2.2 Acesso atravs de sesso de telnet

Para ser possvel acessar a interface de linha de comando de um equipamento atravs de uma sesso de telnet, necessrio que este equipamento esteja configurado com um endereo IP. Abra uma sesso de telnet com este equipamento a partir de uma mquina qualquer da rede. Por questes de segurana, interessante que esta mquina esteja prxima do equipamento e que entre ela e o mesmo no existam
229

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

repetidores. Usando telnet, a senha que voc digitar no criptografada e algum, com um analisador de protocolos, pode captur-la na rede. O comando para abrir a sesso de telnet com o equipamento :
# telnet IP_do_equipamento

Assim que iniciar a sesso voc ter que informar um login (dependendo do fabricante do equipamento) e uma senha, para ter acesso interface de linha de comando do equipamento. No existe uma padronizao sobre a interface de linha de comando dos equipamentos de interconexo. Em geral elas so bastante semelhantes interface no grfica de sistemas Unix-like. Nas prximas sub-sees daremos algumas dicas de como lidar com as interfaces de linha de comando de equipamentos de interconexo. No entanto, como no h padronizao, no podemos garantir que as dicas oferecidas sero vlidas para quaisquer equipamentos.

9.2.3 Sobre logins e senhas

Voc deve ter observado que independentemente de como a interface de linha de comando est sendo obtida, voc ter que informar um login e uma senha. Na realidade, alguns equipamentos no solicitam login. Equipamentos Cisco roteadores e comutadores por exemplo, pedem apenas uma senha. Aps fornecermos a senha, ele oferece uma interface com comandos restritos, com os quais no possvel configurar o equipamento. O comando a seguir deve ser executado para que entremos no modo de configurao global (se necessrio):
roteador> enable

Uma nova senha ser solicitada. Aps fornec-la, estamos aptos a configurar o equipamento. Se estivermos apenas buscando informaes sobre o equipamento no ser necessrio entrar no modo de configurao global do sistema. Neste livro, a maioria dos comandos apresentados no requer que voc esteja o modo de configurao global. Outros equipamentos solicitam um login e uma senha. Estes equipamentos vm com usurios default criados. interessante que voc modifique a senha destes usurios to logo receba o equipamento.

9.2.4 Dicas gerais de uso

Uma vez obtida a interface de linha de comando, algumas dicas so vlidas: se aps conectar o terminal no equipamento de interconexo voc vir caracteres estranhos, sinal de que a velocidade de comunicao entre o terminal e o equipamento no est ajustada. Em roteadores Cisco com IOS verso 10.0 ou superior a velocidade default de comunicao (transmisso e recepo) com o terminal 9600 bps. Configure o seu
230

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

terminal com a mesma velocidade para que a comunicao seja possvel. Uma vez obtida a interface de linha de comando, a velocidade de comunicao com o terminal. pode ser modificada com o comando:
roteador# terminal speed <nova velocidade>

se voc no sabe quais os comandos que esto disponveis, use o help da interface de linha de comando, que pode geralmente ser obtido com o comando:
roteador> ?

Este comando oferece uma lista de todos os comandos que podem ser executados na interface obtida. Alguns equipamentos chegam a dar tambm uma pequena descrio de cada comando. Freqentemente, o comando help pode ser usado tambm aps um comando ainda incompleto, para que voc saiba como pode completar o comando. Suponha que voc deseja ver a configurao das interfaces de um roteador. At agora j descobriu que deve usar um comando iniciado com a palavra show, mas, precisa saber como completar este comando. Ento, o comando a seguir pode ajudar:
roteador> show ?

Este comando vai lhe mostrar todas as opes do comando show. Voc pode usar o comando ? em qualquer nvel, para descobrir como construir o comando que voc deseja; em muitos equipamentos no necessrio escrever todas as palavras do comando de forma completa. Basta escrever todas as iniciais at um ponto em que no haja mais a possibilidade de existirem dois comandos com as mesmas iniciais. Por exemplo, para ver todas as interfaces de um roteador Cisco podemos digitar os seguintes comandos:
roteador> show interfaces

Ou
roteador> sh inter

Ambos retornaro os mesmos resultados. Em outros equipamentos necessrio digitar o comando completo, mas o prprio equipamento pode terminar o comando para voc. Basta que voc escreva o incio de uma palavra do comando e em seguida pressione a tecla de espao e faa isso para todas as palavras que compem o comando; excetuando os comandos do tipo show, que apenas apresentam na tela configuraes do equipamento, se no tiver certeza sobre o que um comando faz, melhor ler os manuais do equipamento antes de arriscar execut-lo. Uma interface de linha de comando semelhante a uma interface no grfica do Linux: no existe o comando desfazer.
231

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

9.3 Localizando problemas com auxlio traceroute

Neste procedimento mostramos como usar traceroute para localizar problemas em uma rede.

9.3.1 Descrio e Dicas

Quando uma estao de gerncia estiver sendo usada, ela indicar problemas atravs de alarmes. Outros eventos que no gerem alarmes tambm podem ser descobertos ao analisar as estatsticas apresentadas pela estao de gerncia. No entanto, nem todos os elementos da rede so monitorados. Tipicamente, apenas os elementos mais crticos, em especial aqueles que participam do backbone, so monitorados pela estao de gerncia. Isto exclui, muitas vezes, repetidores e/ou comutadores que estejam ligadas apenas a mquinas clientes. Quando um problema ocorrer em um elemento da rede no monitorado, ele ser provavelmente descoberto atravs de reclamaes de um ou mais usurios. A ferramenta traceroute pode nos ajudar a localizar o problema. Se nenhum elemento de sua rede est sendo monitorado atravs de uma aplicao de gerncia, todos os problemas sero descobertos atravs dos usurios e isto no uma boa prtica de gerncia. O ideal que apenas os problemas que envolvam um ou alguns poucos usurios ligados a um mesmo equipamento de interconexo sejam descobertos atravs dos usurios. Se a rede no estiver sendo monitorada, recomendamos que voc e sua equipe comecem a planejar o incio do monitoramento, para que os problemas possam ser detectados e solucionados mais rapidamente. Este procedimento, quando necessrio, deve ser realizado na fase de coleta de informaes (ver Seo 3.2, pgina 34).

9.3.2 Usando traceroute

Nesta seo veremos como usar traceroute para localizar problemas em uma rede. Para auxiliar o entendimento deste procedimento, vamos apresent-lo em forma de exemplo. Suponha que alguns usurios informaram que a rede est muito lenta. Este usurios participam do Departamento de Marketing. Da prpria mquina onde voc est conectado, voc pode direcionar um
traceroute para uma das mquinas dos usurios ou para o equipamento

onde elas esto conectadas. Ao realizar este teste, use sempre endereos IP e nunca nomes de domnio, pois o problema que voc quer diagnosticar pode ser no servio de nomes. Voltando ao exemplo, direcione traceroute para a mquina de um usurio. Por exemplo:
# traceroute n 10.16.254.1 1 2 10.16.75.171 10.16.13.97 2 ms 4 ms 1 ms 5 ms 1 ms 4 ms
232

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

3 4 5

10.16.24.254 10.16.254.33 10.16.254.1

7 ms

8 ms

6 ms * * * 1939.310 ms

1936.342 ms 1959.462 ms

Em redes locais Ethernet no sobrecarregadas (menos de 50% de utilizao) os tempos de respostas geralmente no ultrapassam alguns poucos milsimos de segundos. Quando muitos roteadores precisam ser atravessados, aceitvel um atraso maior, mas que no ultrapassa 100 ms. No exemplo acima os tempos de resposta dos equipamentos mostrados nas linhas 4 e 5 so inaceitveis para uma rede local. A resposta deste traceroute nos mostra que o tempo de resposta do equipamento 4 (10.16.254.33) est inaceitvel. Isto no quer dizer que este equipamento em especial est com problema. Esta resposta significa que at o elemento 3 (10.16.24.254) a comunicao est perfeita. As informaes obtidas com o resultado do traceroute nos ajudam a testar os elementos certos e a focar a nossa ateno onde o problema realmente est ocorrendo. Se o tempo de resposta de algum dos equipamentos intermedirios for mais que 3 segundos ou se o equipamento no responde, sero impressos asteriscos (*) na sada do traceroute como mostrado o exemplo a seguir: O parmetro n foi passado para o comando traceroute para indicar que no resultado devem ser apresentados os IPs das mquinas e no seus nomes de domnio. Na sada do traceroute apenas roteadores sero apresentados. Repetidores e comutadores no sero visveis, portanto. Se a comunicao tornou-se mais lenta ou foi interrompida entre dois equipamentos, e entre eles h repetidores ou comutadores, estes tambm ficaro sob suspeita. Com o traceroute podemos descobrir o caminho percorrido pelos datagramas at um determinado destino, sendo possvel descobrir erros de roteamento na rede facilmente. Caracteres H! na sada do traceroute indicam ausncia de rotas. Se voc vir estes caracteres aps executar o traceroute voc provavelmente tem um problema de roteamento. Com o resultado voc j sabe que equipamento no tem rota apropriada para repassar o datagrama at o destino (alvo do traceroute). No Windows o comando equivalente ao traceroute o tracert. Passe o parmetro d para que ele no tente mapear IPs em nomes. Voltemos ao exemplo dos usurios de Marketing. Agora, com o resultado do traceroute, voc j sabe que realmente existe um problema, e que ele est localizado entre os equipamentos apresentados nas linhas 3 e 4.

233

C A P T U L O

P R O C E D I M E N T O S

G E R A I S

9.4 Referncias 9.4.1 Recursos online (Internet)

[CISCO-SPAN] Configuring the Catalyst Switched Port Analyzer (SPAN) Feature. http://www.cisco.com/warp/public/473/41.html [SNIFFER_PRO-INSTALL] Sniffer Pro Installation Guide. http://download.nai.com/products/media/sniffer/su pport/SNP/25/spinstal.pdf

234

10 Procedimentos referenciados nos problemas de nvel fsico e enlace

1 0
Captulo

Neste captulo apresentamos 15 procedimentos que informam como obter e analisar informaes de gerncia. Os procedimentos apresentados neste captulo informam como obter os sinais que foram mais referenciados nos problemas de nvel fsico e de enlace. No entanto, existem alguns problemas de outras camadas que os referenciam.

10.1 Obtendo taxa de erros

Neste procedimento, mostraremos como calcular taxas de erros de entrada e sada e taxas de erros especficas de redes Ethernet com o auxlio de diversas ferramentas de gerncia. Na Seo DESCRIO E DICAS definimos taxas de erros de entrada e sada, taxas de erros especficas da tecnologia Ethernet, limiares para cada uma delas e equaes que oferecem a taxa de erros de um enlace. Nas sees subseqentes descrevemos como a taxa de erros pode ser obtida com o auxlio de estaes de gerncia SNMP, interfaces de linha de comando, analisadores de protocolos e outras ferramentas de gerncia.

10.1.1 Descrio e dicas

Erros podem ser detectados durante o recebimento ou a transmisso de um quadro. Desta forma, pode-se definir erros de entrada e erros de sada. A taxa de erros geralmente expressa como um percentual. Considerando as tecnologias de redes de alta velocidade atuais, as taxas de erros devem estar bastante prximas de zero, caso contrrio um problema real est ocorrendo [CISCOPERF-BP]. A taxa de erros de entrada informa o percentual de quadros que chegaram com erros em uma interface e por isso no puderam ser entregues a protocolos de camadas superiores. A taxa de erros de sada o percentual de quadros que no foram transmitidos devido a erros. A Equao 10.1-1 e a Equao 10.1-2 mostram como calcular as taxas de erros de entrada e sada de um enlace:
Taxa de erros de entrada (%) = nmero de quadros recebidos com erro durante T nmero total de quadros recebidos durante T Equao 10.1-1 235 x 100

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Taxa de erros de sada (%) =

nmero de quadros no transmitidos devido a erros durante T x 100 Nmero total de quadros transmitidos durante T Equao 10.1-2

As equaes apresentadas acima so equaes gerais, que informam a taxa de erros total de entrada e sada de uma interface no intervalo de tempo T. No entanto, em enlaces Ethernet-like57, mais comuns em redes locais, vrios tipos de erros especficos podem ocorrer. Essas taxas de erros especficos podem ser calculadas separadamente. Ao perceber uma taxa de erros elevada uma taxa de erros de entrada de 0,001%, por exemplo voc pode investigar que tipo de erro especfico est causando a maior parte dos erros. A Tabela 10-1 apresenta alguns erros de entrada especficos de enlaces Ethernet e a Tabela 10-2 erros de sada. Tipo de erro Descrio Erros CRC de Quadros com tamanho vlido, mas cuja verificao do campo CRC indica que erros de bits ocorreram durante a transmisso. Em enlaces Ethernet de pares tranados espera-se no mximo 1 bit com erro a cada 109 bits transmitidos58 [GUIA-ETHERNET]. Enlaces ticos apresentam transmisso ainda mais precisa, aceitando um mximo de 1 bit com erro a cada 1012 bits transmitidos. Na prtica o nmero de erros de bits tipicamente menor que os descritos acima. Considerando quadros Ethernet grandes (1518 bytes) e enlaces de pares tranados, a taxa de erros CRC mxima apresentada acima poderia ser descrita como 1 erro a cada 82.345 quadros transmitidos. Isto , uma taxa de erros de no mximo 0,001%. Considerando quadros menores (de 64 bytes) seria possvel encontrar no mximo 1 erro a cada 1.953.125 quadros transmitidos, resultando em uma taxa de erros em torno de 0,00005%. Se h preponderncia de quadros de tamanho intermedirio (727 bytes), pode-se encontrar 1 erro de CRC a cada 171.939 quadros transmitidos, o que oferece uma taxa de erros de aproximadamente 0,0006%. Lembre-se que estes nmeros apresentam os piores casos, e na prtica a taxa de erros ser tipicamente bem menor que as apresentadas. Taxas de erros de CRC elevadas indicam geralmente problemas na interface remota ou no cabeamento da rede. Erros de Quadros que no contm um nmero inteiro de octetos (erro de

57

Enlaces Ethernet, Fast Ethernet, Gigabit Ethernet e 10Gibabit Ethernet.

58 Na realidade, quanto maior a velocidade do enlace Ethernet mais rigorosos se tornam os objetivos de erros. Para enlaces Gigabit Ethernet, por exemplo, aceita-se 1 bit com erro a cada 1012 bits transmitidos.

236

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

alinhamento

enquadramento) e que no possuem CRC vlido. Um nmero muito pequeno de erros de alinhamento pode ocorrer com o tempo em um enlace. Portanto, a taxa de erros de alinhamento em um intervalo de tempo tambm deve ser muito prxima de zero. Se uma interface estiver recebendo muitos quadros com erros de alinhamento, possvel de que a interface ligada a ela ou o cabeamento estejam com problema. Quadros muito longos (maiores que 1518 bytes) podem ser emitidos quando um computador ligado ou reiniciado. Portanto, a ocorrncia espordica de quadros longos no indica problema. A ocorrncia freqente de quadros muito longos indica um problema no local, em geral, defeito em hardware.

Quadros muito longos

Erros Um quadro no pde ser recebido devido a um erro interno da internos da camada MAC. O correto que este tipo de erro no ocorra. camada MAC
Tabela 10-1: Erros Ethernet de entrada especficos.

Tipo de erro Colises tardias

Descrio Quando uma coliso detectada e pelo menos um dos quadros envolvidos na coliso j teve mais de 512 bits transmitidos, a coliso deixa de ser uma coliso simples e passa a ser chamada de coliso tardia. Ao contrrio de colises simples, colises tardias so eventos que nunca devem ocorrer em uma rede Ethernet. Elas indicam que um problema srio est ocorrendo na rede (um defeito de hardware ou uma rede fora das especificaes). Quadros que no foram transmitidos por terem participado de 16 colises consecutivas. A ocorrncia de colises excessivas indica um problema na rede. A ocorrncia de colises excessivas nos horrios de maior utilizao da rede, por exemplo, pode indicar que o meio compartilhado est muitssimo congestionado e que uma providncia urgente deve ser tomada.

Colises excessivas

Erros internos da Quadros que no foram transmitidos devido a erros camada MAC internos da camada MAC. A presena constante destes erros sempre indicativo de problema na interface. Erros de deteco A deteco de portadora falhou ao tentar transmitir um de portadora quadro. Este tipo de erro tambm no deve ocorrer.
Tabela 10-2: Erros Ethernet de sada especficos.

Os erros especficos de entrada podem ocorrer tanto em enlaces full duplex quanto em enlaces half duplex. No entanto, os erros de sada com exceo de
237

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

erros internos da camada MAC s so vlidos para enlaces operando no modo half duplex. Como j mencionado anteriormente, as taxas de erros de entrada e de sada devem ser nmeros muito prximos de zero. Uma taxa de erros de entrada superior a 0,001% j alarmante. Quando a taxa de erros de entrada est elevada mais comum que existam problemas na interface remota, no cabeamento ou interferncia os cabos. A taxa de erros de sada deve ser ainda menor que a taxa de erros de entrada. Na realidade ela deve ser 0%, pois a ocorrncia de quaisquer dos erros especficos que a compem indica problema na rede. Uma outra medida que pode ser tomada como base a quantidade aceitvel de erros em uma hora. Esta medida freqentemente mais fcil de obter do que o percentual. Enlaces de pares tranados com vazo mdia de 1Mbps podem apresentar at no mximo uns 3 erros por hora. Enlaces com vazo mdia de 6 Mbps j podem apresentar at uns 20 erros por hora. Substituindo vm pela vazo mdia do enlace, pode-se aproximar o nmero mximo aceitvel de erros de entrada em uma hora de transmisso atravs da Equao 10.1-3:
Quantidade mxima de erros em uma hora = Equao 10.1-3 (vm x 3600 ) 109

10.1.2 Usando uma estao de gerncia SNMP

Nesta seo mostraremos como utilizar variveis SNMP para obter a taxa de erros de um enlace. Sero consideradas taxas de erros de entrada, de sada e especficas da tecnologia Ethernet. As variveis ifInErrors, ifInUcastPkts, ifInBroadcastPkts e ifInMulticastPkts do Grupo Interfaces da MIB-2 so utilizadas para o clculo da taxa de erros de entrada. A Equao 10.1-4 pode ser usada para obter a taxa de erros de entrada (in) de uma interface.
ifInErrors in (%) ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + ifInErrors Equao 10.1-4 x 100

Onde: ifInErrors a quantidade quadros que chegaram com erros em uma interface e por isso no puderam ser entregues ao protocolos da camada superior durante um certo intervalo de tempo; ifInUcastPkts a quantidade de quadros com endereos destino unicast que chegaram na interface durante um certo intervalo de tempo e foram entregues a protocolos da camada superior;

238

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

ifInBroadcastPkts a quantidade de quadros com endereos destino broadcast que chegaram na interface durante um certo intervalo de tempo e foram entregues a protocolos da camada superior; ifInMulticastPkts a quantidade de quadros com endereos destino multicast que chegaram na interface durante um certo intervalo de tempo e foram entregues a protocolos da camada superior. comum que se use um intervalo de tempo de 5 a 15 minutos entre duas coletas de dados consecutivas. Por exemplo, considere que em um tempo t0 uma coleta de dados SNMP foi realizada. Neste momento, ifInErrors0, ifInUcastPkts0, ifInBroadcastPkts0 e ifInMulticastPkts0 foram recuperados:
ifInErrors0 = 1 ifInUcastPkts0 = 2981631 ifInBroadcastPkts0= 2091273 ifInMulticastOkts0 = 1012354

Aps 5 minutos, em t1, uma nova coleta foi realizada, recuperando-se novos valores para os contadores ifInErrors, ifInUcastPkts e ifInBroadcastPkts e ifInMulticastPkts.
IfInErrors1 = 2 IfInUcastPkts1 = 4012693 IfInBroadcastPkts1 = 2917823 ifInMulticastOkts0 = 1519841

Nestes 5 minutos, a taxa de erros de entrada (in) da interface em questo :

in% = (ifInErrors1 ifInErrors0) x 100
ifInUcastPkts1 ifInUcastPkts0 + ifInBroadcastPkts1 ifInBroadcastPkts0 + ifInMulticastPkts1 ifInMulticastPkts0 + ifInErrors1 ifInErrors0

21 in% = (4012693 - 2981631) + (2917823 - 2091273) + (1519841 - 1012354) + (2-1) x 100

in% = 0,00004%

Neste exemplo, a interface em questo recebeu, durante um intervalo de 5 minutos, mais de 2 milhes de quadros e 1 erro ocorreu. Esta uma taxa de erros aceitvel. Note que, ao utilizar o contador ifInErrors, voc estar considerando qualquer tipo de erro que impea o quadro de ser entregue a uma camada superior, incluindo, por exemplo para redes Ether-like, erros de CRC, de enquadramento e recebimento de quadros muito grandes. Cada um destes erros pode ser
239

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

calculado individualmente, mas, nestes casos, variveis de outras MIBs MIB RMON ou MIBs especficas da tecnologia de transmisso em questo, como MIB Ether-like, por exemplo devero ser utilizadas. A taxa de erros especficos deve ser calculada quando for observada uma taxa de erros elevada em uma determinada interface. Neste caso, voc pode descobrir que tipo de erro est causando a taxa elevada de erros. A taxa de erros de sada tambm pode ser calculada com o auxlio de variveis do grupo Interfaces da MIB-2: ifOutErrors, ifOutUCastPkts, ifOutMulticastPkts.e ifOutBroadcastPkts. O clculo bastante semelhante ao apresentado na Equao 10.1-4:
ifOutErrors in (%) = ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts Equao 10.1-5 x 100

Onde: ifOutErrors a quantidade quadros que no puderam ser transmitidos devido a erros durante um certo intervalo de tempo. ifOutUcastPkts a quantidade de quadros com endereos destino unicast cuja transmisso foi requisitada por protocolos da camada superior durante um certo intervalo de tempo, incluindo quadros descartados ou no enviados. ifOutBroadcastPkts a quantidade de quadros com endereos destino broadcast cuja transmisso foi requisitada por protocolos da camada superior durante um certo intervalo de tempo, incluindo quadros descartados ou no enviados. ifOutMulticastPkts a quantidade de quadros com endereos destino multicast cuja transmisso foi requisitada por protocolos da camada superior durante um certo intervalo de tempo, incluindo quadros descartados ou no enviados. Nas prximas sub-sees sero apresentadas equaes que devem ser utilizadas para o clculo de vrios tipos de erros especficos de entrada e de sada em redes Ether-like. Em todas elas, variveis do tipo contador so utilizadas. Estas variveis so precedidas sempre do smbolo para que voc se lembre que o valor do incremento desta varivel em um determinado intervalo de tempo que deve ser utilizado em cada equao.

10.1.2.1 TAXA DE ERROS DE CRC Os erros de CRC so considerados erros de entrada. Quando um quadro chega com erro de CRC significa que pelo menos um bit do quadro foi alterado durante a transmisso. A taxa de erros de CRC pode ser calculada utilizando-se a
240

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

varivel dot3StatsFCSErrors da MIB Ether-Like [RFC2665] e as variveis ifInUcastPkts, e ifInBroadcastPkts e ifInMulticastPkts do Grupo Interfaces da MIB-2 [RFC2233]. Veja a Equao 10.1-6.
dot3StatsFCSErrors x 100 Taxa de Erros de CRC (%) =
ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + dot3StatsFCSErrors

Equao 10.1-6

Onde: etherStatsFCSErrors a quantidade de quadros recebidos com erro de CRC pela interface em um determinado perodo de tempo.

10.1.2.2 TAXA DE ERROS DE ALINHAMENTO A taxa de erros de alinhamento pode ser calculada utilizando-se a varivel dot3StatsAlignmentErrors da MIB Ether-Like [RFC2665] e as variveis ifInUcastPkts, ifInBroadcastPkts e ifInMulticastPkts do grupo Interfaces da MIB-2 [RFC2233]. A Equao 10.1-7 informa como calcular a taxa de erros de alinhamento.
Taxa de Erros de Alinhamento (%) = dot3StatsAlignmentErrors
ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + ifInErrors

x 100

Equao 10.1-7

Onde: etherStatsAlignmentErrors a quantidade de quadros recebidos com erro de alinhamento pela interface em um determinado perodo de tempo. A MIB RMON [RFC1757] no traz contadores para erros de CRC e alinhamento separadamente. O contador etherStatsCRCAlignErrors incrementado sempre que um quadro com erro de CRC ou de alinhamento for recebido. Com o auxlio desta varivel de gerncia e da varivel etherStatsPkts possvel calcular a taxa de erros de CRC e alinhamento de uma interface seguindo a Equao 10.1-8.
etherStatsCRCAlignErrors Taxa de Erros de CRC e alinhamento (%) = etherStatsPkts Equao 10.1-8 x 100

Onde: etherStatsCRCAlignErrors a quantidade de quadros com erro de CRC ou erro alinhamento recebido pela interface em um determinado intervalo de tempo.
241

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

etherStatPkts a quantidade total de pacotes recebidos, incluindo quadros com erro, e quadros destinados a endereos broadcast e multicast em um determinado intervalo de tempo.

10.1.2.3 TAXA DE ERROS INTERNOS DE RECEPO DA CAMADA MAC Em interfaces Ethernet, outros erros alm de erros de CRC, alinhamento ou quadros muito grandes podem impedir que um quadro seja transmitido para camadas superiores (erro de entrada). Quando isto ocorrer, o contador dot3StatsInternalMacReceiveErrors da MIB Ether-Like ser incrementado. Assim, voc pode calcular a taxa de erros internos da camada MAC como mostrado na Equao 10.1-9:
dot3StatsInternalMacReceiveErrors x 100 Taxa de erros internos de recepo (%) =
ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + dot3StatsInternalMacReceiveErrors

Equao 10.1-9

Onde: dot3StatsInternalMacReceiveErrors a quantidade de quadros que no foram entregues a protocolos da camada superior devido a erros internos na sub-camada MAC em um determinado perodo de tempo. No procedimento apresentado na Seo 10.11 ser visto como obter a quantidade de quadros muito longos recebidos por um enlace.

10.1.2.4 TAXA DE COLISES EXCESSIVAS Objetos das MIBs Ether-like e do grupo Interfaces sero utilizados. O objeto dot3StatsExcessiveCollisions incrementado sempre que um quadro no for transmitido por ter sofrido 16 colises consecutivas. A Equao 10.1-10 pode ser utilizada no clculo da taxa de ocorrncia de colises excessivas:
dot3StatsExcessiveCollisions Taxa de colises excessivas (%) = x 100 ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts Equao 10.1-10

Onde: dot3StatsExcessiveCollisions a quantidade de colises excessivas ocorridas em um determinado intervalo de tempo.

242

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.1.2.5 TAXA DE ERROS INTERNOS DE TRANSMISSO DA CAMADA MAC O contador dot3StatsMacTransmitErrors incrementado sempre que um quadro no pode ser transmitido devido a um erro que no se enquadra em nenhum dos demais erros especficos de transmisso (coliso tardia, colises excessivas ou falha na deteco da portadora). A taxa de erros internos de transmisso pode ser obtido atravs da Equao 10.1-11.
Taxa de Erros Internos de transmisso (%) = dot3StatsInternalMacTransmitErrors
ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts

x 100

Equao 10.1-11

Onde: dot3StatsInternalMacTransmitErrors a quantidade de quadros que no foram transmitidos devido a erros internos na sub-camada MAC em um determinado perodo de tempo. O VERIFICANDO OCORRNCIA DE COLISES TARDIAS informa como verificar se colises tardias esto ocorrendo na rede.

10.1.3 Usando um analisador de protocolos

Nesta seo mostraremos como podemos verificar a ocorrncia de erros em um enlace com o auxlio de um analisador de protocolos. O primeiro passo conectar o analisador corretamente, como descrito no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Infelizmente, a funo de espelhamento no poder ser utilizada quando desejamos ver erros fsicos de um enlace, pois os quadros com erros no so repassados para a porta na qual os dados esto sendo espelhados [CISCO-SPAN]. Voc ter que usar um repetidor auxiliar ou um splitter. Seguindo as dicas deste mesmo procedimento (pgina 226), verifique no painel do Sniffer e no painel de detalhes os erros que esto ocorrendo. Se os contadores de erros estiverem crescendo continuamente, existe algum problema. Voc tambm pode utilizar a funcionalidade de amostragem histrica. O Sniffer pode criar para voc grficos de erros/s. interessante criar um grfico com estatsticas mltiplas que mostre quantidade de erros e octetos por segundo. Dicas para a utilizao desta funcionalidade do Sniffer podem ser encontradas na Seo OUTRAS FUNES INTERESSANTES DO SNIFFER (pgina 226).

243

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.1.4 Usando interface de linha de comando

Nesta seo mostramos comandos da interface de linha de comando de roteadores e comutadores Cisco que oferecem informaes sobre erros nos enlaces. O software de todos os comutadores e roteadores oferece comandos que apresentam estatsticas das interfaces do equipamento. Na maioria dos roteadores Cisco o seguinte comando pode ser executado:
roteador# show interface> interface <tipo da interface> <nmero da

Para analisar estatsticas da porta Fast Ethernet 1/0/0 de um roteador Cisco use o comando a seguir:
roteador# show interface FastEthernet 1/0/0 1. FastEthernet1/0/0 is up, line protocol is up 2. Hardware is cyBus FastEthernet 0002.1743.9820 (bia 0002.1743.9820) 3. Internet address is 208.145.167.233/24 4. MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 8/255 5. Encapsulation ARPA, loopback not set 6. Keepalive set (10 sec) 7. Half-duplex, 100Mb/s, 100BaseTX/FX 8. ARP type: ARPA, ARP Timeout 04:00:00 9. Last input 00:00:00, output 00:00:00, output hang never 10. Last clearing of "show interface" counters never 11. Queueing strategy: fifo 12. Output queue 0/40, 0 drops; input queue 0/75, 0 drops 13. 5 minute input rate 572000 bits/sec, 462 packets/sec 14. 5 minute output rate 3527000 bits/sec, 563 packets/sec 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 484455791 packets input, 2990640235 bytes, 0 no buffer Received 344792 broadcasts, 0 runts, 0 giants, 0 throttles 1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 520096751 packets output, 3410608492 bytes, 0 underruns 1 output errors, 5373084 collisions, 3 interface resets 0 babbles, 1 late collision, 0 deferred. 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Interface, address is

As linhas 16 e 17 mostram contadores de erros de entrada e as linhas 20 e 21 contadores de erros de sada. Nas linhas 15 e 20 so apresentados, respectivamente, contadores de pacotes que entraram e foram transmitidos pela interface.
244

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Em comutadores Cisco use o comando:

console> show port [[mdulo]/porta]

Ele apresentar, dentre outras informaes, contadores de erros de uma interface. Por exemplo, use o comando a seguir para verificar estatsticas da porta 1/1 de um comutador:
Console> show port 1/1 Port Name Status Vlan Duplex Speed Type ----- ------------------ ---------- ---------- ------ ----- -----------1/1 connect 1 auto auto 10/100BaseTX () Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize ----- ---------- ---------- ---------- ---------- --------1/1 0 1 1 1 0 Port Single-Col Multi-Coll Late-Coll Excess-Col Carri-Sen Runts Giants ---- ---------- ---------- ---------- ---------- --------- ------ ------1/1 0 0 0 1 0 0 0 Last-Time-Cleared -------------------------Wed Jan 20 2002, 13:03:12

O comando a seguir oferece contadores de erros para todas as portas do comutador:

comutador> show port counters

Infelizmente este comando no apresenta contadores de quadros de entrada e sada, mas eles podem ser obtidos atravs do comando a seguir:
comutador> show port mac [[mdulo]/porta]

Alm deste comando, alguns comutadores Cisco oferecem o comando show counters, que gera uma cpia dos contadores do comutador, incluindo a quantidade de pacotes recebidos por uma interface e a quantidade de pacotes que chegaram com erros. O mesmo clculo realizado anteriormente, ao apresentar como se calcula a taxa de erros com o auxlio de uma estao de gerncia SNMP vlido aqui. Analisar o resultado de uma nica execuo destes comandos no faz sentido, pois eles retornam valores de contadores cumulativos. Portanto, uma anlise s faz sentido se voc obtiver o valor do contador desejado e aps um certo intervalo de tempo recuper-lo novamente. Desta forma, voc poder calcular a taxa de erros. O clculo idntico ao realizado utilizando uma estao de gerncia SNMP.

10.1.5 Usando ifconfig e netstat

Nesta seco apresentamos ferramentas de gerncia que oferecem informaes sobre erros em interfaces de hospedeiros.

245

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

O comando ifconfig do Linux/Unix tambm pode ser utilizado para recuperar a taxa de erros de uma interface. Ao passar para este comando o argumento a, so apresentadas estatsticas de todas as interfaces da mquina, incluindo um contador de erros e um contador de pacotes recebidos. O mesmo procedimento apresentado nas sees anteriores (como calcular taxa de erros com o auxlio de interfaces de linhas de comando) so vlidos: recupere os valores dos contadores de erros e pacotes recebidos ou transmitidos em dois intervalos de tempos distintos (t0 e t1, por exemplo) e em seguida substitua os valores encontrados na Equao 10.1-1 ou na Equao 10.1-2. Veja a seguir um exemplo da execuo do comando ifconfig. Em negrito esto as informaes que voc ir utilizar para o clculo das taxas de erros de entrada e sada.
[maria@server ~]$ ifconfig -a eth0 Link encap:Ethernet HWaddr 00:04:AC:4C:98:DF Bcast:192.168.1.255 MTU:1500 Mask:255.255.255.0

inet addr:102.168.1.1

UP BROADCAST RUNNING MULTICAST

Metric:1

RX packets:10626336 errors:3 dropped:0 overruns:0 frame:0 TX packets:9429316 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2471067525 (2356.5 Mb) Interrupt:15 Base address:0x2180 TX bytes:1160820381 (1107.0 Mb)

lo

Link encap:Local Loopback inet addr:127.0.0.1 UP LOOPBACK RUNNING Mask:255.0.0.0 MTU:16436 Metric:1

RX packets:926558 errors:0 dropped:0 overruns:0 frame:0 TX packets:926558 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:129180878 (123.1 Mb) TX bytes:129180878 (123.1 Mb)

Se preferir pode utilizar tambm o seguinte comando, que oferece praticamente as mesmas informaes do comando anterior:
[maria@server ~]$ netstat -i Kernel Interface table Iface eth0 lo MTU Met 1500 16436 RX-OK 1062665 0 RX-ERR RX-DRP RX-OVR TX-OK 3 0 0 0 TX-ERR TX-DRP TX-OVR Flg 0 0 0 BMRU LRU

942960 1 0

926584 0

926584 0

Em mquinas Windows use o comando netstat ne para recuperar quantidade de quadros transmitidos e recebidos e erros detectados:
C:\WINDOWS>netstat -ne Estatsticas de interface Recebido Bytes Pacotes unicast 242119 516 Enviado 30360 451

246

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Pacotes no unicast Descartados Erros Prot. Desconhecidos

24 1 2 23

32 1 0

Para calcular a taxa de erros de entrada substitua os valores obtidos com este comando na Equao 10.1-1 e Equao 10.1-2.

10.2 Obtendo a taxa de colises

Neste procedimento falaremos sobre taxa de colises. Na Seo DESCRIO E DICAS discutiremos que taxa de colises devemos considerar elevadas. Nas sees seguintes voc aprender como calcular taxas de colises de enlaces Ethernet com o auxlio de uma estao de gerncia SNMP, de um analisador de protocolos, de uma interface de linha de comandos e de outras ferramentas de gerncia.

10.2.1 Descrio e Dicas

Colises so ocorrncias normais em meios Ethernet compartilhados (half duplex59). Uma taxa elevada de colises maior que a habitual no entanto, pode ser um indicativo de problema. Alguns problemas que causam o aumento da taxa de colises em um enlace so: domnio de colises congestionado, descasamento de modo de transmisso e hardware defeituoso. Alguns administradores de redes acreditam que no mais de 1% dos quadros transmitidos devem colidir; outros acreditam que s a partir de 20% de taxa de colises devemos nos preocupar. Ns fazemos parte de uma turma menos extremista: 10% a taxa mxima de colises que aceitamos. Em [PERF&FAULTCISCO] encontramos uma anlise bastante interessante sobre colises. A seguir veremos um resumo desta anlise. Uma taxa de colises at 10% no causar problemas rede. As colises so detectadas pela prpria camada de enlace, e a retransmisso dos quadros que colidiram de sua responsabilidade. Assim, a retransmisso praticamente instantnea. Por isso, taxas de colises at 10% no degradam o desempenho da rede. O mesmo no ocorre com colises tardias, erros de CRC ou quadros muito grandes. O limiar para estas taxas deve ser bem menor, uma vez que a retransmisso destes quadros s feita aps um certo timeout de camadas superiores. Isto sim, degrada substancialmente o desempenho da rede e pode irritar os usurios. Concluso: importante estar de olho nas taxas de colises de enlaces pelo menos os mais crticos. No entanto, ainda mais importante verificar a ocorrncia de erros como CRC, alinhamento, quadros muito grandes e colises

59

Em ambientes full duplex a taxa de colises deve ser zero.

247

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

tardias. Uma taxa de 0.1% de erros de CRC degrada muito mais o desempenho da rede que uma taxa de 10% de colises. A taxa de colises aumenta quando aumenta a utilizao do enlace half duplex. A Tabela 10-3 [PERF&FAULT-CISCO] d uma idia de como a taxa de colises aumenta em funo do aumento da utilizao do enlace. Utilizao do segmento 0 19% 20 49% > 50% Percentual de pacotes que colidem 1% 5% 15%

Tabela 10-3: Taxas de colises versus utilizao

Geralmente, a Equao 10.2-1 pode ser utilizada para obter a taxa de colises de um enlace.
Taxa de colises (%) = Quantidade de quadros que colidiram durante T Quantidade de quadros transmitidos durante T Equao 10.2-1 x 100

De acordo com esta equao, a taxa de colises o percentual de quadros que colidiram com relao quantidade total de quadros transmitidos (incluindo quadros que colidiram). Comutadores e estaes de trabalho s conseguem detectar as colises nas quais se envolvem (chamadas por alguns fabricantes de colises locais). Por esta razo, no estamos considerando a quantidade de quadros recebidos pela interface na equao. Em situaes em que todas as colises, inclusive as remotas, so detectadas (isso pode ser o caso em algumas sondas RMON), a equao da taxa de colises ser um pouco diferente. Ela considerar todo o trfego de entrada e sada. Veja a Equao 10.2-2.
Taxa de colises (%) = Quantidade de quadros que colidiram durante T Quantidade de quadros transmitidos e recebidos durante T Equao 10.2-2 x 100

O intervalo T pode variar entre 1 minuto e 1 hora. Aconselhamos que este intervalo no ultrapasse 5 minutos quando equipamentos crticos (de backbone, por exemplo) estiverem envolvidos.

10.2.2 Usando uma Estao de Gerncia SNMP

Nesta seo apresentaremos os objetos SNMP que podem ser combinados para calcular a taxa de colises de um enlace Ethernet half duplex. Os seguintes objetos auxiliaro no clculo da taxa de colises:

248

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

dot3StatsSingleCollisionFrames e dot3StatsMultipleCollisionFrames

da MIB Ether-Like [RFC2358], que contam, respectivamente, a quantidade de quadros que colidiram uma nica vez ou mltiplas vezes antes que a transmisso fosse possvel;
etherStatsCollisions da MIB RMON [RFC1757], que informa o nmero total de colises em um segmento (simples e mltiplas).

A taxa de colises de uma interface pode ser calculada como apresentado na Equao 10.2-3:
Taxa de colises (%) = dot3StatsSingleCollisionFrames + dot3StatsMultipleCollisionFrames ifOutUcastPkts + ifOutBroadcastPkts + ifOutMulticastPkts Equao 10.2-3 x100

Onde: dot3StatsSingleCollisionFrames a quantidade de colises simples que ocorreram em um determinado intervalo de tempo; dot3StatsMultipleCollisionFrames a quantidade de colises mltiplas detectadas por uma interface durante um determinado intervalo de tempo. Para uma definio de ifOutUcastPkts, ifOutBroadcastPkts e ifInMulticastPkts veja Seo 10.1.2. O somatrio das 3 variveis fornece o total de quadros de sada na interface em questo. Lembrete: todas as variveis utilizadas nos clculos apresentados so do tipo contador. Portanto, apenas a variao destes contadores no tempo faz sentido. O valor puro do contador no nos diz se houve ou no muitas colises. Mas se obtemos o valor do incremento do contador no tempo podemos ter uma idia de sua taxa de crescimento. Por exemplo, se foram realizadas coletas de dados SNMP em t0 e t1, ento: dot3StatsSingleCollisionFrames = dot3StatsSingleCollisionFrames1 dot3StatsSingleCollisionFrames0. Podemos tambm calcular a taxa de colises de um enlace com objetos do grupo de estatsticas da MIB RMON [RFC 1757]. O objeto etherStatsCollisions uma estimativa do nmero total de colises ocorridas no segmento. Veja Equao 10.2-4.
Taxa de colises (%) = etherStatCollisions ifOutUcastPkts + ifOutBroadcastPkts + ifOutMulticastPkts Equao 10.2-4 x 100

A Equao 10.2-1 a mais utilizada no clculo da taxa de colises. No entanto, como j comentamos na Seo DESCRIO E DICAS, podem existir situaes em que a equao da taxa de colises um pouco diferente. Por exemplo, quando um equipamento detecta colises remotas, isto , colises das quais no
249

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

participa devemos considerar no clculo da taxa de colises no apenas a quantidade de quadros transmitidos, mas tambm a quantidade de quadros recebidos (Equao 10.2-2). Repetidores 10Base-2 e 10Base-5 com uma sonda RMON embutida podem detectar colises remotas. Sendo este o seu caso, a equao Equao 10.2-5 a seguir pode ser usada.
Taxa de colises (%) = etherStatsCollisions etherStatsPkts + etherStatsCollision Equao 10.2-5 x 100

Esta equao tambm pode ser usada se voc tiver uma nica mquina ligada a uma porta de um comutador operando em modo half duplex. Mas, neste caso aconselhamos que voc configure o comutador e a mquina (se for o caso) para trabalharem em modo full duplex, eliminando assim colises, em vez de ficar se preocupando com a taxa de colises deste enlace. Se voc possui uma sonda RMON monitorando um enlace Ethernet com taxa de colises elevada e utilizao de enlaces tambm elevada, voc pode configurar a sonda para reportar, por exemplo, quais so as 10 mquinas que mais transmitem dados na rede em 15 minutos. Com essa informao, voc poder investigar se esses maiores transmissores esto com defeito de hardware, e por isso esto gerando tanto trfego. Use o grupo hostTopN. A configurao da sonda RMON seria a apresentada na Tabela 10-4. Com esta configurao, a sonda RMON apresentar os 10 maiores transmissores de quadros no segmento de rede sendo monitorado. hostTopNRateBase hostTopNTimeRemaining hostTopNRequestedSize hostTopNOutPkts (2) 900 segundos (15 minutos) 10

Tabela 10-4: Configurao de hostTopN para obter 10 maiores transmissores em 15 minutos.

10.2.3 Usando um analisador de protocolos

Nesta seo veremos como obter a taxa de colises a partir de um analisador de protocolos e como ele pode ajudar a encontrar as estaes que mais se envolvem em colises ao tentar transmitir dados. Conecte o analisador de protocolos conforme descrito no UTILIZANDO UM ANALISADOR DE PROTOCOLOS (pgina 217). Infelizmente, para que o analisador veja as colises ocorridas voc no poder usar a funo de espelhamento, tendo que conectar o analisador com o auxlio de um repetidor ou splitter. Seguindo ainda as dicas deste mesmo procedimento (pgina 226), verifique no painel do Sniffer e no painel de detalhes os contadores de colises. Veja o
250

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

incremento dos contadores de quadros e de colises durante um intervalo de tempo T. Em seguida, use a Equao 10.2-2 para encontrar a taxa de colises do domnio. Voc tambm pode utilizar a funcionalidade de amostragem histrica. O Sniffer pode criar para voc grficos de colises/s. interessante criar um grfico com estatsticas mltiplas que mostre quantidade de colises/s e quadros/s. Dicas para a utilizao desta funcionalidade do Sniffer podem ser encontradas na Seo OUTRAS FUNES INTERESSANTES DO SNIFFER (pgina 226). Se voc verificar uma taxa elevada de colises, interessante tentar descobrir se existe uma estao que se envolve mais em colises que as demais estaes. A anlise descrita a seguir, descrita em [HAUGDAHL], pode ser interessante, especialmente quando se desconfia de problemas de hardware ou cabeamento. No Sniffer existe o filtro Default, que permite que todos os quadros sejam capturados. Escolha este filtro e inicie a captura. Observe na tela de detalhamento de estatsticas Ethernet se durante a captura colises ocorreram. Aps algumas dezenas de colises terem ocorrido, finalize a captura O prembulo dos quadros Ethernet no mostrado pelos analisadores. Mas quando dois prembulos colidem e geram uma seqncia de dois 1s seguidos, o analisador comea a receber um quadro prematuramente. Todo o restante do prembulo ainda enviado. Ento os dados do prembulo so apresentados pelo analisador como se fossem parte do cabealho do quadro Ethernet. O prembulo formado por uma seqncia de 1s e 0s: 10101010 Em hexadecimal esta seqncia forma o padro AAA Quando quadros colidem a seqncia do prembulo pode se tornar (em hexadecimal) uma seqncia de 555, pois em binrio essa seqncia formada por 0101, ou uma seqncia de As e 5s. Ao decodificar os quadros no analisador podemos perceber esses padres. Agora lembre-se que: ao detectar uma coliso, uma estao tentar retransmitir o seu quadro que colidiu rapidamente. Isto garante que voc ver na tela de decodificao do analisador aps a coliso pelo menos dois quadros (os que participaram da coliso). Observando os prximos 2 ou 3 quadros aps a coliso temos certeza que pelo menos 2 deles participaram da coliso. Aps analisar vrias colises pode-se chegar concluso que uma estao est quase sempre envolvida nas colises. Se voc percebeu que os quadros transmitidos pela estao A quase sempre colidem, monitore a taxa de colises no enlace ao mesmo tempo que fora a mquina A a transmitir mais dados. Por exemplo, faa uma transferncia de arquivos da mquina A para outra. Se a taxa de colises do enlace aumentar bastante durante a transferncia dos dados, certamente h algo errado com a placa de rede da estao A ou seu cabeamento.

251

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.2.4 Usando uma interface de linha de comando

Nesta seo apresentaremos alguns comandos que podem ser executados em roteadores e comutadores e que oferecem os dados necessrios para o clculo da taxa de colises. Como em todos os outros procedimentos, equipamentos Cisco sero utilizados como exemplo. Se voc possui equipamentos de outros fabricantes, procure no manual do seu equipamento quais os comandos que lhe oferecem contadores de colises detectadas e quadros transmitidos. Em roteadores Cisco com IOS verso 10.0 ou superior, execute o seguinte comando:
roteador# show interfaces <tipo da interface> <nmero da interface>

Este comando apresenta estatsticas da interface escolhida. Veja o resultado deste comando em um roteador Cisco 7507:
roteador>show inter fast 1/0/0 FastEthernet1/0/0 is up, line protocol is up Hardware is cyBus FastEthernet Interface, address is 0002.1743.9820 (bia 0002.1743.9820) Internet address is 200.129.64.139/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 12/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Half-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 3064000 bits/sec, 931 packets/sec 5 minute output rate 5078000 bits/sec, 1002 packets/sec 245369996 packets input, 3191315201 bytes, 0 no buffer Received 54142 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 262296267 packets output, 653636588 bytes, 0 underruns 1 output errors, 12453993 collisions, 4 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

Os dados em destaque (negrito) podem ser utilizados para o clculo da taxa de colises do enlace. Obtenha a variao destes contadores em um intervalo de tempo T e substitua os valores na Equao 10.2-1. Em comutadores Cisco o seguinte comando apresenta, dentre outras informaes, um contador de colises:
252

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

console> show port [mdulo[/porta]]

Para recuperar valores de contadores de quadros transmitidos e recebidos execute o seguinte comando:
console> show mac [mdulo[/porta]]

Alm destes, o comando abaixo tambm pode ser utilizado.

console> show counters

Este comando apresenta valores de contadores da porta, incluindo quantidade de colises detectadas e de quadros transmitidos. Recupere a variao do contador de colises e de quadros transmitidos durante um determinado intervalo de tempo e substitua os valores na Equao 10.2-1 para obter a taxa de colises de uma interface.

10.2.5 Usando ifconfig

Esta seo apresenta como obter os dados necessrios para o clculo da taxa de colises a partir de uma estao Linux. O comando ifconfig pode ser utilizado para recuperar contadores de quadros transmitidos e colises. Recupere estes contadores com o comando:
# ifconfig a <interface>

Veja um exemplo da execuo deste comando:

# ifconfig a eth0 eth0 Link encap:Ethernet inet addr:10.10.10.1 HWaddr 00:60:94:63:6E:3A Bcast:10.10.10.255 MTU:1500 Mask:255.255.255.0 Metric:1

UP BROADCAST RUNNING MULTICAST

RX packets:658685 errors:0 dropped:0 overruns:0 frame:3 TX packets:555222 errors:0 dropped:0 overruns:19 carrier:1 collisions:44644 txqueuelen:100 Interrupt:5

Em destaque esto os dados que voc precisa para calcular a taxa de colises da interface eth0. Lembre-se que estes dados so contadores. Recupere a variao destes contadores durante um determinado intervalo de tempo e substitua os valores obtidos na Equao 10.2-1.

10.3 Verificando ocorrncia de colises tardias

Neste procedimento descrevemos como verificar se colises tardias esto ocorrendo na rede.

253

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.3.1 Descrio e dicas

Colises (sejam elas tardias ou no) s so detectadas por interfaces que esto operando no modo half duplex. Portanto, tudo que se falar aqui s vlido para enlaces Ethernet half duplex, nos quais o protocolo CSMA/CD utilizado. Antes de transmitir qualquer dado, uma estao verifica se o meio est ou no livre e s transmite seus dados quando ela acha que o meio est disponvel. No entanto, duas ou mais estaes podem simultaneamente (dentro de uma pequena janela de tempo) verificar que o meio est livre e, tambm simultaneamente, podem comear a transmitir seus dados. O resultado disso uma coliso. Uma coliso sempre deve ser detectada antes que os primeiros 512 bits dos quadros envolvidos na coliso tenham sido transmitidos. Quando a coliso detectada e mais de 512 bits de pelo menos um quadro envolvido j tiverem sido transmitidos, ela passa a ser chamada de coliso tardia. Colises tardias nunca devem ocorrer. Sua ocorrncia sinal de que a rede tem problemas de projeto (no seguiu as regras de cabeamento de forma correta), existe alguma interface de equipamento com defeito ou ainda existe descasamento de modo de operao.

10.3.2 Usando uma estao de gerncia SNMP

Apresentaremos nesta seo os objetos SNMP que informam a quantidade de colises tardias que ocorrem em um enlace. Alm disso daremos dicas de como configurar alarmes para colises tardias em uma sonda RMON. Observe o valor do contador dot3StatsLateCollisions da MIB Ether-Like [RFC2665]. Ele incrementado sempre que uma coliso tardia detectada. Portanto, o correto que ele jamais seja alterado. Se seu valor for incrementado, uma coliso tardia foi detectada e, portanto, voc tem algum problema na rede. Se voc tem uma sonda RMON monitorando um enlace half duplex, pode configurar um alarme que disparado quando o contador dot3StatsLateCollisions da interface em questo for incrementado. Na Tabela 10-5 so apresentados alguns dados do alarme a ser configurado na sonda RMON. Varivel a ser monitorada: dot3StatsLateCollisions Tipo: Intervalo: Limiar crescente: Limiar decrescente: DeltaValue 600 segundos (10 minutos) 1 0

Tabela 10-5: Dados para configurao de alarme para ocorrncia de colises tardias. 254

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

O alarme deve gerar uma notificao (trap) para a estao de gerncia apenas quando o limiar crescente for atingido.

10.3.3 Usando uma interface de linha de comando

Informaremos nesta seo que comandos em roteadores/comutadores Cisco informam a quantidade de colises tardias em um enlace. Os comandos apresentados aqui servem para a maioria dos roteadores e comutadores Cisco. Se voc possui um equipamento produzido por outro fabricante pesquise no manual do seu equipamento que comando utilizar. bastante provvel que exista um comando semelhante aos apresentados a seguir que lhe d estatsticas de interfaces. Em roteadores Cisco com IOS 10.0 ou superior execute o comando a seguir:
roteador# show interface <tipo> <nmero>

Por exemplo:
roteador# show inter FastEthernet 1/0/0 FastEthernet1/0/0 is up, line protocol is up Hardware is cyBus FastEthernet Interface, address is 0003.2853.0931 (bia 0003.2853.0931) Internet address is 192.168.4.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 10/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Half-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 98 drops; input queue 0/75, 0 drops 5 minute input rate 901000 bits/sec, 566 packets/sec 5 minute output rate 4104000 bits/sec, 678 packets/sec 2159137620 packets input, 346328816 bytes, 0 no buffer Received 1026648 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 4 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 1784610 packets output, 142194201 bytes, 0 underruns 1664 output errors, 48521009 collisions, 11 interface resets 0 babbles, 1 late collision, 0 deferred 1663 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out0

Neste exemplo, o contador de colises tardias est com o valor 1 (linha 22). Com este valor nico no podemos concluir que a rede est com problemas no momento. Este contador pode ter sido incrementado no passado, indicando um
255

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

problema que j foi solucionado. Guarde este valor e mais tarde veja se o contador foi ou no incrementado. Se aps alguns minutos, por exemplo, o contador tiver sido incrementado, existe algum problema srio na rede. Na maioria dos comutadores Cisco execute o comando:
console> show port [mdulo [/porta]]

Este comando apresenta vrias estatsticas de uma porta ou de todas as portas de um mdulo. Dentre estas estatsticas encontra-se um contador de colises tardias. Por exemplo, para analisar as informaes da porta 1 do mdulo 1 de um comutador execute o seguinte comando:
Console> show port 1/1 Port Name Status Vlan Duplex Speed Type ----- ------------------ ---------- ---------- ------ ----- -----------1/1 connect 1 auto auto 10/100BaseTX () Port Single-Col Multi-Coll Late-Coll Excess-Col Carri-Sen Runts Giants ---- ---------- ---------- ---------- ---------- --------- ------ ------1/1 0 0 1 0 0 0 0 Last-Time-Cleared -------------------------Wed Jan 20 2002, 13:03:12

10.4 Obtendo estado operacional de equipamentos

Neste procedimento sero apresentadas algumas formas de se obter o estado operacional de um equipamento.

10.4.1 Descrio e dicas

O estado operacional de um equipamento nos informa se o equipamento est ou no em operao. Equipamentos podem se tornar no operacionais devido a falhas no sistema de alimentao de energia ou devido a defeitos. Existe um fato que facilita a obteno do estado operacional de um equipamento: o equipamento no operacional no responder a qualquer requisio SNMP ou qualquer outra tentativa de comunicao. Ento, qualquer que seja a instrumentao utilizada, se no conseguimos qualquer comunicao com o equipamento alvo podemos concluir que ele no est operacional.

10.4.2 Usando uma estao de gerncia SNMP

Nesta seo descrevemos como obter o estado operacional de um equipamento utilizando uma estao de gerncia SNMP. De tempos em tempos, a estao de gerncia se comunica com os agentes instalados nos dispositivos de rede em busca de dados de gerncia SNMP. Se uma estao de gerncia no obtiver resposta alguma do agente em um dado momento, ela considera que o dispositivo pelo qual o agente responde no est
256

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

operacional. Na realidade, no se pode concluir com certeza se o dispositivo que est no operacional ou se a comunicao com ele, por alguma razo, no est sendo possvel. Dentre as razes que podem deixar a estao de gerncia e um equipamento incomunicveis encontram-se enlaces de comunicao com problema e congestionamento momentneo da rede. No existe uma varivel de gerncia que indica se o equipamento est ou no em operao. Se existisse, o valor desta varivel s poderia ser recuperado quando o dispositivo estivesse em funcionamento. O prprio comportamento do dispositivo, de responder ou no consultas SNMP, nos informa se o equipamento est ou no operacional. Assim, a consulta a qualquer varivel pode ser usada para a obteno do estado operacional de um dispositivo. Aconselhamos que a varivel utilizada para a obteno do estado operacional do equipamento seja sysUpTime, da MIB-2 [RFC1213]. Esta varivel informa a quantidade de tempo, em centsimos de segundos, que se passou desde a ltima vez que o equipamento foi reiniciado. Se em um determinado momento o valor desta varivel menor que o seu valor na ltima coleta SNMP, significa que o equipamento foi reiniciado ou que ele passou mais que 497 dias em operao. O valor mximo desta varivel corresponde a 497 dias. Portanto, se um equipamento passar mais que 497 dias sem ser desligado ou reiniciado, esta varivel tambm ser zerada. interessante saber h quanto tempo um dispositivo est operacional. Muitas vezes descobrimos falhas em software ou hardware de equipamentos ao perceber que ele est reiniciando em curtos espaos de tempo.

10.4.3 Usando ping e traceroute

Apresentamos nesta seo algumas ferramentas que podem ser utilizadas para a obteno do estado operacional de um equipamento. A ferramenta mais usada para verificar o estado operacional de equipamento o ping. A partir de uma estao qualquer, direcione ping para o equipamento cujo estado operacional voc deseja obter:
maria@pc10:~$ ping 192.168.1.1

Se o dispositivo no responder ao ping pode-se concluir inicialmente que ele no est em operao no momento. Mas no se deve descartar a possibilidade de congestionamento de enlaces no caminho at o dispositivo, equipamentos sobrecarregados ou enlaces com problema. Uma outra ferramenta que tambm pode ser utilizada para recuperar o estado operacional de um equipamento o traceroute. Em mquinas com sistema operacional Windows esta ferramenta se chama tracert. Direcione traceroute ao equipamento cujo estado operacional voc pretende obter:
maria@pc10:~$ traceroute -n 192.168.1.1 C:\WINNT> tracert d 192.168.1.1

257

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Os parmetros n e d passados ao traceroute e tracert respectivamente indicam que a ferramenta no deve tentar mapear endereos para nomes de mquinas. Assim, o resultado do comando ser mais rapidamente apresentado e no ficar dependente do sistema de resoluo de nomes.

10.5 Obtendo estado operacional de interfaces

Neste procedimento descreveremos como recuperar o estado operacional de interfaces de rede.

10.5.1 Descrio e Dicas

O estado no operacional de uma interface pode indicar, dentre outras situaes, que: a interface est administrativamente desativada; em geral, o estado administrativo de uma interface comparado com seu estado operacional. Quando o estado administrativo (ver procedimento apresentado na Seo 10.13) no igual ao estado operacional, algum problema pode estar ocorrendo; o equipamento ligado interface est desligado ou com defeito; a interface est com defeito; tipicamente, duas falhas podem levar uma interface a ficar defeituosa: falhas no sistema de alimentao de energia eltrica e defeitos de hardware.

10.5.2 Usando uma estao de gerncia SNMP

Nesta seo descreveremos que varivel SNMP indica o estado operacional de interfaces. Alm disso, dicas de configurao de notificaes e alarmes para o estado operacional de interfaces sero dadas. A varivel ifOperStatus do grupo Interfaces da MIB-s [RFC2233] indica o estado operacional de uma interface. Esta varivel pode assumir os seguintes valores: up(1) indica que a interface est operacional, pronta para receber e transmitir quadros; down(2) interface no operacional; testing(3) interface est em modo teste; unknown(4) por alguma razo a interface est em um estado indeterminado;
258

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

dormant(5) a interface no est em condies de transmitir quadros (no est no estado up). A interface est num estado pendente, esperando a ocorrncia de algum evento externo; notPresent(6) algum componente da interface (em geral de hardware) est faltando. Este estado um refinamento do estado down; lowerLayerDown(7) interfaces de camadas inferiores no esto operacionais, causando o estado no operacional da interface. tambm um refinamento do estado down; No grupo Interfaces original da MIB-2 apenas os estados up(1), down(2) e testing(3) existiam. Se o estado administrativo de uma interface up(1) (ver procedimento apresentado na Seo 10.5) e o estado operacional no up(1), provvel que alguma condio de falha exista na rede. Configure o agente SNMP dos equipamentos mais importantes da rede para gerar notificaes (traps) para a estao de gerncia quando o estado operacional das interfaces crticas mudar para down ou deixar de ser down. O objeto ifLinkUpDownTrapEnable (grupo Interfaces da MIB-2 [RFC2233]) das interfaces crticas deve ser configurado com o valor enabled(1). Uma outra forma de ser avisado quando o estado operacional de uma interface mudar configurar alarmes e eventos em uma sonda RMON. Na Tabela 10-6 so apresentados alguns dados do alarme a ser configurado na sonda RMON: O estado up desejado representado na MIB pelo valor inteiro 1. O limiar crescente 2 alcanado quando o estado da interface for outro diferente do desejado. Quando a interface voltar a funcionar o valor de ifOperStatus vai voltar a ser 1. O alarme deve gerar uma notificao (trap) para a estao de gerncia quando os limiares crescente e decrescente forem atingidos. Varivel a ser monitorada: ifOperStatus Tipo: absoluteValue Intervalo: 600 segundos (10 minutos) Limiar crescente: 2 Limiar decrescente: 2
Tabela 10-6: Dados para configurao de alarme para mudana de estado operacional de uma interface.

10.5.3 Usando uma interface de linha de comando

Nesta seo apresentaremos comandos que podem ser executados em comutadores ou roteadores Cisco para a obteno do estado operacional de interfaces. Se voc possui equipamentos produzidos por outros fabricantes procure os comandos correspondentes aos apresentados nesta seo nos manuais do seu equipamento.
259

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Na maioria dos roteadores Cisco, execute o seguinte comando:

show interfaces [tipo da interface] [nmero da interface]

A primeira linha da resposta a este comando informa o estado da interface. Veja um exemplo:
roteador# show interfaces FastEthernet 1/1/0 FastEthernet0 is down, line protocol is down ()

Esta linha indica que a interface Fast Ethernet 1/1/0 no est operacional. Se a interface estivesse administrativamente desabilitada, a primeira linha seria:
FastEthernet1/1/0 is administratively down, line protocol is down

Em comutadores Cisco execute o comando a seguir:

show port status [mdulo[/porta]]

Este comando informa o estado das portas de um comutador. Veja um exemplo de sua execuo:
Console> show port status

Port

Name

Status

Vlan

Duplex Speed

Type

----- ------------------ ---------- ---------- ------ ------ -----------1/1 1/2 1/3 1/4 connected faulty inactive disabled 4 2 half half half half 100 100 100 100 100BaseTX 100BaseTX 100BaseTX 100BaseTX

O resultado do comando show port status indica que a porta 1/1 est operacional e que ela est conectada a um dispositivo tambm operacional; a porta 1/2 est defeituosa; a porta 1/3 est inativa porque pertence a uma VLAN inexistente e a porta 1/4 est administrativamente desabilitada.

10.5.4 Usando outras ferramentas de gerncia

Em mquinas Unix-like voc pode usar o comando ifconfig para verificar o estado de interfaces. Veja um exemplo do resultado do comando ifconfig abaixo:
root@servidor# ifconfig a eth0 eth0 Link encap:Ethernet HWaddr 00:60:94:63:6E:3A inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:658685 errors:0 dropped:0 overruns:0 frame:3 TX packets:555222 errors:0 dropped:0 overruns:19 carrier:1 collisions:44644 txqueuelen:100 Interrupt:5

260

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Analisando o resultado do comando ifconfig, conclumos que a interface eth0 est administrativamente ativa (UP), aceita endereos de difuso e multicast (BROADCAST e MULTICAST) e que est operacional e no apresenta problemas (RUNNING). Portanto, o resultado de ifconfig para uma interface administrativamente ativa e em funcionamento deve sempre apresentar as palavras UP e RUNNING. O ifconfig no informa quando o equipamento ligado interface est desligado ou com defeito. Mesmo que no seja possvel a comunicao com o equipamento remoto, o ifconfig informar que a interface est up e running. O ifconfig pode apresentar resultados muito diferentes do apresentado acima, que indicam outros erros. Por exemplo, que a interface no pde ser encontrada ou que no possvel a comunicao com o dispositivo.

10.6 Obtendo utilizao de CPU

Neste procedimento apresentaremos como obter a utilizao mdia de CPU em roteadores, comutadores e hospedeiros.

10.6.1 Descrio e dicas

Este ndice desempenho, geralmente calculado na forma de uma porcentagem, informa quanta capacidade de CPU um equipamento est utilizando. Uma utilizao alta de CPU, em geral, um indicativo de problema. Monitorar utilizao de CPU em roteadores muito importante. Nestes equipamentos, utilizaes de CPU elevadas podem comprometer tarefas crticas, como atualizao dinmica de rotas e processamento de pacotes. J os comutadores no utilizam a CPU para realizar a comutao de quadros [PERF&FAULT-CISCO], mas algumas outras atividades por exemplo, o processamento das BPDUs para o clculo da rvore de cobertura so comprometidas devido a altas taxas de utilizao de CPU. indispensvel tambm monitorar a taxa de utilizao de CPU em servidores. Quando a utilizao de CPU nestas mquinas est elevada os clientes percebero um mau desempenho das aplicaes. Muitas vezes a equipe de gerncia de aplicaes ou at os usurios podem culpar a rede pelo mau desempenho das aplicaes. Na realidade, muitos recursos alm da rede podem estar causando a lentido. Dentre eles encontram-se CPU, memria e disco. Muitos so os fatores que podem aumentar a taxa de utilizao de CPU em um servidor. Ele pode estar sendo alvo de ataque DoS, outra aplicao que no deveria estar sendo executada est tomando muito tempo de processador, ou ainda pode ser um indcio de que o servio est sendo muito requisitado e j necessrio alguma soluo para o problema de saturao de capacidade de CPU. O ideal que voc monitore as taxas de utilizao de CPU dos equipamentos mais importantes da rede e estabelea o seu prprio limiar. Uma utilizao mdia de 75% de CPU um sinal de advertncia para que voc fique atento e
261

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

j comece a analisar o porqu desta taxa. 90% de utilizao mdia de CPU alarmante. Alguns equipamentos conseguem trabalhar com altas taxas de utilizao de CPU sem degradar o seu desempenho, outros no. mais interessante calcular a utilizao de CPU para intervalos de tempo maiores. Por exemplo, uma utilizao de CPU mdia de 80% no ltimo minuto no significa na realidade um sinal de advertncia. Por coincidncia podemos ter calculado a utilizao de CPU em um momento em que a mquina estava realmente sobrecarregada. No entanto, se a utilizao mdia de CPU mantm-se em 80% durante algumas dezenas de minutos, preocupe-se! Em resumo, se raramente a utilizao alta esporadicamente calcula-se 90% de utilizao de CPU no h problema. Mas se a utilizao de CPU alta se prolonga por dezenas de minutos, uma investigao deve ser realizada.

10.6.2 Usando uma estao de gerncia SNMP

Nesta seo apresentamos variveis SNMP que oferecem informaes sobre a utilizao de CPU de equipamentos. No existe uma MIB padro como a MIB-2, por exemplo que informe a taxa de utilizao de CPU de equipamentos de interconexo de redes. Em roteadores Cisco com verso de IOS inferior a 12.0(3)T, alguns objetos da MIB OLD-CISCO-SYSTEM [OLD-CISCO-SYSTEM-MIB] podem ser utilizados para a obteno da taxa de utilizao de CPU. Em roteadores com IOS mais recente, objetos da MIB CISCO-PROCESS [CISCO-PROCESS-MIB] podem ser utilizados. A MIB antiga considerava apenas um processador por equipamento. A nova MIB traz uma tabela com informaes sobre todos os processadores. A semntica dos objetos no muda de uma MIB para outra. O que muda o nome dos objetos e o tipo, pois em uma delas na MIB mais recente os objetos so colunares, isto , fazem parte de uma tabela. Cada linha da tabela traz estatsticas de uso de um processador. A Tabela 10-7 descreve os objetos que lhe informam sobre utilizao de CPU. Mais informaes sobre obteno de utilizao de CPU em equipamentos Cisco usando SNMP so encontradas em [CPU-UTILIZATION-HOWTO]. OLD-CISCO-SYSTEM
busyPer

CISCO-PROCESS
cpmCPUTotal5sec

A taxa de utilizao mdia da CPU nos ltimos 5 segundos. A taxa de utilizao mdia da CPU no ltimo minuto. A taxa de utilizao mdia da CPU nos ltimos 5 minutos.

avgBusy1 avgBusy5

cpmCPUTotal1min cpmCPUTotal5min

Tabela 10-7: objetos que informam a utilizao de CPU em roteadores Cisco.

Todos estes objetos j lhe do o percentual de utilizao dos processadores. Portanto, nenhum clculo adicional precisa ser realizado. A varivel que oferece a utilizao mdia nos ltimos 5 minutos deve ser usado para avaliao da utilizao de CPU em equipamentos ao longo do dia. Caso voc suspeite de que
262

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

em um determinado momento um equipamento est com utilizao de CPU muito alta, podendo ser a causa de lentido na rede, a utilizao mdia de CPU em intervalos menores pode ajudar. Se voc possui roteadores de outro fabricante, busque informaes sobre as MIBs suportadas na documentao do seu equipamento. importante que agentes SNMP estejam ativos em todos os servidores. Assim, podemos obter informaes importantes de gerncia via SNMP. Em servidores com agente SNMP instalado a MIB Host Resources [RFC1514] pode ser utilizada. O objeto hrProcessorLoad informa a taxa de utilizao de CPU no ltimo minuto.

10.6.3 Usando uma interface de linha de comando

Nesta seo mostramos alguns comandos que retornam a utilizao de CPU em comutadores e roteadores Cisco. Em comutadores Cisco mais novos voc pode obter a taxa de utilizao de CPU com o seguinte comando:
Console> (enable) show proc cpu (W)CPU utilization for five seconds: 1.0%; one minute: 1. 0%; five minutes: 1. % PID 0 1 2 3 4 5 6 7 Runtime(ms) 0 1 1342 730172 33752 7413 9568 746 Invoked 0 36 2846 4440594 424120 44916 1588983 636118 uSecs 0 1000 46000 40000 1000 1000 1000 10500 5Sec 99.1% 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 1Min 99.0% 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 5min 99.0% 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 % 0.0 %
TTY

0 0 0 0 0 0 0 0

Process idle
Flash MIB Updat

SynDiags SynConfig Statuspoll SWPoll64bCnt SL_TASK RedundantTask

Em roteadores Cisco use o comando show processes cpu como exemplificado a seguir:
roteador1# show processes cpu CPU utilization for five seconds: 3%/3%; one minute: 3%; five minutes: 2% PID Runtime(ms) 1 2 3 4 () 6040 63184 4840624 0 Invoked 1602152 2449411 813473 1 USecs 5Sec 3 25 5950 0 1.30% 0.95% 0.65% 0.10% 1Min 1.20% 1.05% 0.60% 0.15% 5Min 0.95% 0.85% 0.15% 0.05% TTY Process 0 0 0 0 Load Meter Load Meter Check heaps Chunk Manager

Se no seu roteador for verificada uma taxa elevada de CPU, descubra que processo est consumindo mais CPU. Se o seu roteador/comutador no for fabricado pela Cisco, procure o comando que d informaes sobre os processadores na documentao do seu equipamento.

263

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.6.4 Usando top e vmstat

Em mquinas Linux vrios comandos informam a utilizao de CPU. A seguir sero apresentados dois comandos bastante utilizados para a anlise da utilizao de CPU: o top e o vmstat.
E L
M

A M B I E N T E I N U X

O comando top oferece informaes diversas sobre o sistema. Alm de informar a mdia de utilizao de CPU, o comando tambm informa quanta CPU cada processo em execuo est consumindo. Um exemplo da sada do comando top segue:
maria@server:~$ top d 300 8:42pm up 140 days, 4:35, 2 users, load average: 3.31, 3.45, 3.66

68 processes: 59 sleeping, 9 running, 0 zombie, 0 stopped CPU states: 97.7% user, Mem: Swap: 255772K av, 530136K av, 2.2% system, 0.0% nice, 0.0% idle 2360K buff

249484K used, 3828K used,

6288K free, 526308K free

0K shrd,

36616K cached

PID

USER

PRI 16 10 20 9 8

NI 0 0 0 0 0

SIZE 260

RSS 16

SHARE STAT 4 1160 1156 780 44 R S R R S

LIB 0 0 0 0 0

%CPU 38.2 34.4 13.5 0.2 0.0

%MEM 00.0 7.4 4.2 8.2 0.0

TIME

COMMAND

24462 ftp 20259 root 22234 root 12200 root 1 () root

8934m in.ftpd 2:33 0:40 netmngr netmngr

19044 18M 10916 10M 22464 20M 72 64

46:58 named 0:04 init

No exemplo acima percebe-se que a CPU est com mais de 85% de utilizao mdia nos ltimos 300 segundos. As aplicaes in.ftpd e netmngr, juntas, consumiram mais 85% da capacidade de CPU durante este intervalo de tempo. Cabe a voc e sua equipe decidir se h ou no um problema e, se houver, como corrigi-lo. No bom ter um servidor com 100% de utilizao sempre. Mas se esta utilizao alta espordica a alta taxa de utilizao no to alarmante. Por default, de 5 em 5 segundos as estatsticas oferecidas pelo comando top so atualizadas60. Para uma avaliao diria, como j comentamos anteriormente, mais interessante obter a utilizao mdia de CPU para um intervalo maior. Por isso, no exemplo dado, passamos o parmetro 300 para o comando top. Ele indica que as atualizaes s sero feitas a cada 5 minutos e portanto refletiro a utilizao mdia de CPU neste intervalo de tempo. Se voc preferir pode aumentar este intervalo para algumas dezenas de minutos. Um outro comando que pode ser utilizado o vmstat:
maria@server:~$ vmstat 300 procs r 0 1 b 0 0 w 0 0 memory swpd free swap buff cache si so 0 0 io bi 1 1 bo 4 26 system in 2 145 cs 1 111 cpu us 20 19 sy 3 2 id 77 78

3008 21856 1828 33508 0 3008 21860 1828 33508 0

60

Use o comando interativo q para sair das estatsticas top.

264

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

0 0 0 2

0 0 0 0

0 0 0 0

3008 21352 1828 33512 0 3008 22348 1828 33516 0 3008 22348 1828 33516 0 3008 11188 1840 35456 0

0 0 0 0

0 0 0 389

0 0 0 26

145 141 124 156

128 113 77 41

28 26 11 68

3 4 3 1

69 70 86 31

Como o parmetro 300 passado para o comando vmstat, uma linha com as estatsticas atualizadas adicionada a cada cinco minutos (300 segundos). A primeira linha apresenta estatsticas mdias desde a ltima reinicializao da mquina. As demais linhas so adicionadas uma a uma, a cada 5 segundos. Este intervalo de tempo foi passado como parmetro para o comando vmstat. Se nenhum parmetro tivesse sido passado apenas a primeira linha seria apresentada. A partir da segunda linha as estatsticas apresentadas correspondem ao intervalo de tempo passado como parmetro. Observe as 3 ltimas colunas. Elas oferecem informaes sobre a utilizao da CPU. Durante o intervalo de tempo que se passou, qual a porcentagem de utilizao de CPU consumida por processos de usurios e por processos do sistema operacional. A ltima coluna informa a porcentagem de tempo durante o qual a CPU ficou inativa.
E W
M

A M B I E N T E I N D O W S

Em mquinas Windows 2000 podemos gerar um grfico que apresente a utilizao de CPU ao longo do dia. No menu Iniciar escolha Programas > Ferramentas Administrativas > Desempenho. Na tabela de contadores (painel inferior direito) clique com o boto direito do mouse e escolha o item Adicionar Contadores. Em seguida escolha o contador Processor Time relacionado ao processador: Veja na Figura 10-1 um grfico de utilizao de CPU gerado desta forma.

10.7 Obtendo utilizao de memria em roteadores e comutadores

Neste procedimento informaremos como podemos obter a utilizao de memria em roteadores e comutadores.

10.7.1 Descrio e dicas

A utilizao de memria, geralmente expressa como um percentual, informa quanta memria um equipamento est utilizando em comparao com a utilizao mxima de memria do equipamento, que teoricamente , 100%. Roteadores e comutadores armazenam em memria principal os processos em execuo. Mas, ao contrrio de hospedeiros, em roteadores e comutadores no existem tcnicas que possam expandir a memria principal. Quando um roteador no possui recursos suficientes para processar um datagrama no h buffers livres, por exemplo o datagrama descartado, mesmo que no apresente erros. Portanto, comum que encontremos limitaes de memria em um roteador ao descobrir um nmero elevado de descartes.
265

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Em roteadores e comutadores a dica a seguinte: a partir de 75% de utilizao de memria (em longo prazo) fique atento. Este um sinal de advertncia; o limiar de alarme fica em torno de 90%-95% de utilizao de memria em longo prazo. Uma outra regra geral : observe a utilizao de memria de seus roteadores e comutadores e estabelea seu prprio limiar. Se um roteador apresenta constantemente utilizao de 1% de memria e de repente comea a apresentar utilizao de 20%, investigue. Apesar deste nmero no ser elevado e no ser um limiar geral, um nmero muito maior que o constantemente obtido e , muito provavelmente, um indicativo de problema.

Figura 10-1: Estatsticas de uso de CPU no Windows.

10.7.2 Usando uma estao de gerncia SNMP

Nesta seo apresentamos algumas variveis SNMP que trazem informaes sobre o uso de memria em roteadores e comutadores. Mostraremos tambm variveis que informam a quantidade de quadros descartados por um equipamento de interconexo devido limitao de recursos. A MIB CISCO-MEMORY-POOL, proprietria da Cisco, oferece uma tabela, chamada ciscoMemoryPoolUtilizationTable, que indica a utilizao mdia de memria em um roteador em perodos de tempo de 1, 5 e 10 minutos. Esta tabela um incremento da tabela ciscoMemoryPoolTable da qual falaremos mais adiante. Nestas tabelas existe uma linha com estatsticas de alocao de memria para cada tipo de memria existente no roteador. A Cisco definiu 5 tipos de memria. Dentre elas esto a memria de processador, que deve existir em todos os dispositivos, e a memria de entrada e sada. As variveis ciscoMemoryPoolUtilization1Min, ciscoMemoryPoolUtilization5Min e ciscoMemoryPoolUtilization10Min indicam a utilizao de cada tipo de memria nos ltimos 1, 5 e 10 minutos respectivamente. Informaes mais detalhadas podem ser encontradas em [CISCO-MEMORY-POOL-MIB].
266

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Outras variveis SNMP importantes para a monitorao de utilizao de memria em roteadores Cisco [CISCO-MEMORY-POOL-MIB, OLDCISCO-MEMORY-MIB] so:
ciscoMemoryPoolFree, objeto colunar da tabela ciscoMemoryPoolTable da MIB CISCO-MEMORY-POOL ou freeMem varivel da OLD-

CISCO-MEMORY. Estas variveis indicam o nmero de bytes livres na memria do equipamento. O objeto freeMem obsoleto, mas ainda precisa ser usado para a recuperao da quantidade de memria livre em roteadores Cisco com IOS inferior verso 11.1;
ciscoMemoryPoolUsed, objeto colunar da tabela ciscoMemoryPoolTable da MIB CISCO-MEMORY-POOL. Esta

varivel indica o nmero de bytes em uso da memria do equipamento;

ciscoMemoryPoolLargestFree, objeto colunar da tabela ciscoMemoryPoolTable da MIB CISCO-MEMORY-POOL. Indica a

quantidade mxima de bytes contguos livres na memria. Este valor sempre menor ou igual ao valor indicado pela varivel ciscoMemoryPoolFree. O limiar mnimo recomendado para esta varivel 500KB [PERF&FAULT-CISCO];
bufferNoMem da MIB OLD-CISCO-MEMORY. Esta varivel conta

o nmero vezes que a tentativa de criao de um buffer falhou devido falta de memria. Quando este contador aumenta um datagrama provavelmente descartado. Para obter a utilizao de memria com base nestas variveis precisamos comparar a quantidade de memria em uso com a quantidade total de memria no sistema. Isto pode ser feito segunda a Equao 10.7-1 ou a Equao 10.7-2:
Utilizao de memria (%) = Qtde. total de memria Qtde. de memria livre Qtde. total de memria Equao 10.7-1 Qtde. de memria em uso Qtde. total de memria x 100

Utilizao de memria (%) =

x 100

Equao 10.7-2

Como mencionado na Seo DESCRIO E DICAS, datagramas so descartados devido a falta de recursos para process-los, incluindo falta de memria. importante, portanto, que monitoremos a quantidade de descartes devido a falta de recursos em um equipamento. Para tal, variveis do grupo Interfaces da MIB-2 podem ser utilizadas [RFC2233]:
ifInDiscards um contador incrementado cada vez que um quadro que

chega em uma interface, ainda que correto, tem que ser descartado devido falta de recursos, como por exemplo, no h memria disponvel;
267

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

ifOutDiscards um contador incrementado cada vez que um quadro,

ainda que correto, no pode ser transmitido por uma interface devido a falta de recursos, como, por exemplo, falta de memria. Estes contadores no devem ser incrementados com freqncia, e sua taxa de crescimento deve ser bem menor que a taxa de crescimento de entrada e sada de quadros da interface.

10.7.3 Usando uma interface de linha de comando

Nesta seo mostraremos comandos que podem ser executados na interface de linha de comando de comutadores e roteadores Cisco para a obteno de informaes relacionadas utilizao de memria no equipamento. Em equipamentos de outros fabricantes devem existir comandos correspondentes. Busque informaes no manual do seu equipamento. Em roteadores Cisco com verso de IOS superior a 10.0 os seguintes comandos podem ser executados:
show memory [memory-type] [free] [summary] show processes memory

Vejamos primeiro um exemplo da execuo do comando show memory:

roteador> show memory Head Processor 61345760 Fast 61325760 () Total(b) 248228000 131080 Used(b) 16818760 24664 Free(b) 231409240 106416 Lowest(b) 231201272 106416 Largest(b) 230393684 106364

A primeira seo do resultado do comando show memory uma tabela (que pode ser vista no exemplo de execuo apresentado) bastante interessante. Ela oferece estatsticas gerais de uso de cada um dos tipos de memria suportados pelo roteador (neste caso Procecssor e Fast). A Tabela 10-8 explica algumas das colunas desta tabela. Campo Total(b) Descrio

Quantidade total de bytes na memria (soma de bytes disponveis e em uso da memria). Used(b) Quantidade de bytes da memria em uso. Free(b) Quantidade de bytes livres da memria. Lowest(b) Quantidade de memria livre (em bytes) no momento de maior utilizao de memria desde a inicializao do equipamento. Largest(b) Tamanho em bytes do maior bloco livre da memria.
Tabela 10-8 Descrio de alguns campos do resultado do comando show memory.

Veja a seguir o resultado do comando show processes memory:

roteador>show proc mem Total: 248228000, Used: 16820540, Free: 231407460 PID TTY Allocated Freed Holding Getbufs

Retbufs Process

268

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

0 0 0 1 2 3 4 5 6 ()

0 0 0 0 0 0 0 0 0

446636 912 19590060 268 6476 0 21972 96 268

65836 686860 5218804 268 63247816 0 0 0 268

13942472 912 40688 3796 7296 6796 28768 6892 6796

0 0 5445248 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0

*Init* *Sched* *Dead* Load Meter OSPF Hello Check heaps Chunk Manager Pool Manager Timers

16815220 Total

Inicialmente, este comando informa a quantidade total de memria no sistema e as quantidades de memria livre e em utilizao no momento de sua execuo. Em seguida uma tabela com os processos que esto carregados na memria apresentada. Os campos Allocated, Freed e Holding so explicados na Tabela 10-9. Campo Allocated Freed holding Descrio Quantidade de bytes da memria alocados para o processo. Quantidade de bytes da memria liberados pelo processo, independente de os tenha alocado. Quantidade de memria correntemente em uso pelo processo.

Tabela 10-9: Descrio de alguns campos da tabela apresentada pelo comando show processes memory.

Na maioria dos comutadores Cisco o comando a seguir pode ser executado:

show proc [cpu | mem]

O procedimento apresentado na Seo 10.6 mostra o resultado deste comando com o parmetro cpu. A seguir, veja o resultado deste comando com o parmetro mem:
Console> (enable) show proc mem Total: 10945712, Used: 1438992, Free: 9506720 PID TTY Allocated Freed Holding Process 0 0 706240 2832 703408 idle 1 0 240 0 240 Flash MIB Updat 2 0 164944 164144 800 SynDiags 3 0 208224 2992 205232 SynConfig 4 0 96 0 96 Statuspoll 5 0 2592 2560 32 SWPoll64bCnt 6 0 80 0 80 SL_TASK 7 0 2272 1952 320 RedundantTask

O resultado deste comando oferece estatsticas gerais de uso da memria e estatsticas de alocao da memria por processo. Os campos desta tabela podem ser interpretados como mostrado na Tabela 10-9.

269

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.8 Obtendo utilizao de memria em hospedeiros

Neste procedimento informaremos como podemos obter a utilizao de memria em hospedeiros.

10.8.1 Descrio e dicas

A utilizao de memria, geralmente expressa como um percentual, informa quanta memria um equipamento est utilizando em comparao com a utilizao mxima de memria do equipamento, que teoricamente , 100%. Os sistemas operacionais atuais estendem a memria principal atravs de paginao e do conceito de memria virtual. Com o uso destes mtodos possvel que o tamanho dos processos em execuo em um determinado momento seja maior que o tamanho da memria principal, e ainda que o tamanho de um nico processo seja maior que o tamanho da memria principal. Para estender a memria principal, o sistema operacional faz uso de uma rea do disco rgido para armazenar temporariamente pginas (pedaos de processos em execuo), geralmente chamada rea de swap. Ao transporte de uma pgina que estava no disco rgido para a memria principal chamamos page in. O transporte inverso chama-se page out. Para que um processo seja executado no necessrio que ele, seus dados e sua pilha estejam na memria por completo. Basta que esteja em memria principal apenas as partes que esto realmente em uso no momento. O restante dele fica na rea de swap e trazido para a memria principal quando necessrio. O transporte de pginas da memria para o disco de um processo que ainda est em execuo apenas para liberar espao em memria para novas pginas deste ou de outro processo (page out) s necessria quando a soma dos tamanhos dos processos em execuo ultrapassa a capacidade de armazenamento da memria principal. A realizao constante de page in e page out pode comprometer o desempenho do sistema. Assim, o limiar de utilizao de memria em um hospedeiro no medido pela utilizao da memria em si, mas pela freqncia de paginao. Se voc perceber que o sistema operacional est fazendo paginao sempre, uma investigao mais detalhada deve ser realizada. Caso o paginao s ocorra esporadicamente, voc no tem problemas de memria.

10.8.2 Usando uma estao de gerncia SNMP

Nesta seo apresentamos algumas variveis SNMP que trazem informaes sobre o uso de memria em hospedeiros. Em hospedeiros com agentes SNMP instalados, podemos obter informaes sobre a utilizao de memria atravs de objetos da MIB de Recursos do Hospedeiro (Host Resources MIB) [RFC1514]. Cada linha da tabela hrStorageTable traz informaes de uso de um determinado tipo de dispositivo de armazenamento. Atravs de objetos colunares desta tabela podemos obter informaes de uso da memria principal e da memria virtual de um hospedeiro. A seguir mostramos alguns objetos colunares desta tabela:
270

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

hrStorageType indica o tipo de memria cuja utilizao est sendo

reportada. Neste procedimento estamos interessados em memrias do tipo hrStorageRam e hrStorageVirtualMemory;

hrStorageAllocationUnits informa a quantidade de bytes contidos em

cada unidade de alocao da memria;

hrStorageSize indica a quantidade total de unidade de alocao contidas

na memria;
hrStorageUsed informa a quantidade corrente de unidades de alocao

da memria em uso;
hrStorageAllocationFailures conta quantas vezes um pedido de

alocao de memria no foi atendido devido a falta de recursos. Com estas informaes podemos obter a utilizao de memria de um hospedeiro, como mostrado na Equao 10.7-2. Muitas informaes sobre utilizao de memria esto disponveis na MIB Host Resources, mas infelizmente, a informao que mais nos interessa que a taxa de page out - no est l.

10.8.3 Usando top

Neste procedimento mostraremos como obter a utilizao de memria em hospedeiros com sistema operacional Linux ou Windows NT/2000.
E L
M

A M B I E N T E I N U X

O comando top oferece informaes diversas sobre o sistema. Alm de oferecer estatsticas sobre a utilizao de memria total do sistema, este comando tambm informa quanta memria cada processo em execuo est consumindo. Um exemplo da sada do comando top segue:
maria@server:~$ top 8:42pm up 140 days, 4:35, 2 users, load average: 3.31, 3.45, 3.66

68 processes: 59 sleeping, 9 running, 0 zombie, 0 stopped CPU states: 97.7% user, Mem: Swap: PID 255772K av, 530136K av, USER PRI 16 10 20 9 8 NI 0 0 0 0 0 2.2% system, 0.0% nice, 0.0% idle 2360K buff

249484K used, 3828K used, SIZE 260 RSS 16

6288K free, 526308K free SHARE STAT 4 1160 1156 780 44 R S R R S

0K shrd,

36616K cached LIB 0 0 0 0 0 %CPU 38.2 34.4 13.5 0.2 0.0 %MEM 00.0 7.4 4.2 8.2 0.0 TIME COMMAND

24462 ftp 20259 root 22234 root 12200 root 1 () root

8934m in.ftpd 2:33 0:40 netmngr netmngr

19044 18M 10916 10M 22464 20M 72 64

46:58 named 0:04 init

A primeira linha em destaque traz informaes sobre a memria principal. Inclui quantidade de memria total, disponvel, em uso, compartilhada e usada para buffers. Na segunda linha em destaque encontram-se estatsticas relacionadas
271

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

rea de swap, incluindo o tamanho total desta rea, e quanto desta rea est livre e em uso. Estas duas linhas so exatamente o resultado do comando free. Com o comando top podemos estatsticas gerais de uso da memria e da rea de swap e podemos descobrir que processos esto consumindo mais memria. Olhe como est a utilizao da rea de swap. Quando no passamos nenhum parmetro para o comando top, a tela com estatsticas atualizada a cada 5 segundos. Um que traz informaes mais precisas e interessantes sobre ocorrncia de swap e utilizao da memria o vmstat. Veja uma sada tpica deste comando:
maria@server:~$ vmstat 5 procs r b w 1 2 0 0 0 0 3 0 0 2 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 swpd 2592 2580 2580 2580 2604 2604 memory free buff cache swap si 0 2 0 0 0 0 0 0 0 1 1 2 so bi io bo 28 10 13 3 16 system in 457 121 125 156 148 177 123 123 111 115 114 142 cs 706 42 38 107 56 132 38 29 17 23 22 79 us 20 23 13 48 48 11 13 12 13 10 15 27 cpu sy 10 1 3 33 45 40 21 1 1 1 1 2 id 70 77 84 19 6 49 66 87 86 89 84 72

2164 75204 25404 2144 75204 25124 1928 75204 24972 1120 75204 25300 1132 74460 26524 1136 68336 33188

2 1368 0 0 0 7 8 91

5 1198 0 0 0 0 0 0 0

302 2542 10 0 0 0 2 1 6 16 7 29 5 890

2604 19768 63284 20768 2604 19680 63348 20788 2604 19672 63348 20788 2600 19704 63348 20760 2596 19616 63412 20788 2588 19584 63412 20808

A primeira linha apresenta estatsticas mdias desde a ltima reinicializao da mquina. As demais linhas so adicionadas uma a uma, a cada 5 segundos. Este intervalo de tempo foi passado como parmetro para o comando vmstat. Se nenhum parmetro tivesse sido passado apenas a primeira linha seria apresentada. A partir da segunda linha as estatsticas apresentadas correspondem ao intervalo de tempo passado como parmetro. Observe especialmente as colunas memory e swap. Elas oferecem informaes sobre a utilizao da memria e sobre ocorrncias de swap. Os sub-campos deste comando diretamente relacionados utilizao de memria so apresentados na Tabela 10-10. Campo Procs Memory SubDescrio campos w swpd free Nmero de processos levados para a rea de swap (em disco) mas que esto em execuo. Quantidade de memria virtual em uso (KB). Quantidade de memria livre (KB).

272

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

buff Swap si so

Quantidade de memria usada como buffers (KB). Quantidade de memria transportada do disco para a memria (KB/s). Quantidade de memria transportada da memria para o disco (KB/s).

Tabela 10-10 Descrio de sub-campos do resultado do comando vmstat.

E W
M

A M B I E N T E I N D O W S

Em mquinas Windows 2000 podemos gerar grficos que mostrem page outs/s ao longo do dia e memria disponvel. No menu Iniciar escolha Programas > Ferramentas Administrativas > Desempenho. Na tabela de contadores (painel inferior direito) clique com o boto direito do mouse e escolha o item Adicionar Contadores. Em seguida escolha os seguintes contadores relacionados memria: Available MBytes e Pages Output/sec. Veja um grfico de page out/s e memria disponvel gerado pelo Windows 2000 na Figura 10-2.

Figura 10-2: Grfico de desempenho gerado pelo Windows com contadores de page out/s e memria disponvel.

10.9 Analisando quantidade de trfego de broadcast e

multicast

Neste procedimento analisaremos a quantidade de trfego de difuso e multicast em um domnio de difuso.

10.9.1 Descrio e dicas

Um quadro de broadcast (quadro de difuso) um quadro endereado a todas as estaes que fazem parte do mesmo domnio de difuso do emitente do quadro. Muitos servios de rede dependem de quadros de difuso para seu funcionamento. Dentre estes servios encontram-se: ARP, para mapear endereos IP em endereos MAC;
273

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

RARP, usado para mapear endereos MAC em endereos IP; RIP, divulga rotas atravs de quadros de difuso; DHCP (e BOOTP), para requisitar endereos IP e fornecer respostas; NETBIOS, para divulgar servios, localizar servios, implementar logon e implementar navegao em arquivos atravs da rede. Alguns destes servios (ARP, por exemplo) enviam quadros de difuso nvel 2 onde o endereo de difuso fsico usado e outros enviam quadros de difuso nvel 3 (DHCP, por exemplo) onde o endereo de difuso lgico (255.255.255.255) usado. Um quadro cujo endereo destino fsico o de difuso (FFFFFFFFFFFF) carrega um datagrama IP cujo endereo destino de difuso lgico ou no carrega datagrama IP algum. No primeiro caso h difuso nvel 3 e no seguindo nvel 2. Um quadro multicast um quadro endereado a um subconjunto de todas as mquinas da rede. Um datagrama IP com endereo destino multicast vai atravessar roteadores ao longo de seu caminho. possvel que um roteador intermedirio precise copiar este datagrama e transmiti-lo para vrios outros roteadores. Quando o datagrama multicast chega a um roteador que d acesso a mquinas que desejam receber esse datagrama, o roteador encapsula o datagrama em um quadro com endereo fsico destino multicast e o transmite. Esse quadro vai ser transmitido em um domnio de difuso e um comutador que o receber poder transmiti-lo para vrias de suas portas para que ele chegue em todos os seus destinos. Exemplos de servios que usam multicast so: Cisco Discovery Protocol, OSPF, vdeo-conferncia e outras aplicaes multimdia. Ao receber um quadro de broadcast, um comutador o encaminha para todas as mquinas que fazem parte da VLAN do emissor, atingindo assim todas as mquinas do domnio de difuso. Cada equipamento na rede deve receber e processar o quadro, mesmo que no tenha interesse no mesmo. A existncia de quadros de difuso e multicast na rede absolutamente normal. Mas, quando a quantidade de quadros de broadcast/multicast em uma rede est muito alta dizemos que est ocorrendo uma tempestade de difuso. Em geral, queremos monitorar o trfego de broadcast da rede porque um trfego de difuso muito alto pode saturar os processadores dos equipamentos da rede. isso mesmo: em geral, o efeito negativo de uma tempestade de difuso no a saturao dos enlaces da rede, mas sim a saturao dos processadores dos equipamentos da rede. J vimos na literatura de gerncia de redes que no backbone, em horrios normais de trfego, aceita-se que o trfego de broadcast/multicast consuma at uns 20% da largura de banda dos enlaces. No achamos esta forma de analisar o trfego de broadcast e multicast na rede interessante. A quantidade de largura de banda consumida por trfego de difuso depende de vrios fatores, dentre eles: o tipo das aplicaes sendo utilizadas na rede, o sistema operacional de rede, os protocolos utilizados e o horrio em que o trfego est sendo medido. noite, por exemplo, quase todo o trfego da rede ser resumido a trfego de broadcast/multicast. Por depender de tantos fatores intrnsecos de uma
274

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

determinada rede, no consideramos adequado se falar em percentual mximo aceitvel de trfego de broadcast/multicast. Determinar este percentual uma tarefa complexa e envolve todos os fatores mencionados. Achamos mais interessante estabelecer limiares para a quantidade de quadros de broadcast/multicast por segundo. Equipamentos de tecnologia mais recente podem processar algumas centenas de quadros broadcast/multicast por segundo sem afetar seu desempenho. No entanto, na prtica, estabelecemos limiares menores, entre 100 e 200 quadros de difuso por segundo. Para ter uma idia do que ocorre com a utilizao de CPU de um PC com processador Pentium de 120 MHz e placa de rede 3com Fast Etherlink quando o nmero de quadros de broadcast/multicast por segundo aumenta veja a Tabela 10-11 [DESIGNING-CISCO]: Nmero de quadros broadcast/multicast recebidos por segundo 100 1300 3000 Consumo de CPU 2% 9% 25%

Tabela 10-11: Consumo de capacidade de CPU provocado pelo recebimento de quadros de difuso.

possvel identificar tempestades de difuso sem a utilizao de quaisquer ferramentas de gerncia. Observe os LEDs de dados das portas do comutador. Durante tempestades de difuso todos os LEDs de atividade nas portas piscam ao mesmo tempo muitas vezes em curtos espaos de tempo. Algumas vezes chegamos a ter a impresso de que os LEDs esto constantemente acesos durante algum tempo. Esta uma forma ad hoc de identificar tempestades de difuso. Para certificar-se de que a tempestade est ocorrendo necessrio realizar alguns clculos, que nos informe a quantidade mdia de quadros de difuso por segundo que trafega na rede. A quantidade mdia de quadros broadcast e multicast por segundo em uma rede pode ser calculado segundo a Equao 10.9-1 e a Equao 10.9-2:
Broadcasts por segundo = Qtde. de quadros broadcast recebidos e transmitidos em T Qtde. de segundos em T Equao 10.9-1 Multicasts por segundo = Qtde. de quadros multicast recebidos e transmitidos em T Qtde. de segundos em T Equao 10.9-2

possvel ainda que as equaes acima sejam unidas em uma nica equao que oferea a quantidade de quadros de broadcast e multicast que trafegam na rede por segundo. Veja a Equao 10.9-3:
275

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Multicasts/Broadcasts por segundo =

Qtde. de quadros multicast e broadcast recebidos e transmitidos em T Qtde. de segundos em T Equao 10.9-3

Na realidade, as informaes sobre o trfego de difuso so obtidas por interface. Desta forma, podemos separar o trfego de difuso em trfego de entrada e sada: quantidade de quadros de broadcast recebidos por segundo, quantidade de quadros de broadcast transmitidos por segundo e assim por diante. Esta separao bastante interessante, porque durante uma tempestade de difuso podemos ter uma idia de onde os quadros de difuso esto vindo. Veja as equaes a seguir:
Broadcasts por segundoin = Qtde. de quadros broadcast recebidos em T Qtde. de segundos em T Equao 10.9-4 Broadcasts por segundoout = Qtde. de quadros broadcast transmitidos em T Qtde. de segundos em T Equao 10.9-5 Multicasts por segundoin = Qtde. de quadros multicast recebidos em T Qtde. de segundos em T Equao 10.9-6 Multicasts por segundoout = Qtde. de quadros multicast transmitidos em T Qtde. de segundos em T Equao 10.9-7

interessante que uma estao de gerncia apresente um grfico do trfego de quadros de broadcast e multicast por segundo pelo menos nos enlaces de backbone. Nas sees a seguir veremos como obter os termos das equaes apresentadas nesta seo.

10.9.2 Usando uma estao de gerncia SNMP

Nesta seo veremos como obter o trfego de quadros de broadcast/multicast em uma rede com o auxlio de uma estao de gerncia SNMP. Ser tambm apresentado como configurar um alarme RMON que dispare quando a quantidade de quadros de difuso da rede for muito grande. Alguns dos objetos que informam a quantidade de quadros de broadcast/multicast em uma rede j foram mencionados em procedimentos passados. Eles fazem parte do grupo Interfaces da MIB-2 [RFC2233]. So eles: ifInBroadcastPkts, ifOutBroadcastPkts, ifInMulticastPkts e ifOutMulticastPkts. No antigo grupo Interfaces da MIB-2 [RFC1213], apenas dois objetos so utilizados: ifInNUcastPkts e ifOutNUcastPkts. Todos estes objetos so do tipo contador. As variaes destes contadores no tempo significam:
276

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

ifInBroadcastPkts a quantidade de quadros com endereos destino broadcast que chegaram na interface durante um certo intervalo de tempo e foram entregues a protocolos da camada superior; ifInMulticastPkts a quantidade de quadros com endereos destino multicast que chegaram na interface durante um certo intervalo de tempo e foram entregues a protocolos da camada superior; ifOutBroadcastPkts a quantidade total de quadros com endereos destino broadcast cuja transmisso foi solicitada por protocolos de nvel superior em um determinado intervalo de tempo. So includos tambm os quadros com endereo destino broadcast descartados ou no enviados; ifOutMulticastPkts a quantidade total de quadros com endereos destino multicast cuja transmisso foi solicitada por protocolos de nvel superior em um determinado intervalo de tempo. So includos tambm os quadros com endereo destino broadcast descartados ou no enviados;
broadcast ou multicast entregues a camadas superiores em um
ifOutNUcastPkts a quantidade total de quadros com endereos destino broadcast ou multicast cuja transmisso foi solicitada por protocolos de nvel superior em um determinado intervalo de tempo. So includos tambm os quadros com endereo destino broadcast ou multicast descartados ou no enviados. ifInNUcastPkts o nmero de quadros com endereo destino

determinado intervalo de tempo;

O denominador das equaes apresentadas na Seo DESCRIO E DICAS de deve ser o nmero de segundos contidos entre duas coletas de dados SNMP. Vejamos um exemplo: suponha que sua estao de gerncia est coletando dados SNMP a cada 5 minutos (300 segundos); em um certo momento T0 os seguintes valores foram obtidos:
o ifInBroadcastPkts0 = 1200

o ifOutBroadcastPkts0 = 600 o ifInMulticastPkts0 = 4 o ifOutMulticastPkts0 = 4 5 minutos depois, em T1, os seguintes valores foram obtidos: o ifInBroadcastPkts1 = 20200 o ifOutBroadcastPkts1 = 30800
277

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

o ifInMulticastPkts1 = 34
o ifOutMulticastPkts1 = 34

Substitumos os valores encontrados na Equao 10.9-1 e Equao 10.9-2 e obtivemos o seguinte:

Broadcasts por segundo = (20200 1200) + (30800 600) 300 (34 4) + (34 4) 300 = 164 broadcasts por segundo

Multicasts por segundo =

= 0,2 multicasts por segundo

Note que a quantidade mdia de quadros de broadcasts por segundo trafegando na rede est comeando a ficar alta. interessante criar alarmes RMON que gerem eventos de notificao para a estao de gerncia quando o nmero de quadros de broadcast e multicast por segundo estiver alto. Veja na Tabela 10-12 e na Tabela 10-13 alguns dados dos alarmes a serem configurados na sonda RMON: Varivel a ser monitorada: ifInBroadcastPkts Tipo: deltaValue Intervalo: 600 segundos (10 minutos) Limiar crescente: 60000 Limiar decrescente: 60000
Tabela 10-12: Dados para configurao de alarme para trfego de quadros de broadcast de entrada.

Varivel a ser monitorada: ifOutBroadcastPkts Tipo: deltaValue Intervalo: 600 segundos (10 minutos) Limiar crescente: 60000 Limiar decrescente: 60000
Tabela 10-13: Dados para configurao de alarme para trfego de quadros de broadcast de sada.

Os mesmos alarmes podem ser configurados para quadros multicast. Configure os alarmes para enviar notificaes para a estao de gerncia quando os limiares crescente e decrescente forem excedidos.

278

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.9.3 Usando uma interface de linha de comando

Nesta seo, mostraremos quais comandos em roteadores e comutadores Cisco oferecem contadores de quadros de broadcast e multicast. Se voc possui equipamentos produzidos por outro fabricante, procure nos manuais de seus equipamentos os comandos correspondentes aos apresentados aqui. Em roteadores Cisco com verso de IOS 10.0 ou superior execute o seguinte comando:
show ip traffic

Veja um exemplo da resposta deste comando:

roteador> show ip traffic IP statistics: Rcvd: 2593286165 total, 10600762 local destination 0 format errors, 0 checksum errors, 885818 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 32532 with options Opts: 72 end, 1 nop, 4 basic security, 0 loose source route 0 timestamp, 0 extended security, 3 record route 0 stream ID, 0 strict source route, 32459 alert, 0 cipso 0 other Frags: 0 reassembled, 1 timeouts, 226 couldn't reassemble 496166 fragmented, 0 couldn't fragment Bcast: 58033 received, 12 sent Mcast: 1893437 received, 3482544 sent ()

Este comando oferece estatsticas sobre o trfego IP do roteador. Ele no separa o trfego por interface. O comando a seguir tambm pode ser utilizado em roteadores Cisco com IOS verso 10.0 ou superior:
interfaces [tipo da interface] [nmero da interface]

Este comando separa o trfego por interface, mas apresenta apenas a quantidade de quadros de broadcast e multicast recebidos pela interface. Em comutadores Cisco execute o comando a seguir:
show mac [mdulo[/porta]]

O comando abaixo tambm pode ser executado em comutadores cisco com verso de software superior a 6.1:
show port mac [mdulo]/porta]]

Veja um exemplo da execuo do comando show port mac:

Console> show port mac 1 Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast

279

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

-------- -------------------- -------------------- -------------------1/1 121200 0 5210 1/2 5800 1 2340 1/3 198210 6 72150 1/4 3450 10 1120 Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- -------------------1/1 15230 0 2140 1/2 3280 1 125910 1/3 190210 4 12580 1/4 2160 5 46780 ()

Substitua os valores obtidos atravs da interface de linha de comando nas equaes apresentadas na Seo DESCRIO E DICAS.

10.9.4 Usando um analisador de protocolos

Nesta seo veremos como obter o trfego de broadcast/multicast por segundo com o auxlio de um analisador de protocolos. Conecte o analisador de protocolos no domnio de difuso que voc deseja estudar. Se for conectar o analisador em um comutador certifique-se de que est conectando o analisador na VLAN correta. No Sniffer, da Network Associates, use a funo de amostragem histrica para gerar um grfico que apresente a quantidade de broadcasts/s e multicasts/s no tempo. Na Figura 10-3 encontra-se um grfico de broadcasts/s gerado pelo Sniffer. Se voc observar Na Seo UTILIZANDO UM ANALISADOR DE PROTOCOLOS voc encontrar dicas de como utilizar esta funcionalidade. Voc tambm pode optar por apenas observar o contador de quadros broadcast e multicast no painel de detalhes do Sniffer.

Figura 10-3: Grfico de broadcasts/s gerado pelo Sniffer.

10.9.5 Usando outras ferramentas de gerncia

Nesta seo veremos outras ferramentas que podem ser utilizadas em mquinas Windows para a obteno do trfego de broadcast/multicast na rede. Use o comando netstat como exemplificado a seguir:
280

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

C:\WINNT>netstat -ne Estatsticas de interface Bytes Pacotes unicast Pacotes no unicast Descartados Erros Prot. Desconhecidos Recebido 242119 516 24 1 2 23 Enviado 30360 451 32 1 0

Com os dados obtidos voc pode encontrar a mdia de quadros broadcast/multicast recebidos e transmitidos por segundo pela mquina em um determinado intervalo de tempo. Ver Equao 10.9-3.

10.10 Obtendo utilizao de enlaces

Como calcular a utilizao de enlaces? A partir de que valor consideramos a utilizao de um enlace half duplex elevada? E de um enlace full duplex? Neste procedimento responderemos a todas estas questes.

10.10.1 Descrio e Dicas

Medir a utilizao dos recursos da rede ajuda a descobrir quo congestionada ela est. Geralmente a utilizao calculada como uma percentagem, que comparada utilizao mxima do recurso, que teoricamente 100%. Neste procedimento voc vai aprender como calcular a utilizao de enlaces. Outros procedimentos indicam como calcular a utilizao de CPU e de memria. A utilizao de enlaces a medida mais utilizada para verificar a utilizao de uma rede. Na prtica, aps uma certa taxa de utilizao de enlace, o desempenho da rede fica comprometido. O grfico apresentado na Figura 10-4 mostra uma curva tpica do tempo de resposta em funo da utilizao do enlace.

Figura 10-4: grfico tempo de resposta x utilizao de enlaces.

281

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Este grfico apresenta um joelho. Com utilizao menor que o joelho (uns 70% para segmentos com acesso ao meio no compartilhado), o desempenho mdio e a variabilidade do tempo de resposta so bons. No entanto, com utilizao maior que o joelho, a mdia e a variabilidade ficam bem piores. Veja o grfico da Figura 10-5. Aps uma certa taxa de utilizao do enlace (o joelho do grfico), ao aumentar um pouco a utilizao o aumento do tempo de resposta correspondente bastante grande.

Figura 10-5: variabilidade do tempo de resposta em funo da utilizao do enlace.

Tratando-se de enlaces Ethernet compartilhados (half duplex), o joelho do grfico encontra-se quando a utilizao ainda est em 50%. Neste caso, o aumento da taxa de utilizao tambm acompanhado pelo aumento da taxa de colises. Para tecnologias compartilhadas o grfico mostrado na Figura 10-6.

Figura 10-6: grfico de tempo de resposta x utilizao de enlace para enlaces de acesso compartilhado.

Em resumo, para enlaces full duplex ou de acesso ao meio no compartilhado uma utilizao de at 70% aceitvel. Quando se trata de enlaces half duplex, utilizao maior que 50% j alarmante. O modo de operao da interface influencia no clculo da taxa de utilizao. Para interfaces que trabalham no modo half duplex, utilize a Equao 10.10-1:
282

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

qtde de bytes recebidos em T + qtde de bytes transmitidos em T Utilizao (%)= x 8 x 100 T x velocidade de operao da interface Equao 10.10-1

Quando se trata de interfaces full duplex, o clculo da utilizao fica um pouco diferente. Considere, por exemplo, um meio Fast Ethernet operando em modo full duplex. Significa que a velocidade do canal de 100Mbps para transmisso e 100Mbps para recepo, resultando em uma capacidade combinada de 200Mbps. Existem duas formas de se calcular a utilizao de enlaces full duplex. Uma delas (Equao 10.10-2) considera apenas uma direo de transmisso: a que estiver com maior trfego. A forma mais utilizada (Equao 10.10-3 e Equao 10.10-4) separa a taxa de utilizao de entrada da taxa de utilizao de sada. Veja as equaes a seguir:
Utilizao (%) = max(qtde de bytes recebidos em T, qtde de bytes transmitidos em T) T x velocidade de operao da interface Equao 10.10-2 qtde de bytes recebidos em T T x velocidade de operao da interface Equao 10.10-3 qtde de bytes transmitidos em T T x velocidade de operao da interface Equao 10.10-4 x 8 x 100

Utilizao de entrada (%) =

x 8 x 100

Utilizao de sada (%) =

x 8 x 100

A separao da utilizao de entrada e sada tambm pode ser aplicada a enlaces half duplex. Na realidade, mais freqente e interessante que a utilizao de entrada e sada sejam calculadas separadamente, independentemente do modo de operao do enlace. Nas sees seguintes voc aprender como obter os termos das equaes apresentadas acima. Substitua-os adequadamente e obter a taxa de utilizao desejada.

10.10.2 Usando uma estao de gerncia SNMP

Nesta seo voc vai aprender como calcular a utilizao de enlaces com o auxlio de uma estao de gerncia SNMP. Apresentaremos tambm que alarmes relacionado utilizao de enlaces podem ser configurados em uma sonda RMON. Voc pode calcular a utilizao de seus enlaces com o auxlio dos seguintes objetos do grupo Interfaces da MIB-2 [RFC2233]:
283

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

ifInOctets contador de bytes recebidos por uma interface. Por ser um contador, a diferena entre os valores de ifInOctets obtida entre

duas coletas consecutivas que deve ser utilizada no clculo;

ifOutOctets contador de bytes que saem de uma interface. Por ser um contador, a diferena entre os valores de ifOutOctets obtida entre

duas coletas consecutivas que deve ser utilizada no clculo;

ifSpeed a velocidade na qual a interface est operando.

Para realizar o clculo da utilizao voc ter que coletar o valor dos objetos ifInOctets e ifOutOctets em dois momentos distintos. O intervalo de tempo entre as duas coletas de dados SNMP o T de sua equao. Por exemplo, suponha que sua estao de gerncia SNMP coleta dados de 5 em 5 minutos. Em uma primeira coleta voc obteve os seguintes valores:
ifInOctets = 200 ifOutOctets = 3010 ifSpeed = 100000000

Numa segunda coleta os valores dos mesmos objetos (da mesma interface) foram:
ifInOctets = 1225500000 ifOutOctets = 450500000 ifSpeed = 100000000

Voc ento obtm a utilizao de entrada e sada da interface:

Utilizao de entrada (%) = (1225500000 200) x 8 x 100 300 x 100000000 (450500000 3010) x 8 x 100 300 x 100000000 32,68%

Utilizao de sada (%) =

12,01%

Outros objetos do grupo Interfaces podem tambm ser utilizados. Eles possuem o mesmo significado dos objetos descritos acima, porm podem atingir valores superiores, pois so representados por contadores de 64 bits, e no 32 bits como os descritos anteriormente. Os objetos so: ifHCInOctets, ifHCOutOctets e ifHighSpeed. Para interfaces que operam em velocidades inferiores a 20 Mbps os contadores de 32 bits devem ser utilizados. Para interfaces que operam alm de 20 Mbps e aqum de 650 Mbps, contadores de quadros de 32 bits e contadores de octetos de 64 bits devem ser utilizados. Para contadores de octetos de 64 bits devem ser utilizados. Finalmente, contadores de 64 bits devem ser utilizados em se
284

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

tratando de interfaces que operam alm de 650 Mbps. Veja mais informaes em [RFC2233], seo Counter size. Com o auxlio de uma sonda RMON pode-se calcular a utilizao de um segmento Ethernet mais precisamente, atravs da Equao 10.10-5 [RFC1757]:
Utilizao (%) = [etherStatsPkts x (96 + 64)] + (etherStatsOctets x 8) T x velocidade de operao do enlace Equao 10.10-5 x 100

Onde:
etherStatsPkts o contador de pacotes recebidos na rede; etherStatsOctets o contador de octetos recebidos na rede;

entre um quadro e outro existe um intervalo de pelo menos 96 bits e antes de cada quadro existe um prembulo de 64 bits. Por isso estes valores so somados e multiplicados pela quantidade de quadros na rede: quanto se gasta com essas informaes de controle. Se voc tem uma sonda RMON monitorando um enlace, configure alarmes que disparem baseados na quantidade de octetos que entram e saem em uma interface. Para os enlaces full duplex os dados de cada alarme a ser configurado podem ser os apresentados na Tabela 10-14 e Tabela 10-15. Varivel a ser monitorada: ifInOctets Tipo: deltaValue Intervalo: 600 segundos (10 minutos) Limiar crescente: velocidade de operao do enlace x 0,7 x 600
8

Limiar decrescente: 0
Tabela 10-14 Dados para configurao de alarme de utilizao de entrada em enlaces full duplex.

Varivel a ser monitorada: ifOutOctets Tipo: deltaValue Intervalo: 600 segundos (10 minutos) Limiar crescente:
velocidade de operao do enlace x 0,7 x 600 8

Limiar decrescente: Idem limiar crescente

Tabela 10-15: Dados para configurao de alarme de utilizao de sada em enlaces full duplex.

Para enlaces half duplex configure um alarme com os seguintes dados: Varivel a ser monitorada: etherStatsOctets
285

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Tipo: deltaValue Intervalo: 600 segundos (10 minutos) Limiar crescente:

velocidade de operao do enlace x 0,5 x 600 8

Limiar decrescente: Idem limiar crescente

Tabela 10-16: Dados para configurao de alarme de utilizao em enlaces half duplex.

Configure estes alarmes para gerar notificaes de alarmes (traps) para a sua estao de gerncia SNMP. Desta forma, sempre que um enlace passar 10 minutos com utilizao mdia superior ao limiar de 70% para enlaces half duplex ou 50% para enlaces half duplex, sua estao de gerncia ser avisada.

10.10.3 Usando uma interface de linha de comando

Roteadores e comutadores possuem comandos que informam valores de contadores de bytes de entrada e sada em suas interfaces. Nesta seo apresentaremos alguns comandos que podem ser executados em roteadores/comutadores Cisco com o intuito de obter dados para o clculo da utilizao de enlaces. Em roteadores Cisco com IOS 10.0 ou superior use o comando a seguir:
roteador# show interface [tipo da interface] [nmero da interface]

No exemplo a seguir so obtidas informaes sobre a interface Fast Ethernet 1/1/0 de um roteador Cisco:
roteador>show inter FastEthernet 1/1/0 1. 2. 3. 4. 5. 6. 7. 8. 9. FastEthernet1/1/0 is up, line protocol is up Hardware is cyBus FastEthernet Interface, address is 0003.2853.0931 (bia 0003.2853.0931) Internet address is 192.168.4.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 10/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Half-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never

10. Last clearing of "show interface" counters never 11. Queueing strategy: fifo 12. Output queue 0/40, 98 drops; input queue 0/75, 0 drops 13. 5 minute input rate 901000 bits/sec, 566 packets/sec 14. 5 minute output rate 4104000 bits/sec, 678 packets/sec 15. 2159137620 packets input, 346328816 bytes, 0 no buffer 16. Received 1026648 broadcasts, 0 runts, 0 giants, 0 throttles 17. 0 input errors, 0 CRC, 4 frame, 0 overrun, 0 ignored 18. 0 watchdog, 0 multicast 19. 0 input packets with dribble condition detected 20. 1784610 packets output, 142194201 bytes, 0 underruns 21. 1664 output errors, 48521009 collisions, 11 interface resets 22. 0 babbles, 0 late collision, 0 deferred 23. 1663 lost carrier, 0 no carrier

286

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

24. 0 output buffer failures, 0 output buffers swapped out0

Este comando oferece muito mais informaes que simplesmente a quantidade de bytes de entrada e sada. Em negrito esto as informaes que devem ser buscadas quando se deseja calcular a utilizao da interface. As linhas foram numeradas para facilitar a discusso a seguir. Com a taxa de entrada e de sada da interface e sua velocidade de operao podemos calcular a utilizao mdia de entrada e sada de um enlace para o intervalo de tempo T. O clculo pode ser feito como apresentado na Equao 10.10-6 e Equao 10.10-7:
Utilizao de entrada (%)= taxa de entrada de dados Velocidade da interface x 100

Equao 10.10-6 taxa de entrada de dados (bits/s) Velocidade da interface Equao 10.10-7

Utilizao de sada (%) =

x 100

Nas linhas 13 e 14 so dadas as taxas mdias de entrada e sada dos ltimos 5 minutos e na linha 7 a velocidade de operao do enlace. Considerando estas informaes vamos calcular a utilizao de entrada e sada do enlace. Para tal substitua os dados obtidos na Equao 10.10-6 e na Equao 10.10-7. Chegamos s seguintes taxas de utilizao de entrada e sada do enlace para os ltimos 5 minutos:
Utilizao de entrada = 901000 x 100 10000000 4104000 x 100 100000000 = 0,901%

Utilizao de sada =

= 4,104%

Voc pode tambm obter os valores dos contadores de bytes de entrada e de sada apresentados nas linhas 15 e 20 respectivamente para calcular a taxa de utilizao do enlace como apresentado na Equao 10.10-1, Equao 10.10-2 ou Equao 10.10-3 e Equao 10.10-4. Lembre-se que estes dados tratam-se de contadores, e portanto a sua variao em um determinado intervalo de tempo que deve ser considerada. Em comutadores Cisco Catalyst com verso de software superior a 6.2 os seguintes comandos podem ser executados:
show mac [mdulo[/porta]] show mac utilization [mdulo[/porta]] show port mac [modulo[/porta]] (6.2 e superiores)

287

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Todos eles oferecem contadores de bytes de entrada e sada. Os dois ltimos comandos s existem para comutadores com software verso 6.2 ou superiores. Uma outra informao ainda necessria para o clculo da utilizao de enlaces: a velocidade de operao da interface. Use o comando a seguir para obter esta informao:
show port status [mdulo[/porta]]

Por exemplo, para obter contadores de trfego de entrada e sada da porta 1 do mdulo 1 execute:
Console> show mac utilization 1/1 Console> show port status 1/1

Alm dos comandos descritos acima, existe ainda um outro comando que oferece todas as informaes necessrias para o clculo da utilizao de um enlace:
Console> show counters [mdulo[/porta]

Este comando existe na maioria dos comutadores Cisco. Ele fornece contadores relacionados a uma porta ou todas as portas de um mdulo. Muitos contadores so apresentados, dentre eles contadores de octetos de entrada e sada. Com os dados obtidos atravs da interface de linha de comando voc pode se basear nas equaes apresentadas na Seo DESCRIO E DICAS para obter a taxa de utilizao de um enlace de um comutador Cisco. Se seus equipamentos de interconexo no so fabricados pela Cisco, procure no manual do seu equipamento os comandos que lhe oferecem estatsticas de trfego e velocidade de operao de interfaces.

10.10.4 Usando um analisador de protocolos

Nesta seo veremos como obter a utilizao de um enlace com o auxlio de um analisador de protocolos. O primeiro passo conectar o analisador de forma que ele enxergue apenas os dados da porta cuja utilizao voc quer medir. Veja UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Aps conectar o analisador, verifique as estatsticas apresentadas por ele. No Sniffer da NAI, um painel com a utilizao apresentado enquanto o enlace monitorado. Neste mesmo painel voc pode escolher ver os detalhes, onde a utilizao tambm apresentada. Se voc achar que a utilizao est muito alta, capture dados durante alguns minutos. Aps encerrada a captura, verifique quem foram os dez maiores transmissores (tabela Host Table) durante a captura. Veja tambm se os dados foram especficos de um determinado servio (a tabela Matrix pode ser til).

288

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.10.5 Usando outras ferramentas de gerncia

Esta seo lhe oferece algumas dicas de como obter os dados que so necessrios para o clculo da utilizao de enlaces em estaes de trabalho que no possuem agente SNMP instalado. Lembre-se: o ideal que pelo menos nos servidores de sua rede existam agentes SNMP instalados e que a taxa de utilizao seja obtida atravs de uma estao de gerncia SNMP. Em mquinas Linux use o seguinte comando:
maria@server:~$ ifconfig eth0
25. eth0 26. 27. 28. 29. 30. 31. 32. Link encap:Ethernet HWaddr 00:04:AC:4C:98:DF Bcast:192.168.5.255 MTU:1500 Mask:255.255.255.0 Metric:1 inet addr:192.168.5.1

UP BROADCAST RUNNING MULTICAST

RX packets:2739527 errors:0 dropped:0 overruns:0 frame:0 TX packets:2240473 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:538341940 (513.4 Mb) TX bytes:1142036917 (1089.1 Mb)

Interrupt:15 Base address:0x2180

Na linha 7 voc encontra um contador de bytes de entrada e de sada para a interface. Estes contadores podem ser utilizados no clculo da taxas de utilizao de entrada e sada do enlace. Voc precisa saber tambm qual a velocidade e o modo de operao da interface. Se voc deseja calcular a taxa de utilizao de uma interface ligada a uma porta de um comutador ou de um roteador, verifique no comutador/roteador qual o modo e a velocidade de operao da porta em questo (ver pgina 286). Se a interface est ligada a um repetidor, o modo de operao half duplex. Se a placa de rede 10 Mbps a velocidade ser esta. Se a placa de rede 10/100Mbps ela provavelmente vai negociar com o outro lado a velocidade. Se o repetidor tambm 10/100 Mbps, a velocidade ser 100 Mbps. Caso contrrio a velocidade ser 10 Mbps. Esta anlise vale tambm para mquinas Windows. Mas no Windows, em geral, podemos ver a velocidade e o modo de configurao (se no estiver configurado para negociao automtica) nas propriedades avanadas do adaptador de rede instalado. Em mquinas Windows use o comando a seguir para obter contadores de bytes de entrada e sada em interfaces:
C:\WINDOWS>netstat -ne Estatsticas de interface Recebido Bytes 82161 Pacotes unicast 447 Pacotes no unicast 38 Descartados 0 Erros 0 Prot. desconhecidos 48

Enviado 31128 503 38 0 0

Lembre-se que os valores oferecidos por estes comandos so contadores e, portanto, apenas sua variao no tempo tem algum significado. Obtendo-se a variao destes contadores durante um determinado intervalo de tempo, e
289

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

conhecendo a velocidade da interface voc pode calcular a taxa de utilizao da interface para este intervalo de tempo. Para tal as equaes apresentadas na Seo DESCRIO E DICAS devem ser usadas.

10.11 Verificando existncia de quadros muito longos

Este procedimento deve ser seguido quando queremos verificar a existncia de quadros muito grandes na rede. Na Seo DESCRIO E DICAS explicaremos o que um quadro muito longo e em que circunstncias eles podem aparecer na rede. Nas sees seguintes daremos dicas de como verificar a ocorrncia de quadros muito longos com o auxlio de uma estao de gerncia SNMP, de uma interface de linha de comando e de um analisador de protocolos.

10.11.1 Descrio e Dicas

Quadros Ethernet podem ter um tamanho mximo de 1518 bytes. Quadros maiores que este tamanho so considerados muito longos, ou quadros gigantes. Tipicamente, quadros muito longos so emitidos por interfaces de rede defeituosas. Quadros muito longos tambm podem ser enviados ocasionalmente quando um computador ligado ou reiniciado. Alguns testes em interfaces consistem em preencher o buffer da interface com bits 0s ou 1s e em seguida enviar todo o contedo do buffer como um quadro longo [GUIAETHERNET]. Se vrios quadros muito grandes esto sempre presentes na rede uma investigao deve ser realizada, pois a presena contnua destes quadros indica problema. Se alguns poucos quadros muito grandes aparecem esporadicamente, no se preocupe.

10.11.2 Usando uma estao de gerncia SNMP

Nesta seo veremos quais objetos SNMP indicam a ocorrncia de quadros muito longos na rede. As MIBs Ether-like [RFC2665] e RMON [RFC1757] oferecem objetos que contam a quantidade de quadros muito longos recebidos. O objeto dot3StatsFrameTooLongs da MIB Ether-like incrementado sempre que um quadro maior que 1518 bytes recebido pela interface. Nesta MIB no h separao de quadros muito longos com ou sem erros de CRC ou alinhamento. J na MIB RMON, dois objetos indicam o recebimento de quadros muito longos: etherStatsOversizePkts e etherStatsJabbers. O objeto etherStatsOversizePkts incrementado sempre que um quadro maior que 1518 bytes sem erros de CRC ou alinhamento recebido pela interface. J o objeto etherStatsJabbers incrementado apenas quando um quadro muito longo com erro de CRC ou alinhamento recebido.

290

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Se os contadores apresentados estiverem crescendo rapidamente, voc tem muito provavelmente uma interface defeituosa em sua rede. Um grfico de quadros muito longos por segundo pode ser gerado pela estao de gerncia. Na maior parte do tempo, nenhum quadro longo deve ser encontrado.

10.11.3 Usando uma interface de linha de comando

Nesta seo veremos quais comandos podemos executar em roteadores e comutadores Cisco para verificar a presena de quadros muito longos na rede. Em roteadores Cisco com verso de IOS superior a 10.0 execute o comando a seguir:
show interfaces [tipo da interface] [nmero da interface]

Veja abaixo um exemplo da execuo deste comando:

roteador> show interface FastEthernet 1/0/0 FastEthernet1/0/0 is up, line protocol is up () 5 minute input rate 2984000 bits/sec, 916 packets/sec 5 minute output rate 5099000 bits/sec, 987 packets/sec 407408230 packets input, 3004139350 bytes, 0 no buffer Received 87505 broadcasts, 0 runts, 1 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast ()

Em negrito destacamos o contador que informa a quantidade de quadros maiores que 1518 bytes recebidos pela interface. Se este contador estiver sendo continuamente incrementado uma investigao deve ser iniciada. Na maioria dos comutadores Cisco execute o seguinte comando:
show port [mdulo[/porta]]

Veja a seguir um exemplo da resposta deste comando:

Console> show port 9/5 Port Name Status Vlan Duplex Speed Type ----- ------------------ ---------- ---------- ------ ----- -----------9/5 connected 1 auto auto 10/100BaseTX () Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize ----- ---------- ---------- ---------- ---------- --------9/5 1 2 1 2 2 Port Single-Col Multi-Coll Late-Coll Excess-Col Carri-Sen Runts Giants ----- ---------- ---------- ---------- ---------- --------- ----- ------9/5 32 0 0 0 0 30 2 Last-Time-Cleared -------------------------Wed Mar 13 2002, 21:57:31

291

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

O contador de quadros maiores que 1518 bytes recebidos pela interface 9/5 est em destaque (negrito). Verifique se ele est sendo incrementado continuamente.

10.11.4 Usando um analisador de protocolos

Nesta seo veremos como observar a presena de quadros muito longos com o auxlio de um analisador de protocolos. Conecte o analisador de protocolos como descrito no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Verifique na tabela de detalhes do painel do Sniffer os contadores intitulados Oversize e Jabber. Estes contadores esto em destaque na Figura 10-7. Se estes contadores estiverem crescendo rpida e continuamente, provvel que exista em sua rede uma ou mais interfaces defeituosas.

Figura 10-7: Painel de estatsticas detalhadas do Sniffer.

Se voc estiver preocupado com a quantidade de quadros muito longos em sua rede, pode usar a funcionalidade de amostragem histrica do Sniffer para analisar esse trfego. O Sniffer pode gerar para voc um grfico que mostre a quantidade de quadros muito longos por segundo (jabbers/s e oversizes/s) durante um intervalo de tempo de, no mximo, 15 horas. Use este grfico para analisar melhor a quantidade de quadros muito longos por segundo em sua rede. Se sempre existirem quadros muito longos em sua rede, algum equipamento est com problema.

10.12 Obtendo NEXT e atenuao em cabos de pares tranados

Neste procedimento sero apresentados os conceitos de NEXT (near end crosstalk) e atenuao e como verificar se um cabo de pares tranados apresenta NEXT e atenuao fora das especificaes do padro.

10.12.1 Descrio e Dicas

Nesta seo, explicaremos o que NEXT e atenuao. Na seo seguinte descreveremos que ferramentas utilizar para verificar se um cabo de pares tranados apresenta NEXT e atenuao fora dos limites de padronizao do cabo.
292

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Sempre que uma corrente percorre um fio, um campo eletromagntico gerado. Este campo pode causar interferncia com os sinais dos fios adjacentes. Os fios metlicos dos cabos de pares tranados so enrolados entre si (dando a aparncia de uma trana) para que os campos eletromagnticos opostos gerados pela corrente que percorre os fios se cancelem. Quanto mais apertada a trana, mais eficaz ser o cancelamento dos campos, e mais altas taxas de dados sero suportadas pelo cabo. Quando os fios no esto bem tranados, o resultado o NEXT. Em cabos de pares tranados usados em redes locais, NEXT ocorre quando um sinal de um dos pares de fios apanhado por um par de fios adjacente. NEXT , ento, a poro de sinais transmitidos que acoplada aos sinais recebidos [CABLETESTING-NEXT]. NEXT medido em decibis (dB). Considere Ainjetado como sendo a amplitude do sinal injetado e Ainduzido como a amplitude do sinal induzido no par de fios adjacente. Idealmente, queremos que Ainduzido seja zero. Veja como NEXT calculado na Equao 10.12-1:
NEXT (dB) = 20 log Ainduzido Ainjetado

Equao 10.12-1

Como Ainduzido < Ainjetado, o resultado ser um nmero negativo. Note tambm que quanto menor for o valor de Ainjetado (menor induo), maior ser o mdulo do resultado (mdulo de NEXT). Assim, queremos que o valor do NEXT seja muitos decibis (negativos), o que significa muita perda entre um par e outro (ou pouco acoplamento). Todos os sinais eletromagnticos perdem um pouco de sua fora medida que se propagam pelo meio. Por esta razo, os sinais que se propagam de uma extremidade a outra de um cabo de pares tranados chegam na extremidade final com um pouco menos de fora. A atenuao justamente a perda de potncia que o sinal sofre ao longo do caminho entre o transmissor e o receptor. Quanto mais forte a atenuao, mais fraco ser o sinal na extremidade receptora. A atenuao, assim como o NEXT, medida em decibis (dB). Como a atenuao significa uma perda, ela expressa sempre por valores negativos. Quanto menor a perda melhor. Considere Aentrada como sendo a amplitude do sinal injetado no incio do cabo e Asada a amplitude do sinal na sada. Idealmente queremos que Asada seja igual a Aentrada, o que significa que ao houve atenuao. Veja como a atenuao calculada na Equao 10.12-2:
Atenuao (dB) = 20 log Asada Aentrada

Equao 10.12-2

Se Asada = Aentrada, teramos atenuao zero, pois log 1 = 0. Como, na prtica, Asada < Aentrada, o resultado ser um nmero negativo. Note que quanto menor
293

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

for a diferena Asada Aentrada (pouca atenuao) mais prximo de zero estar a atenuao. Assim, queremos que o valor da atenuao prximo de zero (poucos decibis negativos), o que significa pouca perda.

10.12.2 Usando uma ferramenta de certificao

Existem vrios tipos de ferramentas usadas para testar cabos de redes. Estas ferramentas recaem em quatro grandes classes: analisadores de rede, ferramentas portteis de certificao, testadores de cabos e testadores de continuidade. Destas, apenas analisadores de rede e ferramentas de certificao so capazes de medir NEXT e atenuao [FIELD_TEST]. Analisadores de rede so equipamentos caros e requerem uma equipe tcnica altamente treinada para lidar com eles. So ferramentas geralmente utilizadas em laboratrios para avaliar o desempenho de cabos em desenvolvimento [FIELD_TEST]. Por esta razo, no falaremos neste procedimento sobre esse tipo de equipamento. Ferramentas portteis de certificao, por outro lado, podem ser utilizadas por usurios menos sofisticados. Elas so tipicamente utilizadas para verificar se uma infra-estrutura de cabeamento atende aos requisitos impostos pelos padres de cabeamento [FIELD_TEST]. Exemplos de equipamentos de certificao so o OmniScanner e PentaScanner da Microtest e os DSP sries 2000 e 4000 da Fluke. Recomenda-se que o NEXT seja medido nas duas extremidades de um cabo, principalmente quando se tratam de cabos mais compridos. Se um cabo possui uma terminao mal feita em uma extremidade, ao testar o cabo a partir da extremidade oposta, mesmo que o NEXT esteja fora do padro, possvel que o cabo passe no teste devido atenuao sofrida pelo sinal [FLUKE-NETNEXT]. Para cada categoria de cabo existem valores limites de NEXT e atenuao. As prprias ferramentas de certificao iro testar seu cabo e apresentar um relatrio que informa se ele est ou no de acordo com as especificaes do padro do cabo em teste. Em outras palavras, voc no precisa decorar qual o valor mximo aceitvel em decibis da atenuao ou do NEXT em um cabo de pares tranados categoria 5. O prprio testador vai lhe dizer se seu cabo est ou no de acordo com o padro. Para que o seu teste seja vlido voc precisa apenas informar ao testador qual a categoria do cabo que vai ser testado. Suponha que voc deseja testar um cabo de pares tranados categoria 5. Mas, acabou selecionando no testador a categoria 5E. bem possvel que o teste falhe, pois cabos de categoria 5 tm requisitos de desempenho aqum dos cabos de categoria 5E. A Tabela 10-17 [SIEMON] oferece NEXT e atenuao de cabos categorias 5, 5e, 6 e 7 a 100 MHz. Ela mostra ainda valores de NEXT e atenuao para cabos categorias 6 e 7 a 250 MHz e 600 MHz. Os limiares apresentados correspondem aos piores casos. Tipicamente, encontraremos valores de atenuao e NEXT melhores que os apresentados.
294

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

No entraremos em mais detalhes sobre como usar uma ferramenta de certificao por ser uma tarefa bastante dependente do modelo e fabricante da ferramenta. Leia nos manuais do seu equipamento como proceder. Categoria 5 Categoria 5e Categoria (100 MHz) (100 MHz) (100 MHz/250 MHz) NEXT Atenuao 27.1 dB 24 dB 30.1 dB 24 dB 6 Categoria (100 MHz/600 MHz) 7

39.9 dB/33.1 62.1 dB dB

dB/51

21.7 dB/ 36 20.8 dB/ 54.1 dB dB

Tabela 10-17: Valores limites de atenuao e NEXT em cabos de pares tranados categorias 5, 5e, 6 e 7.

10.13 Obtendo estado administrativo de interfaces

Neste procedimento descreveremos como obter o estado administrativo de interfaces de equipamentos de interconexo e estaes de trabalho.

10.13.1 Descrio e Dicas

possvel que interfaces de equipamentos de interconexo no mais transmitam dados devido a defeitos fsicos. No entanto, possvel tambm que uma interface pare de receber e enviar quadros por ordem do administrador da rede. Quando o gerente de rede desativa uma interface diz-se que ela est administrativamente desabilitada. Isto quer dizer que o gerente da rede pode habilitar ou desabilitar uma interface administrativamente de acordo com os requisitos de gerncia de sua rede. Por exemplo, considere um comutador que fica no laboratrio de usurios. Algumas portas do comutador esto vazias. A poltica de segurana da empresa dita que no permitido que mquinas novas sejam inseridas na rede sem que a equipe de gerncia da rede seja consultada. Para auxiliar o cumprimento desta regra da poltica de segurana, voc pode desabilitar administrativamente as portas vagas do comutador, assim, elas no sero facilmente utilizadas para a conexo de novas mquinas. Voc vai desejar verificar o estado administrativo de uma interface em algumas situaes. Por exemplo: voc est conectando uma nova mquina na rede ou recebeu reclamaes de usurios de que a rede no est funcionando. A interface qual a nova mquina ou a mquina do usurios est ligada pode estar administrativamente desabilitada (problema INTERFACE DESABILITADA);

295

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

voc quer encontrar falhas na rede. Se uma interface est inativa porque o gerente assim o deseja, tudo bem. No entanto, quando o estado operacional de uma interface est diferente do estado administrativo, uma investigao deve ser iniciada. Encontrar uma interface no operacional cujo estado administrativo indica que ela deveria estar ativa uma indicao de falha na interface. Nas sees a seguir voc aprender como obter o estado administrativo de uma interface.

10.13.2 Usando uma estao de gerncia SNMP

Nesta seo ser apresentado como obter o estado administrativo de uma interface usando uma estao de gerncia SNMP. A varivel de gerncia ifAdminStatus do grupo Interfaces da MIB-2 [RFC 2233] informa o estado administrativo de uma interface. Esta varivel tem um valor inteiro entre 1 e 3: 1 indica interface ativa; 2 indica interface inativa; 3 indica que a interface est em teste. Se voc deseja comparar o estado administrativo de uma interface com o operacional, ser necessrio recuperar tambm o valor de outra varivel de gerncia da mesma MIB: ifOperStatus. Veja o OBTENDO ESTADO OPERACIONAL DE INTERFACES.

10.13.3 Usando uma interface de linha de comando

Nesta seo mostramos como verificar o estado administrativos de interfaces de comutadores e roteadores Cisco usando uma interface de linha de comando. Na maioria dos roteadores Cisco todos os comandos seguintes podem ser executados para obter o estado das interfaces do roteador:
roteador# show inter accounting roteador# show interfaces roteador# show inter description

Se preferir, voc pode selecionar apenas uma interface. Por exemplo, em roteadores Cisco famlia 7500, execute:
roteador# show interface [tipo_da_interface] [nmero_da_interface]

Este comando apresentar informaes sobre a interface selecionada. Por exemplo, para obter informaes sobre a interface FastEthernet 1/0/0 o seguinte comando deve ser executado:
296

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

#show interface FastEthernet 1/0/0

A primeira linha de retorno indica o estado administrativo da interface. Se ela estiver habilitada e funcionando a primeira linha ser a seguinte:
FastEthernet1/1/0 is up, line protocol is up

Caso a interface esteja administrativamente desativada, a primeira linha ser:

FastEthernet1/1/0 is administratively down, line protocol is down

O comando a seguir informa o estado das portas na maioria dos comutadores Cisco Catalyst (a partir da famlia 29xx):
comutador> show port status [mdulo[/porta]]

Veja o exemplo a seguir:

Console> show port status Port Name Status Vlan Level Duplex Speed Type ----- ------------------ ---------- ---------- ------ ------ ----- -------1/1 disabled 1 normal half 100 100BaseTX 1/2 notconnect 1 normal half 100 100BaseTX 2/1 connected trunk normal half 400 100BaseTX 3/1 notconnect trunk normal full 155 OC3 MMF ATM 5/1 notconnect 1 normal half 100 100BaseTX 5/2 notconnect 1 normal half 100 100BaseTX

Em comutadores Cisco, o estado disabled indica que a porta est desabilitada. A porta 1/1 do exemplo apresentado est inativa administrativamente. Existem outros estados. O estado notconnect, por exemplo, indica que a interface est habilitada, mas no foi possvel estabelecer conexo com o lado remoto (o equipamento remoto est desligado, por exemplo). Se voc possui outros modelos ou marcas de comutadores/roteadores, descubra como verificar o estado administrativo das portas nos manuais de comandos ou de configurao do seu equipamento. Em geral, no ser uma atividade muito complexa.

10.13.4 Usando ifconfig

Nesta seo veremos como obter o estado administrativo de interfaces em mquinas Linux e Windows. Em mquinas Linux o comando ifconfig -a pode ser utilizado. Ele retornar uma lista completa com todas as interfaces da mquina, inclusive as que esto desabilitadas. Um exemplo do retorno deste comando :
root# ifconfig a

297

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

eth0 Link encap:Ethernet

HWaddr 00:60:94:63:6E:3A Mask:255.255.255.0 Metric:1

inet addr:10.10.10.1 Bcast:10.10.10.255 UP BROADCAST RUNNING MULTICAST MTU:1500

RX packets:658685 errors:0 dropped:0 overruns:0 frame:3 TX packets:555222 errors:0 dropped:0 overruns:19 carrier:1 collisions:44644 txqueuelen:100 Interrupt:5 eth1 Link encap:Ethernet HWaddr 00:60:94:63:6E:3A Mask:255.255.255.0

inet addr:10.10.12.1 Bcast:10.10.12.255 BROADCAST MULTICAST MTU:1500 Metric:1

RX packets:85 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:4 txqueuelen:100 Interrupt:10 ()

No exemplo dado a interface eth0 est habilitada. Note que ela est UP e RUNNING. J eth1 no est. Tipicamente, quando uma interface est administrativamente desabilitada ela apresentada pelo comando ifconfig a como a interface eth1: no apresentando os flags UP e RUNNING. O comando ifconfig usado para ativar e desativar interfaces administrativamente. provvel que a interface eth1 do exemplo dado tenha sido desativada pelo comando:
root# ifconfig eth1 down

Quando desabilitamos uma interface administrativamente, as rotas que a utilizam so automaticamente desativadas. Caso a tabela de rotas seja configurada estaticamente, ao ativar a interface manualmente ser necessrio tambm inserir as rotas que foram desativadas. Para ativ-la novamente use o comando:
root# ifconfig eth1 up

Se a placa de rede eth1 no estiver com defeito e seu driver estiver corretamente instalado, aps sua ativao eth1 apresentar os flags UP e RUNNING assim como eth0 e estar apta a receber e enviar dados. Em mquinas Windows interfaces podem ser administrativamente desativadas atravs do Gerenciador de Dispositivos. No Windows 2000 voc pode verificar o estado administrativo de uma interface seguindo os passos a seguir: clique com o boto direito do mouse sobre o cone Meu Computador. No menu que surgir escolha o item Propriedades; na tabela Hardware, pressione o boto Gerenciador de Dispositivos; clique com boto direito do mouse sobre a placa de rede cujo estado voc deseja verificar;
298

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

no menu que surgir escolha o item Propriedades. Uma janela apresentando as propriedades da placa de rede selecionada aparecer; nesta janela possvel verificar se a placa de rede est ou no habilitada. possvel tambm modificar o estado da placa, se desejado.

10.14 Verificando ocorrncia de enchentes

Neste procedimento descreveremos como verificar se comutadores esto enviando muitos quadros em enchente.

10.14.1 Descrio e Dicas

Comutadores mantm tabelas de endereos, que informam atravs de qual interface um certo endereo MAC pode ser alcanado. Estas tabelas iniciam-se vazias, e medida que as mquinas se comunicam atravs do comutador, elas vo sendo povoadas, atravs de uma tcnica conhecida por backward learning. Ao receber um quadro atravs de uma de suas portas, emitido por uma mquina origem A, o comutador aprende atravs de que porta a mquina A pode ser alcanada, e adiciona esta informao na sua tabela. Ao receber um quadro destinado a um certo endereo fsico, o comutador procura em sua tabela de endereos atravs de que porta o quadro deve ser enviado. Se no encontrar esta informao na tabela de endereos, o quadro enviado para todas as portas do comutador, exceto a porta pela qual o quadro foi recebido. Chamamos este envio de um quadro para todas as portas do comutador de flooding, que traduzimos aqui como enchente. A ocorrncia muito freqente de enchentes um dos sinais do problema TEMPO DE ENVELHECIMENTO DE TABELAS DE ENDEREOS INADEQUADO, apresentado na pgina 94.

10.14.2 Usando uma estao de gerncia SNMP

Utilizando uma estao de gerncia SNMP podemos recuperar o valor do tempo de envelhecimento de entradas de tabelas de endereos em comutadores. Mas, no ser possvel analisar as enchentes. Nesta seo indicaremos que objetos SNMP oferecem informaes sobre tabelas de endereos de comutadores. O objeto dot1dTpAgingTime da Bridge MIB [RFC1493] indica por quanto tempo informaes da tabela de endereos aprendidas dinamicamente so vlidas. Outro objeto interessante desta mesma MIB o dot1dTpLearnedEntryDiscards indica quantas vezes uma entrada da tabela de endereos que acabou de ser aprendida teve que ser descartada por no haver mais espao suficiente para armazen-la. Se dot1dTpAgingTime for muito pequeno, enchentes freqentes ocorrero, j que o comutador armazenar entradas na tabela de endereos durante pouco
299

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

tempo e logo no saber mais para que porta enviar um quadro destinado a um certo endereo MAC. Se existem tantas entradas na tabela de endereos que no h mais espao para o armazenamento de novas entradas (dot1dTpLearnedEntryDiscards cresce continuamente), o comutador tambm poder ter que enviar muitos quadros em enchente. Estes objetos nos do informaes importantes sobre a tabela de endereos de um comutador. Mas, apenas na seo a seguir, com o auxlio de um analisador de protocolos, podemos verificar e analisar a ocorrncia de enchentes.

10.14.3 Usando um analisador de protocolos

Nesta seo descreveremos como um analisador de protocolos pode nos auxiliar a verificar a ocorrncia de enchentes e analis-la. Na realidade, precisaremos de dois analisadores de protocolos, no apenas de um. Conecte os analisadores no comutador a ser analisado. Capture quadros em ambos os analisadores durante alguns minutos. aconselhvel que a captura e o encerramento dela sejam simultneos em ambos os analisadores. Aps encerrar a captura, compare os quadros capturados pelos analisadores. Voc verificar que muitos quadros apesar de no serem destinados a endereos de difuso foram capturados por ambos os analisadores. Isto significa que o comutador no sabia para que porta envi-los e eles foram transmitidos por enchente. Aconselhamos anteriormente que o incio e o trmino da captura fossem simultneos para facilitar a anlise dos quadros capturados. Os analisadores de protocolos geralmente informam o tempo real de captura do quadro 15 de maro de 2002, 15:17:10, por exemplo e o tempo relativo, considerando que a captura iniciou no tempo 00:00:00.000. O tempo relativo de captura dos quadros pode ajudar a descobrir quadros enviados por enchentes. Eles so enviados no mesmo perodo aps o incio da captura. Verifique o endereo MAC destino dos quadros transmitidos atravs de enchentes. Se quadros com o mesmo endereo MAC destino foram transmitidos atravs de enchente em curtos espaos de tempo menos de 5 minutos bastante provvel que o tempo de envelhecimento das entradas da tabela de endereos esteja inadequado. Apesar de muito raro, possvel ainda que a tabela de endereos esteja muito grande, e no exista mais espao no comutador para armazenar novas entradas, tornando a tabela incompleta. Um comutador Cisco Catalyst, por exemplo, tem memria suficiente para armazenar 16 mil entradas nesta tabela. Portanto, esta realmente no ser uma situao comum. preciso estar lidando com equipamentos com menor capacidade de armazenamento para que ela possa vir a ocorrer.

10.15 Analisando trfego de difuso ARP

Neste procedimento apresentaremos como analisar solicitaes ARP em um domnio de difuso.
300

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

10.15.1 Descrio e Dicas

O protocolo ARP utilizado para mapear endereos IP (lgicos) em endereos MAC (fsicos). O protocolo ARP, resumidamente, funciona da seguinte forma: quando uma mquina no sabe o endereo MAC correspondente a um certo IP, ela envia um quadro de difuso na rede solicitando mquina com o endereo IP em questo que informe seu endereo MAC. Tipicamente, uma mquina no far mais que 1 consulta ARP a cada 10 segundos. Se em um domnio de difuso existirem N mquinas, no devemos encontrar neste domnio mais que N/10 solicitaes ARP por segundo. Na prtica, o nmero de solicitaes ARP bem menor. Mesmo que todos os usurios das N mquinas estivessem utilizando servios que requeiram muitos mapeamentos IP MAC, praticamente impossvel que todos eles faam uma solicitao a cada segundo. Em geral encontraremos um nmero bem menor que N. Dentre as causas do aumento do trfego de difuso ARP encontram-se: o tempo de validade da cache ARP em estaes de trabalho, roteadores e comutadores da rede est muito pequeno (ver problema VALIDADE DA CACHE ARP INADEQUADA); sua rede est sendo alvo de ataques.

10.15.2 Usando um analisador de protocolos

Nesta seo veremos como analisar o trfego de difuso ARP em um domnio de difuso usando um analisador de protocolos. Um analisador de protocolos a ferramenta mais apropriada para a anlise do trfego ARP em um domnio de difuso. Conecte o analisador em um comutador ou repetidor que faa parte do domnio de difuso que voc deseja analisar. O primeiro passo criar um filtro, que capture apenas os quadros que carreguem solicitaes de mapeamento ARP. Se quiser capturar apenas as requisies ARP, adicione tambm uma regra que selecione apenas quadros ARP cujo endereo destino o de difuso (fsico). Dicas para a criao deste filtro so encontradas na pgina 222. Selecione o filtro de captura ARP que acabou de ser criado e inicie a captura. Capture algumas dezenas de quadros. Aps a captura podemos realizar algumas anlises: quantas requisies ARP por segundo voc capturou? Isso pode ser feito olhando as estatsticas de captura. A tabela de estatsticas de captura mostrada na Figura 10-8. Note que durante 36 segundos capturamos 1230 quadros de requisio ARP. Isto nos d uma mdia de 34 requisies ARP por segundo. Este nmero est muito grande? Existem mais de 34 mquinas no domnio de difuso?
301

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

qual o endereo IP de quem envia os quadros de solicitao de mapeamento ARP? Se muitos quadros de requisies ARP esto trafegando na rede, observe quem solicita estes mapeamentos ARP. A Figura 10-9 apresenta a decodificao de um quadro de requisio ARP. O endereo da mquina que est enviando a solicitao ARP indicado no Sniffer pelo rtulo Senders protocol address. Podemos listar pelo menos duas situaes de erros bem definidas: se for o roteador de acesso sub-rede sob estudo que est requisitando os mapeamentos ARP, significa que existem mquinas em outras subredes que desejam falar com as mquinas desta sub-rede. Se o roteador solicita o mapeamento do mesmo IP em curtos espaos de tempo, verifique a validade da cache ARP deste roteador. Se o roteador solicita mapeamentos IP MAC de endereos IP que no esto alocados a mquina alguma, desconfie de ataques. Em 2002 todo o mundo sofreu com ataques de vermes. O Code Red [CODERED] e o Nimda [NIMDA] foram os mais poderosos. Quando colocvamos o Sniffer para capturar requisies ARP percebamos que o roteador solicitava mapeamentos de IPs que no estavam alocados a mquina nenhuma. Foi quando comeamos a desconfiar de ataques. Mais tarde recebemos a informao do CERT (Computer Emergency Response Team) sobre o Code Red; se os endereos de quem solicita os mapeamentos ARP no fazem parte da sub-rede em estudo, desconfie de problemas com VLANs. Em geral mquinas de uma mesma rede IP compartilham o mesmo domnio de difuso. Suponha que as mquinas do domnio de difuso sob anlise possuem endereos da rede 192.168.1.0/24. No seria estranho que uma mquina cujo endereo IP da rede 192.168.3.0/24 solicitasse mapeamentos ARP no domnio de difuso sob estudo? Isto um sinal tpico de problemas com VLANs mquina inserida na VLAN incorreta (ver pgina 130). possvel tambm que existam mquinas com endereos IP incorretos; as solicitaes ARP pedem o mapeamento de quais endereos IP? Estes endereos existem? Eles fazem parte da classe de endereos da sub-rede em estudo? Na Figura 10-9 o endereo IP que deve ser mapeado est selecionado. se o endereo IP existe na sub-rede e o mapeamento for possvel, tudo bem. Mas se o endereo no existir suspeite de ataques, como j falamos anteriormente; se o endereo pertence a outra sub-rede, podem existir mquinas com configuraes de rede incorretas. Por exemplo, suponha que a mquina 192.168.1.1 solicitou o mapeamento IP MAC do endereo IP 192.168.3.2. No estranho? A mquina 192.168.1.1 acha que pode fazer uma entrega direta mquina 192.168.3.2, que pertence a outra sub-rede e a outro domnio de difuso. Suspeite da configurao de rede das mquinas que solicitam mapeamentos ARP de endereos IP de outras sub-redes.
302

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Figura 10-8: Tabela de estatsticas de captura.

Figura 10-9: Quadro de solicitao ARP.

10.16 Referncias 10.16.1 Livros

[DESIGNING-CISCO] [GUIA-ETHERNET] [HAUGDAHL] Teare, D. Designing Cisco Networks. Cisco Press. Fevereiro, 1999. Spurgeon, C. E. Ethernet O Guia Definitivo. Traduo Daniel Vieira, Editora Campus, 2000. Haugdahl, J.
303

Scott.

Network

Analysis

and

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

Troubleshooting. Addison Wesley, 2000 [PERF&FAULT-CISCO] Maggiora, P. L. D., Elliot, C. E., Pavone Jr, R. L., Phelps, K. J., Thompson, J. M. Performance and Fault Management. Cisco Press. 2000.

10.16.2 Recursos online (Internet)

[CABLETESTING-NEXT] Near End Crosstalk (NEXT). http://www.cabletesting.com/CableTesting/Test ing/Definitions/Definitions_NEXT.htm [CISCO-MEMORY-POOLMIB] Johnson, J., Wang, S. CISCO-MEMORYPOOL-MIB. Julho, 2001. ftp://ftp.cisco.com/pub/mibs/v1/CISCOMEMORY-POOL-MIB-V1SMI.my [CISCO-PERF-BP] Cisco Performance Management: Best Practices White Paper. http://www.cisco.com/warp/public/126/perfm gmt.htm [CISCO-SPAN] Configuring the Catalyst Switched Port Analyzer (SPAN) Feature. http://www.cisco.com/warp/public/473/41.htm l [CODERED] Informaes do CERT sobre o verme Code Red I. http://www.cert.org/incident_notes/IN-200108.html [FIELD_TEST] An up-to-date review of physical layer measurements, cabling standards, troubleshooting practices and certification techniques. http://www.wwtc.edu/nsf/AAMI_San_Jose/Ar ne_WebSite/cabling/cableTestingHandbook.pdf [FLUKE-NET-NEXT] NEXT. http://www.flukenet.com/consultants/testing/next.asp [NIMDA] Informaes do CERT sobre o verme NIMDA. http://www.cert.org/advisories/CA-2001304

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

26.html [OLD-CISCO-MEMORYMIB] Johnson, J., Wang, S. OLD-CISCO-MEMORYMIB. Fevereiro, 1994. ftp://ftp.cisco.com/pub/mibs/v1/OLDCISCO-MEMORY-MIB.my [SIEMON] Rybinski, V. De-Mystifying Category 5, 5e, 6, and 7 Performance Specifications. Dezembro, 1999. http://www.siemon.com/white_papers/99-1217-demystifying.asp [CISCO-PROCESS-MIB] CISCO-PROCESS-MIB Definitions. ftp://ftp.cisco.com/pub/mibs/v1/CISCOPROCESS-MIB-V1SMI.my [CPU-UTILIZATIONHOWTO] How to Collect CPU Utilization on Cisco IOS Devices Using SNMP. http://www.cisco.com/en/US/tech/tk648/tk36 2/technologies_tech_note09186a0080094a94.sht ml [OLD-CISCO-SYSTEMMIB] Jeffrey, J. T. Cisco System MIB file. Julho de 1994. ftp://ftp.cisco.com/pub/mibs/v1/OLDCISCO-SYS-MIB.my

10.16.3 RFCs
[RFC1213] McCloghrie, K., Rose, M. Management Information Base for Network Management of TCP/IP-based internets: MIB-II. Maro, 1991. Grillo, P., Waldbusser, S. Host Resources MIB. Setembro, 1993. Waldbusser, S. Remote Network Monitoring Management Information Base. Fevereiro, 1995. McCloghrie, K., F. Kastenholz. The Interfaces Group MIB using SMIv2. Novembro, 1997. [RFC2358] [RFC2665] Flick, J., Johnson, J. Definitions of Managed Objects for the Ethernet-like Interface Types. Junho, 1998. Flick, J., Johnson, J. Definitions of Managed Objects for the Ethernet-like Interface Types. Agosto de 1999.
305

[RFC1514] [RFC1757] [RFC2233]

C A P T U L O

1 0

P R O C E C D I M E N T O S

( C A M A D A S

F S I C A

E N L A C E )

[RFC1493]

Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K. Definitions of Managed Objects for Bridges. Julho, 1993

306

11 Procedimentos referenciados nos problemas de nvel de rede

1 1
Captulo

Neste captulo apresentamos 14 procedimentos que informam como obter e analisar informaes de gerncia. Os procedimentos apresentados neste captulo informam como obter os sinais que foram mais referenciados nos problemas de nvel de rede. No entanto, existem alguns problemas de outras camadas que podem lhes referenciar.

11.1 Verificando se duas mquinas respondem mesma consulta ARP

Neste procedimento mostraremos como verificar se mais de uma interface est respondendo a uma mesma consulta ARP.

11.1.1 Descrio e Dicas

O protocolo ARP usado para mapear endereos IP em endereos fsicos (MAC). Quando uma estao deseja descobrir o endereo MAC da mquina que possui um determinado endereo IP, ela envia um quadro de difuso solicitando mquina configurada com este endereo IP que informe o seu endereo MAC. Quando duas ou mais estaes respondem mesma requisio ARP, duas ou mais estaes esto configuradas com o mesmo endereo IP. usando este raciocnio que os sistemas operacionais de rede da Microsoft se protegem contra endereos duplicados. Antes de usar um endereo de rede uma mquina certifica-se de que ele no est duplicado, enviando uma consulta ARP envolvendo este endereo. Se alguma outra mquina da rede estiver configurada para usar o mesmo endereo IP, ela responder consulta ARP. A mquina que realizou o teste ter sua placa de rede desabilitada o usurio ser informado disso para que no existam endereos IP duplicados na rede.

11.1.2 Usando um analisador de protocolos

Neste procedimento mostraremos como podemos usar um analisador de protocolos para verificar se mais de uma mquina da rede responde a uma mesma consulta ARP, isto , se existem endereos IP duplicados na rede.
307

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Como sempre, o primeiro passo conectar o analisador de protocolos no local apropriado. Precisamos capturar, alm de consultas ARP, as respostas correspondentes. As consultas ARP so destinadas ao endereo de difuso, portanto, todas as mquinas que fazem parte do mesmo domnio de difuso as recebem. J as respostas so destinadas apenas mquina que enviou a consulta correspondente. Daremos aqui duas opes: se todas as mquinas da rede em estudo esto conectadas entre si por repetidores, conecte o analisador em um dos repetidores e proceda como descrito no Teste A; se existem mquinas ligadas a comutadores, conecte o analisador em um comutador ou em um repetidor (o equipamento que estiver conectado a mais mquinas do domnio de difuso) e proceda como descrito no Teste B. Se voc ligar o analisador em um comutador, lembre-se que ele deve fazer parte da VLAN que define o domnio de difuso sob anlise;
T
E S T E

Como todas as mquinas do domnio de difuso esto ligadas em repetidores, o analisador enxergar todas as consultas e respostas ARP que trafegam neste domnio de difuso. Selecione um filtro que capture apenas quadros contendo dados do protocolo ARP. Capture algumas dezenas de quadros. Ao encerrar a captura, analise os quadros capturados em busca de duas respostas mesma consulta ARP. Este procedimento no garante que endereos duplicados no existam na sua rede. Voc s ver duas respostas ARP mesma consulta caso tenha a sorte de, durante a captura, alguma mquina realizar uma consulta ARP envolvendo endereos IP duplicados. Este um teste mais simples, porm menos conclusivo que o Teste B. Portanto, se preferir, realize o procedimento descrito no Teste B. Ao contrrio do procedimento descrito no Teste A, no ficaremos aqui merc da sorte. Em contrapartida, este ser um processo um pouco mais trabalhoso. Ns mesmos enviaremos consultas ARP na rede. Se voc suspeita que algum IP est duplicado, inicie o processo testando este IP. Primeiramente, configure o seu analisador com um endereo IP e mscara de rede que permitam-no se comunicar com outras mquinas da rede. O segundo passo certificar-se (usando o comando arp em sistemas Linux e Windows) de que a tabela ARP de seu equipamento est vazia. No Windows e no Linux, cada entrada precisa ser removida individualmente. Em ambos os sistemas operacionais mencionados o comando a seguir pode ser usado para cada um dos endereos a serem removidos da tabela.
C:\WINDOWS> removida> arp d <endereo IP da entrada a ser

E S T E

# arp d <endereo IP da entrada a ser removida>

Em um roteador Cisco com IOS verso 10.0 ou superior, o comando a seguir apagar todas as entradas da tabela ARP:
roteador# clear arp-cache

Para causar o envio de uma consulta ARP envolvendo um determinado endereo IP da mesma sub-rede, envie mensagens ICMP Echo (ping) para este endereo IP. Para que esta mensagem seja enviada, ser necessrio fazer antes o
308

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

mapeamento IP MAC. Desta forma, nos podemos induzir o envio de consultas ARP envolvendo o endereo IP que desejarmos. Seu analisador capturar as consultas e as respostas, j que estas sero endereadas a ele. Selecione o filtro que capture apenas quadros do protocolo ARP e inicie a captura. Durante a captura, force o envio de consultas ARP para os endereos IP que voc desejar usando ping. Ao encerrar a captura, analise os quadros capturados em busca de duas respostas mesma consulta ARP.

11.2 Verificando ocorrncia de consultas ARP sem resposta

Neste procedimento mostraremos como verificar a existncia de consultas ARP sem resposta em uma rede.

11.2.1 Descrio e Dicas

O protocolo ARP usado para fazer mapeamentos IP MAC em uma rede. Quando uma mquina deseja descobrir o endereo MAC correspondente a um determinado endereo IP, ela envia uma consulta ARP em difuso na rede. A mquina que est usando o endereo IP em questo responde esta consulta, informando o seu endereo MAC. Consultas ARP sem resposta podem simplesmente indicar que a mquina cujo endereo MAC deseja-se descobrir est desligada. Porm, podem tambm indicar problemas tais como mscara de rede incorreta, equipamentos inseridos na VLAN incorreta e falta de troca de informaes sobre VLANs entre comutadores. Estes problemas so apresentados nas Sees 6.3, 6.7 e 6.9, respectivamente. Alm disso, consultas ARP sem resposta podem tambm indicar que o endereo IP a ser mapeado no est alocado a mquina alguma na rede. Em geral, esta uma situao causada por ataques. O cdigo malicioso gera endereos aleatrios, que podem ou no existir.

11.2.2 Usando um analisador de protocolos

Veremos nesta seo como usar um analisador de protocolos para checar a existncia de consultas ARP sem resposta em um domnio de difuso. O primeiro passo conectar o analisador de forma que ele capture consultas e respostas ARP. Se no domnio de colises em estudo existem apenas repetidores, simplesmente conecte o analisador em um dos repetidores. Quando existem comutadores no domnio de difuso, a conexo do analisador torna-se um pouco mais trabalhosa. As consultas ARP sero sempre capturadas, pois elas so direcionadas ao endereo de difuso. J as respostas a estas consultas que precisamos analisar so endereadas mquina que realizou a consulta. Por isto, se existem comutadores no domnio de difuso no poderemos ver todas as respostas ARP.
309

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Se existe apenas um comutador, voc pode optar por espelhar todas as portas do comutador que participam do domnio de difuso (mesma VLAN) em questo em uma outra porta, e conectar nesta porta o analisador de protocolos. No entanto, nem todos os comutadores permitiro que isso seja feito. Alm disso, essa soluo s ser possvel se o trfego combinado de cada porta espelhada no ultrapassar a banda passante da interface na qual os dados forem espelhados. Uma outra alternativa conectar os equipamentos conectados no comutador que participam do domnio de difuso em estudo em um repetidor e conectar este repetidor no comutador. Conecte o analisador de protocolos neste repetidor. Da mesma forma, deve-se tomar cuidado para no saturar a largura de banda dos enlaces do repetidor. Se no domnio de difuso em estudo existe mais de um comutador, o analisador pode ser conectado da mesma forma descrita acima (quando existe apenas um comutador), mas nesta situao, o analisador capturar apenas as respostas ARP destinadas a equipamentos ligados ao mesmo comutador ao qual o analisador est conectado. procedimento ser um pouco diferente. Mais adiante, abordaremos esta situao. Se o analisador de protocolos foi conectado de forma que requisies e respostas ARP de todas estaes membros da VLAN possam ser capturadas, proceda como a seguir: selecione um filtro que capture apenas quadros do protocolo ARP e capture algumas dezenas de quadros; ao encerrar a captura analise os quadros capturados em busca de consultas ARP sem resposta. Ao encontrar consultas ARP sem resposta, analise quem enviou a consulta e que endereo IP deveria ser mapeado. Estas informaes podem ajudar a descobrir qual o problema. Na Figura 11-1 apresentamos a decodificao de uma consulta ARP pelo Sniffer, da Network Associates. Nesta figura destacamos o endereo IP de quem solicitou a consulta. Mais abaixo, indicado pelo rtulo Target protocolo address est o endereo IP que deve ser mapeado para um endereo MAC. O endereo IP de quem solicitou a consulta ARP indicado pelo rtulo Senders protocol address.

310

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Figura 11-1: Decodificao de consulta ARP no Sniffer.

Se no domnio de difuso existir mais de um comutador, o procedimento ser semelhante, mas a anlise pode ser mais trabalhosa. Selecione no analisador um filtro que capture apenas quadros do protocolo ARP e inicie a captura. Capture algumas dezenas de quadros. Ao encerrar a captura analise o trfego ARP capturado. Em muitas situaes, quando voc vir uma consulta ARP sem resposta no poder concluir com certeza se esta uma consulta ARP sem resposta, ou se a resposta simplesmente no foi capturada. A seguir encontramse dicas de como analisar os dados capturados e como certificar-se de que a consulta realmente no foi respondida: estude as consultas ARP para as quais o analisador no capturou resposta alguma. Veja que mquina enviou a consulta e que endereo IP deveria ser mapeado. Com estas informaes poder ser possvel concluir que: o endereo IP a ser mapeado no existe ou a mquina que fez a consulta no deveria estar participando do domnio de colises em estudo; se aps a anlise descrita acima voc ainda est com dvidas sobre o que est ocorrendo, faa voc mesmo esta consulta. Induza, a partir do seu analisador, uma consulta ARP que solicite o mesmo mapeamento da consulta ARP sem resposta; para tal, configure o seu analisador com endereo e mscara de rede apropriados. Deve ser possvel que o analisador se comunique com as demais mquinas do domnio de difuso sob anlise; envie mensagens ICMP Echo (ping) para a mquina cujo IP deve ser mapeado para endereo MAC. Por exemplo, suponha que voc encontrou dentre os quadros capturados uma consulta ARP enviada pela mquina 192.168.1.204 solicitando o mapeamento ARP do endereo IP 192.168.1.222. Selecione o filtro de captura ARP no
311

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

analisador e inicie a captura. Ento, a partir do prprio analisador de protocolos, direcione mensagens ICMP Echo para a mquina 192.168.1.222. Para que a comunicao entre o analisador e a mquina 192.168.1.222 seja possvel ser necessrio descobrir o endereo MAC da mquina cujo IP 192.168.1.222. A resposta a esta consulta ser enviada ao prprio analisador. Encerre a captura e analise os dados capturados: a consulta foi respondida? Na realidade, se o ping foi respondido pela mquina 192.168.1.222 com sucesso, significa que a consulta ARP foi respondida. Mas, o oposto no sempre verdade: se o ping no foi respondido com sucesso, no se pode concluir que a consulta ARP no foi respondida. Pode ser que a mquina remota esteja configurada para no responder ping. Por isso recomendamos que voc capture os dados e os analise.

11.3 Obtendo tabela de rotas de roteadores

Neste procedimento sero apresentadas algumas maneiras de obteno da tabela de rotas de roteadores e estaes de trabalho.

11.3.1 Descrio e Dicas

Um roteador s capaz de rotear adequadamente os datagramas que recebe se ele possuir uma tabela de rotas completa e sem erros. Em muitas situaes voc vai precisar analisar a tabela de rotas de seus equipamentos de interconexo em busca de problemas. As tabelas de rotas de hospedeiros so tipicamente bastante simples. Basicamente existem duas entradas: uma que utilizada quando o datagrama est destinado mesma sub-rede do hospedeiro, e outra utilizada nos demais casos (a rota default). As tabelas de rotas de roteadores, por outro lado, podem ser bem mais complexas. Para analisar corretamente a tabela de rotas de um roteador precisamos conhecer a topologia e o endereamento da rede profundamente. Caso contrrio no seremos capazes de decidir se a tabela est ou no correta. Em geral, parte da tabela de rotas de um roteador configurada estaticamente e parte dinamicamente atravs de protocolos como RIP e OSPF. Alm de saber se as rotas esto corretas, devemos tambm verificar se cada rota foi aprendida como deveria ter sido, isto , se ela foi inserida na tabela atravs de configurao manual ou atravs de protocolos de roteamento dinmico. Nas sees a seguir so dadas dicas de como obter tabelas de rotas de roteadores. Aps obter a tabela de rotas voc ter que analis-la, para decidir se h ou no algum erro. Em geral, analisamos a tabela de rotas de um equipamento quando suspeitamos que ela est incorreta ou incompleta. comum tambm que j tenhamos alguma suspeita de que erro est ocorrendo. Por exemplo, toda a rede do Departamento Financeiro est sem conectividade. A rede deste departamento a 192.168.1.0/24. Ento analisaremos nas tabelas
312

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

de rotas dos demais roteadores que rotas esto sendo seguidas quando a rede destino a 192.168.1.0/24.

11.3.2 Usando uma estao de gerncia SNMP

Nesta seo veremos que objetos SNMP trazem informaes de tabelas de rotas. A ipCidrRouteTable da IP Forwarding Table MIB [RFC2096] (a segunda atualizao da tabela ipRouteTable da MIB-2) traz uma entrada para cada linha da tabela de rotas de um roteador. Em outras palavras, cada linha desta tabela representa uma entrada da tabela de rotas do equipamento sendo monitorado. Caminhar nesta tabela o mesmo que caminhar na tabela de rotas do roteador. O ndice desta tabela formado pelos objetos ipCidrRouteDest, ipCidrRouteMask, iipCidrRouteTos e ipCidrRouteNextHop. O objeto ipCidrRouteDest indica o endereo IP destino da rota (geralmente um endereo de rede). A varivel colunar ipCidrRouteNextHop informa o endereo IP do roteador para o qual os datagramas destinados rede ipCidrRouteDest devem ser entregues. ipCidrRouteMask informa a mscara de rede da rede destino (ipCidrRouteDest). Um AND lgico deve ser realizado entre esta mscara e o endereo destino contido no datagrama a ser roteado. O resultado desta operao que ser comparado com o endereo contido em ipCidrRouteDest. Voc pode tambm obter a informao de como cada rota foi aprendida atravs do objeto ipCidrRouteProto.

11.3.3 Usando uma interface de linha de comando

Nesta seo veremos como obter a tabela de rotas em um roteador Cisco. Os comandos a serem executados dependem do fabricante e do modelo do roteador utilizado. Se os comandos apresentados aqui no valerem para o seu roteador, busque comandos correspondente nos manuais do seu equipamento. Em roteadores Cisco com verso de IOS 10.0 ou superior use o seguinte comando:
roteador> show ip route Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR Gateway of last resort is 192.143.254.174 to network 0.0.0.0 C 192.168.64.0/24 is directly connected, FastEthernet1/0/0

O E1 192.17.251.0/24 [110/53] via 192.143.254.174, 02:28:54, ATM4/0/0.103 O E1 192.18.234.0/24 [110/53] via 192.143.254.174, 02:28:54, FastEthernet1/0/0 192.211.38.0/30 is subnetted, 1 subnets O E1 192.211.38.148 [110/52] via 192.143.254.174, 02:28:54, ATM4/0/0.103

313

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

O E1 192.137.174.0/24 [110/54] via 192.143.254.174, 02:29:24, ATM4/0/0.103 O E1 192.168.174.0/24 [110/54] via 192.143.254.174, 02:29:24, FastEthernet1/1/0 S S () 192.168.65.0/24 [1/0] via 192.168.64.131 192.168.66.0/24 [1/0] via 192.168.64.131

Quando nenhum parmetro passado, toda a tabela de rotas apresentada, como exemplificado. Note que com este comando voc pode ver cada entrada da tabela de rotas e como ela foi inserida se estaticamente ou por algum protocolo de construo dinmica de tabelas de rotas (RIP ou OSPF, por exemplo). Se voc quiser ver apenas a rota para determinada rede destino passe o endereo da rede destino como parmetro:
roteador>show ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "static", distance 1, metric 0 Redistributing via ospf 1916 Advertised by ospf 1916 metric 50 metric-type 1 subnets tag 145 routemap I Routing Descriptor Blocks: * 192.168.64.131 Route metric is 0, traffic share count is 1

Este resultado indica que a rota para a rede foi aprendida por configurao esttica, que ela est sendo divulgada via o protocolo OSPF e que o prximo roteador que deve receber o datagrama com destinado rede 192.168.1.0/24 192.168.64.131. Voc pode tambm observar apenas as rotas estticas (parmetro static), as redes diretamente conectadas (parmetro connected) ou apenas as rotas aprendidas atravs de um determinado protocolo. Por exemplo, o comando seguinte apresenta apenas as rotas aprendidas atravs do protocolo OSPF:
roteador# show ip route ospf

Outros protocolos que podem ser passados como parmetro so: bgp, egp, eigrp, hello, igrp, isis e rip. Estes comandos so interessantes quando a tabela de rotas grande e parte dela configurada estaticamente e outra parte dinamicamente. Com eles voc pode analisar a tabela por partes. Para tal voc precisa saber perfeitamente como cada rota deve ser aprendida.

11.3.4 Usando netstat e route

Nesta seo apresentaremos como obter a tabela de rotas de mquinas com sistema operacional Linux ou Windows. Em mquinas Linux os seguintes comandos apresentam a tabela de rotas configurada na mquina:
314

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

# netstat nr # route -n

Em mquinas com sistema operacional Windows execute o comando a seguir a partir de um promp de comandos:
C:\WINNT> route print

11.4 Verificando ocorrncia de requisies DHCP sem resposta do servidor

Neste procedimento mostraremos como verificar se um cliente DHCP fica sem resposta do servidor DHCP aps enviar mensagens DHCPDISCOVER ou DHCPREQUEST.

11.4.1 Descrio e Dicas

Leia mais sobre DHCP no apndice 9

Em condies normais, aps enviar uma mensagem a um servidor DHCP, o cliente recebe a resposta do servidor DHCP. Mensagens DHCPDISCOVER so respondidas pelo servidor com mensagens DHCPOFFER e mensagens DHCPREQUEST com uma mensagem DHCPACK ou DHCPNAK. Se, por algum motivo, o cliente DHCP no receber resposta de um servidor, ele ficar tentando ainda se comunicar com este por algum tempo. Se ainda assim a comunicao no for possvel, o cliente DHCP no poder obter suas configuraes de rede ou renov-las e, portanto, no poder se comunicar atravs da rede. Alguns sistemas operacionais mostram ao usurio da mquina mensagens de erro quando o servidor DHCP no alcanado. Alguns problemas de rede podem interferir na comunicao entre servidor e cliente DHCP, de forma que o cliente envia mensagens de solicitao de endereo mas no recebe resposta alguma do servidor. Dentre estes problemas encontram-se: agente de repasse DHCP mal configurado e comutadores que no conseguem trocar informaes sobre VLANs entre si. Estes problemas so descritos nas Sees 6.5 e 6.9 respectivamente.

11.4.2 Usando um analisador de protocolos

Veremos nesta seo como usar um analisador de protocolos para analisar a comunicao entre servidor e cliente DHCP. Conecte o analisador de forma que ele possa capturar o trfego DHCP entre o cliente e o servidor DHCP. Primeiramente, vamos conectar o analisador mais prximo do cliente. Escolha uma mquina cliente DHCP que no esteja conseguindo obter suas configuraes de rede dinamicamente. Selecione no analisador de protocolos um filtro que capture apenas mensagens do protocolo DHCP e inicie a captura. Durante a captura, force o cliente DHCP a enviar mensagens DHCPDISCOVER ou DHCPREQUEST ao
315

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

servidor. Isto pode ser feito em mquinas Windows com o comando ipconfig /renew_all. No Linux o comando a ser usado vai depender da implementao do cliente DHCP em uso. As implementaes atualmente existentes so: dhcpcd, pump e dhclient. Para forar um cliente dhcpcd a renovar configuraes de rede com o servidor passe a opo n:
# dhcpcd n [interface]

Em clientes pump passe o parmetro R:

# pump R [-i interface]

Uma outra forma de forar o cliente DHCP a enviar estas mensagens simplesmente reinici-lo. Aps forar o envio de mensagens DHCPREQUEST pelo cliente, espere ainda alguns poucos minutos antes de encerrar a captura. Encerre a captura e analise os quadros capturados. O servidor DHCP respondeu solicitao do cliente? Com o procedimento realizado at aqui j podemos concluir se o servidor DHCP est ou no respondendo as solicitaes do cliente. Mas, outro teste pode ser realizado para descobrir informaes adicionais. Para descobrir onde a comunicao falha se a requisio DHCP que no chega no servidor ou a resposta deste que no chega no cliente realize o mesmo procedimento com o analisador conectado mais prximo do servidor DHCP. Este teste adicional s precisa ser realizado quando cliente e servidor estiverem ligados a comutadores distintos ou quando um agente de repasse estiver sendo utilizado. Selecione o filtro DHCP e inicie a captura. Durante a captura, force mais uma vez o cliente DHCP a enviar mensagens DHCPDISCOVER ou DHCPREQUEST. Aps encerrar a captura verifique se as requisies do cliente chegaram at o servidor e se foram respondidas por ele.

11.4.3 Verificando logs do servidor DHCP

Podemos tambm obter informaes sobre a comunicao entre cliente e servidor DHCP analisando os arquivos de log do servidor. Nem todos os servidores DHCP tero informaes to detalhadas. Apresentaremos nesta seo alguns eventos de logs do servidor DHCP do Windows 2000 e dhcpd que descrevem a comunicao entre cliente e servidor. Force um cliente DHCP com problemas a enviar mensagens DHCPDISCOVER ou DHCPREQUEST ao servidor DHCP (dicas de como fazer isto so encontradas na Seo 11.4.2) e busque nos logs do servidor mensagens sobre esta comunicao. Se houver realmente problema na comunicao cliente/servidor DHCP nenhuma mensagem ser encontrada no arquivo de logs.
W
I N D O W S

2 0 0 0

Para que o servidor DHCP do Windows 2000 escreva arquivos de logs mais detalhados, habilite o log de auditoria da seguinte forma: na ferramenta de administrao do DHCP (Iniciar > Programas > Ferramentas
316

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Administrativas > DHCP) clique com o boto direito do mouse sobre o servidor DHCP e escolha o item Propriedades. Na tabela Geral clique em Habilitar Logging de Auditoria DHCP. Por default, o servidor criar um arquivo de log chamado DhcpSrvLog.xxx61 no diretrio winnt\system32\dhcp. Os arquivos de log do servidor tm linhas com o seguinte formato:
ID, Data, Hora, Descrio, Endereo IP, Nome do hospedeiro, Endereo MAC

Na Tabela 11-1 cada um dos campos mencionados acima descrito [ANALYZING-DHCP-LOG]. Campo ID Data Hora Descrio Endereo IP Nome Hospedeiro Descrio Um cdigo de identificao de evento do servidor DHCP. A data na qual a mensagem de log foi escrita no arquivo de log do servidor DHCP. A hora em que a entrada foi escrita no arquivo de log do servidor DHCP. Uma descrio deste evento do servidor DHCP. O endereo IP do cliente DHCP. do O nome do cliente DHCP. O endereo MAC (Medium Access Control) do cliente DHCP.

Endereo MAC

Tabela 11-1: Descrio dos campos de uma entrada no arquivo de logs do servidor DHCP Windows 2000.

Na Tabela 11-2 so apresentadas algumas identificaes de eventos do servidor DHCP que trazem informaes sobre a comunicao cliente/servidor DHCP [ANALYZING-DHCP-LOG]. Identificao de evento Descrio 10 11 12 15 Um novo endereo IP foi concedido a um cliente. Uma concesso foi renovada pelo cliente. Uma concesso foi liberada pelo cliente. Uma concesso foi negada.

61 Existe um log para cada dia. O arquivo de log da segunda-feira chama-se DhcpSrvLog.Mon, o da tera chama-se DhcpSrvLog.Tue e assim sucessivamente.

317

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Tabela 11-2: Eventos que informam sobre a comunicao cliente/servidor DHCP.

D ( L
H C P D I N U X

Tipicamente, os logs do dhcpcd so escritos no arquivo /var/logs/messages ou /var/adm/messages, dependendo do seu sistema. Veja a seguir um exemplo da gravao de uma conversa entre servidor e cliente no arquivo de logs:
Apr 12 10:15:37 mingau dhcpd: DHCPDISCOVER from 00:10:b5:61:b2:65 via eth0 Apr 12 10:15:38 mingau dhcpd: DHCPOFFER on 192.168.4.1 to 00:10:b5:61:b2:65 (Computador) via eth0 Apr 12 10:15:38 mingau dhcpd: DHCPREQUEST for 192.168.4.1 (200.129.64.153) from 00:10:b5:61:b2:65 (Computador) via eth0 Apr 12 10:15:38 mingau dhcpd: DHCPACK on 192.168.4.1 to 00:10:b5:61:b2:65 (Computador) via eth0

11.5 Verificando se log do servidor DHCP indica falta de endereos IP

Neste procedimento daremos algumas dicas de como verificar nos logs do servio DHCP implementaes ISC e Windows 2000 se est faltando endereos para os clientes DHCP.

11.5.1 Descrio e dicas

No arquivo de logs dos servidores DHCP podemos encontrar mensagens que nos ajudam a descobrir problemas e entender melhor seu comportamento. Muitas mensagens interessantes e importantes so escritas nos arquivos de logs do DHCP. Mas, neste procedimento, falaremos apenas das mensagens escritas quando o servidor quer nos avisar que no possui mais endereos disponveis para oferecer aos clientes. importante que voc esteja sempre atento aos arquivos de logs do servidor DHCP e que saiba interpret-los adequadamente.

11.5.2 Verificando logs do servidor

Nesta seo veremos onde se localizam os logs do servio DHCP ISC e Windows 2000. Veremos tambm que mensagens estes logs contm quando o servidor DHCP no mais tiver endereos a oferecer aos seus clientes.
D H C P I S C

O servidor DHCP oferecido pela ISC (Internet Software Consortium) enviar mensagens para o arquivo de log atravs do syslog. Por default, as mensagens de log do DHCP sero encontradas juntamente com mensagens de logs de todos os outros daemons que tambm usam o syslog. Tipicamente estas mensagens so encontradas em /var/log/messages ou /var/adm/messages, dependendo do seu sistema. Quando faltam endereos IP as mensagem de erro no free leases encontrada no arquivo de logs do servidor DHCP ISC. Se voc encontrar neste arquivo uma mensagem de log que voc no entende, a vai uma dica: pesquise no arquivo dhcp.c do servidor ISC as mensagens de log. Procure as chamadas das funes log_error ou log_info. Leia os comentrios escritos prximos a estas chamadas. Em geral eles descrevem o que causa o envio da mensagem de log.
318

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

D H C P W
I N D O W S

2 0 0 0

No Windows 2000, informaes de inicializao e trmino do servio DHCP so visualizadas atravs do Event Viewer. Quando queremos obter informaes de logs mais detalhadas temos que habilitar o sistema de logging. Isto feito conforme explicado na Seo 11.4.3. Quando o servidor DHCP no tiver endereos disponveis para oferecer a um cliente DHCP ele informar o erro no arquivo de logs. No Windows 2000 o evento identificado pelo nmero 14 indica que uma requisio no foi satisfeita porque no existiam mais endereos IP disponveis no escopo. Conhea outras identificaes de eventos do servidor DHCP Windows em [ANALYZINGDHCP-LOG, WIN-TIP412].

11.6 Verificando ocorrncia de mensagens DHCPNAK na rede

Neste procedimento mostraremos como verificar se servidores DHCP esto constantemente enviando mensagens DHCPNAK para os clientes DHCP.

11.6.1 Descrio e Dicas

Mensagens DHCPNAK so enviadas pelo servidor DHCP a um cliente DHCP nas seguintes situaes [RFC2131]: o cliente DHCP solicita o aluguel de um endereo IP que no faz parte da faixa de endereos IP configurada no servidor DHCP. Isto comum quando um cliente transferido de uma rede para outra. O cliente ainda se lembra do ltimo endereo alocado a ele, mas este endereo faz parte de outra rede; o cliente DHCP solicita renovar o aluguel de seu endereo, mas o tempo de concesso do mesmo j expirou. Quando mensagens DHCPNAK so constantemente enviadas pelo servidor DHCP mesmo que nenhuma mquina tenha sido transferida de uma rede para outra, desconfie que o nmero de mquinas na rede est bem maior que o nmero de endereos IP que podem ser concedidos pelo servidor. Desta forma, o servidor no est conseguindo manter um cliente DHCP com o mesmo endereo IP por muito tempo. Mesmo quando usamos DHCP podemos ter um certo conhecimento sobre qual IP est alocado s mquinas da rede. O servidor DHCP esfora-se para sempre permitir que uma mquina permanea com o mesmo endereo IP que ela recebeu na primeira alocao dinmica pelo maior tempo possvel. Mesmo que o tempo de concesso de um endereo tenha expirado, o servidor DHCP no conceder este endereo a um outro cliente, exceto se no houver outro endereo IP disponvel.

319

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

11.6.2 Usando um analisador de protocolos

Veremos nesta seo como verificar com o auxlio de um analisador de protocolos se mensagens DHCPNAK esto sendo constantemente enviadas do servidor DHCP para clientes DHCP. Conecte o analisador de protocolos de forma que ele possa enxergar todo o trfego do servidor DHCP. Se ainda no existir, crie um filtro que selecione apenas quadros que carregam dados do protocolo DHCP para captura. Selecione o filtro DHCP e inicie a captura. interessante que voc passe algum tempo capturando quadros, pelo menos um tempo inicial de 1 hora. tambm recomendado que este procedimento seja realizado em um horrio de pico, em que existam vrios clientes DHCP ativos. Aps encerrar a captura verifique a existncia de mensagens DHCPNAK dentre os quadros capturados. Se nenhuma mensagem DHCPNAK foi encontrada dentre os quadros capturados, no podemos concluir com certeza que estas mensagens no estejam sendo transmitidas aos clientes em algum momento. Para ser mais conclusivo, voc pode iniciar uma nova captura que dure mais algum tempo. Se quiser faa vrias capturas e verifique se dentre os dados capturados existem mensagens DHCPNAK.

11.6.3 Verificando logs do servidor DHCP

O envio de uma mensagem DHCPNAK deve ser gravada no arquivo de logs do servidor DHCP. Nesta seo veremos um exemplo da mensagem de log gravada pela implementao dhcpd da ISC ao enviar uma mensagem DHCPNAK. Esta verificao mais conclusiva que a anterior, realizada com o analisador de protocolos, sendo, portanto, mais recomendada. Veja abaixo a mensagem gravada pelo servidor dhcpd ao enviar DHCPNAK:
Apr 12 11:00:13 servidor dhcpd: DHCPNAK on 192.168.4.1 to 00:04:ac:ee:c7:db via eth0

Provavelmente, o IP 192.168.4.1 foi liberado pelo cliente (que recebeu a mensagem DHCPNAK) h algum tempo, mas agora ele pretende renovar a concesso. No entanto, enquanto este cliente estava inativo, o IP em questo j foi concedido a outro cliente DHCP.

11.7 Analisando requisies de clientes DHCP externos

Neste procedimento, estudaremos as requisies de clientes DHCP que esto em um outro domnio de difuso e usam um agente de repasse DHCP para se comunicar com um servidor DHCP.

11.7.1 Descrio e Dicas

Um agente de repasse um hospedeiro ou roteador que repassa mensagens DHCP entre clientes e servidores que no participam de um mesmo domnio de
320

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

difuso. Usando agentes de repasse eliminamos a necessidade de se ter um servidor DHCP em cada domnio de difuso. Quando agentes de repasse so utilizados, o servidor DHCP passa a receber requisies deste agente. Quando o agente de repasse est mal configurado ou quando existe um filtro IP barrando o trfego DHCP entre o agente de repasse e o servidor DHCP, as requisies de clientes que usam o agente de repasse no chegaro ao servidor DHCP. Na prxima seo veremos como usar um analisador de protocolos para checar o trfego DHCP entre o agente de repasse e o servidor DHCP.

11.7.2 Usando um analisador de protocolos

Mostraremos nesta seo como analisar o trfego DHCP entre um servidor e um agente de repasse DHCP com o auxlio de um analisador de protocolos. O primeiro passo conectar o analisador de forma que ele possa enxergar as mensagens DHCP enviadas do agente de repasse para o servidor DHCP. Selecione um filtro que capture apenas mensagens DHCP e inicie a captura. Dicas de como conectar o analisador e como criar este filtro no Sniffer, da Network Associates, podem ser encontradas no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Durante a captura, force a comunicao entre clientes DHCP que usam o agente de repasse e o servidor DHCP. Isto pode ser feito em clientes DHCP Windows usando o comando ipconfig /renew_all. Em mquinas Linux o comando a ser utilizado depende da implementao do cliente DHCP instalada. Para forar um cliente dhcpcd a renovar configuraes de rede com o servidor passe a opo n:
# dhcpcd n [interface]

Em clientes pump passe o parmetro R:

# pump R [-i interface]

Outra forma de forar o cliente DHCP a comunicar-se com o servidor simplesmente reiniciar a mquina cliente. Assim, certamente capturaremos quadros com mensagens DHCP enviadas pelo agente de repasse. Aps encerrar a captura analise os quadros capturados. Verifique especialmente para que endereo as mensagens DHCP esto sendo enviadas. O endereo IP destino destas mensagens mesmo o endereo IP do servidor DHCP que deve lidar com esta requisio? Se nenhuma mensagem DHCP foi capturada voc provavelmente tem um problema com o seu agente de repasse. Voc pode conectar um analisador de protocolos prximo ao cliente DHCP para certificarse de que ele realmente est enviando requisies DHCP. Se voc verificou que o agente de repasse est enviando corretamente as requisies DHCP para o servidor DHCP, mas os clientes DHCP que usam o agente continuam sem poder obter suas configuraes de rede, continue o procedimento como descrito a seguir:
321

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

conecte o analisador de protocolos de forma que ele possa capturar todo o trfego do servidor DHCP; selecione o filtro de captura DHCP e inicie a captura; mais uma vez, force clientes DHCP externos a realizarem requisies DHCP; ao encerrar a captura analise os quadros capturados. Dentre eles voc encontra quadros transmitidos pelo agente de repasse?

11.8 Verificando existncia de mensagens ICMP de redirecionamento na rede

Neste procedimento veremos como verificar se os roteadores da rede esto enviando muitas mensagens ICMP de redirecionamento. Alm disso, descreveremos como um analisador de protocolos pode nos ajudar a obter mais dados sobre as mensagens ICMP de redirecionamento encontradas na rede.

11.8.1 Descrio e dicas

Mensagens ICMP de redirecionamento (tipo 5, cdigo 0-3) so enviadas por roteadores na seguinte situao [RFC 792]: ao receber um datagrama IP, um roteador consulta sua tabela de rotas em busca do prximo roteador para o qual o datagrama deve ser enviado. Se o roteador perceber que o prximo roteador e a mquina que originou o datagrama fazem parte da mesma rede, o roteador envia uma mensagem ICMP de redirecionamento para a mquina origem do datagrama. A origem, por sua vez, incluir em sua tabela de rotas a nova rota, temporariamente. Em resumo, uma mensagem ICMP de redirecionamento enviada para informar a um hospedeiro que ele deveria usar uma outra rota (melhor) ao tentar se comunicar com certos destinos. Apenas roteadores podem enviar mensagens ICMP de redirecionamento. Quando um hospedeiro recebe uma mensagem ICMP de redirecionamento ele deve agir da seguinte maneira [RFC1122]: acrescentar uma nova rota na tabela de rotas apropriadamente; descartar a mensagem de redirecionamento se ela indicar um roteador que no possui o mesmo prefixo de rede da interface pela qual a mensagem ICMP de redirecionamento chegou. Por exemplo, se um hospedeiro recebe pela sua interface cujo endereo 192.168.1.24 uma mensagem de redirecionamento, ele pode descartar esta mensagem se ela indicar que datagramas destinados a uma certa mquina devem ser entregues ao roteador 192.168.2.254;
322

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

descartar a mensagem de redirecionamento se ela no tiver sido enviada pelo primeiro roteador ao qual o datagrama que causou sua transmisso foi entregue. Segundo [RFC1812] um roteador com protocolos de roteamento dinmico ativos deve descartar mensagens ICMP de redirecionamento destinadas a ele. Em geral, a existncia de trfego de mensagens ICMP de redirecionamento na rede indica tabelas de rotas incorretas ou incompletas em hospedeiros. Felizmente, estes erros em tabelas de rotas no causaro a falta de conectividade na rede. Ao enviar uma mensagem de redirecionamento um roteador apenas est tentando ensinar origem de um datagrama um caminho mais curto para entreg-lo ao destino.

11.8.2 Usando uma estao de gerncia SNMP

Apresentamos nesta seo objetos SNMP que informam a quantidade de mensagens ICMP de redirecionamento recebida e enviada por um equipamento. Estes objetos so definidos no grupo ICMP da MIB-2 [RFC1213]: o objeto icmpInRedirects um contador do grupo conta a quantidade de mensagens ICMP de redirecionamento recebida por um equipamento. Por exemplo, sempre que uma mquina A receber uma mensagem ICMP de redirecionamento, o contador icmpInRedirects ser incrementado. Portanto, com o auxlio deste contador, voc pode descobrir se um hospedeiro est recebendo com freqncia mensagens ICMP de redirecionamento; o objeto icmpOutRedirects conta a quantidade de mensagens ICMP de redirecionamento enviada por um equipamento. Apenas roteadores enviam mensagens deste tipo, portanto s faz sentido monitorar estes objetos em roteadores. Como estes objetos so contadores, devemos identificar seu incremento em um determinado intervalo de tempo. Considere que o intervalo de coleta de dados ICMP T. Em duas coletas de dados consecutivas os valores do contador ipInRedirects obtidos de um equipamento foram ipInRedirects0 e ipInRedirects0+T. Ento, durante o tempo T, o equipamento em questo recebeu ipInRedirects0+T - ipInRedirects0 mensagens ICMP de
redirecionamento.

11.8.3 Usando uma interface de linha de comando

Nesta seo apresentaremos como verificar se roteadores Cisco esto enviando ou recebendo muitas mensagens ICMP de redirecionamento. Se voc possui roteadores produzidos por outro fabricante, procure nos manuais do seu equipamento comandos que possam lhe informar dados sobre mensagens ICMP.

323

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Em roteadores Cisco com verso de IOS superior a 10.0, execute o comando a seguir para visualizar estatsticas do trfego IP:
show ip traffic

Veja um exemplo do resultado deste comando onde destacamos contadores de mensagens ICMP de redirecionamento recebidas e enviadas:
roteador> show ip traffic () ICMP statistics: Rcvd: 0 format errors, 19 checksum errors, 1 redirects, 31 unreachable 209227 echo, 11 echo reply, 0 mask requests, 0 mask replies, 0 quench 0 parameter, 0 timestamp, 0 info request, 0 other 18 irdp solicitations, 0 irdp advertisements Sent: 961458 redirects, 7934 unreachable, 10 echo, 209227 echo reply 0 mask requests, 0 mask replies, 0 quench, 0 timestamp 0 info reply, 106591 time exceeded, 0 parameter problem 0 irdp solicitations, 0 irdp advertisements ()

Se o roteador estiver enviando muitas mensagens de redirecionamento, o ideal descobrir para quem estas mensagens esto sendo enviadas e qual o endereo destino dos datagramas que causam o envio destas mensagens. Mas, estas informaes s podem ser descobertas com um auxlio de um analisador de protocolos, como voc ver na prxima seo.

11.8.4 Usando um analisador de protocolos

Nesta seo veremos como usar um analisador de protocolos para analisar o trfego ICMP de redirecionamento em uma rede. Conecte o analisador de protocolos de forma que ele possa capturar as mensagens ICMP que voc deseja. Neste ponto, voc deve estar tentando analisar as mensagens ICMP de redirecionamento enviadas por um roteador, recebidas por um hospedeiro ou ainda as mensagens ICMP de redirecionamento destinadas ou originadas em redes externas. De forma geral, voc estar tentando capturar mensagens ICMP que trafegam entre dois equipamentos. Conecte o analisador de protocolos de forma que ele capture os dados desejados, seguindo as dicas oferecidas no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Em seu analisador de protocolos crie/selecione um filtro que capture apenas quadros que contenham mensagens ICMP. No analisador de protocolos Sniffer, da Network Associates, este filtro pode ser criado como descrito na Seo 9.1.2 (pgina 222). Voc pode ainda criar um filtro mais detalhado que capture apenas mensagens ICMP de redirecionamento. Selecione o filtro desejado e capture dados por alguns minutos. Aps encerrar a captura decodifique os quadros capturados. Verifique para quem as mensagens
324

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

esto sendo enviadas, isto , olhe o endereo IP destino dos datagramas capturados. Alm disso, veja qual a rota envolvida no erro.

Figura 11-2: Decodificao de uma mensagem ICMP de redirecionamento no Sniffer.

Na Figura 11-2 apresentamos um quadro que carrega uma mensagem ICMP de redirecionamento. Note que este quadro carrega o cabealho IP do datagrama original que causou o envio da mensagem de redirecionamento. Com os dados contidos na mensagem ICMP podemos portanto descobrir: 1) o endereo do roteador que deve ser usado como melhor rota; 2) a mquina que enviou o datagrama que causou o envio da mensagem de redirecionamento e 3) o endereo destino que pode ser alcanado a partir de um rota melhor. Todas estas informaes podem ser vistas no quadro decodificado na Figura 11-2. Nesta figura destacamos o endereo (192.168.1.13) do prximo roteador que deve ser usado pela mquina 192.168.1.23 ao transmitir dados para o destino 192.168.5.9.

325

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

11.9 Analisando trfego de mensagens ICMP Time Exceeded

Neste procedimento veremos como verificar se os roteadores da rede esto enviando muitas mensagens ICMP de TTL excedido em trnsito. Alm disso, descreveremos como um analisador de protocolos pode nos ajudar a estudar melhor as mensagens ICMP de TTL excedido em trnsito que trafegam na rede.

11.9.1 Descrio e dicas

Existem dois cdigos para mensagens de controle ICMP Time Exceeded: tempo de vida excedido em trnsito (cdigo 0) e tempo de remontagem de fragmentos excedido (cdigo 1). Quando um roteador observa que o valor do TTL de um datagrama sendo processado vai cair para zero, o datagrama descartado, e uma mensagem de tempo de vida excedido enviado para a mquina que originou o datagrama (endereo fonte do datagrama). Se um hospedeiro no puder remontar um datagrama porque faltam fragmentos do mesmo, ele descarta o datagrama e envia uma mensagem de tempo excedido durante remontagem para a origem do datagrama. Mensagens ICMP Time Exceeded, idealmente, no deveriam trafegar na rede. Se uma mensagem ICMP de tempo excedido encontrada esporadicamente, no h problema. No entanto, se estes tipos de mensagens esto sempre presentes em sua rede uma investigao mais detalhada faz-se necessria. Neste procedimento estamos preocupados em lhe mostrar como verificar se seus roteadores esto enviando muitas mensagens ICMP de TTL excedido (cdigo 0).

11.9.2 Usando uma estao de gerncia SNMP

Nesta seo veremos como uma estao de gerncia SNMP pode auxiliar na deteco de mensagens ICMP de TTL excedido na rede. O contador icmpOutTimeExcds do grupo ICMP da MIB-2 [RFC1213] incrementado cada vez que uma mensagem ICMP de tempo excedido transmitida. Em geral, mensagens ICMP de TTL excedido s so enviadas por roteadores e apenas hospedeiros enviam mensagens ICMP de tempo de remontagem excedido. Portanto, a varivel icmpOutTimeExcds, quando obtida de roteadores, informa a quantidade de mensagens ICMP de TTL excedido enviadas por eles. Lembre-se que esta varivel um contador, e que o seu valor absoluto nada significa. O importante saber o valor do incremento desta varivel no tempo. Por exemplo, colete dados SNMP de 5 em 5 minutos. Em uma determinada coleta, voc encontrou que icmpOutTimeExcds0 continha o valor 8.000.000.
326

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Este nmero nada significa. Voc s pode concluir se h ou no problemas na rede quando tiver em mos o valor da varivel icmpOutTimeExcds na prxima coleta. Suponha que na prxima coleta o valor da varivel 8.000.500. Isto significa que em 5 minutos, o roteador enviou 500 mensagens ICMP de TTL excedido. Foi uma mdia de 100 mensagens por minuto, ou quase 2 mensagens por segundo. Este um nmero bastante alto. provvel que existam problemas de roteamento em sua rede, ou ainda que ela esteja sendo atacada.

11.9.3 Usando uma interface de linha de comando

Apresentaremos nesta seo como obter a quantidade de mensagens ICMP de TTL excedido enviada por roteadores Cisco. Se voc possui roteadores produzidos por outro fabricante procure nos manuais dos seus equipamentos os comandos correspondentes aos que sero apresentados aqui. Em um roteador Cisco com IOS verso 10.0 ou superior, execute o comando:
roteador> show ip traffic IP statistics: () ICMP statistics: Rcvd: 0 format errors, 1 checksum errors, 0 redirects, 5 unreachable 27150 echo, 1 echo reply, 0 mask requests, 0 mask replies, 0 quench 0 parameter, 0 timestamp, 0 info request, 0 other 0 irdp solicitations, 0 irdp advertisements Sent: 146052 redirects, 36 unreachable, 0 echo, 27150 echo reply 0 mask requests, 0 mask replies, 0 quench, 0 timestamp 0 info reply, 7863 time exceeded, 0 parameter problem 0 irdp solicitations, 0 irdp advertisements ()

Este comando oferece estatsticas de vrios protocolos da pilha TCP/IP, dentre eles, o ICMP. O nmero de mensagens ICMP de tempo excedido transmitido pelo roteador est em negrito no exemplo. Este nmero um contador, , portanto, ser necessrio recuperar o seu valor em dois momentos distintos e ver quantas mensagens ICMP de tempo excedido foram realmente enviadas neste intervalo de tempo.

11.9.4 Usando um analisador de protocolos

Nesta seo veremos como usar um analisador de protocolos para verificar se mensagens ICMP de TTL excedido esto sendo constantemente enviada por roteadores da rede e veremos como obter dados sobre estas mensagens. Com um analisador de protocolos voc no poder observar a quantidade total de mensagens ICMP de TTL excedido por todas as interfaces do roteador de uma s vez. Pode observar apenas as mensagens enviadas por uma interface de cada vez. Em compensao, com o analisador podemos ver o cabealho do datagrama que gerou a mensagem (que teve o TTL zerado). De onde ele veio e para onde ele deveria ter ido. Estas informaes nos ajudam a determinar ou entender melhor o problema que est ocorrendo.
327

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Conecte o analisador de protocolos de forma que ele capture os dados transmitidos e recebidos pela interface do roteador que voc deseja testar. Aps conectar o analisador, capture mensagens ICMP. Dicas de como conectar o analisador e criar filtros de captura (no Sniffer, da Network Associates) so encontradas no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Se a taxa de captura estiver muito alta, capture algumas centenas de quadros. Se rarssimos quadros esto sendo capturados espere alguns minutos (10 minutos, por exemplo), antes de encerrar a captura. Finalmente, ao encerrar a captura, analise os quadros capturados. A mensagem ICMP de TTL excedido em trnsito traz consigo o cabealho IP do datagrama cujo TTL chegou a zero. Desta forma, podemos saber quem enviou o datagrama e para que destino. A Figura 11-3 mostra a decodificao de uma mensagem ICMP de TTL excedido em trnsito. Em destaque est o IP fonte (192.168.14.130) do datagrama cujo TTL excedeu e em seguida o IP destino. Ao analisar esta mensagem descobrimos que existe um problema de comunicao entre 192.168.14.130 e 192.168.2.132.

Figura 11-3: Decodificao de uma mensagem ICMP de TTL excedido em trnsito.

328

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

11.10 Analisando trfego de mensagens ICMP de destino inalcanvel

Neste procedimento descreveremos em que circunstncias um equipamento envia mensagens ICMP de destino inalcanvel para outro equipamento e como analisar o trfego deste tipo de mensagens em uma rede.

11.10.1 Descrio e Dicas

Existem vrios tipos de mensagens ICMP de destino inalcanvel. Algumas delas so enviadas por roteadores, outras por hospedeiros. Antes de descartar qualquer datagrama, o roteador/hospedeiro envia uma mensagem ICMP de destino inalcanvel para a origem do mesmo reportando que o destino (ou est) inalcanvel. Mensagens ICMP de destino inalcanvel tm sempre o cdigo 3. Existem vrios tipos de mensagens ICMP de destino inalcanvel, mas neste procedimentos trataremos apenas dos apresentados na Tabela 11-3. Cdigo Descrio 0 Rede inalcanvel. Quando um roteador recebe um datagrama mas no possui uma rota que sirva para lev-lo at o seu destino, o roteador envia para a origem do datagrama uma mensagem ICMP de rede inalcanvel. Esta mensagem geralmente enviada por roteadores com tabelas de rotas incompletas ou quando o endereo destino do datagrama no existe. Hospedeiro inalcanvel. Quando um roteador tenta fazer uma entrega direta ao destino final, mas este no est alcanvel. A mquina est desligada ou fora de servio. Porta inalcanvel. Quando o destino final recebe um datagrama mas no existem processos para trat-lo na porta especificada como porta destino.
Tabela 11-3 Alguns cdigos de mensagens ICMP de destino inalcanvel.

Mensagens ICMP de destino inalcanvel so consideradas mensagens de erro. Se poucas mensagens ICMP de destino inalcanvel so esporadicamente encontradas na rede no se preocupe. Mas se elas esto sempre presentes e em grande quantidade, bom analis-las melhor, pois elas podem lhe dar dicas sobre o que est ocorrendo de errado na rede.

11.10.2 Usando uma estao de gerncia SNMP

Nesta seo veremos como uma estao de gerncia SNMP pode oferecer informaes sobre o trfego de mensagens ICMP de destino inalcanvel. As seguintes variveis de gerncia da MIB-2 [RFC1213] podem ser teis:
329

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

IcmpInDestUnreachs conta a quantidade de mensagens ICMP de

destino inalcanvel recebidas pelo equipamento;

IcmpOutDestUnreachs conta a quantidade de mensagens ICMP de destino inalcanvel transmitidas pelo equipamento;

As variveis apresentadas so do tipo contador, por isso precisamos descobrir o seu incremento ao longo de um determinado intervalo de tempo. Para saber, por exemplo, se um roteador est enviando muitas mensagens ICMP de destino inalcanvel precisamos obter o valor de IcmpOutDestUnreachs, esperar um certo tempo e depois obter o valor desta varivel novamente. A diferena de valores entre a primeira e a segunda coletas informa se o roteador est ou no transmitindo muitas mensagens de destino inalcanvel. No comum que roteadores recebam mensagens ICMP de destino inalcanvel. Se um roteador recebe uma mensagem deste tipo significa que ele est originando os datagramas que causam o envio de mensagens de destino inalcanvel. Excetuando-se dados de controle de roteamento transmitidos por protocolos como RIP e OSPF, trfego SNMP, mensagens de logs62 e sesses de telnet, um roteador no a origem de datagramas, apenas um repassador destes. Se um roteador est enviando muitas mensagens ICMP de destino inalcanvel, algum problema est ocorrendo na rede, e merece uma investigao. Infelizmente, com uma estao de gerncia SNMP no podemos saber que tipo de mensagem ICMP de destino inalcanvel est sendo recebida/transmitida pelos equipamentos da rede. No podemos tambm saber que endereo ou porta destino gerou a mensagem de destino inalcanvel. Na Seo USANDO UM ANALISADOR DE PROTOCOLOS voc ver como realizar esta investigao usando um analisador de protocolos.

11.10.3 Usando uma interface de linha de comando

Apresentaremos nesta seo como obter a quantidade de mensagens ICMP de destino inalcanvel enviada/recebida por roteadores Cisco. Se voc possui roteadores produzidos por outro fabricante procure nos manuais dos seus equipamentos os comandos correspondentes aos que sero apresentados aqui. Em um roteador Cisco com IOS verso 10.0 ou superior, execute o comando:
roteador> show ip traffic IP statistics: () ICMP statistics: Rcvd: 0 format errors, 1 checksum errors, 0 redirects, 5 unreachable 27150 echo, 1 echo reply, 0 mask requests, 0 mask replies, 0 quench 0 parameter, 0 timestamp, 0 info request, 0 other 0 irdp solicitations, 0 irdp advertisements

62

O roteador pode estar configurado para escrever logs em um hospedeiro.

330

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Sent: 146052 redirects, 36034 unreachable, 0 echo, 27150 echo reply 0 mask requests, 0 mask replies, 0 quench, 0 timestamp 0 info reply, 7863 time exceeded, 0 parameter problem 0 irdp solicitations, 0 irdp advertisements ()

As quantidades de mensagens ICMP de destino inalcanvel transmitidas e recebidas pelo roteador esto em negrito. Estes valores so contadores, portanto, ser necessrio recuper-los em dois momentos distintos e ver quantas mensagens ICMP de destino inalcanvel foram realmente enviadas neste intervalo de tempo. Utilizando uma interface de linha de comando no ser tambm possvel obter informaes sobre o tipo de mensagem de destino inalcanvel transmitida/recebida pelo roteador.

11.10.4 Usando um analisador de protocolos

Quando voc desejar realizar uma investigao mais profunda sobre o trfego de mensagens ICMP de destino inalcanvel use um analisador de protocolos. Nesta seo veremos como proceder. Voc descobriu que um roteador est enviando muitas mensagens ICMP de destino inalcanvel e resolveu analisar melhor estas mensagens usando um analisador de protocolos. Para descobrir atravs de qual interface do roteador as mensagens ICMP esto sendo enviadas ser necessrio analisar o trfego em cada uma delas. Conecte o analisador de protocolos adequadamente, como descrito no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Se voc desconfia que as mensagens ICMP esto sendo enviadas para mquinas no locais, voc pode conectar seu analisador em um enlace por onde passe todo o trfego de sada da rede interna. Conectar o analisador de protocolos de forma que ele enxergue todo o trfego de sada da rede interna interessante porque voc pode ver todas as mensagens ICMP enviadas por todos os roteadores da rede interna para mquinas externas. Crie/selecione um filtro que capture apenas mensagens ICMP. Dicas para a criao deste filtro no Sniffer, da Network Associates, podem ser encontradas na Seo 9.1.2 CRIANDO E SELECIONANDO FILTROS DE CAPTURA. Capture mensagens ICMP durante alguns minutos. Em seguida analise as mensagens ICMP de destino inalcanvel capturadas. Em primeiro lugar, olhe o tipo das mensagens capturadas. Como dissemos na Seo DESCRIO E DICAS, existem vrios tipos de mensagens ICMP de destino inalcanvel, cada um deles reportando um certo tipo de erro. Observe o endereo IP origem e destino das mensagens ICMP de destino inalcanvel capturadas. Assim, voc saber que roteador est enviando estas mensagens e que mquina enviou um datagrama para um destino/porta inalcanvel. Na Figura 11-4 destacamos o endereo IP (192.168.2.1) do roteador que enviou a mensagem ICMP de destino inalcanvel.
331

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Uma outra anlise interessante pode ser realizada quando se tratam de mensagens ICMP de rede ou hospedeiro inalcanveis. Toda mensagem ICMP carrega o cabealho IP do datagrama que gerou a mensagem. Isto significa que podemos saber qual o destino que est inalcanvel. Na Figura 11-5 destacamos o endereo IP destino (192.168.1.6) do datagrama original que causou o envio da mensagem ICMP de destino inalcanvel, isto , o endereo IP da mquina que est inalcanvel. Quando se tratam de mensagens ICMP de portas inalcanveis interessante saber tambm que porta est envolvida. Infelizmente, na mensagem ICMP apenas o cabealho do datagrama que gerou a mensagem anexado. Isto significa que ao analisar uma mensagem ICMP de porta inalcanvel podemos saber que mquina gerou a mensagem, mas no podemos saber que porta foi acessada. Para descobrir que porta est envolvida, comece a capturar os dados originados nas mquinas para as quais as mensagens ICMP de portas inalcanveis foram destinadas.

Figura 11-4: Endereo IP do roteador que gerou a mensagem ICMP de destino inalcanvel.

332

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Vamos ver um exemplo: suponha que voc capturou mensagens ICMP de porta inalcanvel originadas na mquina 192.168.5.100 e destinadas mquina 192.168.1.200. Isto significa que um processo na mquina 192.168.1.200 tentou se comunicar com uma porta desativada da mquina 192.168.5.100. Mas, que porta esta? Crie um filtro no analisador que selecione apenas datagramas que envolvam as mquinas 192.168.1.200 e 192.168.5.100. possvel que a mquina 192.168.1.200 tente novamente acessar o servio desativado da mquina 192.168.5.200. Capture algumas dezenas de quadros. Veja a porta destino das mensagens que precedem uma mensagem ICMP de porta inalcanvel. Analisando os quadros capturados voc poder descobrir que porta est desativada na mquina que est gerando as mensagens ICMP de porta inalcanvel.

Figura 11-5: Cabealho IP do datagrama que causou o envio da mensagem ICMP de destino inalcanvel.

Note que se a mquina 192.168.1.200 fizer uma tentativa de comunicao com uma porta inalcanvel da mquina 192.168.5.100 e depois desistir, nada poderemos concluir com este teste. Alm disso, se as mquinas 192.168.5.100 e 192.168.1.200 esto se comunicando atravs de vrios processos em vrias portas distintas, devemos tomar cuidado para no tirar concluses erradas. Por exemplo, a mquina 192.168.5.100 servidora Web e de correio eletrnico. Um cliente na mquina 192.168.1.200 est usando estes dois servios oferecidos pela mquina 192.168.5.100, alm de estar tentando acessar nesta um servio no
333

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

ativado. Neste caso, devemos analisar bem a comunicao entre as duas mquinas antes de identificar com certeza que porta est desativada.

11.11 Verificando se pacotes esto sendo descartados por falta de rotas

Neste procedimento descreveremos como verificar se os roteadores da rede esto descartando muitos datagramas por no encontrarem uma rota que possa lev-los ao seu destino.

11.11.1 Descrio e dicas

A varivel ipOutNoRoutes da MIB-2 [RFC1213] do tipo contador. Quando um roteador recebe um datagrama e nenhuma rota que o leve ao destino especificado encontrada, o datagrama descartado e a varivel ipOutNoRoutes incrementada. O crescimento da varivel ipOutNoRoutes no necessariamente um problema de roteamento. Segundo a definio desta varivel, quando todos os roteadores default de um roteador esto inacessveis, esta varivel tambm incrementada. Neste caso, o problema no de roteamento. O crescimento desta varivel em roteadores que no possuem rota default preocupante e pode indicar erros na tabela de rotas do roteador. O incremento desta varivel pode tambm indicar ataques. Programas maliciosos e worms, por exemplo, geram endereos destino falsos, muitas vezes de redes que no existem. O crescimento desta varivel em roteadores que deveriam ter rota default indica que a rota default no est configurada no momento (se ela for aprendida dinamicamente) ou que todos os roteadores default no esto acessveis.

11.11.2 Usando uma estao de gerncia SNMP

Recupere o valor da varivel ipOutNoRoutes da MIB-2 nos roteadores de sua rede usando uma estao de gerncia SNMP. Lembre-se que ela um contador, e, portanto, o incremento desta varivel em um determinado intervalo de tempo que tem significado. Na maior parte do tempo esta varivel no deve mudar de valor.

11.11.3 Usando uma interface de linha de comando

Nesta seo veremos como obter o valor da varivel ipOutNoRoute usando uma interface de linha de comando em roteadores Cisco. Em roteadores Cisco com verso de IOS superior a 10.0 voc pode obter estatsticas de trfego IP com o seguinte comando:
roteador> show ip traffic

334

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

IP statistics: Rcvd: 2593286165 total, 10600762 local destination 0 format errors, 0 checksum errors, 885818 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 32532 with options Opts: 72 end, 1 nop, 4 basic security, 0 loose source route 0 timestamp, 0 extended security, 3 record route 0 stream ID, 0 strict source route, 32459 alert, 0 cipso 0 other Frags: 0 reassembled, 1 timeouts, 226 couldn't reassemble 496166 fragmented, 0 couldn't fragment Bcast: 58033 received, 12 sent Mcast: 1893437 received, 3482544 sent Sent: 17569897 generated, 1571770454 forwarded Drop: 811982 encapsulation failed, 0 unresolved, 0 no adjacency 10070563 no route, 0 unicast RPF, 0 forced drop

()

O contador no route (em negrito) indica quantos pacotes foram jogados fora devido falta de rotas. Lembre-se que o valor nico de no route nada significa. O que vale o seu incremento no tempo. No exemplo acima vemos que 10070563 datagramas foram descartados por falta de rotas. Este nmero nada significa. Ele pode ter sido incrementado em um momento em que todos os roteadores default estavam inoperantes. Apenas se esta varivel estiver crescendo no momento e todos os roteadores default estiverem operacionais que podemos concluir que existe um problema.

11.12 Analisando a origem do trfego de difuso em um domnio de difuso

Neste procedimento apresentaremos como identificar as mquinas que esto enviando quadros de difuso em um determinado domnio de difuso.

11.12.1 Descrio e Dicas

Antes de entenderemos este procedimento, necessrio sabermos um pouco mais sobre quadros e datagramas de difuso e domnios de difuso. Existem dois tipos de difuso: difuso nvel 2 (enlace) e difuso nvel 3 (rede), tambm chamada difuso lgica. Quadros de difuso nvel 2 so destinados ao endereo fsico (MAC) de difuso, que FFFFFFFFFFFF. Quadros ARP so exemplos de quadros de difuso nvel 2. Eles so quadros gerados por protocolos da camada de enlace, e no carregam, portanto, dados do protocolo IP ou superiores. Um quadro de difuso nvel 3, por sua vez, carrega um datagrama IP cujo endereo destino o endereo de difuso dirigida ou o endereo de difuso limitada. O endereo de difuso dirigida formado pelo prefixo da rede seguido de bits 1 em substituio ao sufixo de identificao da mquina. Por exemplo, o endereo de difuso dirigida da rede 192.168.1.0/24 192.168.1.255. Um datagrama de difuso dirigida roteado at a rede destino como se fosse um datagrama direcionado a uma nica mquina desta rede. Quando este quadro chega no
335

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

roteador ligado diretamente a esta rede, ele trata de entregar o quadro a todas as mquinas da rede. Para enviar um datagrama de difuso dirigida a origem deve conhecer o prefixo da rede a ser alcanada. Segundo [BCP0034], roteadores devem ser, por default, proibidos de repassar datagramas destinados ao endereo de difuso dirigida. Esta prtica foi adotada por questes de segurana, pois datagramas destinados a endereos de difuso dirigida podem ser usados em diversos tipos de ataques de negao de servio. Assim, um roteador s deve receber um datagrama destinado a um endereo de difuso dirigida se ele tiver sido explicitamente configurado pelo administrador da rede para aceitar rotear este tipo de datagrama. Roteadores mais novos j se comportam assim. J roteadores mais antigos ainda podem estar repassando datagramas de difuso dirigida e voc deve reconfigur-lo apropriadamente para que ele no mais aceite receber este tipo de trfego. O endereo IP 255.255.255.255 chamado de endereo de difuso limitada. Quando uma estao gera um datagrama destinado a este endereo, todas as estaes da mesma rede local que a remetente recebem o datagrama. Datagramas de difuso limitada no so roteados, eles so gerados e entregues em um mesmo domnio de difuso. Em geral, domnios de difuso so limitados por roteadores ou por VLANs. Tipicamente, as mquinas de um mesmo domnio de difuso compartilham de um mesmo prefixo e mscara de rede. De posse da documentao da rede devemos estar aptos a identificar o prefixo e a mscara de rede de um domnio de difuso. Em um domnio de difuso onde todos os roteadores negam receber mensagens destinadas ao endereo de difuso dirigida, devemos encontrar apenas quadros de difuso originados em mquinas do domnio de difuso em questo. Suponha que as mquinas de um certo domnio de difuso possuem os seguintes prefixo e mscara de rede: 192.168.2 e 255.255.255.0. Se todos os roteadores ligados diretamente a esta rede negam transmitir quadros de difuso dirigida, encontraremos neste domnio de difuso apenas quadros de difuso originados por mquinas cujo prefixo de rede e mscara de rede so respectivamente 192.168.2 e 255.255.255.0. Alguns problemas de rede relacionados a VLANs (que definem domnios de difuso) podem causar uma desordem geral nos domnios de difuso da rede. Esta desordem ser claramente percebida: encontraremos em um domnio de difuso quadros de difuso nvel 2 ou difuso lgica limitada enviados por mquinas que, devido a seu endereo IP, no deveriam estar fazendo parte deste domnio de difuso.

11.12.2 Usando um analisador de protocolos

A nica forma de descobrir a origem dos quadros de difuso que trafegam em um domnio de difuso usando um analisador de protocolos. Nesta seo veremos como este estudo pode ser feito.

336

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Como queremos analisar apenas quadros de difuso, basta conectar o analisador de forma que ele participe do domnio de difuso que deve ser estudado. Seja em um repetidor, seja em um comutador, o analisador receber todos os quadros de difuso deste domnio de difuso. Em redes Ethernet, endereos de difuso lgicos sempre so mapeados para o endereo de difuso fsico FFFFFFFFFFFF quando vo ser entregues aos destinos finais. Assim, quando uma estao gera um datagrama destinado ao endereo 255.255.255.255, por exemplo, o endereo destino fsico do quadro que carrega este datagrama ser FFFFFFFFFFFF. Crie um filtro de captura que selecione apenas quadros de difuso nvel 2 para a captura, isto , quadros cujo endereo MAC destino FFFFFFFFFFFF. No analisador de protocolos Sniffer, da Network Associates, este filtro pode ser criado como descrito no UTILIZANDO UM ANALISADOR DE PROTOCOLOS. Selecione o filtro criado e capture quadros durante alguns minutos. Em seguida, analise os quadros de difuso capturados. Verifique em o endereo das mquinas que esto enviando quadros de difuso. Se o quadro sendo analisado for um quadro de difuso lgica, olhe o endereo de quem o transmitiu no cabealho do datagrama IP (IP fonte). Se o quadro no traz dados do protocolo IP, como ARP, por exemplo, o endereo do remetente estar nos dados do protocolo nvel 2. Na Figura 11-6 destacamos o endereo IP da mquina que transmitiu um quadro de difuso ARP. No ser possvel localizar o endereo origem de mensagens DHCPDISCOVER que so enviadas para o endereo destino 255.255.255.255 pois a mquina que o transmite ainda no sabe qual o seu prprio endereo IP, por isto mesmo est solicitando um ao servidor DHCP.

Figura 11-6: Decodificao de uma requisio ARP no Sniffer.

337

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

11.13 Analisando a configurao de rede em um hospedeiro

Neste procedimento mostraremos como analisar a configurao de rede endereo IP, mscara de rede, roteador default e servidor de nomes em um hospedeiro.

11.13.1 Descrio e dicas

A configurao de rede de um hospedeiro normalmente envolve os seguintes valores: endereo IP do hospedeiro; mscara de rede; endereo IP dos servidores de nomes de domnio; endereo IP do roteador default. A partir do endereo IP, da mscara de rede e do endereo do roteador default, uma pequena mas imprescindvel tabela de rotas criada. Estas configuraes podem ser obtidas dinamicamente pelo hospedeiro ou podem ser definidas nele manualmente. No primeiro caso diz-se que o hospedeiro tem IP dinmico, pois um cliente DHCP, e no segundo que ele tem IP esttico. Verificar as configuraes de rede em hospedeiros uma tarefa bastante simples. Os prprios sistemas operacionais oferecem ferramentas que nos permitem visualizar as configuraes de rede do hospedeiro.

11.13.2 Usando outras ferramentas de gerncia

Veremos nesta seo como obter as configuraes bsicas de rede em mquinas com sistema operacional Windows e Linux. Em mquinas Windows 98/ME/NT/2000 o comando ipconfig /All pode ser utilizado. Veja o exemplo da sada deste comando na Figura 11-7. Exceto no Windows NT/2000, o comando winipcfg tambm pode ser utilizado. A Figura 11-8 apresenta o resultado deste comando. Os comandos j apresentados informam o endereo IP do roteador default configurado em um hospedeiro. Se voc deseja analisar a tabela de rotas completa de uma mquina com sistema operacional Windows execute o seguinte comando a partir de um prompt de comandos:
C:\> route print

338

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Figura 11-7: Exemplo do resultado do comando ipconfig /All.

Figura 11-8: Sada do comando winipcfg.

Em mquinas Linux esta verificao ser um pouco mais trabalhosa. Para descobrir o endereo IP do hospedeiro e a mscara de sub-rede execute o seguinte comando:
[maria@pc-15~]$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:04:AC:4C:98:DF Bcast:192.168.10.255 MTU:1500 Metric:1

inet Mask:255.255.255.0

addr:192.168.10.15

UP BROADCAST RUNNING MULTICAST

RX packets:9103385 errors:0 dropped:0 overruns:0 frame:0 TX packets:8066438 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2151783033 (2052.1 Mb) TX bytes:439771715 (419.3 Mb)

339

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Interrupt:15 Base address:0x2180

lo

Link encap:Local Loopback inet addr:127.0.0.1 UP LOOPBACK RUNNING Mask:255.0.0.0 MTU:16436 Metric:1

RX packets:788372 errors:0 dropped:0 overruns:0 frame:0 TX packets:788372 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:111515980 (106.3 Mb) TX bytes:111515980 (106.3 Mb)

O comando a seguir apresenta a tabela de rotas do hospedeiro. Observe o roteador default configurado.
[maria@pc-15~]$ route -n
Kernel IP routing table Destination 192.168.10.0 192.168.22.3 2 127.0.0.0 0.0.0.0 Gateway 0.0.0.0 192.168.10.13 1 0.0.0.0 192.168.10.25 4 Genmask 255.255.255.0 Flags Metric Ref Use Iface U 0 0 0 0 0 0 0 0 0 0 0 0 eth0 eth0 lo eth0

255.255.255.255 U 255.0.0.0 0.0.0.0 U UG

Quando o hospedeiro recebe mensagens ICMP de redirecionamento, ele pode adicionar em sua tabela de roteamento rotas especficas para hospedeiros. Na segunda linha da tabela de rotas apresentada acima, por exemplo, vemos uma rota especfica para outro hospedeiro (192.168.22.32). As mensagens ICMP de redirecionamento ensinam rotas melhores aos hospedeiros e estas rotas so inseridas na tabela de rotas (ver Seo 11.8.1). Idealmente, um hospedeiro no deve receber mensagens de redirecionamento e a existncia de rotas especficas para outros hospedeiros em tabelas de rotas s deveria ser constatada caso a rota tenha sido adicionada manualmente pelo administrador da rede. O nome do hospedeiro pode ser visualizado atravs do seguinte comando:
# hostname fqdn pc-15.exemplo.com.br

Por fim, para ver quais os servidores DNS configurados para responder consultas DNS deste hospedeiro veja o arquivo /etc/resolv.conf.
# more /etc/resolv.conf
domain exemplo.com.br nameserver 192.168.1.53 nameserver 192.168.1.54 nameserver 192.168.1.55

A diretiva domain indica o domnio de nomes a que o hospedeiro pertence. As diretivas nameserver informam os endereos IP dos servidores de nomes deste hospedeiro, que sero consultados na ordem em que foram configurados no arquivo.
340

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

11.14 Verificando conectividade via IP e conectividade via nome de domnio

Neste procedimento veremos como identificar se a falta de conectividade para um determinado equipamento total ou se apresenta apenas quando o seu nome de domnio usado.

11.14.1 Descrio e Dicas

Em vrias ocasies, nos deparamos com problemas reportados como falta de conectividade. Uma rede existe para que seus servios possam ser utilizados pelos usurios. Em geral, estes servios so acessados atravs dos nomes das mquinas onde esto instalados os programas servidores. Quando o mapeamento dos nomes dos servidores para endereos IP no possvel, os usurios tm a impresso de que o servio no est disponvel ou que a rede no est funcionando. A realizao do teste proposto neste procedimento indicado quando desconfiamos que o problema est no servio de nomes e no em camadas inferiores.

11.14.2 Usando ping

Nesta seo mostramos como usar o ping para confirmar problemas com o servio de nomes. Suponha que a sua estao de gerncia se comunica com os elementos gerenciados atravs de seus nomes de domnio. De repente, voc percecebeu que a partir de um certo ponto, todos os elementos da rede ficaram no operacionais. Voc desconfia que o problema com o servio de nomes, ento resolve fazer um teste simples para confirmar ou negar sua suspeita. O teste consiste em escolher um endereo IP de um equipamento que, de acordo com a estao, no est acessvel. Voc escolheu o equipamento roteador23.exemplo.com.br, cujo endereo IP 192.168.23.3. Simplesmente envie ping para este equipamento primeiro usando seu IP e depois seu nome. Veja o resultado:
# ping 192.168.23.3 PING 192.168.23.3 (192.168.23.3): 56 data bytes 64 bytes from 192.168.23.3: icmp_seq=0 ttl=255 time=1.0 64 bytes from 192.168.23.3: icmp_seq=1 ttl=255 time=0.6 64 bytes from 192.168.23.3: icmp_seq=2 ttl=255 time=0.6 64 bytes from 192.168.23.3: icmp_seq=3 ttl=255 time=0.6 64 bytes from 192.168.23.3: icmp_seq=4 ttl=255 time=0.6

ms ms ms ms ms

--- 192.168.23.3 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.6/0.6/1.0 ms # ping roteador23.exemplo.com.br 341

C A P T U L O

1 1

P R O C E D I M E N T O S

( C A M A D A

D E

R E D E )

Note que o equipamento respondeu quando voc usou seu endereo IP, mas no o seu nome. Este um comportamento tpico de uma rede com problemas no servio DNS.

11.15 Referncias 11.15.1 Recursos online (Internet)

[ANALYZINGDHCP-LOG] Analyzing Server Log files. Microsoft Windows 2000 Server Documentation. http://www.microsoft.com/windows2000/en/server/help/sa g_DHCP_tro_AnalyzingSrvLogs.htm [WIN-TIP316] Tip #316: Enable DHCP Logging. http://windows.about.com/library/tips/bltip316.htm [WIN-TIP412] Tip #412: DHCP Logging Event IDs. http://windows.about.com/library/tips/bltip412.htm

11.15.2 RFCs
[BCP0034] [RFC 792] [RFC1122] [RFC1812] [RFC1213] Senie, ,D. Changing the Default for Directed Broadcasts in Routers. Agosto, 1999. Postel, J. Internet Control Message Protocol. Setembro, 1981 Braden, R. Requirements for Internet Hosts - Communication Layers. Outubro, 1989 Baker, F. Requirements for IP Version 4 Routers. Junho, 1995. McCloghrie, K., Rose, M. Management Information Base for Network Management of TCP/IP-based internets: MIB-II. Maro, 1991. Baker, F. IP Forwarding Table MIB. Janeiro, 1997. Droms, R. Dynamic Host Configuration Protocol. 1997.

[RFC2096] [RFC2131]

11.15.3 Livros base

[COMER] Comer, D. Internetworking with TCP/IP: Principles, Protocols, and Architectures. Volume 1. Quarta edio. Prentice Hall, 2000.

342

12 Procedimentos referenciados nos problemas de nvel de aplicao

1 2
Captulo

Neste captulo apresentamos 8 procedimentos que informam como obter e analisar informaes de gerncia. Os procedimentos apresentados neste captulo informam como obter os sinais que foram mais referenciados nos problemas de nvel de aplicao. No entanto, existem alguns problemas de outras camadas que podem lhes referenciar.

12.1 Verificando consistncia de dados nos servidores DNS primrio e secundrios

Nesta seo veremos como verificar se servidores primrio e secundrios respondem igualmente s mesmas consultas, isto , se eles possuem os mesmos dados sobre as zonas pelas quais respondem.

12.1.1 Descrio e dicas

O servidor de nomes primrio de uma zona recupera as configuraes de nomes de sua zona a partir de um arquivo local. J os servidores secundrios recuperam os dados sobre a zona a partir de outro servidor DNS, chamado o servidor principal. Geralmente, os servidores secundrios recuperam dados sobre a zona a partir do servidor primrio. No comum, mas tambm possvel que servidores secundrios recuperem os dados da zona a partir de outro servidor secundrio. Os servidores de nomes primrio e secundrios devem retornar a mesma resposta quando uma mesma consulta lhes feita. Suponha que ns1.exemplo.com.br o servidor primrio do domnio exemplo.com.br. Os servidores ns2.exemplo.com.br e ns3.exemplo.com.br so servidores secundrios que obtm os dados sobre a zona exemplo.com.br a partir de ns1. Quando perguntarmos a ns1, ns2 e ns3 qual o IP correspondente ao nome www.exemplo.com.br, todos os servidores devem oferecer a mesma resposta. Os servidores de nomes mais novos (BIND verses 8.2.3 e superiores e servidor DNS do Windows 2000, por exemplo) notificam por default os servidores secundrios quando percebem que os seus arquivos de zonas foram modificados. Quando o servidor principal age desta forma, as modificaes em arquivos de zonas so rapidamente vistas pelos servidores secundrios. Quando
343

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

o servidor principal no notifica os secundrios sobre modificaes nos arquivos de zonas, os servidores secundrios s percebero a mudana aps algum tempo, que no mximo o intervalo de refresh configurado no registro SOA do arquivo de zonas modificado. Portanto, se seus servidores principais no notificam os servidores secundrios sobre mudanas, as respostas de servidores principais e secundrios podem diferir durante algum tempo (no mximo o intervalo de refresh) isso normal.

12.1.2 Usando nslookup, dig e host

Descreveremos nesta seo como verificar a consistncia dos dados entre servidores DNS primrio e secundrios usando as seguintes ferramentas: nslookup, dig e host. Antes de realizar este procedimento voc ter que decidir quais as consultas que sero feitas aos servidores primrio e secundrios. Voc deve consultar os servidores de nomes primrio e secundrios sobre as ltimas modificaes realizadas no servidor de nomes primrio. Suponha que a ltima modificao realizada foi alterar o IP da mquina www.exemplo.com.br de 192.168.1.2 para 192.168.1.80. Ento, solicite aos servidores de nomes primrio e secundrios que faam o mapeamento direto e reverso de www. Conecte-se em um dos servidores de nomes que sero testados. O servidor de nomes que, por default, responder s consultas feitas atravs de nslookup, dig ou host o servidor DNS que serve mquina onde voc est conectado. Se esta mquina abriga um servidor DNS bastante provvel que ela seja cliente DNS dela mesma. No exemplo mostrado a seguir o comando nslookup foi utilizado. Quando este comando executado sem parmetros ele age de forma interativa. Estabelecemos conexo com o servidor DNS primrio do domnio exemplo.com.br, que ns1.exemplo.com.br e executamos os seguintes comandos:
[maria@ns1 ~]$ nslookup > www.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Name:

www.exemplo.com.br

Address: 192.168.1.80 > 192.168.1.80 Server: Address: 192.168.1.53 192.168.1.53#53

80.1.168.192.in-addr.arpa >

name = www.exemplo.com.br.

344

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Com estas consultas, descobrimos que, no servidor de nomes primrio, a mquina cujo nome www.exemplo.com.br possui o endereo IP 192.168.1.80 e a mquina cujo IP 192.168.1.80 tem o nome www.exemplo.com.br. Uma perfeita correspondncia de registros A e PTR. Os resultado foi o que espervamos. Agora devemos realizar esta mesma consulta nos servidores secundrios de exemplo.com.br. O objetivo verificar se os servidores secundrios tambm consideram o mapeamento www.exemplo.com.br 192.168.1.80. Usando ainda o nslookup no modo interativo em ns1 (continuao dos comandos apresentados anteriormente), execute os comandos a seguir:
> server ns2.exemplo.com.br Default server: ns2.exemplo.com.br Address: 192.168.1.54#53 > www.exemplo.com.br Server: Address: ns2.exemplo.com.br 192.168.1.54#53

Name:

www.exemplo.com.br

Address: 192.168.1.2 > 192.168.1.80 Server: Address: ns2.exemplo.com.br 192.168.1.54#53

** server can't find 80.1.168.192.in-addr.arpa.: NXDOMAIN > 192.168.1.2 Server: Address: ns2.exemplo.com.br 192.168.1.54#53

2.1.168.192.in-addr.arpa > server ns3.exemplo.com.br

name = www.exemplo.com.br.

Default server: ns3.exemplo.com.br Address: 192.168.1.55#53 > www.exemplo.com.br Server: Address: ns3.exemplo.com.br 192.168.1.55#53

Name:

www.exemplo.com.br

Address: 192.168.1.2 > 192.168.1.80 Server: Address: ns3.exemplo.com.br 192.168.1.55#53

** server can't find 80.1.168.192.in-addr.arpa.: NXDOMAIN

345

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

> 192.168.1.2 Server: Address: ns3.exemplo.com.br 192.168.1.55#53

2.1.168.192.in-addr.arpa

name = www.exemplo.com.br.

O comando server <nome do servidor DNS> utilizado para modificar o servidor que responde s consultas realizadas com nslookup. Com estas consultas, descobrimos que os dados dos servidores secundrios no esto compatveis com os dados do servidor primrio. No servidor primrio o endereo IP de www.exemplo.com.br 192.168.1.80, enquanto que nos servidores secundrios o endereo IP de www ainda 192.168.1.2. A ferramenta nslookup automaticamente instalada quando o servidor de nomes BIND ou do Windows instalado. Portanto, este procedimento pode ser realizado em quaisquer destes servidores. Outra ferramenta que pode lhe ajudar se o seu servidor DNS for uma implementao BIND o dig. Para realizar as mesmas consultas que acabamos de fazer com nslookup conecte-se em ns1 e execute os seguintes comandos:
maria@ns1:~$ dig www.exemplo.com.br maria@ns1:~$ dig x 192.168.1.80

Assim como o nslookup, o dig tambm usa, por default, o servidor de nomes configurado para servir a mquina onde ele est sendo executado. Com os comandos apresentados, voc vai descobrir como www est configurado em ns1. Vai descobrir que para ns1 o IP de www 192.168.1.80. A sada do dig oferece muito mais informaes que a sada do nslookup. Veja, por exemplo, a resposta do dig para a consulta dig www.exemplo.com.br:
maria@ns1:~$ dig www.exemplo.com.br
; <<>> DiG 9.2.0rc3 <<>> www.exemplo.com.br ;; global options: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45099 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 printcmd

;; QUESTION SECTION: ;www.exemplo.com.br. IN A

;; ANSWER SECTION: www.exemplo.com.br. 86400 IN A 192.168.1.80

;; AUTHORITY SECTION: exemplo.com.br. 86400 IN NS ns1.exemplo.com.br.

;; ADDITIONAL SECTION: ns1.exemplo.com.br. 86400 IN A 192.168.1.53

346

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

;; Query time: 1 msec ;; SERVER: 192.168.1.53#53(192.168.1.53) ;; WHEN: Tue Mar 12 20:38:41 2002

;; MSG SIZE

rcvd: 137

Em negrito destacamos a resposta que estvamos procurando. At agora consultamos apenas o servidor primrio (ns1). Para realizar consultas nos demais servidores a partir de ns1 execute os seguintes comandos:
maria@ns1:~$ dig @ns2.exemplo.com.br www.exemplo.com.br maria@ns1:~$ dig @ns2.exemplo.com.br x 192.168.1.80 maria@ns1:~$ dig @ns3.exemplo.com.br www.exemplo.com.br maria@ns1:~$ dig @ns3.exemplo.com.br x 192.168.1.80

Existe ainda uma outra ferramenta que pode ser usada para realizar consultas DNS: a ferramenta host. Execute os comandos a seguir para realizar as mesmas consultas que realizamos anteriormente com nslookup e dig:
maria@ns1:~$ host www.exemplo.com.br maria@ns1:~$ host 192.168.1.80 maria@ns1:~$ host www.exemplo.com.br ns2.exemplo.com.br maria@ns1:~$ host 192.168.1.80 ns2.exemplo.com.br maria@ns1:~$ host www.exemplo.com.br ns3.exemplo.com.br maria@ns1:~$ host 192.168.1.80 ns3.exemplo.com.br

Veja um exemplo da resposta deste comando:

maria@ns1:~$ host 192.168.1.80 80.1.168.192.in-addr.arpa domain name pointer www.exemplo.com.br.

12.2 Analisando mensagens de log do servidor DNS BIND

Neste procedimento vamos falar um pouco sobre mensagens de log do servidor DNS implementao BIND.

12.2.1 Descrio e Dicas

Um bom gerente de redes deve estar sempre atento aos arquivos de logs de seus servidores. Nestes arquivos encontramos informaes importantes sobre o estado dos servios. Mostraremos neste procedimento apenas duas mensagens que podem surgir no arquivo de logs do servidor DNS, mas muitas outras mensagens certamente
347

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

estaro presentes. interessante que voc entenda estas mensagens, pois elas podem indicar algum problema.

12.2.2 Verificando logs do servidor DNS

Mostraremos nesta seo onde se localiza o arquivo de logs do servidor DNS (BIND) e algumas mensagens escritas neste arquivo em situaes de erro. Muitas outras informaes sobre mensagens de logs do servidor DNS podem ser encontradas em [DNS&BIND]. A implementao BIND do servio DNS enviar mensagens para o arquivo de log atravs do syslog. Por default, as mensagens de log do DHCP sero encontradas juntamente com mensagens de logs de todos os outros daemons que tambm usam o syslog. Tipicamente estas mensagens so encontradas em /var/log/messages ou /var/adm/messages, dependendo do seu sistema. Se voc modificou a configurao default do syslogd, veja no arquivo /etc/syslog.conf em que arquivo as mensagens de logs dos daemons esto sendo geradas. O arquivo que contm logs do BIND um arquivo de texto ASCII. Para ver todo o arquivo de logs:
# more /var/logs/messages

Para ver apenas as ltimas 50 linhas do arquivo:

# tail n 50 /var/logs/messages

Para localizar a palavra TTL, por exemplo:

# grep TTL /var/logs/messages
T T L
D E F A U L T
N O C O N F I G U R A D O

Em servidores DNS BIND verses 8.2 e superiores, o TTL default de uma zona deve ser configurado explicitamente atravs da diretiva $TTL. Quando isto no for feito o servidor DNS escrever uma mensagem no arquivo de log indicando o erro. A mensagem a seguir pode ser encontrada no arquivo de logs do servidor DNS BIND verso 8:
Apr 13 21:40:39 ns1 named[68]: Zone exemplo.com.br (file exemplo.zone): no default TTL ($TTL <value>) set, using SOA minimum instead

J em servidores DNS BIND verso 9 a mensagem um pouco diferente. Veja abaixo:

Apr 13 21:40:39 ns1 named[68]: dns_zone_load: zone exemplo.com.br/IN: database exemplo.zone: dns_db_load failed: no TTL
S
E R V I D O R

P R I N C I P A L I N A L C A N V E L

No arquivo de logs de servidores DNS secundrios podemos encontrar mensagens que indicam que no foi possvel alcanar o servidor principal ao tentar realizar uma transferncia de zona. Nos servidores DNS BIND verses 4 e 8 a mensagem a seguinte:
Apr 13 21:40:39 ns1 named[68]: zoneref: Masters for secondary zone exemplo.com.br unreachable

348

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Em servidores BIND verso 9 a mensagem como segue:

Apr 13 21:40:39 ns1 named[68]: refresh_callback: zone exemplo.com.br/IN: failure for 192.168.1.53#53: timed out
S
O B R E D O

L O G S

S E R V I D O R

D N S
I N D O W S

As mensagens de log do servidor DNS do Windows podem ser vistas atravs do Visualizador de Eventos. Pressione Iniciar > Programas > Ferramentas Administrativas > Visualizador de Eventos e em seguida clique em Servidor DNS para ver apenas as mensagens deste servidor. O servidor DNS da Microsoft pode ser configurado para escrever outras mensagens de logs em um arquivo. Este arquivo localiza-se por default em %Raiz do sistema%\System32\dns. Ele se chama Dns.log e pode ser lido no WordPad (arquivo escrito no formato RTF).

12.3 Verificando a resoluo de nomes de domnio externos

Neste procedimento apresentaremos como verificar se um servidor de nomes est resolvendo nomes de domnios externos.

12.3.1 Descrio e Dicas

Em geral, quando solicitamos a um servidor de nomes que ele resolva nomes de domnios externos, uma das seguintes situaes ocorrer: o servidor de nomes j resolveu esta requisio e a resposta ainda est armazenada em cache. Ento, o servidor simplesmente envia a resposta ao cliente DNS; o servidor DNS no possui a resposta desta consulta armazenada em cache e precisa falar com outros servidores, que podem estar dentro ou fora da organizao. Quando um servidor DNS no conseguir se comunicar com outros servidores DNS os servidores DNS raiz, por exemplo nomes de domnios externos no podero ser resolvidos. Suponha que ns1.exemplo.com.br seja servidor primrio de uma nica zona: exemplo.com.br. Se, por algum motivo, ns1 no conseguir se comunicar com pelo menos um servidor raiz, apenas nomes do domnio exemplo.com.br podero ser resolvidos por ele. Ele no ser capaz de responder qualquer consulta que envolva outro domnio.

12.3.2 Usando nslookup, dig e host

Nesta seo apresentaremos como podemos verificar se um servidor de nomes est resolvendo nomes de domnios externos. Para tal usaremos as ferramentas nslookup, dig e host. Conecte-se no servidor de nomes que voc deseja testar. O servidor de nomes que, por default, responder as consultas feitas atravs de nslookup, dig ou
349

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

host o servidor DNS que serve mquina onde voc est conectado. Se esta

mquina abriga um servidor DNS bastante provvel que ela seja cliente DNS dela mesma. Primeiramente, certifique-se de que o servidor de nomes em questo est resolvendo nomes locais apropriadamente. Use nslookup, dig ou host para resolver nomes de mquinas locais. Usaremos como exemplo o servidor ns1.exemplo.com.br, que o servidor de nomes primrio do domnio exemplo.com.br. Sabemos que este servidor deve saber mapear o nome www.exemplo.com.br para um endereo IP. Ento, esta foi a primeira consulta que realizamos.
U
S A N D O

maria@ns1:~$ nslookup www.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

N S L O O K U P

Name: www.exemplo.com.br Address: 192.168.1.80

Em seguida, escolha um nome de uma mquina um domnio externo. Escolhemos o nome externo www.cisco.com. Veja a seguir as consultas e respectivas respostas:
U
S A N D O

maria@ns1:~$ nslookup www.cisco.com Server: Address: 192.168.1.53 192.168.1.53#53

N S L O O K U P

Non-authoritative answer: Name: www.cisco.com Address: xx.xx.xx.25

U
S A N D O D I G

maria@ns1:~$ dig www.cisco.com ; <<>> DiG 9.2.0rc3 <<>> www.cisco.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cisco.com. ;; ANSWER SECTION: www.cisco.com. ;; AUTHORITY SECTION: cisco.com. cisco.com. ;; ;; ;; ;;

IN

86400

IN

xx.xx.xx.25

86400 86400

IN IN

NS NS

ns1.cisco.com. ns2.cisco.com.

Query time: 908 msec SERVER: 192.168.1.53#53(192.168.1.53) WHEN: Thu Apr 11 10:52:33 2002 MSG SIZE rcvd: 83

350

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

S A N D O H O S T

maria@ns1:~$ host www.cisco.com www.cisco.com has address xx.xx.xx.25

Nas consultas realizadas, obtivemos sempre resposta do servidor. Veja agora como o servidor responde a estes mesmos comandos quando no consegue, por alguma razo, se comunicar com os servidores raiz:
U
S A N D O

maria@ns1:~$ nslookup www.cisco.com Server: Address: 192.168.1.53 192.168.1.53#53

N S L O O K U P

;; connection timed out; no servers could be reached

U
S A N D O D I G

maria@ns1:~$ dig www.cisco.com

; <<>> DiG 9.2.0rc3 <<>> www.cisco.com ;; global options: printcmd ;; connection timed out; no servers could be reached
U
S A N D O H O S T

maria@ns1:~$ host www.cisco.com ;; connection timed out; no servers could be reached

Estes so resultados tpicos obtidos quando o servidor que est realizando a consulta no obtm respostas de outro servidor aps um certo intervalo de tempo. Nestes exemplos, o servidor DNS no pde resolver as consultas feitas a ele porque, por alguma razo, um dos servidores consultados por ele no pde ser alcanado. Quando a consulta realizada no pode ser resolvida porque o nome ou o IP que deve ser mapeado no existe, os comandos nslookup, dig e host respondem com NXDOMAIN ou non existent domain. Veja alguns exemplos:
U
S A N D O

N S L O O K U P

maria@ns1:~$ nslookup www.exemplp.com.br Server: 192.168.1.53 Address: 192.168.1.53#53 ** server can't find www.exemplp.com.br.: NXDOMAIN

S A N D O D I G

maria@ns1:~$ dig www.exemplp.com.br ; <<>> DiG 9.2.0rc3 <<>> www.exemplp.com.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53108 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.exemplp.com.br.

IN

;; AUTHORITY SECTION: com.br. 10762 IN SOA Hostmaster.REGISTRO.br. 2002041600 7200 3600 604800 86400

NS.DNS.br.

351

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

;; ;; ;; ;;
U
S A N D O H O S T

Query time: 1 msec SERVER: 200.129.64.130#53(200.129.64.130) WHEN: Tue Apr 16 08:37:22 2002 MSG SIZE rcvd: 99

maria@ns1:~$ host www.exemplp.com.br Host www.exemplp.com.br. not found: 3(NXDOMAIN)

Assim, podemos diferenciar claramente quando no possvel realizar uma consulta porque um dos servidores no responde (TIMED OUT) e quando a resposta a esta consulta realmente no existe (NXDOMAIN). Se voc quiser obter mais detalhes sobre a consulta, pode executar os comandos nslookup e dig com a opo que faz com que eles ofeream resultados mais detalhados sobre a consulta. Veja exemplos:
U

maria@ns1:~$ nslookup -d2 www.cisco.com

S A N D O

N S L O O K U P

main parsing www.cisco.com () looking up www.cisco.com setup_system() got a nameserver line make_server(192.168.1.53) () start_lookup() setup_lookup(0x8161d50) resetting lookup counter. () using root origin recursive query add_question() starting to render the message () send_udp(40123010) bringup_timer() have local timeout of 5 working on lookup 0x8161d50, query 0x40123010 () sending a request () send_done() () connect_timeout() () resending UDP request to first server () sending a request () ;; connection timed out; no servers could be reached cancel_lookup() ()

352

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

S A N D O D I G

O comando dig tambm aceita a mesma opo d2. O comando dig correspondente ao comando nslookup apresentado anteriormente :
# maria@ns1:~$ dig -d2 www.cisco.com

12.4 Analisando trfego DNS de um servidor de nomes de domnio

Neste procedimento vamos analisar o trfego de entrada e sada de um servidor DNS usando um analisador de protocolos.

12.4.1 Descrio e Dicas

Analisar o trfego DNS de entrada e sada de um servidor DNS pode ajudar a descobrir problemas como clientes DNS mal configurados, filtros IP barrando o trfego DNS e ataques de negao de servio. Se, por exemplo, virmos que o servidor envia consultas DNS para outros servidores, mas nunca obtm as respostas, possvel que exista um filtro IP barrando o trfego entre o servidor DNS em estudo e outros servidores DNS. Ao analisarmos todo o trfego de entrada e sada do servidor e no apenas o trfego DNS podemos encontrar outros sinais, como por exemplo mensagens ICMP de porta inalcanvel, indicando que o processo servidor no est em execuo. Se nenhum problema existir no servidor DNS e em seus clientes, e se tambm no existirem filtros barrando o trfego DNS, veremos basicamente: consultas DNS chegando no servidor e as respectivas respostas sendo transmitidas por ele para os emissores das consultas. Em se tratando de um servidor DNS interno, veremos apenas requisies de clientes internos; consultas enviadas por este servidor cujo trfego est sob anlise para outros servidores DNS e as respectivas respostas chegando logo mais.

12.4.2 Usando um analisador de protocolos

Nesta seo veremos como analisar o trfego de um servidor DNS usando um analisador de protocolos. Usaremos o analisador de protocolos Sniffer, da Network Associates, como exemplo. Conecte o analisador de protocolos de forma que ele capture todo o trfego do servidor de nomes que voc deseja testar. Veja no UTILIZANDO UM ANALISADOR DE PROTOCOLOS dicas de como conectar o analisador. Depois de conectar o analisador, voc pode criar um filtro que capture apenas o trfego DNS do servidor ou pode capturar todo o trfego do servidor.
353

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Aconselhamos que inicialmente voc capture todo o trfego e s se perceber que no h nada errado (vrias mensagens ICMP sendo enviadas ou transmitidas pelo servidor, por exemplo), se concentrar apenas no trfego DNS. Se voc perceber que muitas mensagens ICMP esto sendo transmitidas e/ou recebidas pelo servidor DNS analise-as como mostrado nos procedimentos apresentados nas Sees 11.8, 11.9 e 11.10. Basicamente, veja origem, destino e tipo das mensagens ICMP. Analise o trfego DNS do servidor. O servidor responde a todas as consultas feitas a ele? Existem consultas sem respostas realizadas pelo servidor? Quem consulta o servidor? normal que estas mquinas o consultem? Estas so algumas perguntas que voc deve responder ao analisar o trfego DNS do servidor. Na Figura 12-1 apresentamos uma seqncia de quadros onde o servidor DNS envia consultas para outros servidores, mas no recebe as respectivas respostas.

Figura 12-1: Servidor DNS envia consultas e no recebe resposta alguma.

12.5 Verificando consistncia de mapeamentos DNS direto e reverso

Neste procedimento ser descrito como verificar se h descasamento de mapeamento reverso e direto no servidor de nomes primrio.

12.5.1 Descrio e dicas

O mapeamento direto informa qual o endereo IP associado a um certo nome de domnio. O mapeamento reverso, como o prprio nome diz, faz o oposto: informa qual o nome de domnio correspondente a um dado endereo IP. Em geral queremos que o mapeamento direto e reverso estejam casados, isto , que o mapeamento direto de um nome A leve a um dado IP, e o mapeamento reverso deste IP leve ao mesmo nome A. possvel que nomes de domnio tenham apelidos. Por exemplo, perfeitamente possvel que a mquina cujo nome de domnio
354

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

servidor.exemplo.com.br tenha os seguintes apelidos: ftp.exemplo.com.br e mail.exemplo.com.br. Neste caso, o mapeamento direto vai indicar que o nome um apelido de outro.

12.5.2 Usando nslookup, dig e host

Nesta seo veremos como verificar se mapeamentos direto e reverso correspondentes so consistentes utilizando as ferramentas nslookup, dig e host. Suponha que voc deseja estudar os mapeamentos diretos e reversos da mquina cliente pc1.exemplo.com.br, cujo IP 192.168.11.1. Para realizar esta tarefa usando nslookup conecte-se no servidor de nomes primrio da zona exemplo.com.br e execute os seguintes comandos:
U

[maria@ns1 ~]$ nslookup

S A N D O

N S L O O K U P

> pc1.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Name: pc1.exemplo.com.br Address: 192.168.11.1 > 192.168.11.1 Server: 192.168.1.53 Address: 192.168.1.53#53 1.11.168.192.in-addr.arpa name = pc-1.exemplo.com.br.

Note que o mapeamento reverso de 192.168.11.1 leva ao nome de domnio pc-1.exemplo.com.br e no a pc1.exemplo.com.br. possvel tambm que o mapeamento direto e reverso no casem porque um dos dois no existe. Suponha que voc configurou que o nome pc1.exemplo.com.br corresponde ao endereo 192.168.11.1 (mapeamento direto), mas esqueceu de configurar que o endereo 192.168.11.1 mapeado no nome pc1.exemplo.com.br. Veja como seria o resultado do nslookup:
[maria@ns1 ~]$ nslookup > pc1.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Name: pc1.exemplo.com.br Address: 192.168.11.1 > 192.168.11.1 Server: Address: 192.168.1.53 192.168.1.53#53

** server can't find 1.11.168.192.in-addr.arpa.: NXDOMAIN

355

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Sempre que realizarmos uma consulta via nslookup e recebermos a resposta ** server can't find x.: NXDOMAIN significa que o servidor no foi capaz de realizar o mapeamento solicitado. Vamos verificar, com a ferramenta dig, se o mapeamento direto e reverso envolvendo pc1 esto casados:
U
S A N D O D I G

[maria@ns1 ~]$ dig pc1.exemplo.com.br

; <<>> DiG 9.2.0rc3 <<>> ns1.exemplo.com.br ;; global options: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;pc1.exemplo.com.br. ;; ANSWER SECTION: pc1.exemplo.com.br. ;; AUTHORITY SECTION: exemplo.com.br. ;; Query time: 2 msec ;; SERVER: 192.168.1.53#53(192.168.1.53) ;; WHEN: Thu Mar 21 19:33:47 2002 ;; MSG SIZE rcvd: 67 43200 IN NS ns1.exemplo.com.br. 43200 IN A 192.168.11.1 IN A printcmd

[maria@ns1 ~]$ dig x 150.165.75.21

; <<>> DiG 9.2.0rc3 <<>> -x 192.168.1.53 ;; global options: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4408 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;1.11.168.192.in-addr.arpa. ;; ANSWER SECTION: 1.11.168.192.in-addr.arpa. 43200 IN ;; AUTHORITY SECTION: 11.168.192.in-addr.arpa. 43200 ;; ADDITIONAL SECTION: ns1.exemplo.com.br. ;; Query time: 2 msec ;; SERVER: 192.168.1.53#53(192.168.1.53) ;; WHEN: Thu Mar 21 19:31:11 2002 ;; MSG SIZE rcvd: 107 43200 IN A 192.168.1.53 IN NS ns1.exemplo.com.br. PTR pc-1.exemplo.com.br. IN PTR printcmd

356

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Se o status da consulta retornar NXDOMAIN, a seo ANSWER SECTION no existir, significando que o mapeamento solicitado no foi possvel. Por fim, vamos realizar nossa verificao de consistncia entre mapeamentos direto e reverso correspondentes utilizando a ferramenta host:
U
S A N D O H O S T

[maria@ns1 ~]$ host pc1.exemplo.com.br pc1.exemplo.com.br has address 192.168.11.1

[maria@ns1 ~]$ host 192.168.11.1 1.11.168.192.in-addr.arpa domain name pointer pc-1.exemplo.com.br.

Quando o mapeamento solicitado no for possvel a resposta ser:

[maria@ns1 ~]$ host pc-1.exemplo.com.br Host pc-1.exemplo.com.br. not found: 3(NXDOMAIN)

Uma observao final: nomes de domnio podem ter apelidos. Neste caso, nomes diferentes levaro a um mesmo endereo IP e este endereo IP corresponde a apenas um nome. Quando voc solicitar o mapeamento direto de um apelido, o nslookup, dig e host informaro que este nome um apelido e informa o endereo IP correspondente a este nome de domnio. No fica caracterizado, portanto, um descasamento de mapeamento direto e indireto. Veja como as ferramentas nslookup e host informam que ftp apelido de servidor.exemplo.com.br.
[maria@ns1 ~]$ nslookup > ftp.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

ftp.exemplo.com.br canonical name = servidor.exemplo.com.br. Name: servidor.exemplo.com.br Address: 192.168.1.20 [maria@ns1 ~]$ host ftp.exemplo.com.br ftp.exemplo.com.br is an alias for servidor.exemplo.com.br. servidor.exemplo.com.br has address 192.168.1.20

Quando for solicitado via dig um mapeamento direto de um apelido a seo de resposta vir como exemplificado a seguir:
;; ANSWER SECTION: ftp.exemplo.com.br. servidor.exemplo.com.br. 43200 43200 IN IN CNAME A servidor.exemplo.com.br. 192.168.1.20

357

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

12.6 Consultando o servidor DNS e obtendo respostas com nomes de domnio duplicados
Neste procedimento veremos como realizar diversos tipos de consultas em um servidor de nomes. Veremos como ele responde quando consultamos um nome que envolve o seguinte erro de configurao: ao escrever um arquivo de zona, o administrador da rede usou nomes totalmente qualificados, mas esqueceu de finaliz-los com um . (ponto).

12.6.1 Descrio e Dicas

Ao escrever um arquivo de zonas, podemos escolher usar nomes relativos ao domnio sendo configurado (www apenas, por exemplo) ou nomes totalmente qualificados (www.exemplo.com.br). Quando usamos nomes completos precisamos termin-los com um ponto. Um servidor interpreta um nome sem um ponto final como um nome relativo zona sendo configurada, e acrescenta o nome desta zona a este nome. Consultas a este nome viro com o nome do domnio duplicado. Se o servidor achar o . aps o nome, ele saber que o nome j est completo e no mais precisar acrescentar a ele o nome do domnio.

12.6.2 Usando nslookup, dig e host

Mostraremos nesta seo como realizar algumas consultas usando nslookup, dig e host que envolvem nomes cuja configurao est levando o servidor a duplicar o nome do domnio. Testaremos a configurao do servidor ns1, do domnio exemplo.com.br. Suponha que o nome da mquina www (192.168.1.80) foi escrito no arquivo de configurao de zona em sua forma completa, mas o administrador da rede esqueceu de pr o . final. O mesmo ocorreu com a mquina mail (192.168.1.25) no registro MX e com as mquinas ns2 (192.168.1.54) e ns3 (192.168.1.55) em registros NS. Quando o administrador foi configurar o nome correspondente ao IP 192.168.1.20 no arquivo de configurao de mapeamento reverso (registro PTR), esqueceu de colocar o ponto aps o nome completo da mquina ftp.exemplo.com.br. Vamos ver como descobrimos isto realizando algumas consultas.
U
S A N D O

maria@ns1:~$ nslookup www.exemplp.com.br Server: Address: 192.168.1.53 192.168.1.53#53

N S L O O K U P

No existe www???

** server can't find www.exemplo.com.br.: NXDOMAIN > 192.168.1.80 Server: Address: 192.168.1.53 192.168.1.53#53

Mas 192.168.1.80 www!!!

80.1.168.192.in-addr.arpa

name = www.exemplo.com.br.

358

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

> www.exemplo.com.br.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Ser que esqueci do .? Sim!

Name:

www.exemplo.com.br.exemplo.com.br.

Address: 192.168.1.80 > ftp.exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Name:

ftp.exemplo.com.br.

Address: 192.168.1.20 > 192.168.1.20 Server: Address: 192.168.1.53 192.168.1.53#53

20.1.168.192.in-addr.arpa

name = ftp.exemplo.com.br.1.168.192.in-addr.arpa.

> set type=MX > exemplo.com.br Server: Address: 192.168.1.53 192.168.1.53#53

Quem so os servidores SMTP?

exemplo.com.br

mail exchanger = 10 mail.exemplo.com.br.exemplo.com.br.

> set type=NS > pop-pb.rnp.br Server: Address: 192.168.1.53 192.168.1.53#53

Quem so os servidores de nomes?

exemplo.com.br exemplo.com.br exemplo.com.br

U
S A N D O D I G

nameserver = ns1.exemplo.com.br. nameserver = ns2.exemplo.com.br.exemplo.com.br. nameserver = ns3.exemplo.com.br.exemplo.com.br.

As mesmas consultas realizadas com nslookup podem ser realizadas com dig. Veja as consultas e algumas respostas:
maria@ns1:~$ dig www.exemplo.com.br
; <<>> DiG 9.2.0rc3 <<>> www.exemplo.com.br ;; global options: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32077 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 () printcmd

maria@ns1:~$ dig x 192.168.1.80

() ;; ANSWER SECTION:

359

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

80.1.168.192.in-addr.arpa. 43200 IN ()

PTR

www.exemplo.com.br.

maria@ns1:~$ dig www.exemplo.com.br.exemplo.com.br

() ;; QUESTION SECTION: ;www.exemplo.com.br.exemplo.com.br. IN A

;; ANSWER SECTION: www.exemplo.com.br.exemplo.com.br. () 43200 IN A 192.168.1.80

maria@ns1:~$ dig ftp.exemplo.com.br

() ;; QUESTION SECTION: ; ftp.exemplo.com.br. IN A

;; ANSWER SECTION: ftp.exemplo.com.br. () 43200 IN A 192.168.1.20

maria@ns1:~$ dig x 192.168.1.20

() ;; ANSWER SECTION:
20.1.168.192.in-addr.arpa. 43200 IN PTR ftp.exemplo.com.br.1.168.192.in-addr.arpa.

()

maria@ns1:~$ dig mx exemplo.com.br

() ;; QUESTION SECTION: ; exemplo.com.br. IN MX

;; ANSWER SECTION: exemplo.com.br. () 43200 IN MX 10 mail.exemplo.com.br. exemplo.com.br.

maria@ns1:~$ dig ns exemplo.com.br

() ;; QUESTION SECTION: ; exemplo.com.br. IN NS

;; ANSWER SECTION: exemplo.com.br. exemplo.com.br. exemplo.com.br. () 86400 86400 86400 IN IN IN NS NS NS ns1.exemplo.com.br. ns2.exemplo.com.br.exemplo.com.br. ns3.exemplo.com.br.exemplo.com.br.

S A N D O H O S T

Usando o comando host, as pesquisas correspondentes s apresentadas usando nslookup e dig so as seguintes:
maria@ns1:~$ host www.exemplo.com.br

360

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Host www.exemplo.com.br not found: 3(NXDOMAIN)

maria@ns1:~$ host 192.168.1.80

80.1.168.192.in-addr.arpa domain name pointer www.exemplo.com.br.

maria@ns1:~$ host www.exemplo.com.br.exemplo.com.br

www.exemplo.com.br.exemplo.com.br has address 192.168.1.80

maria@ns1:~$ host ftp.exemplo.com.br

ftp.exemplo.com.br has address 192.168.1.20

maria@ns1:~$ host 192.168.1.20

20.1.168.192.in-addr.arpa domain name pointer ftp.exemplo.com.br.1.168.192.in-addr.arpa

maria@ns1:~$ host -t mx exemplo.com.br

exemplo.com.br mail is handled by 10 mail.exemplo.com.br.exemplo.com.br.

maria@ns1:~$ host -t ns exemplo.com.br

exemplo.com.br name server ns1. exemplo.com.br. exemplo.com.br name server ns2. exemplo.com.br.exemplo.com.br. exemplo.com.br name server ns3. exemplo.com.br.exemplo.com.br.

Aproveitamos este procedimento para mostrar como realizar tipos diferentes de consultas (NS e MX) no servidor DNS usando nslookup, host e dig.

12.7 Verificando se um servidor SMTP est com repasse totalmente fechado

Neste procedimento mostraremos um teste simples que pode ser realizado para verificar se um servidor de correio eletrnico est negando enviar mensagens para usurios no locais, mesmo quando um usurio local, usando uma mquina cliente local que solicita o envio da mensagem.

12.7.1 Descrio e Dicas

O servidor de correio eletrnico deve agir de forma seletiva: ele no pode aceitar enviar mensagens de quaisquer remetentes conectados em quaisquer que sejam as mquinas clientes para quaisquer destinatrios. Mas ele deve aceitar enviar mensagens solicitadas por usurios conectados em mquinas clientes locais para quaisquer destinatrios. Se um usurio estiver conectado em uma mquina no local e solicitar a entrega de um e-mail, o servidor deve aceitar entreg-lo apenas se os destinatrios da mensagem forem um ou mais usurios de domnios para os quais o servidor de correio eletrnico est configurado para servir.

12.7.2 Usando uma interface de linha de comando

Nesta seo mostraremos como podemos manipular um servidor SMTP com uma interface de linha de comando e como proceder para testar se um determinado servidor de correio eletrnico est com repasse (relay) totalmente fechado.
361

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

Conecte-se em uma mquina cliente da rede. Execute nesta mquina o seguinte comando:
# telnet IP_do_servidor_SMTP 25

Este comando pode ser executado a partir de um prompt de comando no Windows. Se voc estiver usando um cliente telnet Windows, configure-o para realizar eco local do que voc digitar. Caso contrrio os seus comandos no sero apresentados na tela do telnet, pois o servidor de correio no faz echo do que recebe do cliente telnet. Aps estabelecida a conexo podemos conversar diretamente com o servidor a ser testado. No exemplo que daremos a seguir estamos testando o servidor mail.exemplo.com.br. Este servidor deve aceitar transmitir mensagens solicitadas por usurios locais conectados em mquinas com IP da rede 192.168.1.0/25. Efetuamos o login na mquina 192.168.1.200 e executamos o telnet na porta 25 para servidor de correio eletrnico. Veja como procedemos para test-lo:
# telnet mail.exemplo.com.br 25 220 mail.exemplo.com.br ESMTP mail from:<maria@exemplo.com.br> 250 ok rcpt to:<maria@cisco.com> 553 sorry, (#5.7.1) quit Closing connection. Good bye. that domain isn't in my list of allowed rcpthosts

Este um exemplo de mensagem que deveria ter sido aceita para entrega pelo servidor. O remetente maria@exemplo.com.br, conectada em uma mquina cliente local. Se o servidor de correio eletrnico estiver corretamente configurado ele aceitar transmitir a mensagem, pois o cliente que solicita o envio da mesma est conectado em uma mquina cliente local:
# telnet mail.exemplo.com.br 25 220 mail.exemplo.com.br ESMTP mail from:<maria@exemplo.com.br> 250 ok rcpt to:<cris@cisco.com> 250 ok Data 354 go ahead teste .

362

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

250 ok 1018961859 qp 18197 quit Closing connection. Good bye.

12.8 Verificando se um servidor SMTP est com relay totalmente aberto

Neste procedimento mostraremos como podemos testar se um servidor de correio eletrnico est aceitando repassar mensagens de qualquer remetente na Internet para qualquer destinatrio.

12.8.1 Descrio e Dicas

Um servidor de correio eletrnico com repasse (relay) aberto aceita repassar mensagens de quaisquer usurios conectados em quaisquer mquinas no mundo para quaisquer destinatrios. Servidores com repasse totalmente aberto so utilizados por spammers para enviar mensagens no solicitadas em grande quantidade. Para mais informaes veja problema SERVIDOR DE CORREIO ELETRNICO COM REPASSE TOTALMENTE ABERTO (pgina 201).

12.8.2 Usando uma interface de linha de comando

Nesta seo mostraremos um teste simples que pode ser realizado para verificar se um determinado servidor de correio eletrnico est com relay aberto. A interface de linha de comando pode ser obtida atravs de telnet. Conectese em uma mquina que certamente no pode ser cliente do servidor SMTP e faa um telnet na porta 25 do servidor a ser testado:
# telnet IP_do_servidor 25

Este comando pode ser executado a partir de um prompt de comando no Windows. Se usar cliente telnet Windows lembre-se de configur-lo para realizar eco local dos seus comandos, caso contrrio voc ao poder ver o que voc digitar. No exemplo que apresentaremos nesta seo testamos o servidor mail.exemplo.com.br. Este servidor deve aceitar transmitir mensagens solicitadas por usurios locais conectados em mquinas com IP da rede 192.168.1.0/25. Ele considera apenas usurios do domnio exemplo.com.br como usurios locais, isto , ele no servidor de correio eletrnico de nenhum outro domnio. Nos conectamos em uma mquina de uma outra rede cujo IP 192.168.200.1. A partir desta mquina executamos o telnet na porta 25 do servidor de correio eletrnico. Veja a seguir como procedemos para test-lo:
# telnet mail.exemplo.com.br 25

363

C A P T U L O

1 2

P R O C E D I M E N T O S

( C A M A D A

D E

A P L I C A O )

220 mail.exemplo.com.br ESMTP helo teste.com.br 250 mail.exemplo.com.br mail from:<qualquerusuario@qualquerdominio.com.br> 250 ok rcpt to:<maria@cisco.com> 250 ok Data 354 go ahead teste . 250 ok 1018961859 qp 18197 quit Closing connection. Good bye.

Note que estamos simulando um cliente SMTP na mquina 192.168.200.1, que est solicitando ao servidor de correio eletrnico sob teste que transmita uma mensagem para um usurio que no pertence a nenhum dos domnios que deveriam ser servidos pelo servidor SMTP. Se o servidor de correio eletrnico estivesse corretamente configurado ele s aceitaria transmitir a mensagem se ela estivesse destinada a um usurio do domnio exemplo.com.br.

12.8.3 Usando servios oferecidos por instituies anti-spam

Nesta seo apresentamos uma outra forma de testar se um servidor de correio eletrnico est com relay aberto.
TOTALMENTE ABERTO,

Como apresentado no problema SERVIDOR DE CORREIO ELETRNICO COM REPASSE existem vrias organizaes que lutam contra spammers. Algumas destas organizaes oferecem um servio que consiste em testar se um determinado servidor de correio eletrnico est inseguro. Em http://www.abuse.net/relay.html e http://mail-abuse.org/tsi/ar-test.html, por exemplo, este servio oferecido. Nestas pginas voc encontrar a receia completa de como deve proceder para usar o servio.

12.9 Referncias 12.9.1 Livros

[DNS&BIND] 33. Albitz, P. Liu, C. DNS and BIND. Quarta Edio. OReilly. Abril, 2001.

364

 N D I C E

R E M I S S I V O

NDICE REMISSIVO
A
Acesso ao meio compartilhado, 68 Alarmes, 16, 18, 20, 34, 137, 232, 254, 255, 258, 259, 266, 276, 278, 283, 285, 286 Algoritmo de estado de enlace, 156, 164 Algoritmo vetor-distncia, 164 Analisador de protocolos, iv, 16, 18, 19, 28, 31, 35, 69, 70, 89, 93, 98, 119, 121, 217, 218, 219, 220, 222, 225, 228, 230, 235, 243, 247, 250, 280, 288, 290, 292, 300, 301, 307, 308, 309, 310, 312, 315, 320, 321, 322, 324, 326, 327, 328, 330, 331, 336, 337, 353 capturando e analisando dados, 225, 243 dedicado, 228 filtro default, 222 filtros baseados em endereos, 223 filtros baseados em padres de dados, 223, 224 filtros baseados em protocolos conhecidos, 223 filtros de captura, 217, 222, 328, 331 instalado em computador pessoal, 228 Analogia com a Medicina, 26, 37 ARP, 27, 82, 91, 92, 93, 96, 97, 98, 99, 106, 107, 108, 133, 143, 144, 244, 252, 255, 273, 274, 286, 300, 301, 302, 303, 307, 308, 309, 310, 311, 335, 337 analisando trfego de difuso ARP, 98, 300 funcionamento, 301 tabela, 96 tempo de validade de uma entrada, 96, 97, 98, 99, 100, 301 grande, 96 pequeno, 97 recomendado, 97 rvore de Cobertura, 84, 85, 86, 87, 88, 89, 90, 91, 94, 95, 138 algoritmo, 85, 88 BPDUs, 84, 85, 88, 89, 90, 94, 261 dimetro da rede comutada, 85 forward delay, 87, 90 hello time, 87, 88, 89, 90 max age, 87, 90 mudanas de topologia, 85, 89, 94 Atualizao de componentes de software, 60 cabos de fibra tica, 42, 43, 44, 46, 49, 67 micro-fraturas, 42 cabos de pares tranados, 42, 44, 46, 47, 49, 50, 67, 71, 72, 75, 77, 236, 238, 292, 293, 294, 295 cat3, 72 cat5, 72, 74, 75, 294 cat5e, 294 cat6, 294 cat7, 294 cruzados, 51, 72, 73 IBM STP, 72 paralelos, 51, 72, 73, 75 Cabo de testes, 59 Cabos de rede atenuao do sinal, 48, 75, 292, 293, 294, 295 equao, 293 limiar, 294 cabos de pares tranados cabos cruzados, 51, 72, 73 cabos paralelos, 51, 72, 73, 75 seqncia de cores, 51 enlaces metlicos, 43, 44, 62 enlaces ticos, 43, 62, 67 interferncia, 44, 47, 49, 67, 68, 88, 238, 293 fontes comuns de rudo, 66 NEXT (Near-end crosstalk), 48, 50, 79, 292, 293, 294, 295, 304 equao, 293 limiar, 293 Camada fsica, iii, 26, 32, 38, 39, 40, 42, 59, 71, 228 Catlogo de problemas, iii, iv, 25, 26, 29, 31, 32, 216 Colises deteco, 254 excessivas, 48, 237, 242, 243 taxa de, 242 tardias, 61, 62, 76, 77, 237, 243, 247, 248, 253, 254, 255 alarme RMON, 254 contador, 254, 255, 256 taxa de, 242, 248, 249, 250 elevada, 22, 30, 68, 250 Comando access-list, 167, 200 copy system, 61 dig, 344, 346, 347, 349, 350, 351, 352, 353, 355, 356, 357, 358, 359, 360, 361 host, 61, 344, 347, 349, 350, 351, 352, 355, 357, 358, 360, 361 hostname, 340 ifconfig, 31, 108, 112, 245, 246, 253, 260, 261, 289, 297, 298, 339 ipchains, 167, 198, 199 ipconfig, 108, 111, 316, 321, 338 ipfwadm, 167 iptables, 167, 198, 199, 200 named-checkzone, 183, 185

B
Boot (reinicializao) de equipamentos, 56, 60, 265, 272

C
Cabo de rede, 38, 39, 42, 45, 46, 47, 57, 59, 63, 65, 66, 73

365

 N D I C E

R E M I S S I V O

netstat, 16, 19, 31, 163, 245, 246, 280, 281, 289, 314, 315 nslookup, 195, 344, 345, 346, 347, 349, 350, 351, 352, 353, 355, 356, 357, 358, 359, 360, 361 ping, 16, 19, 35, 40, 45, 46, 49, 59, 63, 65, 163, 217, 257, 308, 309, 311, 341 route, 124, 129, 279, 313, 314, 315, 335, 338, 340 top, 264, 271, 272 traceroute, 16, 19, 35, 127, 149, 153, 154, 155, 217, 232, 233, 257, 258 tracert, 127, 233, 257, 258 vmstat, 264, 265, 272, 273 winipcfg, 108, 111, 338, 339 write network, 61 Comando set set arp, 100 set cam, 96 set port, 54, 55, 83 set trunk, 146 Comando show show access-list, 166, 198 show arp, 99 show cam, 96 show counters, 245, 253, 288 show dhcp, 122 show environment, 58 show interface, 231, 244, 252, 255, 260, 286, 291, 296, 297 show ip, 159, 279, 313, 314, 324, 327, 330, 334 show mac, 253, 279, 287, 288 show memory, 268 show port, 54, 245, 253, 256, 260, 279, 287, 288, 291, 297 show proc, 263, 268, 269 show processes, 263, 268, 269 show running-config, 159 show spantree, 86 show trunk, 145 show version, 58 show vlan, 135, 140 Comutadores, 17, 46, 54, 55, 59, 60, 61, 62, 71, 73, 78, 83, 84, 85, 86, 87, 88, 89, 90, 92, 94, 95, 96, 99, 100, 135, 136, 137, 139, 140, 141, 142, 143, 144, 145, 146, 217, 218, 219, 220, 229, 230, 232, 244, 245, 252, 255, 256, 259, 260, 261, 263, 265, 266, 268, 269, 279, 286, 287, 288, 291, 296, 297, 299, 301, 308, 309, 310, 315, 316 aprendizagem pela origem (backward learning), 94, 299 Cisco estado administrativo de interfaces, 297 espelhamento de porta, 218, 219, 243, 304 proteo contra tempestades de difuso, 85 Conector, 26, 37, 38, 44, 47, 48, 49, 50, 51, 66, 72, 73, 77, 88 crimpagem, 47, 50 RJ-45, 47, 50, 51, 72 Crimpador, 51 inspeo visual, 49, 50

pares separados (split pairs), 47, 48, 50 seqncia de cores, 51 Conversor tico, 46, 47, 60

D
Descarte de pacotes, 265, 267 DHCP agente de repasse, 116, 117, 119, 122, 133, 134, 315, 316, 320, 321, 322 cliente, 103, 105, 108, 114, 116, 118, 122, 123, 138, 143, 144, 145, 315, 316, 317, 319, 320, 321, 338 configuraes obrigatrias, 115 DHCPACK, 315, 318 DHCPDISCOVER, 122, 315, 316, 318, 337 DHCPNAK, 119, 123, 315, 319, 320 DHCPOFFER, 119, 122, 315, 318 DHCPREQUEST, 122, 315, 316, 318 duplicao de servidor, 115 escopo mal definido, 115 mensagens de log, 316, 317, 318, 320 Linux, 318, 320, 348 Windows, 317 nmero de mquinas ativas superior disponibilidade de endereos, 116 servidor, 38, 64, 102, 103, 104, 105, 107, 108, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 132, 133, 134, 137, 138, 140, 143, 144, 145, 224, 315, 316, 317, 318, 319, 320, 321, 322, 337 tempo de concesso de endereo inadequado, 116 Difuso domnios de, 91, 138, 141, 218, 335, 336 equao trfego difuso, 275, 276, 278 equao trfego multicast, 275, 276, 278 limiares, 274, 275 quadros de, 27, 31, 82, 85, 86, 91, 92, 93, 95, 96, 97, 107, 133, 137, 139, 141, 142, 143, 144, 218, 227, 273, 274, 275, 276, 335, 336, 337 tempestades de, 85, 275 trfego de quadros de, 85, 92, 139, 276, 278 trfego mdio, 139 DNS, 27, 37, 113, 170, 171, 172, 173, 175, 176, 178, 182, 194, 197, 232, 341 anlise de logs, 347, 348 anlise de trfego, 353 arquivos de configurao, 27, 170, 172, 173, 174, 175, 179, 184, 185, 187, 188, 192, 193, 194, 195, 343 nmero de srie, 177, 178, 179, 181, 186, 187, 188, 194 formato recomendado, 181 ativao durante o boot, 174 BIND, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 182, 183, 184, 185, 186, 187, 190, 196, 199, 206, 343, 346, 347, 348, 349, 364 cache, 181, 182, 186, 191, 349 domnio reverso default, 194

366

 N D I C E

R E M I S S I V O

FDQN no terminado com ponto, 358 intervalo de refresh, 178, 179, 180, 186, 187, 188, 189, 190, 191, 344, 349 intervalo de retry, 184, 190, 191 mapeamento direto, 175, 176, 177, 184, 192, 344, 354, 355, 356, 357 mapeamento reverso, 175, 176, 177, 194, 354, 355, 358 nomes totalmente qualificados, 192, 193, 194 portas de transporte utilizadas, 196 registro SOA, 27, 170, 183, 184, 185, 186, 189, 190, 191, 344 registros IN A, 175, 176, 177, 194 registros IN PTR, 175, 176, 177, 194, 358 respostas negativas, 182, 186, 187 TTL, 182, 183, 184, 186, 187, 190 servidor de nomes, 38, 103, 104, 110, 113, 114, 118, 121, 122, 133, 170, 171, 172, 174, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 196, 197, 198, 199, 200, 338, 343, 344, 345, 346, 349, 350, 353, 354, 355, 358 primrio, 343 secundrio, 343 tempo de expirao, 190, 197 TTL default, 27, 170, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 348 valores de tempo muito grandes, 186 valores de tempo muito pequenos, 186 verificao de descasamento, 354 Documentao da rede, 32, 60, 77, 83, 103, 135, 137, 141, 149, 163, 336

E
Endereo de difuso dirigida, 335, 336 limitada, 335, 336 IP, 27, 102, 106, 117, 118, 121, 212, 317, 332 dinmico, 338 esttico, 338 IP duplicado, 106, 109, 307, 308 MAC, 46, 130, 134, 138, 141, 218, 299, 300, 301, 307, 309, 310, 311, 317, 337 Enlaces de redundncia, 84, 86, 130 Equipamentos de interconexo, 17, 31, 39, 43, 44, 49, 56, 62, 63, 64, 66, 72, 73, 82, 85, 92, 97, 136, 139, 229, 230, 262, 288, 295, 312 interfaces de rede, 65, 66, 104, 106, 290 desabilitada, 82 estado administrativo, 57, 82, 258, 259, 295, 296, 297, 298 porta de inverso, 73 Equipamentos reserva, 60 Equipe de gerncia de redes, ii, iii, 16, 19, 20, 21, 22, 23, 25, 32, 34, 69, 77, 82, 83,

128, 130, 131, 134, 136, 140, 155, 261, 295 gerente da equipe, 16, 19, 20 help desk, 16, 19, 20, 34, 35, 37 operador do sistema, 20, 34 suporte tcnico, 16, 19, 20, 35, 137 Erros de alinhamento, 48, 62, 69, 72, 236, 241, 242, 247, 290 de CRC, 43, 48, 62, 236, 239, 240, 241, 242, 247, 248, 290 deteco de portadora, 237 internos da camada MAC, 237 quadros muito longos, 237, 242, 290, 291, 292 jabber, 292 oversize, 292 quantidade de quadros muito longos por segundo, 292 taxa de erros de alinhamento via SNMP, 241 CRC e alinhamento via SNMP, 241 CRC via SNMP, 241 entrada, 235, 236, 238, 239, 247 internos de recepo via SNMP, 242 internos de transmisso via SNMP, 243 sada, 235, 236, 238, 240 taxa de erros elevada, 22, 30, 43, 236, 240 taxa mxima de erros em um hora, 238 Estao de gerncia, 16, 17, 18, 20, 28, 31, 34, 35, 37, 40, 76, 82, 83, 87, 88, 89, 95, 128, 150, 154, 156, 159, 161, 232, 238, 245, 247, 254, 255, 256, 258, 259, 262, 266, 270, 276, 277, 278, 283, 284, 286, 289, 290, 291, 296, 299, 313, 323, 326, 329, 330, 334, 341 descobrimento automtico de topologia, 78, 156 CDP (Cisco Discovery Protocol), 156, 274 Estado operacional equipamentos, 34, 256, 257 interfaces, 258, 259, 296 alarme, 259 Ethernet 100Base-TX, 42, 46, 47, 71, 72, 75, 78 10Base-TX, 75, 78 colises, 68 CSMA/CD, 53, 254 migrao de redes, 71 regras de cabeamento, 27, 42, 71, 75, 76, 77, 78, 254

F
Ferramentas de gerncia, 16, 19, 22, 25, 26, 28, 30, 31, 35, 78, 82, 235, 245, 247, 256, 260, 275, 280, 289, 338 interface de linha de comandos, 247 Filtro de pacotes, 27, 102, 164, 165, 166, 170, 195

367

 N D I C E

R E M I S S I V O

G
Gerncia de aplicaes, 21 Gerncia de Redes, ii, iii, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 32, 40, 68, 274 Gerncia de redes pr-ativa, 23 Gerncia de redes x Medicina, 26, 37

I
ICMP contador de mensagens destino inalcanvel enviadas, 330 contador de mensagens destino inalcanvel recebidas, 330 destino inalcanvel, 126, 133, 148, 152, 158, 165, 329, 330, 331, 332, 333 mensagem de destino inalcalvel, 158, 329, 330, 331 mensagem de hospedeiro inalcalvel, 329 mensagem de porta inalcalvel, 329 mensagem de rede inalcalvel, 329 mensagem de redirecionamento, 103, 322, 323, 324, 325, 340 ndices invertidos, iii, iv, 25, 29, 30, 32, 37, 38, 39 de sintomas, 30, 37 de sintomas e sinais, 30, 37 Informaes de gerncia, ii, iii, iv, 16, 17, 18, 19, 22, 30, 31, 35, 235, 307, 343 Instrumentao, 16, 22, 25, 26, 28, 30, 31, 35, 82, 256 Interface de linha de comando, 247 via porta de terminal, 229 via telnet, 229

L
LEDs, 43, 44, 49, 57, 58, 73, 95, 135, 137, 275 Limiar, 16, 18, 19, 22, 34, 37, 57, 58, 85, 92, 139, 188, 227, 235, 247, 255, 259, 261, 266, 267, 270, 275, 278, 285, 286, 294 Linha base (baseline) de configurao, 59, 60, 141

M
Mquina de testes, 45, 46, 49, 59, 65, 206 Mscara de rede IP maior do que deveria ser, 110 menor do que deveria ser, 110 Medicina, iii, 16, 21, 22, 23, 24, 25, 26, 40 Memria page in, 270 page out, 57, 270, 271, 273 paginao e memria virtual, 270, 272 Metodologia geral de deteco, diagnstico e resoluo de problemas, ii, iii, iv, 26, 30, 32, 33, 35, 36, 37, 41, 149 busca de informaes, 32, 34 desenvolvimento de hipteses, 32, 36

deteco, 29, 34 documentao das atividades, 41 lista de hipteses especficas, 36, 37, 38 organizao da lista de hipteses, 38 recorrncia de problema, 36 soluo do problema, 40 teste da soluo implantada, 40 teste das hipteses, 39 MIB Bridge, 87, 88, 89, 91, 95, 299 MIB CISCO-MEMORY-POOL, 266, 267, 304 MIB CISCO-PROCESS, 262 MIB Ether-like, 240, 290 MIB Host Resources, 263, 270, 271, 305 MIB IP Forwarding Table, 313, 342 ipCidrRouteTable, 313 MIB OLD-CISCO-MEMORY-MIB, 267, 305 MIB OLD-CISCO-SYSTEM, 262 MIB RMON, 240, 241, 249, 290 MIB-2, 126, 238, 240, 241, 257, 259, 262, 267, 276, 283, 296, 313, 323, 326, 329, 334 icmpInRedirects, 323 icmpOutRedirects, 323 icmpOutTimeExcds, 326, 327 ifAdminStatus, 83, 296 ifInBroadcastPkts, 238, 239, 241, 242, 276, 277, 278 ifInDiscards, 267 ifInMulticastPkts, 238, 239, 241, 242, 249, 276, 277 ifInOctets, 284, 285 ifOperStatus, 258, 259, 296 ifOutBroadcastPkts, 240, 242, 243, 249, 276, 277, 278 ifOutDiscards, 268 ifOutMulticastPkts, 240, 242, 243, 249, 276, 277 ifSpeed, 54, 284 sysUpTime, 257 Modo de operao descasamento, 52, 53, 54, 220, 254 descasamento de velocidade, 52, 53, 66, 220 full duplex, 52, 53, 54, 69, 220, 237, 247, 250, 281, 282, 283, 285 half duplex, 52, 53, 54, 68, 69, 85, 220, 237, 247, 248, 250, 254, 281, 282, 283, 285, 286, 289 Modo de Operao descasamento, 220

N
Negociao automtica, 52, 55, 289

O
OSI modelo de referncia, iii, 38 OSPF, 130, 150, 156, 164, 269, 274, 312, 313, 314, 330

368

 N D I C E

R E M I S S I V O

P
Placa de rede, 38, 39, 42, 46, 54, 55, 59, 61, 62, 63, 64, 65, 66, 69, 77, 93, 97, 131, 134, 135, 251, 275, 289, 298, 299, 307 driver, 63, 64, 66, 298 software de diagnstico, 63, 66 Pontes, 17 POP, 132, 138, 143 Problema, iv, v, 19, 20, 22, 23, 25, 26, 28, 29, 30, 31, 32, 34, 35, 36, 37, 38, 39, 40, 41, 43, 44, 45, 46, 47, 48, 49, 50, 51, 53, 54, 55, 56, 57, 58, 59, 60, 63, 64, 65, 66, 67, 68, 69, 70, 72, 74, 75, 76, 77, 82, 83, 84, 85, 86, 87, 89, 90, 91, 92, 93, 96, 97, 99, 102, 103, 104, 105, 108, 109, 111, 112, 114, 115, 116, 117, 119, 120, 121, 122, 124, 127, 128, 130, 131, 132, 134, 135, 136, 137, 138, 140, 141, 142, 143, 145, 146, 147, 148, 149, 150, 151, 153, 154, 155, 156, 158, 159, 160, 163, 164, 165, 166, 167, 170, 171, 172, 173, 174, 177, 180, 181, 183, 184, 185, 186, 187, 189, 191, 192, 193, 194, 197, 198, 199, 203, 205, 217, 220, 226, 232, 233, 235, 236, 237, 238, 243, 247, 254, 256, 257, 258, 261, 262, 264, 266, 290, 292, 295, 299, 301, 310, 316, 321, 326, 327, 330, 334, 335, 341, 348, 353, 363, 364 elementos essenciais, 26 descrio, 26 sinais, 28 sintomas, 28, 34 sugestes de tratamento, 28 testes confirmatrios, 28 Procedimento, iii, iv, 19, 22, 25, 28, 30, 31, 32, 35, 39, 57, 93, 98, 114, 150, 154, 163, 217, 222, 223, 229, 232, 235, 242, 243, 246, 247, 250, 252, 253, 256, 258, 259, 261, 265, 269, 270, 271, 273, 276, 281, 290, 292, 294, 295, 299, 300, 307, 308, 309, 310, 311, 312, 315, 316, 318, 319, 320, 321, 322, 326, 329, 334, 335, 338, 341, 343, 344, 346, 347, 349, 353, 354, 358, 361, 363

trfego, 27, 102, 161, 162, 163, 164, 165, 166, 167 RIP-1, 27, 102, 146, 147, 148, 149, 150, 156, 157, 158, 159, 160, 161 RIP-2, 27, 102, 150, 156, 157, 158, 159, 160 RMON sondas, 250, 254, 259, 278, 283, 285 Roteadores, 17, 27, 55, 57, 58, 59, 60, 61, 62, 65, 71, 73, 78, 91, 94, 102, 107, 124, 125, 126, 127, 128, 137, 142, 146, 147, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 220, 229, 230, 233, 244, 252, 255, 259, 260, 261, 262, 263, 265, 266, 267, 268, 274, 279, 286, 291, 296, 297, 301, 312, 313, 322, 323, 324, 326, 327, 329, 330, 331, 334, 335, 336 Cisco estado administrativo de interfaces, 296 de borda, 221 default, 102, 103, 104, 105, 106, 107, 110, 111, 114, 115, 117, 121, 122, 126, 133, 138, 338, 340 rotas estticas, 124, 150, 314 tabelas de rotas, 102, 103, 106, 111, 118, 124, 125, 126, 128, 130, 146, 148, 149, 150, 152, 153, 154, 157, 158, 161, 163, 164, 165, 166, 298, 312, 313, 314, 322, 323, 329, 334, 338, 340 Roteamento contador de pacotes descartados por falta de rotas, 126, 334

S
Saturao enlaces, 69, 70, 76, 85, 188, 274 recursos, 85, 86 Servios paranicos, 176, 183 Sinais atenuao do sinal, 76 aumento da utilizao dos enlaces, 97, 139 clientes DHCP no obtm configurao de rede, 134 colises tardias, 53, 62 crescimento rpido de ipOutNoRoutes, 126 h conectividade via endereos IP mas no via nomes de domnio, 171, 180 ICMP de tempo excedido, 126, 326, 327, 328 mais de uma resposta para uma requisio ARP, 107, 118 mquinas recebem configuraes de outra sub-rede, 140 mensagens de log DHCP, 119 mensagens de log DNS/BIND, 184 mensagens DHCP REQUEST sem resposta de qualquer servidor DHCP, 119 mensagens DHCPNAK freqentes, 119

Q
Quadros muito longos, 237, 242, 290, 291, 292

R
Redes no contguas, 27, 102, 146, 148, 149, 150 Repetidores, 17, 37, 38, 54, 60, 62, 68, 71, 73, 76, 77, 78, 95, 217, 229, 230, 232, 308, 309 RIP, 124, 146, 148, 151, 158, 161, 167 dimetro da rede, 27, 102, 151 mensagens, 146, 156, 157, 158 mensagens de atualizao de rotas, 147 mtricas, 151, 153, 155, 156 MIB, 160

369

 N D I C E

R E M I S S I V O

mensagens ICMP de destino inalcanvel, 126, 148, 152, 158, 166, 329, 330, 331 mensagens ICMP de porta inalcanvel, 171 mensagens ICMP de redirecionamento, 103, 111, 118, 322, 323, 324, 340 mensagens ICMP Host Unreachable, 133 nenhuma requisio externa de clientes DHCP na rede, 119 nomes locais s se resolvem com o nome do domnio duplicado, 194 quadros de difuso enviados por mquinas de outra sub-rede, 107 quantidade excessiva de quadros de difuso ARP, 97 quantidade excessiva trfego de quadros de difuso, 85, 91, 92, 93 requisies ARP sem resposta correspondente, 30, 111, 118, 144 resoluo de nomes externos no funciona, 30, 197 rotas especficas para outros hospedeiros, 111, 118, 340 servidores DNS retornam respostas diferentes a uma mesma consulta, 188 taxa de colises elevada, 53, 76, 247, 251 taxa elevada de erros, 72, 240 tempestade de enchente (flooding), 85 utilizao alta de CPU, 188 utilizao de enlaces elevada, 188 Sinal, ii, iv, v, 22, 23, 25, 26, 28, 29, 30, 31, 32, 35, 36, 37, 39, 42, 43, 45, 46, 47, 48, 57, 58, 60, 62, 63, 64, 65, 66, 69, 70, 72, 73, 75, 76, 83, 85, 86, 88, 92, 97, 99, 111, 114, 117, 118, 119, 133, 134, 144, 145, 166, 172, 177, 178, 180, 184, 189, 194, 197, 202, 204, 205, 217, 226, 230, 235, 254, 261, 262, 266, 293, 294, 299, 302, 307, 343, 353 sinal diferencial, 23, 28 sinal patognomnico, 23, 26 Sintoma, ii, iv, v, 22, 23, 25, 26, 28, 29, 30, 32, 34, 36, 37, 39, 43, 45, 47, 48, 53, 58, 60, 62, 63, 64, 65, 67, 68, 70, 72, 73, 75, 82, 86, 87, 88, 95, 98, 99, 103, 111, 114, 117, 119, 132, 134, 138, 140, 143, 144, 145, 166, 172, 180, 187, 188, 189, 193 Sintomas clientes no conseguem efetuar logon, 144 clientes no conseguem navegar em todas as mquinas da rede, 144 conectividade intermitente, 43, 48, 95, 97, 106, 117 demora para estabelecimento de conexo, 177 falta de conectividade, 22, 43, 48, 53, 56, 61, 62, 72, 73, 75, 82, 84, 87, 92, 97, 98, 106, 111, 117, 126, 132, 138, 143, 144, 148, 149, 152, 153, 157, 165, 323, 341 falta de conectividade para uma ou mais redes, 126, 148, 152, 157, 165 falta seletiva de conectividade, 110, 111

indisponibilidade de alguns servios, 43, 132, 138, 177, 180, 188, 191, 193 ocorrncia muito freqente de enchentes, 95, 299 rede lenta, 29, 43, 48, 53, 56, 61, 62, 67, 68, 69, 70, 72, 75, 92, 95, 97, 98, 138, 162, 163, 187, 188, 189, 263 rede no est funcionando, 22, 28, 37, 82, 114, 134, 143, 171, 184, 197, 295, 341 servios locais indisponveis, 183 servidor responde pelo IP mas no responde pelo nome, 114 s h conectividade com mquinas da mesma sub-rede, 102 usurios no conseguem enviar e-mails, 202, 204 usurios no conseguem enviar e-mails para alguns destinos, 202 Sistema de alimentao de energia, 66, 256, 258 Sistema de gerncia arquitetura elementos gerenciados, agentes, 17, 256, 263, 270, 289, 321, 341 estao de gerncia, 16, 17, 18, 20, 28, 31, 34, 35, 37, 40, 76, 82, 83, 87, 88, 89, 95, 128, 150, 154, 156, 159, 161, 232, 238, 245, 247, 254, 255, 256, 258, 259, 262, 266, 270, 276, 277, 278, 283, 284, 286, 289, 290, 291, 296, 299, 313, 323, 326, 329, 330, 334, 341 informaes de gerncia, ii, iii, 16, 17, 18, 19, 22, 31, 35, 235, 307, 343 protocolos de gerncia, 17 SNMP, 17, 18, 19, 24, 31, 54, 82, 83, 87, 88, 89, 90, 91, 95, 128, 150, 154, 156, 159, 161, 235, 238, 239, 245, 247, 248, 249, 254, 256, 257, 258, 259, 262, 263, 266, 267, 270, 276, 277, 283, 284, 286, 289, 290, 296, 299, 313, 323, 326, 329, 330, 334 SMTP qmail, 203, 204, 205, 206, 207 repasse totalmente aberto, 201, 363 repasse totalmente fechado, 27, 170, 203, 204, 361 sendmail, 203, 204, 205, 206 usando servios de instituies antispam, 363, 364 Sniffer funo de amostragem histrica, 227, 243, 251, 280, 292 Spammers, 201, 363, 364 Sub-redes, 125, 129, 137, 146, 147, 148, 149, 150, 151, 152, 153, 154, 156, 302 mscara, 146, 148 Substituio de comutador, 137 Sugestes de tratamento, 28, 32, 47, 51, 54, 59, 60, 66, 68, 71, 75, 78, 83, 87, 90, 93, 96, 99, 105, 112, 115, 122, 130, 136, 141, 146, 150, 156, 158, 159, 160, 164, 167, 174, 177, 181, 184, 186, 190, 194, 199, 203, 205

370

 N D I C E

R E M I S S I V O

Super-redes, 146

T
Tabela de endereos, 94, 95, 217, 223, 224, 299, 300 enchente (flooding), 94, 218, 299 tempo de envelhecimento, 91, 92, 94, 95, 96, 299, 300 grande, 94 pequeno, 94 recomendado, 96 de rotas, 111, 118, 124, 126, 128, 130, 146, 148, 150, 152, 157, 158, 163, 165, 166, 312, 313, 314, 323, 329, 340 dinmica, 124, 150 esttica, 124 Tempo de resposta, 162, 233, 281, 282 Testador de cabos, 39, 43, 44, 45, 48, 50, 73, 77 de certificao, 294 OTDR, 44, 45, 77 TDR, 44, 77 Testes confirmatrios, 23, 28, 39, 50, 59, 63, 76, 121, 125, 197

limiar, 261 de CPU em comutadores, 261 de CPU em roteadores, 261, 262 de CPU em servidores, 261 de enlaces, 92, 95, 97, 139, 162, 188, 190, 250, 281, 283, 286, 288, 289 equao, 283, 284, 287 limiares, 282 de memria, 57, 265, 266, 267, 268, 270, 271, 272 em hospedeiros, 270, 271 equao, 267 limiar, 266 Windows, 273

V
VLANs, 131 etiquetamento de quadros, 142, 143 802.1Q, 143, 146 ILS, 143 por MAC, 46, 130, 131, 134, 135, 136 por portas, 130, 131, 134, 137, 141 troncos, 142, 145, 146 VLSM, 27, 102, 146, 147, 148, 149, 150, 157, 168

W U
Utilizao de CPU, 57, 85, 92, 139, 188, 261, 262, 263, 264, 265, 275, 281 Windows controlador de domnio, 144 logon, 37, 139, 144, 274 WINS, 121, 144

371