Sei sulla pagina 1di 371

i

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
i i

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.

Prefcio
O
P R E F C I O
i i i
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
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 OSI
1
. 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.
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.

1
O modelo OSI foi criado como primeiro passo para a padronizao internacional dos protocolos
usados nas vrias camadas.
P A R T E I :
F U N D A M E N T O S
E A B O R D A G E M
P A R T E I I : O
C A T L O G O D E
P R O B L E M A S
P A R T E I I I :
P R O C E D I M E N -
T O S
P A R T E I V :
A P N D I C E S
P R E F C I O
i v
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 consult-
los. 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
P R E F C I O
v
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 Estilo para apresentao de comandos.
comando
iterativo
Estilo usado para diferenciar respostas de comandos e
comandos quando se tratam de comandos iterativos.
Dest aque
Estilo usado para destacar palavras ou frases chave de um
pargrafo. usado para destacar sintomas e sinais de um
problema.
Si nal di f erenci al
Estilo usado para indicar um sinal diferencial, cuja
existncia confirma um determinado problema.
$TTL
Estilo usado para representar algo que deve estar escrito em
um arquivo.
/etc/resolv.conf Estilo que representa nomes de arquivos.
Menu
Estilo que indica itens de interfaces amigveis como as do
Windows: menu, botes, etc.
equaes
Estilo para apresentao de equaes.
ifInErrors
Estilo para representar nomes de variveis de MIBs
(Management Information Base).
Tabela 1-1: Legenda de estilos encontrados no livro.
S U M R I O
6
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
S U M R I O
7
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
S U M R I O
8
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
S U M R I O
9
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
S U M R I O
10
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
S U M R I O
11
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
S U M R I O
12
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
S U M R I O
13
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
S U M R I O
14
12.9 REFERNCIAS ................................................................................................... 364
12.9.1 Livros ........................................................................................................ 364







Part e I
Int roduo


16
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 pi ng, t r acer out e e
net st at . 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 Int roduo 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.
Capt ulo
1
E
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
17
1.1 Int roduo Gernci a de Redes de Comput adores
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 el ement os gerenci ados possuem um software especial chamado
agent e. Este software permite que o equipamento seja monitorado e
controlado atravs de uma ou mais estaes de gerncia;
em um sistema de gerncia de redes deve haver pelo menos uma
est ao de gernci a. Em sistemas de gerncia distribudos existem
duas ou mais estaes de gerncia. Em sistemas centralizados mais
comuns existe apenas uma. Chamamos de gerent e 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;
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 prot ocol o de gernci a. Este protocolo permite operaes de
monitoramento (leitura) e controle (escrita);
gerentes e agentes podem trocar informaes, mas no qualquer tipo de
informao. As i nf ormaes de gernci a 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, comutadores
2
, 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.

2
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.
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
18

Figura 1-1: Elementos de uma arquitetura geral de soluo de gerncia.
A padronizao de soluo de gerncia mais usada no mundo chama-se Internet-
Standard Network Management Framework. Ela soluo mais conhecida como
gernci a 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
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
19
outras ferramentas mais simples como os comandos pi ng, t r acer out e e
net st at , 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 gerent e 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
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
20
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 gerncia
3
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.

3
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.
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
21
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 mdi co 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.
P 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 ?

C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
22
Medicina Gerncia de Redes
Muitas doenas podem ser
prevenidas, outras no. Por
exemplo, a AIDS uma doena
que pode ser prevenida, j a
leucemia no.
Um probl ema 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.
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 si nt omas. 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.
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 help-
desk
4
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, si nt omas so as conseqncias de
um problema para os usurios. Rede lenta e
falta de conectividade so exemplos de
sintomas de problemas.
Aps conversar com o paciente e
descobrir o que ele est sentindo,
o mdico realiza alguns exames e
observaes em busca de si nai s.
Quem nunca foi para um
otorrinolaringologista
5
? 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 si nai s. 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

4
Ou outro profissional com o qual os usurios da rede entrem em contato para fazer reclamaes.
5
Mdico que trata de doenas de ouvido, nariz e garganta.
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
23
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 obt-
las, o gerente precisa saber interpret-las,
isto , precisa identificar quando esto com
valores estranhos, tornando-se sinais.
Certas doenas apresentam sinais
tpicos, cuja existncia confirmam
o diagnstico sem a necessidade
de testes adicionais. Na Medicina,
estes si nai s so chamados
pat ognomni cos.
Problemas de rede tambm podem
apresentar sinais patognomnicos.
Chamaremos estes sinais de si nai s
di f erenci ai s. Quando o sinal diferencial
encontrado nenhum teste confirmatrio
necessrio. J achamos o problema.
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
t est es ou exames que possam
conf i rmar uma das hipteses e
negar as demais.
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 t est es
conf i rmat ri os. 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.
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.
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.
C A P T U L O 1 I N T R O D U O A G E R N C I A D E R E D E S
24
Tabela 1-1: Analogia entre a Medicina e a Gerncia de Redes.
1.4 Refernci as
1.4.1 Li vr os
[HARNEDY] Harnedy, S., Harnedy, S. J. Total SNMP: Exploring the Simple
Network Management Protocol. Segunda Edio. Editora Prentice
Hall, Agosto, 1997.
[MAURO &
SCHMIDT]
Mauro, Schmidt. Essential SNMP. OReilly and Associates, 2001.
[ROSE1] Rose, T. M. The Simple Book: An Introduction to Network
Management. Segunda Edio. Editora Prentice Hall, Maro, 1996.
[ROSE2] Rose, T.M., McCloghrie, K. How to Manage Your Network using
SNMP: The Network Management Practicum. Editora Prentice
Hall, Janeiro, 1995.
[STALLINGS] Stallings, W. SNMP, SNMPv2, SNMPv3 and RMON1 and 2.
Terceira Edio. Editora Addison-Wesley, 1998.


25
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 Int roduo ao cat logo 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 Anal ogi a ent re a Gernci a de Redes e a Medi ci na
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 Gerncia de Rede
Si nt omas: o que um paciente sente
quando est doente.
Si nt omas: o que o usurio da rede
sente quando um problema est
ocorrendo.
Capt ulo
2
N
C A P T U L O 2 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
26
Si nai s: informaes sobre o
estado/comportamento do paciente
obtidas pelo mdico atravs de exames
e/ou observaes.
Si nai s: informaes sobre o
estado/comportamento da rede
obtidas pelo gerente da rede com o
auxlio de instrumentao adequada.
Si nai s pat ognomni cos: sinais cuja
existncia j confirmam a existncia de
uma certa doena.
Si nai s di f erenci ai s: sinais cuja
existncia confirmam um certo
problema.
Test es confi rmat ri os: testes que o
mdico precisa realizar para chegar ao
diagnstico diferencial quando estiver
suspeitando de vrias doenas.
Test es confi rmat ri os: testes que o
gerente de redes precisa realizar para
confirmar ou negar um ou mais
problemas.
Tabela 2-1: Resumo da analogia entre a Medicina e a Gerncia de Redes.
2.2 O cat l ogo de probl emas
O catlogo de problemas uma coletnea de 37
6
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. Descri o
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.

6
Pretendemos aumentar o nmero de problemas includos no catlogo a cada nova edio do livro.
C A P T U L O 2 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
27
Camada Fsi ca
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;
Camada de Enl ace
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;
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);
Camada de
Apl i cao
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;
C A P T U L O 2 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
28
Servidor de correio eletrnico com repasse totalmente
fechado;
Tabela 2-2: Problemas organizados por camada OSI trazidos nesta edio.
2. Si nt omas
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. Si nai s
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. Test es conf i rmat ri os
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. Sugest es de t rat ament o
Nas sugestes de tratamento iremos sugerir solues eficientes para o
problema sendo descrito. O problema que foi confirmado deve ser
C A P T U L O 2 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
29
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 c at l ogo de pr obl emas?
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.
C A P T U L O 2 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
30
2.2.2 Os ndi c es i nver t i dos
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 procedi ment os
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 -l o? Outras
perguntas que podem ser feitas so: quando consi dero que seu val or est
anormal ? O que est e si nal si gni f i ca? Qual seri a o comport ament o normal ?
Os procedimentos tm o objetivo de responder estas perguntas.
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.
C A P T U L O 2 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
31
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,
i f conf i g e net st at , 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 net st at . 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.



32
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 Met odologia geral de det eco,
diagnst ico 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.
Capt ulo
3
N
C A P T U L O 3 - M E T O D O L O G I A
33

Figura 3-1: Fluxograma da Metodologia Geral de Localizao e Resoluo de Problemas
de rede.
C A P T U L O 3 - M E T O D O L O G I A
34
3.1 Det eco: a rede est apresent ando compor t ament o
est ranho
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 i nfor maes
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?


C A P T U L O 3 - M E T O D O L O G I A
35
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 desk
7
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,
pi ng e t r acer out e. 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 infra-
estrutura 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.

7
Quando esta equipe existir e considerar que realmente existe um problema e no for capaz de
solucion-lo.
C A P T U L O 3 - M E T O D O L O G I A
36
3.3 Recor rnci a de probl ema? 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 Desenvol va hi pt eses
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 probl emas podem causar os si nt omas e
si nai s percebi dos? 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
C A P T U L O 3 - M E T O D O L O G I A
37
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.

C A P T U L O 3 - M E T O D O L O G I A
38
3.5 Or gani ze a l i st a de hi pt eses
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 cita-
se 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 Camada de rede e aplicao
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;
servidor DHCP
desativado
8
;
servidor DHCP com
escopo incorreto;
servidor de nomes
desativado;
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

8
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.

C A P T U L O 3 - M E T O D O L O G I A
39
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 Test e as hi pt eses l evant adas
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.

C A P T U L O 3 - M E T O D O L O G I A
40
Di ca: 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 pi ng. 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
pi ng 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 pi ng 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.
3.7 Sol uci one o probl ema
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 Test e a sol uo i mpl ant ada
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

C A P T U L O 3 - M E T O D O L O G I A
41
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 Document e suas at i vi dades
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 Refernci as
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
[GUIA-
ETHERNET]
Spurgeon, C. E. Ethernet O Guia Definitivo. Traduo Daniel
Vieira, Editora Campus, 2000.

42
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 rompi do ou dani fi cado
4.1.1 Desc r i o
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
Capt ulo
4

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
43
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 Si nt omas
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 f al t a de conect i vi dade. Micro-fraturas tornam
a rede l ent a uma vez que causam uma grande quantidade de erros.
Pares tranados com geometria alterada podem causar f al t a de conect i vi dade,
conect i vi dade i nt ermi t ent e ou ainda conexes l ent as. Se o cabo danificado
fizer parte do backbone, muitos usurios sero afetados.
Os usurios, em geral, reclamaro que a rede no f unci ona, ou al guns servi os
no f unci onam ou a que a rede ou al guns servi os est o mui t o l ent os. Isto
ir depender da localizao do cabo com problema e do tipo de defeito no cabo.
4.1.3 Si nai s
Um dos principais sintomas de cabeamento ruim a t axa de erros el evada,
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 10
9
bits transmitidos e em enlaces ticos 1 erro a cada 10
12
bits
transmitidos.
4.1.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Verificar LEDs;
Testar o cabo sob suspeita com um testador de cabos;
Se no tiver um testador de cabos disposio:
trocar o cabo por outro, ou
utilizar outra porta nos equipamentos de interconexo envolvidos.
Pr ocedi ment o
10. 1
T E S T E 1
T E S T E 2
T E S T E 3
T E S T E 4
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
44
Test e confirmat rio 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).
Test e confirmat rio 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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
45



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.
Test e confirmat rio 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 rede
9
.
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:
Test e confirmat rio 4
Para realizar este teste voc precisar de uma mquina de testes.
Conecte a mquina de testes em uma das extremidades do cabo.
Envie pi ng para o equipamento ligado outra extremidade do
cabo. Se este equipamento for um repetidor envie pi ng para um
outro dispositivo ligado ao repetidor. Realize o mesmo teste
conectando a mquina de testes no outro equipamento. Se o

9
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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
46
resultado dos pi ngs anunciar taxas de perda de pacotes maiores
que zero em ambas as direes, o problema foi confirmado. Se em
apenas uma direo o pi ng 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 1
10
. 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 pi ng para
comutador2 (# pi ng 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 pi ng para comutador1 (# pi ng
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.

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
47

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 Sugest es de t r at ament o
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 Conect or defei t uoso ou mal i nst al ado
4.2.1 Desc r i o
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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
48
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 utilizados
11
.
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 Si nt omas
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 conect i vi dade
i nt ermi t ent e. Em outras situaes a conseqncia pode ser fal t a de
conect i vi dade ou rede l ent a.
4.2.3 Si nai s
Conectores mal crimpados podem levar a um nmero el evado de erros, em
especi al erros de CRC [GUIA-ETHERNET, TIPS-ETHERNET] e de al i nhament o.
Deve-se sempre suspeitar de uma taxa de erros que no esteja muito prxima de
zero.
Taxa de col i ses el evada. Uma taxa de colises superior a 10% deve ser
investigada. Conectores com problema tambm podem ser a causa de col i ses
excessi vas
12
[TIPS-ETHERNET].
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 at enuao do si nal [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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Pr ocedi ment o
10. 1
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 12
T E S T E 1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
49
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 pi ng para confirmar problemas no
cabo;
Realize uma inspeo visual no cabo de pares tranados;
Test e confirmat rio 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.
Test e confirmat rio 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.
T E S T E 2
T E S T E 3
T E S T E 4
T E S T E 5
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
50
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.
Test e 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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
51
4.2.5 Sugest es de t r at ament o
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 par al el o Cabo c r uzado
Pino RJ-45 Pino RJ-45
Pino RJ-45 Pino RJ-45
1 Tx + 1 Rx +
1 Rx + 3 Tx +
2 Tx 2 Rx
2 Rx 6 Tx
3 Rx + 3 Tx +
3 Tx + 1 Rx +
6 Rx 6 Tx
6 Tx 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.

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
52
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 Descasament o de modo e/ou vel oci dade de operao
4.3.1 Desc r i o
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
L e i a m a i s
s o b r e
E t h e r n e t
n o
a p n d i c e
1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
53
negociao automtica), gerando assim, descasamento de modo de operao
[KEIBRICH].
4.3.2 Si nt omas
Quando o problema descasamento de velocidade o sintoma f al t a de
conect i vi dade. 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 l ent a.
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 Si nai s
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:
Nmero el evado 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.

Taxa de col i ses superi or a 10%. 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 col i ses t ardi as.
4.3.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Verificar modo de operao e velocidade configurados para o enlace com
problema;
Pr ocedi ment o
10. 1
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 3
T E S T E 1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
54
Test e confirmat rio 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:
comut ador > show por t [ mdul o[ / por t a] ]
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 Sugest es de t r at ament o
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 por t capabi l i t i es [ mdul o[ / por t a] ]
set por t speed [ mdul o[ / por t a] ] {4 | 10 | 16 | 100 |
aut o}
show por t [ mdul o[ / por t a] ]
set por t dupl ex [ mdul o[ / por t a] ] { f ul l | hal f }
Por exemplo, para configurar a porta 1/1 como sendo 100 Mbps, full duplex
execute:
comut ador > ( enabl e) set por t speed 1/ 1 100
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
55
comut ador > ( enabl e) set por t dupl ex 1/ 1 f ul l
Tratando-se de mquinas com sistema operacional Windows, o modo e a
velocidade de operao podem ser configurados, quando a placa de rede assim
permitir
13
. 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.

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
56
isso, todo cuidado necessrio, principalmente quando se trata de enlaces vitais
para a satisfao dos usurios da rede.
4.4 Equi pament o de i nt erconexo defei t uoso
4.4.1 Desc r i o
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 Si nt omas
Um equipamento de interconexo ou algumas de suas portas com defeito
podem ser a causa de rede l ent a ou f al t a de conect i vi dade. Quanto mais
prximo do backbone central estiver o equipamento, mais usurios sero
afetados.

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
57
4.4.3 Si nai s
Equi pament o no operaci onal . 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.
I nt erf aces apresent am est ado no operaci onal . 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.
Para se ter uma idia relativa de quo saudvel est o seu equipamento de
interconexo, voc pode medir a utilizao de seus recursos [PERF&FAULT-
CISCO]. Limiares de utilizao de recursos sendo excedidos podem ser
indicativos de falhas no equipamento.
Taxa el evada de ut i l i zao de CPU. Em geral, utilizao mdia de CPU
superior a 75% j deve ser investigada.

Taxa el evada de ut i l i zao de memri a. 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
Tr f ego al t o de br oadc ast /mul t i c ast . Este tipo de trfego pode ser gerado por
um equipamento de interconexo defeituoso. O efeito negativo de um trfego alto de
broadcast/multicast a saturao dos processadores dos equipamentos da rede.
4.4.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Pr ocedi ment o
10. 4
Pr ocedi ment o
10. 5
Pr ocedi ment o
10. 6
Pr ocedi ment o
10. 7
Pr ocedi ment o
10. 9
T E S T E 1
T E S T E 2
T E S T E 3
T E S T E 4
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
58
Test e confirmat rio 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.
Test e confirmat rio 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 t el net . 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
r ot eador # show ver si on
r ot eador # show envi r onment al l
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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
59
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:
Test e confirmat rio 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 DE EQUIPAMENTO DE INTERCONEXO
DEFEITUOSAS.
A partir da mquina de teste, utilizando a ferramenta pi ng, deve-
se tentar alcanar outros dispositivos da rede. Realize este teste
conectado a mquina de teste em diversas portas do equipamento
sob suspeita e enviando pi ng 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 pi ng, bastante provvel que o equipamento no
esteja com defeito.
Test e confirmat rio 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 baseline
14
de configurao da

14
Leia mais sobre linha base de configurao na seo Sugestes de tratamento do problema VLANs
no esto configuradas.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
60
rede para realizar esta tarefa. Se os sinais e sintomas cessarem o
equipamento estava realmente com defeito.
4.4.5 Sugest es de t r at ament o
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



C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
61
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:
consol e> ( enabl e) copy conf i g {t f t p: | r cp: } [ al l ]
Por exemplo, para salvar as configuraes de comutador1 no servidor TFTP
192.168.101.10 o seguinte comando poderia ser executado:
Consol e> ( enabl e) copy conf i g t f t p: comut 1. cf g
I P addr ess or name of r emot e host [ 192. 168. 101. 10] ? y
Upl oad conf i gur at i on t o t f t p: comut 1. cf g ( y/ n) [ n] ? y
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
/
Conf i gur at i on has been copi ed successf ul l y. ( 10299 byt es) .
Consol e> ( enabl e)
Em roteadores Cisco com IOS verso 12.0 ou superior, use os seguintes
comandos para armazenar em um arquivo a configurao completa do roteador:
r ot eador # copy syst em: r unni ng- conf i g {t f t p: | f t p: | r cp: }
Por exemplo, para salvar a configurao de roteador1 no servidor
192.168.101.10 use o comando a seguir:
r ot eador 1# copy syst em: r unni ng- conf i g t f t p:
Remot e host [ ] ? 192. 168. 101. 10
Name of conf i gur at i on f i l e t o wr i t e [ r t r 1- conf g] ? <cr >
Wr i t e f i l e r t r 1- conf g on host 192. 168. 101. 10?[ conf i r m] <cr >
! [ OK]
O comando copy syst em citado acima substitui o comando wr i t e
net wor k em roteadores com IOS mais antigos. O comando wr i t e
net wor k vlido para o IOS 12.0, mas em outros IOSs mais novos ele no
mais existir.
4.5 Pl aca de rede ou por t a de equi pament o de i nt erconexo
defei t uosas
4.5.1 Desc r i o
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;


C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
62
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 Si nt omas
Os sintomas de placa de rede ou porta de equipamento defeituosos so: f al t a de
conect i vi dade ou rede l ent a. 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 Si nai s
Tax a el evada de er r os, em espec i al er r os de CRC e de al i nhament o
[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 el evada de col i ses. Uma taxa de colises superior a 10% deve ser
investigada.

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

Um t r f ego al t o de br oadc ast /mul t i c ast 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.
Aument o da ut i l i zao do enl ace. A interface de rede defeituosa pode gerar
trfego intil. Este trfego causar o aumento da utilizao do enlace em relao
utilizao normalmente observada.
Exi st nci a de quadros mai ores que o t amanho mxi mo i mpost o pel o
padro pode ser sinal de defeito em interfaces [GUIA-ETHERNET].

Pr ocedi ment o
10. 1
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 3
Pr ocedi ment o
10. 9
Pr ocedi ment o
10. 10
Pr ocedi ment o
10. 11
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
63
4.5.4 Test es c onf i r mat r i os
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.
R E S U M O D O S T E S T E S
Para confirmar que uma placa de rede est com defeito realize um dos testes
a seguir:
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:
Troque a posio dos cabos nos equipamentos;
Substitua o equipamento por outro;
Teste as portas sob suspeita com pi ng;
Se voc est desconfiado de uma placa de rede de um servidor ou estao cliente
realize um dos trs testes confirmatrios a seguir:
Test e confirmat rio 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 di ag (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
T E S T E 1
T E S T E 2
T E S T E 3
T E S T E 4
T E S T E 5
T E S T E 6
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
64
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.
Test e confirmat rio 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.
Test e confirmat rio 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:
Test e confirmat rio 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
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
65
equipamento em questo para o seu laboratrio e descubra se o
defeito no equipamento mesmo ou em uma de suas interfaces.
Test e confirmat rio 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.
Test e confirmat rio 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 pi ng, 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 pi ng 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 pi ng para o equipamento 10.16.254.33.
Se o resultado do pi ng 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 pi ngs em busca de
comportamento anormal de alguma porta.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
66
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 Sugest es de t r at ament o
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 di ag). 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 Int erfernci a no cabo
4.6.1 Desc r i o
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].

C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
67
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 Si nt omas
O pri nci pal si nt oma rede l ent a. Se o cabo que est sofrendo interferncia faz
parte do backbone muitos usurios podem ser afetados.
4.6.3 Si nai s
Tax a el evada de er r os [HAUGDAHL]. 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.
4.6.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Test e confirmat rio 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.
Pr ocedi ment o
10. 1
T E S T E 1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
68
4.6.5 Sugest es de t r at ament o
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 Sat urao de banda em segment os Et her net
compar t i l hados
4.7.1 Desc r i o
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 Si nt omas
O principal sintoma de domnios de colises congestionados rede l ent a.
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.
L e i a m a i s
s o b r e
E t h e r n e t
n o
a p n d i c e
1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
69
4.7.3 Si nai s
Tax a de c ol i ses el evada. Este um dos sinais tpicos de saturao de banda
em segmentos Ethernet compartilhados. Taxas de colises superiores a 10%
devem ser investigadas.
Ut i l i zao de enl aces Et hernet compart i l hados (hal f dupl ex) superi or a 50%
de sua capaci dade. Para outras tecnologias onde no h compartilhamento ou
enlaces Ethernet operando no modo full duplex a utilizao pode chegar a 70%
sem comprometer o desempenho do enlace.
4.7.4 Test es c onf i r mat r i os
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.
R E S U M O D O S T E S T E S
Ver origem das colises;
Verificar o estado do domnio de colises antes das modificaes, se
possvel;
Test e confirmat rio 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
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 10
T E S T E 1
T E S T E 2
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
70
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.
Test e confirmat rio 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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
71
4.7.5 Sugest es de t r at ament o
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 Ti po er rado de cabo
4.8.1 Desc r i o
Dois tipos de erros em cabos de pares tranados so:
1. Ut i l i zar cat egori a de cabo i nadequada;
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


C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
72
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 uso
15
). 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. Ut i l i zar cabos cruzados em vez de cabos paral el os ou vi ce 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 Si nt omas
Quando cabos cruzados ou paralelos so utilizados para interconectar
equipamentos da rede erroneamente, o sintoma f al t a de conect i vi dade.
Quando a categoria de cabo errada utilizada o sintoma pode ser rede l ent a ou
f al t a de conect i vi dade. O tamanho do cabo pode influenciar: cabos bem
curtos podem causar rede lenta, enquanto cabos maiores levaro falta de
conectividade.
4.8.3 Si nai s
Quando cabos de categoria inadequada so utilizados o principal sinal uma
t axa el evada de erros, em especi al erros de al i nhament o. 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S

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.
Pr ocedi ment o
10. 1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
73
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:
Test e confirmat rio 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-a-
ponto. 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:
Test e confirmat rio 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,
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
74
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:
Test e confirmat rio 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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
75
4.8.5 Sugest es de t r at ament o
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 Vi ol ao de regras de cabeament o Et her net
4.9.1 Desc r i o
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 Si nt omas
O principal sintoma da violao de regras de cabeamento rede l ent a. Entre as
estaes mais distantes pode haver falta de conectividade devido atenuao do
sinal.

L e i a m a i s
s o b r e
E t h e r n e t
n o
a p n d i c e
1
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
76
4.9.3 Si nai s
As regras de cabeamento informam o nmero mximo de estaes em cada
domnio de colises. Quando esta regra violada a principal conseqncia
uma taxa el evada de col i ses, 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.
Ocorrnci a de col i ses t ardi as. 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 at enuao do si nal (perda da fora do sinal devido resistncia
eltrica do meio de transmisso).
4.9.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Verificar o que est fora de especificao:
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.
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 3
Pr ocedi ment o
10. 11
T E S T E 1
T E S T E 2
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
77
Test e confirmat rio 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.
Test e confirmat rio 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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
78
4.9.5 Sugest es de t r at ament o
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 Refernci as
4.10.1 Li vr os
[GUIA-ETHERNET] Spurgeon, C. E. Ethernet O Guia Definitivo. Traduo
Daniel Vieira, Editora Campus, 2000.
[HAUGDAHL] Haugdahl, J. Scott. Network Analysis and
Troubleshooting. Addison Wesley, 2000
[LAN WIRING] Trulove, J. LAN Wiring. McGraw-Hill, 1997.
[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.
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
79
4.10.2 Rec ur sos onl i ne (I nt er net )
[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
[CISCO-AUTO-
NEGOTIATION]
Configuring and Troubleshooting Ethernet 10/100Mb
Half/Full Duplex Auto-Negotiation.
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://www-
commeng.cso.uiuc.edu/docs/autosense/autosense.html
[STEINKE] Steinke, Steve. Troubleshooting Ethernet Problems.
http://www.networkmagazine.com/article/NMG20000724S00
54
[TIPS-
ETHERNET]
Tips on Troubleshooting Ethernet Errors.
http://www.ncat.co.uk/Net_Lib/eth_errs.htm.
4.10.3 RFCs
[RFC2233] McCloghrie, K., F. Kastenholz. The Interfaces Group MIB
using SMIv2. Novembro, 1997.
[RFC2665] Flick, J., Johnson, J. Definitions of Managed Objects for the
Ethernet-like Interface Types. Agosto de 1999.

4.10.4 Li vr os base
[CISCO-
INTERNETWORKING]
Cisco Systems (Editor). Internetworking Technologies
C A P T U L O 4 P R O B L E M A S D E N V E L F S I C O
80
Handbook. Cisco Press. Dezembro, 2000.

4.10.5 Out r os r ec ur sos on-l i ne
[CABLING_MISC]
Misc. Cabling Information.
http://learn.wwtc.edu/aev/cabling/misc.htm


81

82
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 Int erface desabi l i t ada
5.1.1 Desc r i o
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 Si nt omas
A interface desabilitada administrativamente ficar inativa e, portanto, o sintoma
ser f al t a de conect i vi dade. Qualquer que seja o equipamento ligado interface
desativada no ter conectividade com outros membros da rede.
Capt ulo
5
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
83
5.1.3 Si nai s
I nexi st nci a de t rf ego de sada e de entrada na interface. Em outras palavras,
a utilizao da interface desabilitada zero.

Int erface admi ni st rat i vament e desabi l i t ada. Ao verificar o estado da
interface, percebe-se que ela foi desativada manualmente pela equipe de gerncia
da rede.

5.1.4 Test es c onf i r mat r i os
O sinal interface administrativamente desabilitada diferencial Portanto, se ele
for percebido o problema j est confirmado.
5.1.5 Sugest es de t r at ament o
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
i f Admi nSt at us), atravs de um terminal de gerncia conectado ao
equipamento ou t el net .
Em comutadores Cisco, use os comandos a seguir para ativar e desativar
operao de portas:
set por t enabl e mod/ por t
set por t di sabl e mod/ por t
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.

Pr ocedi ment o
10. 10
Pr ocedi ment o
10. 13


C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
84
5.2 Probl ema com r vore de cober t ura
5.2.1 Desc r i o
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 Si nt omas
O lao infinito de quadros entre comutadores ir levar rapidamente fal t a de
conect i vi dade.
5.2.3 Si nai s
Ut i l i zao de enl aces el evada. 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.
L e i a m a i s
s o b r e o
p r o t o c o l o
r v o r e d e
C o b e r t u r a
n o
c a p t u l o 6
Pr ocedi ment o
10. 10
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
85
Taxa de col i ses el evada. 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
t empest ades de quadros de di f uso, 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.
Ut i l i zao el evada 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.
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 t empest ade de enchent e. 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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;
Pr ocedi ment o
10. 2
Pr ocedi ment o
10. 9
Pr ocedi ment o
10. 6
Pr ocedi ment o
10. 14

T E S T E 1
T E S T E 2
T E S T E 3
T E S T E 4
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
86
Os testes a seguir devem ser realizados em todos os comutadores da rede que
participam do lao.
Test e confirmat rio 1
Com um terminal de gerncia ou atravs de t el net
16
, 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 spant r ee 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 spant r ee
Spanni ng t r ee di sabl ed
Se o PAC estiver habilitado o retorno seria semelhante ao exemplo
abaixo:
Sw- bb- vendas> show spant r ee
Spanni ng t r ee enabl ed
Desi gnat ed Root 00- 50- 1c- 7a- 8b- 2e
Desi gnat ed Root Pr i or i t y 32768
Desi gnat ed Root Cost 0
Desi gnat ed Root Por t 1/ 0

16
Pode ser que a largura de banda dos enlaces esteja saturada e voc no consiga chegar no
equipamento atravs de t el net
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
87
Root Max Age 20 sec Hel l o Ti me 2sec
For war d Del ay 10 sec
Por t , Vl an Vl an Por t - St at e Cost Pr i or i t y Fast - St ar t Gr oup- met hod
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 1 f or war di ng 10 32 di sabl ed
2/ 1 1 bl ocki ng 10 48 di sabl ed
3/ 1 1 f or war di ng 10 32 enabl ed
4/ 1 1 f or war di ng 10 32 enabl ed
5/ 1 1 f or war di ng 10 32 di sabl ed
6/ 1 1 f or war di ng 10 32 di sabl ed
7/ 1 1 f or war di ng 10 32 di sabl ed
8/ 1 1 f or war di ng 10 32 di sabl ed
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 dot 1dSt p 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 dot 1dSt pPor t Tabl e.
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.
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
88
Test e confirmat rio 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.
Test e confirmat rio 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
comut adores. 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.
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
89
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:
Test e confirmat rio 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 conf i gur ao est o sendo
envi adas no i nt er val o conf i gur ado ( hello
time) os anal i sador es de pr ot ocol os
ger al ment e i nf or mam o t empo que se passou
ent r e a chegada de doi s quadr os
consecut i vos capt ur ados. As BPDUs de
conf i gur ao devem ser envi adas em
i nt er val os r egul ar es, def i ni dos pel o hello
time. Ver i f i que de quant o em quant o t empo
BPDUs de conf i gur ao so envi adas e
compar e est e val or com o hello time
conf i gur ado nos comut ador es;
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
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
90
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 Sugest es de t r at ament o
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 Valor recomendado Variao permitida
Bridge Hello Time 2.0 1.0 10.0
Bridge Max Age 20.0 6.0 40.0
Bridge Forward Delay 15.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:
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
91
atravs da interface de linha de comando com o auxlio de t el net 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 spant r ee pr i or i t y. 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 Sat urao de recur sos devi do a excesso de quadros de
di fuso
5.3.1 Desc r i o
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.
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
92
5.3.2 Si nt omas
mais comum que o excesso de quadros de difuso tornem a rede l ent a. No
entanto, dependendo da quantidade destes quadros, os usurios podem reclamar
de f al t a de conect i vi dade.
5.3.3 Si nai s
Quant i dade excessi va t rf ego de quadros de di f uso. 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.
Ut i l i zao al t a de CPU. 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.
Aument o da ut i l i zao de enl aces. 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 Test es c onf i r mat r i os
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.
Pr ocedi ment o
10. 9
Pr ocedi ment o
10. 6
Pr ocedi ment o
10. 10
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
93
R E S U M O D O S T E S T E S
Examinar os tipos de quadros de difuso que esto trafegando e qual a sua
origem;
Test e confirmat rio 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 Sugest es de t r at ament o
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
T E S T E 1
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
94
colises em vrios domnios menores configurando VLANs nos comutadores
ou inserindo roteadores na rede.
5.4 Tempo de envel heci ment o de t abel as de endereos
i nadequado
5.4.1 Desc r i o
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 learning
17
.
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.
L e i a m a i s
s o b r e
c o m u t a d o -
r e s n o
a p n d i c e
4
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
95
envelhecimento esteja grande
18
, a tabela de endereos ser rapidamente
atualizada.
5.4.2 Si nt omas
Quando os comutadores estiverem configurados com tempo de
envelhecimento muito pequeno, os usurios podero reclamar de rede l ent a. Se
o tempo de envelhecimento estiver muito grande, o sintoma ser conect i vi dade
i nt ermi t ent e.
5.4.3 Si nai s
Quando o tempo de envelhecimento for muito pequeno, o sintoma principal
ser ocorrnci a mui t o f reqent e de enchent es. 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 aument o da ut i l i zao dos
enl aces em relao utilizao normalmente verificada.

5.4.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Verificar valor configurado para tempo de envelhecimento de tabelas de
endereo;
Test e confirmat rio 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 10
6
s). 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.
Pr ocedi ment o
10. 14
Pr ocedi ment o
10. 10
T E S T E 1
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
96
Pode-se tambm verificar e atualizar o tempo de envelhecimento
com o auxlio de um terminal de gerncia ou de t el net . 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 camagi ngt i me [ vl an]
set camagi ngt i me [ vl an] <agi ng_t i me_em_segs>
Por exemplo, para configurar um tempo de envelhecimento de 5
minutos na VLAN 1, o seguinte comando deve ser executado:
consol e> ( enabl e) set camagi ngt i me 1 300
5.4.5 Sugest es de t r at ament o
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 Val i dade da cache ARP i nadequada
5.5.1 Desc r i o
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
L e i a m a i s
s o b r e A R P
n o
a p n d i c e
7
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
97
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 Si nt omas
Quando o perodo de validade for muito pequeno, os usurios podem sentir a
rede l ent a. 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 f al t a de conect i vi dade durant e det ermi nado perodo de
t empo com out ras mqui nas 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 Si nai s
Se o perodo de validade da cache ARP for muito pequeno, uma quant i dade
excessi va de quadros de di f uso 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 aument o
na ut i l i zao dos enl aces 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.
Pr ocedi ment o
10. 15
Pr ocedi ment o
10. 10
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
98
5.5.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Test e confirmat rio 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.
Test e confirmat rio 2
No Windows NT/2000, use um editor de registro
(r egedi t . 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
T E S T E 1
T E S T E 2
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
99
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:
Consol e> ( enabl e) show ar p
Se os valores default forem configurados, e ainda assim os sinais/sintomas
persistirem, o problema no validade de cache ARP inadequada.
5.5.5 Sugest es de t r at ament o
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 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
ncleo, modifica-se o tempo 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.
C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
100
Em comut ador es Ci sco sr i e 6000 use o comando abai xo par a
modi f i car o t empo de val i dade da cache ARP:
Consol e> ( enabl e) set ar p agi ngt i me
<agi ngt i me_em_segs>
5.6 Refernci as
5.6.1 Li vr os
[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 Rec ur sos onl i ne (I nt er net )
[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
[IEEE802.1D] Padro IEEE 802.1D. Part 3: Media Access Control (MAC)
Bridges.
http://standards.ieee.org/getieee802/download/802.1D-
1998.pdf
5.6.3 RFCs
[RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K.
Definitions of Managed Objects for Bridges. Julho, 1993

5.6.4 Li vr os 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.


C A P T U L O 5 P R O B L E M A S D E N V E L D E E N L A C E
101

102
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 Tabel a de rot as de hospedei ros i ncor ret as
6.1.1 Desc r i o
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 Si nt omas
Quando a tabela de rotas de um hospedeiro estiver com rota default incorreta ou
inexistente, a conseqncia para os usurios que s haver conect i vi dade
com mqui nas da mesma sub-rede. Os usurios de mquinas com este
Capt ulo
6
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
103
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 Si nai s
Se um hospedeiro estiver com a tabela de rotas incompleta, ele receber do seu
roteador default mensagens I CMP de redi reci onament o. 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Se a configurao for manual:
Verifique o endereo IP do roteador default configurado;
Se a configurao do roteador default for dinmica:
Verifique a configurao do escopo em questo no servidor DHCP;
Se o escopo estiver correto:
Verifique a configurao de cliente DHCP no hospedeiro;
Test e confirmat rio 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.
Pr ocedi ment o
11. 8
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
104
Test e confirmat rio 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 r out er s define o endereo
do roteador default.
Test e confirmat rio 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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
105
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 Sugest es de t r at ament o
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 opt i on r out er s corrija o endereo do roteador default. Em
seguida tambm ser necessrio reiniciar o servidor DHCP:
# / et c/ r c. d/ i ni t . d/ dhcpd r est ar t
Ou:
# ki l l TERM <no. do pr ocesso dhcpd>
19

# dhcpd

19
Este nmero pode ser obtido com o comando # ps ae | gr ep dhcpd.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
106
6.2 Endereo IP de hospedei ro i ncor ret o
6.2.1 Desc r i o
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 Si nt omas
Se o endereo IP da mquina est incorreto o usurio da mquina reclamar de
f al t a de conect i vi dade. 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 Mscara Interface Custo End. do roteador
193.168.1.0 255.255.255.0 Eth0 1 193.168.1.2
0.0.0.0 0.0.0.0 Eth0 1 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 conect i vi dade i nt ermi t ent e. 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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
107
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 Si nai s
Quando existem mquinas com mesmo IP na rede, sero encont radas pel o
menos duas respost as mesma requi si o 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 di f uso envi ados por
mqui nas de out ra 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.
6.2.4 Test es c onf i r mat r i os
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.
R E S U M O D O S T E S T E S
Verifique o endereo IP configurado nas mquinas clientes;
Se voc descobrir que existem IPs duplicados na rede:
Se existir mais de um servidor DHCP na rede, certifique-se de que as faixas de
endereos de cada um no se sobrepem;
Pr ocedi ment o
11. 1
Pr ocedi ment o
11. 12
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
108
Test e confirmat rio 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 i pconf i g ou
wi ni pcf g. Eles lhe retornaro configuraes de rede das
mquinas, incluindo o endereo IP configurado.
Em mquinas Linux use o comando i f conf i g a. Este
comando apresenta informaes sobre todas as interfaces da
mquina.
Test e confirmat rio 2
Se existir mais de um servidor DHCP
20
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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
109
No Linux, a faixa de endereos definida no arquivo
/etc/dhcpd.conf. Veja as linhas que comeam com a palavra
r ange.
6.2.5 Sugest es de Tr at ament o
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 i f cf g- , 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
I PADDR.
Aps modificar o endereo de rede de uma interface reinicialize
21
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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
110
6.3 Hospedei ro com mscara de rede i ncor ret a
6.3.1 Desc r i o
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 Si nt omas
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 f al t a sel et i va de conect i vi dade,
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.
L e i a m a i s
s o b r e
m s c a r a s
d e r e d e
n o
a p n d i c e
7
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
111
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 f al t a de conect i vi dade, ou
que s consegue se comuni car com al gumas mqui nas da rede l ocal .
6.3.3 Si nai s
Quando a mscara de sub-rede est configurada com um valor maior que o
correto, vrias mensagens I CMP REDIRECT sero encont radas 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, rot as especf i cas para out ros
hospedei ros, e no apenas rotas para redes, como se espera. Essas rotas so
aprendidas pelo hospedeiro atravs das mensagens ICMP REDIRECT
mencionadas no sinal anterior.
Quando a mscara de rede est com um valor menor que o valor correto,
t raf egaro na rede requi si es ARP, sem a respost a correspondent e. 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Verifique a mscara do hospedeiro;
Se a mscara obtida atravs de um servidor DHCP verifique a configurao do
escopo no servidor DHCP;
Test e confirmat rio 1
Em mquinas Windows use o programa i pconf i g ou
wi ni pcf g. Eles lhe retornaro configuraes de rede das
mquinas, incluindo a mscara de rede configurada.
Pr ocedi ment o
11. 8
Pr ocedi ment o
11. 13
Pr ocedi ment o
11. 2
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
112
Em mquinas Linux use o comando i f conf i g 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.
Test e confirmat rio 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 opt i on subnet - mask
define a mscara de rede. Ela est correta?
6.3.5 Sugest es de t r at ament o
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/network-
scripts existe um arquivo de configurao para cada interface da mquina. Estes
arquivos comeam sempre com i f cf g- , seguidos do nome do dispositivo. Se
voc deseja modificar a mscara de rede da interface eth0, ento edite o arquivo
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
113
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 modific-
lo 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 opt i on subnet - mask). Em seguida
reinicie o servidor DHCP:
# / et c/ r c. d/ i ni t . d/ dhcp r est ar t
Ou:
# ki l l TERM <no. do pr ocesso dhcpd>
22

# dhcpd
6.4 Cl i ent e DNS mal confi gurado
6.4.1 Desc r i o
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 Si nt omas
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 | gr ep dhcpd.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
114
Nestes casos, a reclamao tpica do usurio da mquina com cliente DNS mal
configurado ser de que a rede no est f unci onando. Um usurio mais
avanado pode utilizar endereos IP em vez de nomes e descobrir que o
servi dor responde quando se ut i l i za o seu I P, mas no responde quando o
nome ut i l i zado.
6.4.3 Si nai s
Servi os so acessados vi a endereo I P e no so acessados at ravs do
nome do servi dor. 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Test e confirmat rio 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.
Test e confirmat rio 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.
Pr ocedi ment o
11. 14
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
115
6.4.5 Sugest es de t r at ament o
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 Ser vi dor DHCP mal confi gurado
6.5.1 Desc r i o
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
L e i a m a i s
s o b r e
D H C P n o
a p n d i c e
9
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
116
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;
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
117
Os endereos IPs dos servidores DHCP esto incorretos no agente de
repasse;
6.5.2 Si nt omas
Quando o servidor DHCP est com o escopo mal conf i gurado 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 f al t a de conect i vi dade durant e um cert o t empo
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 f al t a de conect i vi dade,
uma vez que os hospedeiros no obtero suas configuraes de rede.

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
118

Figura 6-1: Exemplo do funcionamento do servidor DHCP
6.5.3 Si nai s
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:
Quando a mscara de rede estiver configurada com um valor menor
que o valor real t raf egaro na rede requi si es ARP, sem a respost a
correspondent e.
Alm disso, podero ser encontradas nas tabelas de rotas de
hospedeiros, rot as especfi cas para out ros hospedei ros. 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, vri as
mensagens ICMP REDI RECT sero encont radas na rede;

Quando existirem IPs duplicados na rede sero encont radas pel o
menos duas respost as mesma requi si o ARP;

Quando o endereo do servidor de nomes de domnio estiver incorreto
ou no estiver configurado servi os sero acessados vi a endereo I P
e no sero acessados at ravs do nome do servi dor.
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
Pr ocedi ment o
11. 2
Pr ocedi ment o
11. 13
Pr ocedi ment o
11. 8
Pr ocedi ment o
11. 1
Pr ocedi ment o
11. 14
Pr ocedi ment o
11. 6
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
119
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, encont raremos const ant ement e mensagens
DHCPNAK.
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 escri t as nos l ogs do servi dor 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 requi si o ext erna de cl i ent es DHCP ser
encont rada na rede;
Se o servidor DHCP no estiver ativado ou os endereos dos servidores DHCP
estiverem incorretamente configurados em um agente de repasse DHCP,
t raf egaro na rede mensagens DHCP REQUEST sem respost a de qual quer
servi dor DHCP. Aps requisies DHCP espera-se que o(s) servidor(es) DHCP
retorne(m) mensagens do tipo DHCPOFFER.
6.5.4 Test es c onf i r mat r i os
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.
R E S U M O D O S T E S T E S
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;
Pr ocedi ment o
11. 5
Pr ocedi ment o
11. 7
Pr ocedi ment o
11. 4
T E S T E 1
T E S T E 2
T E S T E 3
T E S T E 4
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
120
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:
Test e confirmat rio 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 | gr ep 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.
# gr ep dhcp / et c/ r c. d/ r c*
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.
# gr ep dhcp / et c/ r c. 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.
T E S T E 5
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
121
Test e confirmat rio 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 domnio
23
. 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.
Test e confirmat rio 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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
122
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.
Test e confirmat rio 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:
r ot eador # show dhcp ser ver
Test e confirmat rio 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 Sugest es de t r at ament o
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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
123
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

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
124
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 Rot as est t i cas mal confi guradas
6.6.1 Desc r i o
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
# r out e add net 192. 168. 10. 0 net mask 255. 255. 255. 0 gw
192. 168. 13. 1
devesse ser executado em um roteador para adicionar uma certa rota
24
.
No entanto, por erro de digitao, o comando executado foi
# r out e add net 192. 168. 19. 0 net mask 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.
L e i a m a i s
s o b r e
r o t e a -
m e n t o n o
a p n d i c e
8


C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
125
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 sub-
redes 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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
126
6.6.2 Si nt omas
Em geral, todas as situaes de erro de configurao de rotas levam a destinos
inalcanveis. Os usurios reclamaro de f al t a de conect i vi dade para uma ou
mai s redes.
6.6.3 Si nai s
Quando laos lgicos existirem, muitas mensagens I CMP Ti me 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 f al t am ent radas na t abel a de rot as de um rot eador, Dest i nat i on
Unreachabl e Messages (I CMP t i po 3, cdi go 0) so encont radas na rede.
Se um roteador receber um datagrama e no souber para onde envi-lo, ele
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 i pOut NoRout es (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 cresci ment o rpi do do val or da vari vel i pOut NoRout es pode
indicar erros na tabela de rotas.
6.6.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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;
Pr ocedi ment o
11. 9
Pr ocedi ment o
11. 10
Pr ocedi ment o
11. 11
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
127
Test e confirmat rio 1
Para localizar o problema, a melhor ferramenta a ser utilizada o
t r acer out e (t r acer t 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 t r acer out e 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 t r acer out e 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 t r acer out e para o
servidor da aplicao em questo, obtendo a seguinte sada:
# t r acer out e n 192. 168. 6. 10
1 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 1. 254
2 0. 231 ms 0. 165 ms 0. 153 ms 192. 168. 2. 254
3 0.214 ms 0.189 ms 0.344 ms 192.168.1.254
4 0.254 ms 0.213 ms 0.222 ms 192.168.2.254
5 0.235 ms 0.198 ms 0.210 ms 192.168.1.254
6 0.301 ms 0.255 ms 0.278 ms 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:
# t r acer out e n 192. 168. 6. 10
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
128
1 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 13. 1
2 0. 231 ms 0. 165 ms 0. 153 ms 192. 168. 15. 3
3 0.214 ms 0.189 ms 0.344 ms 192.168.17.3
4 !H !H !H
5 !H !H !H
...
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.
Test e confirmat rio 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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
129
Test e confirmat rio 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
r ot eador # i p r out e 155. 190. 0. 0 255. 255. 0. 0 nul l 0
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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
130
6.6.5 Sugest es de t r at ament o
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 Equi pament o i nseri do em VLAN i ncor ret a
6.7.1 Desc r i o
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.

L e i a m a i s
s o b r e
V L A N s n o
a p n d i c e
1 2

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
131

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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
132
6.7.2 Si nt omas
O sintoma deste problema sempre f al t a de conect i vi dade ou
i ndi sponi bi l i dade de al guns servi os, 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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
133
6.7.3 Si nai s
Os sinais estaro espalhados em vrias VLANs e at nas mquinas afetadas pela
modificao. Na VLAN original
25
, sero percebidos os seguintes sinais:
Requi si es ARP t raf egam sem respost a. 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.
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 Unreachabl e. 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:
Trf ego de di f uso cuj o endereo ori gem no faz part e do conj unt o de
endereos conf i gurados nas mqui nas 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:
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 rede
26
. 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 mqui na, que deveri a f azer part e de uma
det ermi nada rede, vai apresent ar confi guraes de out ra 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.
Pr ocedi ment o
11. 2
Pr ocedi ment o
11. 10
Pr ocedi ment o
11. 12
Pr ocedi ment o
11. 13
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
134
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, apresent ar o endereo 0.0.0.0 como seu endereo de
rede, endereo de servi dor de nomes e mscara de rede.
6.7.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Voc tem um ambiente de VLANs configuradas por portas ou por endereo
MAC?
Caso a VLAN seja configurada por porta:
Verifique a disposio das mquinas nas portas do comutador. Alguma
modificao foi realizada?
Se a VLAN for configurada por endereo MAC:
Verifique se o endereo MAC de algum equipamento membro da VLAN foi
modificado (uma mquina inteira ou uma placa de rede foi substituda);
Test e confirmat rio 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 e-
mails. 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
Pr ocedi ment o
11. 13
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
135
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.
Test e confirmat rio 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:
Consol e> 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.
Test e confirmat rio 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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
136
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 Sugest es de t r at ament o
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.

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
137
6.8 VLANs no est o confi guradas
6.8.1 Desc r i o
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 sub-
rede 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
V e r m a i s
s o b r e
V L A N s n o
a p n d i c e
1 2

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
138
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 Si nt omas
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 l ent a.
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. no f unci onament o de cert os servi os 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 cert os servi os. 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 IP
27
;
2.2. f al t a de conect i vi dade as configuraes oferecidas pelo
servidor DHCP so incompletas. O cliente DHCP esperava
receber, dentre outros parmetros o roteador default, mas o servidor

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;
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
139
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 Si nai s
Quant i dade excessi va t rf ego de quadros de di f uso. 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.
Ut i l i zao al t a de CPU. 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.
Sat urao da l argura de banda. 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.
Mqui nas que f azem part e de uma det ermi nada sub-rede passam a receber
quadros de di f uso de mqui nas de out ra 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 sub-
rede e originalmente pertencia a outra VLAN.
Pr ocedi ment o
10. 9
Pr ocedi ment o
10. 6
Pr ocedi ment o
10. 10
Pr ocedi ment o
11. 12
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
140
Quando as configuraes de rede das mquinas so obtidas dinamicamente,
possvel encontrar mqui nas que deveri am f azer part e de uma sub-rede com
conf i guraes de out ra 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Houve a substituio de algum comutador?
O novo comutador est com as VLANs corretamente configuradas?
Test e confirmat rio 1
Este problema s
28
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.
Test e confirmat rio 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:
consol e> ( enabl e) show vlan
Comutadores mais antigos, Cisco Catalyst 1900, por exemplo, as
VLANs configuradas podem ser vistas escolhendo-se, no menu

28
possvel tambm que o comutador apresente problemas e por isso as VLANs sejam
desconfiguradas, mas este j um problema de nvel fsico (EQUI PAMENTO DE I NTERCONEXO
DEFEI TUOSO) que acarretou a desconfigurao das VLANs.
Pr ocedi ment o
11. 13
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
141
principal, a opo Vi r t ual Lan. Em comutadores IBM 8271-
712 escolha a opo Swi t ch Management . No nvel de
gerncia de VLANs selecione a opo Set up. 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 Sugest es de t r at ament o
A soluo para este problema configurar as VLANs. Esta seo nem deveria
existir para este problema, no fossem as seguintes importantes dicas:
Document e 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, organi zar a l i nha base de
conf i gurao 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 Comut adores no conseguem t rocar i nfor maes sobre
VLANs ent re si
6.9.1 Desc r i o
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.


A p r e n d a
m a i s
s o b r e
V L A N s n o
a p n d i c e
1 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
142
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.

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
143
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 Si nt omas
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 f al t a de conect i vi dade
ou, em l i nguagem de usuri o, que a rede no est f unci onando, j que ele
no consegue obter suas configuraes de rede.
Um outro sintoma pode ser o no f unci onament o de al guns servi os 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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
144
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 f al t a de conect i vi dade ent re mqui nas cl i ent es.
Se voc tem uma rede Microsoft e no estiver utilizando servidor WINS
29
,
al guns cl i ent es recl amaro de no consegui r ef et uar o l ogon na rede. Uma
outra reclamao ser de no consegui r navegar em t odas as mqui nas da
rede
30
. 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 Si nai s
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.
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
requi si es ARP sem respost a.
Requi si es DHCP sem respost a do servi dor DHCP. 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.
Pr ocedi ment o
11. 2
Pr ocedi ment o
11. 4
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
145
Cl i ent es DHCP sem as conf i guraes 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 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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?
Test e confirmat rio 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.
Test e confirmat rio 2
Verifique se os comutadores envolvidos so do mesmo fabricante.
Caso no sejam, as chances deste problema estar ocorrendo so
maiores.
Test e confirmat rio 3
Verifique o tipo de codificao utilizada nos troncos. Em
comutadores Cisco mais novos execute o comando:
Consol e> ( enabl e) show trunk
Pr ocedi ment o
11. 13
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
146
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 Sugest es de t r at ament o
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 t r unk mod/ por t [ on | desi r abl e | aut o |
nonegot i at e] dot 1q
O comando a seguir configura um tronco 802.1Q na porta 1 do mdulo 1 de
um comutador Cisco [CISCO-VLAN-TRUNKS]:
Consol e> ( enabl e) set t r unk 1/ 1 desi r abl e dot 1q
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 Ambi ent e RIP-1 com VLSM e/ou redes no cont guas
6.10.1 Desc r i o
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, sub-
redes 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

L e i a m a i s
s o b r e R I P
n o c a p -
t u l o X
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
147
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 resumo
31
, 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.

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

31
Em [CISCO-RIP-BEHAVIOR, CISCO-RIP-VLSM E CISCO-RIP-
DISCONTIGUOUS] apresentada uma viso mais detalhada do comportamento de um roteador
RIP ao enviar e receber mensagens de atualizaes de rotas.
L e i a m a i s
s o b r e
e n d e r e a -
m e n t o n o
a p n d i c e
8

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
148
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 Si nt omas
difcil prever o comportamento do roteamento em um ambiente RIP-1 com
VLSM e/ou redes no contguas. Em geral, os usurios reclamaro de fal t a de
conect i vi dade para uma ou mai s 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 Si nai s
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 Dest i nat i on Unreachabl e (I CMP t i po 3, cdi go 0) provavel ment e
t raf egaro na rede. O ideal que mensagens deste tipo no existam na rede.
6.10.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Voc tem um problema de roteamento?
Pr ocedi ment o
11. 10
T E S T E 1
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
149
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.
Test e confirmat rio 1
provvel que os usurios das redes prejudicadas reclamem.
Conecte-se em uma mquina de uma das redes atingidas pelo
problema e direcione um t r acer out e para uma mquina na
outra rede.
Se o seu teste revelar que faltam rotas nos roteadores (!H na sada
do t r acer out e) 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.
Test e confirmat rio 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
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
150
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 RIP-
1, 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:
Test e confirmat rio 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 Sugest es de t r at ament o
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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
151
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 Di met ro RIP com mai s de 15 rot eadores
6.11.1 Desc r i o
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.
L e i a m a i s
s o b r e R I P
n o
a p n d i c e
8

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
152

Figura 6-8: exemplo de rede com distncia maior que 15 entre duas sub-redes
6.11.2 Si nt omas
Os usurios das redes envolvidas iro reclamar de f al t a de conect i vi dade ent re
as redes. 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 Si nai s
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 Dest i nat i on Unreachabl e (ICMP t i po 3,
cdi go 0) provavel ment e t raf egaro na rede. O ideal que mensagens deste
tipo no existam na rede.
L e i a m a i s
s o b r e
e n d e r e a -
m e n t o n o
a p n d i c e
7
Pr ocedi ment o
11. 10
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
153
6.11.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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?
Test e confirmat rio 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 t r acer out e 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 t r acer out e para o BD do Almoxarifado.
A sada foi a seguinte:
# t r acer out e n 192. 168. 16. 2
1 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 1. 1
2 ! H ! H ! H
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 t r acer out e
para uma mquina do Departamento de Produo obtm-se uma
sada semelhante:
# t r acer out e n 192. 168. 1. 2
1 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 16. 1
T E S T E 1
T E S T E 2
T E S T E 3
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
154
2 ! 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.
Test e confirmat rio 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.
Test e confirmat rio 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
t r acer out e 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
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
155
Departamento de produo, o datagrama deve passar por
roteador1 e logo aps por roteador2 e roteador3. O gerente, ento,
conectou-se via t el net ou atravs de um terminal de gerncia
em roteador2, que o segundo roteador pelo qual o datagrama
deveria passar. Dele, o gerente direcionou um t r acer out e para
uma mquina da LAN do Almoxarifado. A sada do
t r acer out e foi a seguinte:
# t r acer out e n 192. 168. 16. 2
1 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 3. 1
2 0. 231 ms 0. 165 ms 0. 153 ms 192. 168. 4. 1
3 0. 214 ms 0. 189 ms 0. 344 ms 192. 168. 5. 1
4 0. 254 ms 0. 213 ms 0. 222 ms 192. 168. 6. 1
5 0. 235 ms 0. 198 ms 0. 210 ms 192. 168. 7. 1
6 0. 301 ms 0. 255 ms 0. 278 ms 192. 168. 8. 1
7 0. 226 ms 0. 209 ms 0. 245 ms 192. 168. 9. 1
8 0. 219 ms 0. 159 ms 0. 218 ms 192. 168. 10. 1
9 0. 132 ms 0. 211 ms 0. 217 ms 192. 168. 11. 1
10 0. 231 ms 0. 165 ms 0. 153 ms 192. 168. 12. 1
11 0. 214 ms 0. 189 ms 0. 344 ms 192. 168. 13. 2
12 0. 231 ms 0. 199 ms 0. 243 ms 192. 168. 14. 1
13 0. 231 ms 0. 229 ms 0. 235 ms 192. 168. 15. 1
14 0. 301 ms 0. 302 ms 0. 265 ms 192. 168. 16. 1
15 0. 282 ms 0. 209 ms 0. 287 ms 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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
156
6.11.5 Sugest es de t r at ament o
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 Rot eadores RIP-2 no envi am ou recebem pacot es RIP-
1
6.12.1 Desc r i o
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-2
32
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.


L e i a m a i s
s o b r e R I P
n o
a p n d i c e
8
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
157
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 Si nt omas
Os usurios reclamaro de f al t a de conect i vi dade para uma ou mai s 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.

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
158
6.12.3 Si nai s
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 I CMP de dest i no i nal canvel (I CMP
t i po 3, cdi go 0) provavel ment e t raf egaro na rede. O ideal que mensagens
deste tipo no existam na rede.
6.12.4 Test es c onf i r mat r i os
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.
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;
Test e confirmat rio 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 RIP-
1 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.
Pr ocedi ment o
11. 10
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
159
Num caso mais raro, em que o ambiente era completamente RIP-
2 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.
Test e confirmat rio 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. At ravs de uma i nt erface de l i nha 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:
r ot eador > show i p r i p send ver si on
r ot eador > show i p r i p r ecei ve ver si on
O comando seguinte mostra toda a configurao corrente do
roteador e pode tambm ser utilizado:
r ot eador # show r unni ng- conf i g
2. Com o auxl i o de uma est ao de gernci a SNMP
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
160
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
endereo de difuso;
ripVersion2 (4) envia atualizaes RIP-2 atravs de
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 Sugest es de t r at ament o
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:
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:
r ot eador 1# i p r i p send ver si on 1 2
A T R A V S
D E U M A
I N T E R F A C E
D E L I N H A
D E
C O M A N D O
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
161
r ot eador 1# i p r i p r ecei ve ver si on 1 2
Tambm possvel escolher aceitar receber ou enviar apenas pacotes RIP-1.
r ot eador 1# i p r i p send ver si on 1
r ot eador 1# i p r i p r ecei ve ver si on 1
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.
6.13 Trfego RIP sat urando l ar gura de banda
6.13.1 Desc r i o
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.
C O M O
A U X L I O
D E U M A
E S T A O
D E
G E R N C I A
S N M P
L e i a m a i s
s o b r e R I P
n o
a p n d i c e
8

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
162
6.13.2 Si nt omas
Os usurios reclamaro de rede l ent a. 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 Si nai s
Taxa de ut i l i zao de enl aces de l onga di st nci a
33
superi or a 70%. 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.
6.13.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S

33
Enlaces de redes locais, tm maior capacidade, no sendo provvel a sua saturao devido ao
trfego RIP.
Pr ocedi ment o
10. 10
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
163
Quantas redes esto interligadas? Milhares? Existem enlaces de baixa
velocidade?
Qual o trfego RIP gerado pelos roteadores?
Test e confirmat rio 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 pi ng, 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:
# net st at nr | wc - l
Test e confirmat rio 2
Para descobrir quanta largura de banda o trfego RIP est
consumindo, substitua a varivel n- ent r adas da equao abaixo
pelo nmero de entradas RIP nas tabelas de rotas dos roteadores.
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
164
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 Sugest es de t r at ament o
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 Fi l t ro IP no per mi t e a passagem de t rfego RIP (UDP
520)
6.14.1 Desc r i o
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.
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
165
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 Si nt omas
Os usurios reclamaro de f al t a de conect i vi dade para uma rede, vri as
redes ou t odas as out ras redes. No exemplo anterior, certamente, o pessoal
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 Si nai s
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,

Pr ocedi ment o
11. 10
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
166
mensagens Dest i nat i on Unreachabl e (I CMP t i po 3, cdi go 0) provavel ment e
t raf egaro na rede. O ideal que mensagens deste tipo no existam na rede.

Sendo roteados com base nas tabelas incompletas dos roteadores, laos lgicos
podem ser formados. A formao dos laos vai levar exi st nci a de
mensagens ICMP de TTL excedi do na rede. Idealmente estas mensagens no
devem ser encontradas.
6.14.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
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.
Test e confirmat rio 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.
Test e confirmat rio 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- l i st
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.
Pr ocedi ment o
11. 9
T E S T E 1
T E S T E 2
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
167
Atualmente, o filtro configurado com um dos seguintes
comandos: i pt abl es, i pchai ns ou i pf wadm. Os comandos
abaixo mostram as regras de entrada e de sada para configuraes
realizadas com i pt abl es, i pchai ns e com i pf wadm.
# i pt abl es L n | mor e
# i pchai ns L - n| mor e
# i pf wadmL n | mor e
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 Sugest es de t r at ament o
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- l i st . Considerando que os roteadores do exemplo
apresentado na Seo DESCRIO so fabricados pela Cisco, o problema
solucionado com os seguintes comandos:
r ot eador 1# no access- l i st 101 deny udp any any eq 520
r ot eador 1# access- l i st 101 per mi t udp 192. 168. 4. 1 0. 0. 0. 0 any eq 520
r ot eador 1# access- l i st 101 per mi t 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 :
r ot eador 1# access- l i st 101 per mi t 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:
/ sbi n/ i pchai ns A i nput p udp s 192. 168. 4. 1/ 32 d 0/ 0 520 i et h1 j
ACCEPT
/ sbi n/ i pchai ns A out put p udp s 192. 168. 4. 2/ 32 d 0/ 0 520 i et h1 j \
ACCEPT
ou
/ sbi n/ i pf wadmI a accept P udp S 192. 168. 4. 2/ 32 D 0/ 0 520
/ sbi n/ i pf wadmO a accept P udp S 192. 168. 4. 1/ 32 D 0/ 0 520
C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
168
Em um filtro IP menos seguro os endereos das interfaces poderiam ser
trocados por 0/0.
6.15 Refernci as
6.15.1 Rec ur sos onl i ne (I nt er net )
[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-RIP-
DISCONTIGUOUS]
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
[DHCP_FAQ] Wobus, J., Lemon, T., Droms, R. DHCP FAQ.
http://www.dhcp-handbook.com/dhcp_faq.html

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

C A P T U L O 6 P R O B L E M A S D E N V E L D E R E D E
169
6.15.3 Li vr os base
[COMER] Comer, D. Internetworking with TCP/IP:
Principles, Protocols, and Architectures. Volume
1. Quarta edio. Prentice Hall, 2000.
[CISCO-ROUTING-
TCP/IP]
Doyle, J. Routing TCP/IP, Volume 1: CCIE
Professional Development. Cisco Press.
Setembro, 1998.
[CISCO-IP-ROUTING] Sportack, M. IP Routing Fundamentals. Cisco
Press. Fevereiro, 1999.
[DHCP-HANDBOOK] Lemon, T. Droms, R. The DHCP Handbook:
Understanding, Deploying, and Managing
Automated Configuration Services. Pearson
Higher Education. Outubro, 1999.
[DHCP-WIN-2000] Alcott, N. DHCP for Windows 2000. OReilly.
Janeiro, 2001.
[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.


170
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 ser vi o de nomes no est habi l i t ado
7.1.1 Desc r i o
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
Capt ulo
7
A p r e n d a
m a i s
s o b r e o
s e r v i o
d e n o m e s
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
171
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 Si nt omas
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
f unci onando.
7.1.3 Si nai s
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 cl i ent es recebero mensagens I CMP Port Unreachabl e sempre que
tentarem utilizar o servio de resoluo de nomes.
De todas as mquinas da rede, percebemos que h conect i vi dade com out ras
mqui nas at ravs de seu I P, mas no at ravs de seu nome.

7.1.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S

Pr ocedi ment o
11. 10
Pr ocedi ment o
11. 14
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
172
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;
Test e confirmat rio 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 | gr ep 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).
Test e confirmat rio 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
T E S T E 1
T E S T E 2
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
173
configurao em algumas verses do BIND o servidor pra a
execuo quando encontra erros nos arquivos de configurao.
Em mquinas Linux Slackware
35
, 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:
# gr ep named / et c/ r c. d/ r c*
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.d
36
) existe um link iniciado com a
letra S que aponta para o arquivo /etc/rc.d/init.d/named.
# gr ep named / et c/ r c. 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.
36
Para as mquinas que trabalham em ambiente grfico.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
174
7.1.5 Sugest es de t r at ament o
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):
i f [ - x / usr / sbi n/ named ] ; t hen
echo - n " named "
/ usr / sbi n/ named
f i
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 / sbi n/ named
O caminho para o processo named pode ser outro, depende de onde o named
est instalado
37
. 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 | gr ep 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.d
38
:
# cd / et c/ r c. d/ r c3. d
# l n - s S45named . . / i ni t . d/ named
Voc pode iniciar o servidor de nomes manualmente com o comando:
# / et c/ r c. d/ i ni t . c/ named st ar t

37
O comando t ype 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.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
175
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: descasament o de regi st ros A e PTR em ar qui vos de
zonas
7.2.1 Desc r i o
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 BIND
39
a configurao do mapeamento direto e reverso no
feita no mesmo registro, nem no mesmo arquivo de zona. necessrio um
registro Internet Address (I N A) para o mapeamento direto e um registro
Internet Pointer (I N PTR) para o reverso. Os registros I N A ficam no arquivo
de zonas de mapeamento direto, enquanto os registros I N 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 I N A 192. 168. 1. 1 ; no ar qui vo de mapeament o di r et o
E o registro abaixo no arquivo de zona reverso:
1 I N PTR pc- 1. exempl o. com. br ; no ar qui vo de mapeament o r ever so
Isto significa que ao modificar registros I N A no arquivo de mapeamento
direto, necessrio efetuar as modificaes correspondentes nos registros I N
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.
L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
176
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 I N A ou esquecer de modific-
lo aps inserir ou alterar um registro I N 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, t el net e r sh, 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
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
177
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 Si nt omas
O usurio da mquina envolvida no erro de configurao de DNS reclamar
que al guns servi os no f unci onam. No exemplo da seo anterior, o usurio
de pc-1 poderia reclamar que no consegue usar t el net , FTP ou ssh para
alguns destinos. Neste caso a reclamao pode ser tambm que preci sam
esperar al gum t empo quando vo se conect ar a cert os servi dores.
7.2.3 Si nai s
Resol uo di ret a de um nome de mqui na no casa com a resol uo
reversa no servi dor de nomes pri mri o do domni o. Este sinal ser percebido
em duas situaes:
os registros I N A e I N 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 Test es c onf i r mat r i os
O sinal apresentado na seo anterior diferencial. Portanto, se ele for
encontrado a existncia do problema est confirmada.
7.2.5 Sugest es de t r at ament o
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 r ndc pode ser utilizado. No BIND 8.x o comando
Pr ocedi ment o
12. 5
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
178
correspondente ao r ndc o ndc. No entanto, o BIND deve estar devidamente
configurado para ser controlado por eles.
# r ndc r el oad
# ndc r el oad
Em todas as verses:
# ki l l HUP <nmer o do pr ocesso named>
O nmero do processo named pode ser encontrado com um dos seguintes
comandos:
# ps ae | gr ep named ( em sistemas baseados no BSD),
# ps ef | gr ep named (sistemas baseados no System V)
# cat / var / r un/ named. pi d
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 Inconsi st nci a ent re regi st ros dos ser vi dores DNS
pri mri o e secundri os
7.3.1 Desc r i o
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 BIND
40
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.
L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
179
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 srie
41
, no queira que os
servidores escravos estejam atualizados to logo voc modifique os arquivos do

41
Diretiva not i f y no arquivo /etc/named.conf. Mais informaes em [DNS&BIND].
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
180
servidor primrio. Eles s estaro atualizados aps um ou mais intervalos de
refresh
42
.
7.3.2 Si nt omas
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 i ndi sponi bi l i dade de al guns servi os.
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 poss vel encont r ar
<nome- da- maqui na> ou A pgi na no pode ser exi bi da ( )
No poss vel encont r ar o ser vi dor ou ocor r eu umer r o
de DNS.
7.3.3 Si nai s
Os servi dores pri mri o e secundri os ret ornaro respost as di f erent es a
uma mesma consul t a 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 conect i vi dade at ravs dos endereos I Ps das mquinas
envolvidas no erro, mas no at ravs de seus nomes de domni o.

7.3.4 Test es c onf i r mat r i os
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.
Pr ocedi ment o
12. 1
Pr ocedi ment o
11. 14
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
181
7.3.5 Sugest es de t r at ament o
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 defaul t de uma zona DNS no est confi gurado
7.4.1 Desc r i o
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.com
43
.
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.


L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
182
O servidor raiz tambm no sabe quem www.cisco.com
44
, 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].
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
183
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 Si nt omas
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 servi os l ocai s, mas conseguem acessar a
Int ernet . No entanto, como no h resoluo de nomes locais, alguns servi os
como t el net , ssh e FTP podem no f unci onar, 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
cliente
45
. 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).

45
Nem todos os servidores tm este mesmo comportamento, s os que so compilados ou
configurados para agir assim modo paranico.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
184
a rede no est f unci onando. Ao tentar navegar na Internet, por exemplo, o
prprio navegador apresentar uma pgina de erro indicando erro de DNS.
Quando o servidor de nomes externo est com este problema, pessoas que
no est o na organi zao podem recl amar. Elas diro que os servi os
of ereci dos pel a sua organi zao no est o f unci onando. 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 Si nai s
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 def aul t TTL set usi ng SOA mi ni mum i nst ead .
Ser indicado no arquivo de log tambm o arquivo onde o TTL default no est
configurado.
7.4.4 Test es c onf i r mat r i os
O sinal apresentado na seo anterior confirmatrio. Se ele foi encontrado
nenhum teste adicional precisa ser realizado.
7.4.5 Sugest es de t r at ament o
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:
Pr ocedi ment o
12. 2
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
185
# ki l l HUP <nmer o do pr ocesso 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 ar qui vo a ser ver i f i cado>
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 execute
48
:
# 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 named-
checkzone informar claramente.
7.5 DNS: TTL e out ros campos do regi st ro SOA com val ores
i nadequados
7.5.1 Desc r i o
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 raiz
49
.
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 default
50
. O servidor que

46
Este nmero pode ser obtido com o comando # ps ae | gr ep 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 <dom ni o> <ar qui vo a ser ver i f i cado>
48
No BIND 9.2 o comando seria: # named- checkzone exempl o. 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.

L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
186
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-se
51
: 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.

51
Existem ainda outros campos que sero citados apenas na seo SUGESTES DE TRATAMENTO.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
187
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
zonas
52
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 Si nt omas
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, usuri os de out ros domni os podem no consegui r acessar
al guns servi os. 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 l ent i do 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 not i f y yes). Verses anteriores 8 no suportam a notificao [DNS&BIND].
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
188
acesso aos servi os. 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
al guns servi os i ndi sponvei s.
7.5.3 Si nai s
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
ut i l i zao el evada de CPU. O limiar de advertncia para utilizao de CPU
75%.

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 enl aces de menor capaci dade (l onga di st nci a, em geral )
sat urados devido ao trfego DNS. O limiar para utilizao de enlaces de acesso
no compartilhado 70%.
Quando o intervalo de refresh for muito grande os servi dores pri mri o e
secundri os podero ret ornar respost as di f erent es a uma mesma consul t a
DNS durante algum tempo. Isto tambm ocorrer se voc modificar algum
arquivo no servidor primrio e esquecer de incrementar o nmero de srie
associado ao arquivo.
7.5.4 Test es c onf i r mat r i os
R E S U M O D O S T E S T E S
Se o sintoma rede lenta:
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:
Pr ocedi ment o
10. 6
Pr ocedi ment o
10. 10
Pr ocedi ment o
12. 1
T E S T E 1
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
189
Modificaes em registros do servidor primrio foram realizadas? Verifique o
TTL default e os valores do SOA configurados.
Test e confirmat rio 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.
Test e confirmat rio 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.
T E S T E 2
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
190
7.5.5 Sugest es de t r at ament o
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 ; 86400 Segundos (1 dia)4
@ IN SOA ns.exemplo.com.br. root.exemplo.com.br. (
200201231 ; Serial
4h ; Refresh 4 Horas
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
191
1h ; Retry 1 Hora
2w ; Expire 2 Semanas
2h) ; 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 ki l l :
# ki l l HUP <nmer o do pr ocesso 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.


C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
192
7.6 Fal t a . aps nomes t ot al ment e qual i fi cados em
regi st ros DNS
7.6.1 Desc r i o
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 I N A 200. 120. 10. 100
ou
www. exempl o. com. br . I N 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. exempl o. com. br I N 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
L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
193
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:
ger enci a. exempl o. com. br I N NS ser ver . ger enci a. exempl o. com. br .
ser ver . ger enci a. exempl o. com. br . I N A 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.
ger enci a. exempl o. com. br . I N NS ser ver . ger enci a. exempl o. com. br
ser ver . ger enci a. exempl o. com. br . I N A 200. 120. 11. 53
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 Si nt omas
A reclamao geral ser i ndi sponi bi l i dade de servi os. 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.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
194
7.6.3 Si nai s
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 al guns nomes l ocai s s podem ser resol vi dos quando de acrescent a o
nome do domni o 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.in-
addr.arpa. Respostas incorretas tambm ser oferecidas quando o ponto for
esquecido em registros MX e NS.
7.6.4 Test es c onf i r mat r i os
O sinal apresentado na seo anterior diferencial. Isto significa que se ele for
encontrado o problema est confirmado.
7.6.5 Sugest es de t r at ament o
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.
Pr ocedi ment o
12. 6
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
195
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:
r oot # nsl ookup
> www1
Ser ver : 200. 120. 10. 53
Addr ess: 200. 120. 10. 53#53
Name: www1. exempl o. com. br
Addr ess: 200. 120. 10. 101
> 200. 120. 10. 101
Ser ver : 200. 120. 10. 53
Addr ess: 200. 120. 10. 53#53
101. 10. 120. 200. i n- addr . ar pa name = www1. exempl o. com. br .
Este teste comprova que as modificaes realizadas foram corretas e que o
servidor j as reconhece.
7.7 Fi l t ro IP bar rando t rfego DNS
7.7.1 Desc r i o
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

L e i a m a i s
s o b r e D N S
n o
a p n d i c e
1 0
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
196
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 Si nt omas
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 qual quer servi o f ora da organi zao. 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
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
197
usurio um erro de DNS. No Internet Explorer, por exemplo, aps algum
tempo, uma pgina de erro apresentada, contendo mensagens como: No
poss vel encont r ar <nome- da- maqui na> ou A pgi na no
pode ser exi bi da ( ) No poss vel encont r ar o
ser vi dor ou ocor r eu umer r o de DNS.
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 f unci onando, 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, usuri os ext ernos se quei xaro de no consegui r
acessar os servi os de sua organizao: enviar e-mails, por exemplo.
7.7.3 Si nai s
Consul t as DNS sem respost a. 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.
A resol uo de nomes ext ernos no funci ona. 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 servi dores secundri os mensagens no arqui vo de l ogs i ndi cam que
no f oi possvel a comuni cao com o servi dor pri nci pal . Este pode ser um
sinal de que o trfego entre servidores secundrios e principais est sendo
barrado por um filtro IP.
7.7.4 Test es c onf i r mat r i os
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:
# t el net <I P do ser vi dor DNS> 53
Se o servidor DNS responder, ele est em execuo.
R E S U M O D O S T E S T E S
Pr ocedi ment o
12. 4
Pr ocedi ment o
12. 3
Pr ocedi ment o
12. 2
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
198
Localize os filtros IP da organizao localizados entre servidores DNS e
verifique se eles permitem a passagem do trfego DNS;
Test e confirmat rio 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
i pchai ns ou i pt abl es use um dos seguintes comandos:
# i pchai ns L n | mor e
# i pt abl es L n | mor e
Em um roteador Cisco com listas de acesso configuradas use o
comando:
r ot eador # show access- l i st
T E S T E 1
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
199
7.7.5 Sugest es de t r at ament o
Se o problema foi confirmado, corrija as regras de filtragem do firewall. Lembre-
se 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:
opt i ons {
di r ect or y " / 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 i pchai ns adicione as seguintes regras:
DNS = 192. 168. 1. 53 # ender eo I P de umser vi dor DNS
any = 0. 0. 0. 0/ 0. 0. 0. 0
i pchai ns - A f or war d - s $DNS 1024- 65535 - d $any 53 - p t cp \
- j ACCEPT
i pchai ns - A f or war d - s $DNS 1024- 65535 - d $any 53 - p udp \
- j ACCEPT
i pchai ns - A f or war d - s $any 53 - d $DNS 1024- 65535 - p t cp \
- j ACCEPT
i pchai ns - A f or war d - s $any 53 - d $DNS 1024- 65535 - p udp \
- j ACCEPT
Em um filtro IP Linux que usa i pt abl es as regras so as seguintes:
DNS = 192. 168. 1. 53 # ender eo I P de umser vi dor DNS
any = 0. 0. 0. 0/ 0. 0. 0. 0
i pt abl es - A FORWARD - p t cp - s $any spor t 53 - d $DNS \
- - dpor t 1024: 65535 - j ACCEPT
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
200
i pt abl es - A FORWARD - p t cp - s $any spor t 53 - d $DNS \
- - dpor t 1024: 65535 - j ACCEPT
i pt abl es - A FORWARD - p t cp - s $DNS spor t 1024: 65535 - d \
$any - - dpor t 53 - j ACCEPT
i pt abl es - A FORWARD - p udp - s $DNS spor t 1024: 65535 - d \
$any - - dpor t 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- l i st 102 per mi t t cp <DNS1> gt 1023 any eq domai n
access- l i st 102 per mi t udp <DNS1> gt 1023 any eq domai n
access- l i st 102 per mi t t cp any eq domai n <DNS1> gt 1023
access- l i st 102 per mi t udp any eq domai n <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.
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
201
7.8 Ser vi dor de cor rei o el et rni co com repasse t ot al ment e
aber t o
7.8.1 Desc r i o
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
L e i a m a i s
s o b r e o
s e r v i o d e
c o r r e i o
e l e t r n i c o
n o
a p n d i c e
1 1
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
202
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 Si nt omas
Se seu site for cadastrado em bases de dados de repasses abertos os usuri os
l ocai s recl amaro que no conseguem envi ar mensagens para cert os
dest i nos (usurios cujo servidor SMTP esto configurados para consultar as
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 i ndi cam que o seu servi dor SMTP est cadast rado em uma l i st a
negra ant i spam.
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.mail-
abuse.org/rss/enduser.html.
O admi ni st rador da rede receber por e-mai l avi sos 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 Si nai s
O servi dor SMTP acei t a fazer a ent rega de mensagens sempre, 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 Test es c onf i r mat r i os
O sinal apresentado na seo anterior confirmatrio, no sendo necessrios
outros testes adicionais.
Pr ocedi ment o
12. 8
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
203
7.8.5 Sugest es de t r at ament o
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 sendmai l (v8.9 e superior), assim como a
implementao qmai l 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.


C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
204
7.9 Ser vi dor de cor rei o el et rni co com repasse t ot al ment e
fechado
7.9.1 Desc r i o
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 qmai l , desde suas verses mais antigas, j vem negando o
repasse por default. As verses 8.9 e superiores do sendmai l , 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 Si nt omas
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 envi ar 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 envi ada por que um de seus
dest i nat r i os f oi r ecusado pel o ser vi dor .
7.9.3 Si nai s
O servi dor SMTP no acei t a envi ar mensagens dest i nadas a usuri os no
l ocai s, 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 Test es c onf i r mat r i os
O sinal apresentado na seo anterior confirmatrio. Se ele for observado
nenhum teste adicional precisa ser realizado.
L e i a m a i s
s o b r e o
s e r v i o d e
c o r r e i o
e l e t r n i c o
n o
a p n d i c e
1 1
Pr ocedi ment o
12. 7
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
205
7.9.5 Sugest es de t r at ament o
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 sendmai l e qmai l .
No sendmai l verses 8.8 e superiores, adicione o nome ou o IP das
mquinas que podem ser clientes do servidor SMTP no arquivo /etc/mail/relay-
domains. 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 sendmai l . Apenas as verses 8.7 e superiores aceitam o
sinal HUP.
# ki l l al l HUP sendmai l
Ou, para os sistemas que no suportam o comando ki l l al l :
# ki l l - HUP <nmer o do pr ocesso do sendmai l
53
>
O qmai l s aceita mensagens destinadas a mquinas listadas no arquivo
/var/qmail/control/rcpthosts. Quando terminamos de instalar o qmai l , este
arquivo contm o nome da mquina local. Se o arquivo rcpthosts no existir, o
qmai l vai passar a ser repasse aberto. Para ser mais seletivo realize os passos a
seguir:
1. voc precisar usar um TCP wrapper (i net d ou t cpser ver , por exemplo).
Se voc usa o i net d, a primeira ao modificar a linha correspondente ao
servio SMTP (iniciada com smtp) no arquivo de configurao do i net d
(/etc/inetd.conf). A nova linha deve ser a seguinte:
smt p st r eamt cp nowai t qmai l d / usr / l ocal / bi n/ t cpd
/ var / qmai l / bi n/ t cp- env / var / qmai l / bi n/ qmai l - smt pd
A linha foi quebrada acima em duas, mas no arquivo inetd.conf tudo isso deve
ficar em apenas uma linha.
2. reinicie o servio i net d:
# ki l l HUP <nmer o do pr ocesso i net d>
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 | gr ep sendmai l .
C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
206
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 t cpser ver 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 Refernci as
7.10.1 Li vr os
[DNS&BIND] Albitz, P. Liu, C. DNS and BIND. Quarta Edio.
OReilly. Abril, 2001.
7.10.2 Rec ur sos onl i ne (I nt er net )
[ANTISPAM-BR] Como denunciar e reclamar?
http://www.antispam.org.br/denunciar.html
[CONTROLLED-
SMTP-RELAYING]
Allowing controlled SMTP relaying in Sendmail 8.9.
http://www.sendmail.org/tips/relaying.html.
[MAPS] Site do Mail Abuse Prevention System (MAPS).
http://www.mail-abuse.org/
[MAPS-RSS] Site do MAPSSM Relay Spam Stopper (RSS).

C A P T U L O 7 P R O B L E M A S D E N V E L D E A P L I C A O
207
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-manual-
html/misc/FAQ.html
7.10.3 RFCs
[RFC1035] Mockapetris, V. Domain names - implementation and
specification. Novembro, 1987.
[RFC1912] Barr, D. Common DNS Operational and Configuration Errors.
Fevereiro, 1996.
[RFC2181] Bush, R., Elz, R. Clarifications to the DNS Specification. Julho,
1997.
[RFC2308] Andrews, M. Negative Caching of DNS Queries. Maro, 1998.

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


208
8 Os ndices Invert idos
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 ndi ce i nver t i do de si nt omas
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.
Si nt oma: 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

Si nt oma: Falta de conectividade
54


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.
Capt ulo
8
C A P T U L O 8 N D I C E S I N V E R T I D O S
209
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
Si nt oma: Conectividade intermitente
Conector defeituoso ou mal instalado
Tempo de envelhecimento de tabelas de endereos inadequado
Endereo IP de hospedeiro incorreto
Servidor DHCP mal configurado
Si nt oma: Falta de conectividade com algumas mquinas da rede local
O TTL default de uma zona no est configurado
Si nt oma: 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
Si nt oma: Precisa esperar algum tempo para que a conexo com o servidor seja
C A P T U L O 8 N D I C E S I N V E R T I D O S
210
estabelecida
Descasamento de registros A e PTR em arquivos de zonas DNS
Si nt oma: No consegue enviar e-mails
Servidor de correio eletrnico com repasse totalmente fechado
Si nt oma: 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 ndi ce i nver t i do de si nt omas e si nai s
Na Tabela 8-2 apresentamos o ndice invertido de sintomas e sinais de
problemas.
Si nt oma: Rede lenta
Si nai s: 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
Si nt oma: Falta de conectividade
Si nai s: 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
Si nt oma: Conectividade intermitente
Si nai s: Taxa elevada de erros
Interferncia o cabo
Conector defeituoso ou mal instalado
Si nt oma: Rede lenta
Si nai s:
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
Si nt oma: Falta de conectividade
Si nai s:
Taxa elevada de erros
C A P T U L O 8 N D I C E S I N V E R T I D O S
211
Taxa elevada de colises
Placa de rede ou porta de equipamento de interconexo defeituosas
Conector defeituoso ou mal instalado
Si nt oma: Rede lenta
Si nai s:
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
Si nt oma: Rede lenta ou falta de conectividade
Si nai s:
Equipamento no operacional
Interfaces no operacionais
Utilizao de memria elevada
Utilizao de CPU elevada
Trfego de broadcast/multicast elevado
Equipamento de interconexo defeituoso
Si nt oma: Rede lenta
Si nai s:
Taxa de colises elevada
Utilizao de enlaces elevada
Saturao de banda em segmentos Ethernet compartilhados
Si nt oma: Rede lenta ou falta de conectividade
Si nai s:
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
Si nt oma: Falta de conectividade, rede lenta ou conectividade intermitente
Si nai s:
Nmero elevado de erros
Taxa elevada de colises
NEXT e atenuao
Conector defeituoso ou mal instalado
Si nt oma: Rede lenta
Si nai s:
Taxa elevada de colises
Ocorrncia de colises tardias
Atenuao
Violao de regras de cabeamento Ethernet
Si nt oma: Rede lenta
C A P T U L O 8 N D I C E S I N V E R T I D O S
212
Si nai s:
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
Si nt oma: Falta de conectividade
Si nai s:
Inexistncia de trfego
Estado administrativo down
Interface desabilitada
Si nt oma: Falta de conectividade
Si nai s:
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
Si nt oma: Rede lenta ou falta de conectividade
Si nai s:
Trfego de broadcast elevado
Aumento da utilizao de enlaces
Utilizao elevada de CPU
Saturao de recursos devido a excesso de quadros de difuso
Si nt oma: Rede lenta ou conectividade intermitente
Si nai s:
Ocorrncia freqente de enchentes
Aumento na utilizao de enlaces
Tempo de envelhecimento de tabelas de endereos inadequado
Si nt oma: Rede lenta (tempo pequeno) ou falta de conectividade temporria (tempo
grande)
Si nai s:
Aumento da utilizao de enlaces
Trfego de difuso ARP elevado
Validade da cache ARP inadequada
Si nt oma: Conectividade intermitente
Si nai s: Duas respostas mesma requisio ARP
Endereo IP de hospedeiro incorreto
Si nt oma: Falta de conectividade
Si nai s: Quadro de difuso enviados por mquinas de outra sub-rede
Endereo IP de hospedeiro incorreto
Servidor DHCP mal configurado
Si nt oma: Falta de conectividade total ou para algumas mquinas da rede local
C A P T U L O 8 N D I C E S I N V E R T I D O S
213
Si nai s:
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
Si nt oma: Conectividade apenas com mquinas da rede local
Si nai s: Trfego de mensagens ICMP de redirecionamento
Tabela de rotas de hospedeiros incorretas
Hospedeiro com mscara de rede incorreta
Si nt oma: Falta de conectividade ou conectividade intermitente
Si nai s:
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
Si nt oma: Falta de conectividade
Si nai s:
Trfego de mensagens ICMP de TTL excedido;
Trfego de mensagens ICMP de destino inalcanvel;
Crescimento rpido de ipOutNoRoutes.
Rotas estticas mal configuradas
Si nt oma: Falta de conectividade ou indisponibilidade de alguns servios
Si nai s:
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
Si nt oma: Rede lenta, indisponibilidade de alguns servios ou falta de conectividade
Si nai s:
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
C A P T U L O 8 N D I C E S I N V E R T I D O S
214
Si nt oma: Falta de conectividade ou indisponibilidade de alguns servios
Si nai s:
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
Si nt oma: Falta de conectividade
Si nai s: 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)
Si nt oma: Rede lenta
Si nai s: Utilizao elevada de enlaces.
Trfego RIP saturando largura de banda
Saturao de banda em segmentos Ethernet compartilhados
Si nt oma: Falta de conectividade
Si nai s:
Trfego ICMP de porta inalcanvel;
Existe conectividade via IP, mas no via nome DNS de mquina.
O servio de nomes no est habilitado
Si nt oma: Indisponibilidade de alguns servios
Si nai s: 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
Si nt oma: Indisponibilidade de alguns servios
Si nai s:
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
Si nt oma: Falta de conectividade apenas para a rede local ou completa
Si nai s:
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
Si nt oma: Rede lenta
Si nai s:
Existe conectividade via IP, mas no via nome DNS de mquina;
Servidores primrio e secundrios retornam respostas diferentes mesma
consulta.
C A P T U L O 8 N D I C E S I N V E R T I D O S
215
TTL e outros campos do registro SOA com valores inadequados
Si nt oma: Falta de conectividade
Si nai s:
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
Si nt oma: Alguns servios no funcionam ou precisam esperar muito tempo para que a
conexo seja estabelecida
Si nai s: Resoluo direta no casa com resoluo reversa.
Descasamento de registros A e PTR em arquivos de zonas DNS
Si nt oma: Indisponibilidade de alguns servios
Si nai s:
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
Si nt oma: No conseguem enviar mensagens para certos destinos
Si nt oma: Administrador recebe reclamaes
Si nai s: Servidor aceita fazer entrega sempre.
Servidor de correio eletrnico com repasse totalmente aberto
Si nt oma: No conseguem enviar mensagens
Si nai s: 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.





Part e II
Cat logo de problemas




217
9 Procediment os 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 pi ng
e t r acer out e. Estes procedimentos so, na realidade, procedimentos de
apoio aos demais procedimentos.
9.1 Ut i l i zando um anal i sador de prot ocol os
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 Conec t ando o anal i sador de pr ot oc ol os
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 comutador
55
. 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.
Capt ulo
9
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
218
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
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
219
esto conectadas
56
. 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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
220
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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
221

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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
222
9.1.2 Cr i ando e sel ec i onando f i l t r os de c apt ur a
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

C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
223
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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
224
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.

C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
225

Figura 9-11: Definindo o protocolo cujos dados sero capturados.
9.1.3 Capt ur ando e dec odi f i c ando quadr os
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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
226

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 Out r as f un es i nt er essant es do Sni f f er
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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
227

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;
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
228
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
J abbers/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 Sobr e anal i sador es de pr ot oc ol os
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
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
229
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 i nt erface de l i nha de comando de um
equi pament o de i nt erconexo
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 t el net 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 Ac esso at r avs da por t a c onsol e
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/TIA-
232 (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 Ter mi nal e pcpl us.
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 Ac esso at r avs de sesso de t el net
Para ser possvel acessar a interface de linha de comando de um equipamento
atravs de uma sesso de t el net , necessrio que este equipamento esteja
configurado com um endereo IP.
Abra uma sesso de t el net 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
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
230
repetidores. Usando t el net , 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 t el net com o equipamento :
# t el net I P_do_equi pament o
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 Sobr e l ogi ns 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):
r ot eador > enabl e
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 Di c as ger ai s 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
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
231
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:
r ot eador # t er mi nal speed <nova vel oci dade>
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:
r ot eador > ?
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:
r ot eador > 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:
r ot eador > show i nt er f aces
Ou
r ot eador > sh i nt er
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.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
232
9.3 Local i zando probl emas com auxl i o t racerout e
Neste procedimento mostramos como usar t r acer out e para localizar
problemas em uma rede.
9.3.1 Desc r i o e Di c as
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 t r acer out e 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 t r ac er out e
Nesta seo veremos como usar t r acer out e 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
t r acer out e 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 t r acer out e para a
mquina de um usurio. Por exemplo:
# t r acer out e n 10. 16. 254. 1
1 10. 16. 75. 171 2 ms 1 ms 1 ms
2 10. 16. 13. 97 4 ms 5 ms 4 ms

C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
233
3 10. 16. 24. 254 7 ms 8 ms 6 ms
4 10. 16. 254. 33 1936. 342 ms * *
5 10. 16. 254. 1 1959. 462 ms * 1939. 310 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 t r acer out e 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 t r acer out e 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 t r acer out e 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 t r acer out e 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 t r acer out e 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 t r acer out e indicam ausncia de rotas. Se voc vir
estes caracteres aps executar o t r acer out e 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
t r acer out e).
No Windows o comando equivalente ao t r acer out e o t r acer t . 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
t r acer out e, voc j sabe que realmente existe um problema, e que ele est
localizado entre os equipamentos apresentados nas linhas 3 e 4.
C A P T U L O 9 P R O C E D I M E N T O S G E R A I S
234
9.4 Refernci as
9.4.1 Rec ur sos onl i ne (I nt er net )
[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


235
10 Procediment os referenciados nos
problemas de nvel fsico e enlace
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 Obt endo t axa de er ros
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 Desc r i o e di c as
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 [CISCO-
PERF-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:
nmero de quadros recebidos com erro durante T
x 100 Taxa de erros de entrada (%) =
nmero total de quadros recebidos durante T
Equao 10.1-1
Capt ulo
10
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 E N L A C E )
236
nmero de quadros no transmitidos devido a erros durante T
x 100 Taxa de erros de sada (%) =
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-like
57
, 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 de
CRC
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 10
9
bits transmitidos
58
[GUIA-ETHERNET].
Enlaces ticos apresentam transmisso ainda mais precisa,
aceitando um mximo de 1 bit com erro a cada 10
12
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 10
12
bits
transmitidos.
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 E N L A C E )
237
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
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.
Erros
internos da
camada
MAC
Um quadro no pde ser recebido devido a um erro interno da
camada MAC. O correto que este tipo de erro no ocorra.
Tabela 10-1: Erros Ethernet de entrada especficos.
Tipo de erro Descrio
Colises tardias 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).
Colises excessivas 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.
Erros internos da
camada MAC
Quadros que no foram transmitidos devido a erros
internos da camada MAC. A presena constante destes
erros sempre indicativo de problema na interface.
Erros de deteco
de portadora
A deteco de portadora falhou ao tentar transmitir um
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
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 E N L A C E )
238
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 v
m
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:
(vm x 3600 )
Quantidade mxima de erros em uma hora =
10
9

Equao 10.1-3
10.1.2 Usando uma est a o de ger nc i a 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
x 100
in (%)
ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + ifInErrors
Equao 10.1-4
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;
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 E N L A C E )
239
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 t
0

uma coleta de dados SNMP foi realizada. Neste momento, ifInErrors
0
,
ifInUcastPkts
0
, ifInBroadcastPkts
0
e ifInMulticastPkts
0
foram recuperados:
ifInErrors
0
= 1
ifInUcastPkts
0
= 2981631
ifInBroadcastPkts
0
= 2091273
ifInMulticastOkts
0
= 1012354
Aps 5 minutos, em t
1
, uma nova coleta foi realizada, recuperando-se novos
valores para os contadores ifInErrors, ifInUcastPkts e ifInBroadcastPkts e
ifInMulticastPkts.
IfInErrors
1
= 2
IfInUcastPkts
1
= 4012693
IfInBroadcastPkts
1
= 2917823
ifInMulticastOkts
0
= 1519841
Nestes 5 minutos, a taxa de erros de entrada (
in
) da interface em questo :
(ifInErrors1 ifInErrors0) x 100

in% =
ifInUcastPkts1 ifInUcastPkts0 + ifInBroadcastPkts1 ifInBroadcastPkts0 + ifInMulticastPkts1 ifInMulticastPkts0 + ifInErrors1 ifInErrors0

2 1
x 100
in% =
(4012693 - 2981631) + (2917823 - 2091273) + (1519841 - 1012354) + (2-1)
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
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 E N L A C E )
240
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
x 100
in (%) =
ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts

Equao 10.1-5
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
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 E N L A C E )
241
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 ALI NHAMENTO
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.
dot3StatsAlignmentErrors
x 100 Taxa de Erros de Alinhamento (%) =
ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + ifInErrors
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
x 100 Taxa de Erros de CRC e alinhamento (%) =
etherStatsPkts
Equao 10.1-8
Onde:
etherStatsCRCAlignErrors a quantidade de quadros com erro de
CRC ou erro alinhamento recebido pela interface em um determinado
intervalo de tempo.
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 E N L A C E )
242
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 I NTERNOS 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 COLI SES EXCESSI VAS
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
x 100 Taxa de colises excessivas (%) =
ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts
Equao 10.1-10
Onde:
dot3StatsExcessiveCollisions a quantidade de colises excessivas
ocorridas em um determinado intervalo de tempo.
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 E N L A C E )
243
10.1.2.5 TAXA DE ERROS I NTERNOS DE TRANSMI SSO 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.
dot3StatsInternalMacTransmitErrors
x 100 Taxa de Erros Internos de transmisso (%) =
ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts
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 anal i sador de pr ot oc ol os
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).
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 E N L A C E )
244
10.1.4 Usando i nt er f ac e de l i nha de c omando
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:
r ot eador # show i nt er f ace <t i po da i nt er f ace> <nmer o da
i nt er f ace>
Para analisar estatsticas da porta Fast Ethernet 1/0/0 de um roteador Cisco use
o comando a seguir:
r ot eador # show i nt er f ace Fast Et her net 1/ 0/ 0
1. Fast Et her net 1/ 0/ 0 i s up, l i ne pr ot ocol i s up
2. Har dwar e i s cyBus Fast Et her net I nt er f ace, addr ess i s
0002. 1743. 9820 ( bi a 0002. 1743. 9820)
3. I nt er net addr ess i s 208. 145. 167. 233/ 24
4. MTU 1500 byt es, BW100000 Kbi t , DLY 100 usec, r el y 255/ 255, l oad
8/ 255
5. Encapsul at i on ARPA, l oopback not set
6. Keepal i ve set ( 10 sec)
7. Hal f - dupl ex, 100Mb/ s, 100BaseTX/ FX
8. ARP t ype: ARPA, ARP Ti meout 04: 00: 00
9. Last i nput 00: 00: 00, out put 00: 00: 00, out put hang never
10. Last cl ear i ng of "show i nt er f ace" count er s never
11. Queuei ng st r at egy: f i f o
12. Out put queue 0/ 40, 0 dr ops; i nput queue 0/ 75, 0 dr ops
13. 5 mi nut e i nput r at e 572000 bi t s/ sec, 462 packet s/ sec
14. 5 mi nut e out put r at e 3527000 bi t s/ sec, 563 packet s/ sec
15. 484455791 packet s i nput , 2990640235 byt es, 0 no buf f er
16. Recei ved 344792 br oadcast s, 0 r unt s, 0 giants, 0 t hr ot t l es
17. 1 input errors, 1 CRC, 0 f r ame, 0 over r un, 0 i gnor ed
18. 0 wat chdog, 0 mul t i cast
19. 0 i nput packet s wi t h dr i bbl e condi t i on det ect ed
20. 520096751 packet s out put , 3410608492 byt es, 0 under r uns
21. 1 output errors, 5373084 col l i si ons, 3 i nt er f ace r eset s
22. 0 babbl es, 1 late collision, 0 def er r ed.
23. 0 l ost car r i er , 0 no car r i er
24. 0 out put buf f er f ai l ur es, 0 out put buf f er s swapped out
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.
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 E N L A C E )
245
Em comutadores Cisco use o comando:
consol e> show por t [ [ mdul o] / por t a]
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:
Consol e> show por t 1/ 1

Por t Name St at us Vl an Dupl ex Speed Type
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 connect 1 aut o aut o 10/ 100BaseTX

( )

Por t Align-Err FCS-Err Xmit-Err Rcv-Err Under Si ze
- - - - - ---------- ---------- ---------- ---------- - - - - - - - - -
1/ 1 0 1 1 1 0

Por t Si ngl e- Col Mul t i - Col l Late-Coll Excess-Col Carri-Sen Runt s Giants
- - - - - - - - - - - - - - - - - - - - - - - - ---------- ---------- --------- - - - - - - -------
1/ 1 0 0 0 1 0 0 0

Last - Ti me- Cl ear ed
- - - - - - - - - - - - - - - - - - - - - - - - - -
Wed J an 20 2002, 13: 03: 12
O comando a seguir oferece contadores de erros para todas as portas do
comutador:
comut ador > show por t count er s
Infelizmente este comando no apresenta contadores de quadros de entrada e
sada, mas eles podem ser obtidos atravs do comando a seguir:
comut ador > show por t mac [ [ mdul o] / por t a]
Alm deste comando, alguns comutadores Cisco oferecem o comando show
count er s, 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 i f c onf i g e net st at
Nesta seco apresentamos ferramentas de gerncia que oferecem informaes
sobre erros em interfaces de hospedeiros.
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 E N L A C E )
246
O comando i f conf i g 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 (t
0
e t
1
, 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 i f conf i g. Em negrito esto as
informaes que voc ir utilizar para o clculo das taxas de erros de entrada e
sada.
[ mar i a@ser ver ~] $ i f conf i g - a
et h0 Li nk encap: Et her net HWaddr 00: 04: AC: 4C: 98: DF
i net addr : 102. 168. 1. 1 Bcast : 192. 168. 1. 255 Mask: 255. 255. 255. 0
UP BROADCAST RUNNI NG MULTI CAST MTU: 1500 Met r i c: 1
RX packets:10626336 errors:3 dr opped: 0 over r uns: 0 f r ame: 0
TX packets:9429316 errors:1 dr opped: 0 over r uns: 0 car r i er : 0
col l i si ons: 0 t xqueuel en: 100
RX byt es: 2471067525 ( 2356. 5 Mb) TX byt es: 1160820381 ( 1107. 0 Mb)
I nt er r upt : 15 Base addr ess: 0x2180

l o Li nk encap: Local Loopback
i net addr : 127. 0. 0. 1 Mask: 255. 0. 0. 0
UP LOOPBACK RUNNI NG MTU: 16436 Met r i c: 1
RX packet s: 926558 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 0
TX packet s: 926558 er r or s: 0 dr opped: 0 over r uns: 0 car r i er : 0
col l i si ons: 0 t xqueuel en: 0
RX byt es: 129180878 ( 123. 1 Mb) TX byt es: 129180878 ( 123. 1 Mb)
Se preferir pode utilizar tambm o seguinte comando, que oferece praticamente
as mesmas informaes do comando anterior:
[ mar i a@ser ver ~] $ net st at - i
Ker nel I nt er f ace t abl e
I f ace MTU Met RX-OK RX-ERR RX- DRP RX- OVR TX-OK TX-ERR TX- DRP TX- OVR Fl g
et h0 1500 1062665 3 0 0 942960 1 0 0 BMRU
l o 16436 0 926584 0 0 0 926584 0 0 LRU
Em mquinas Windows use o comando net st at ne para recuperar
quantidade de quadros transmitidos e recebidos e erros detectados:
C: \ WI NDOWS>net st at - ne
Est at st i cas de i nt er f ace
Recebi do Envi ado
Byt es 242119 30360
Pacot es uni cast 516 451
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 E N L A C E )
247
Pacot es no uni cast 24 32
Descar t ados 1 1
Er r os 2 0
Pr ot . Desconheci dos 23
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 Obt endo a t axa de col i ses
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 Desc r i o e Di c as
Colises so ocorrncias normais em meios Ethernet compartilhados (half
duplex
59
). 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&FAULT-
CISCO] 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.
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 E N L A C E )
248
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 Percentual de pacotes que colidem
0 19% 1%
20 49% 5%
> 50% 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.
Quantidade de quadros que colidiram durante T
Taxa de colises (%) = x 100
Quantidade de quadros transmitidos durante T
Equao 10.2-1
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.
Quantidade de quadros que colidiram durante T
x 100 Taxa de colises (%) =
Quantidade de quadros transmitidos e recebidos durante T
Equao 10.2-2
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 Est a o de Ger nc i a 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:
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 E N L A C E )
249
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:
dot3StatsSingleCollisionFrames + dot3StatsMultipleCollisionFrames
x100 Taxa de colises (%) =
ifOutUcastPkts + ifOutBroadcastPkts + ifOutMulticastPkts
Equao 10.2-3
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 t
0
e t
1
, ento:
dot3StatsSingleCollisionFrames = dot3StatsSingleCollisionFrames
1
dot3StatsSingleCollisionFrames
0
.
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.
etherStatCollisions
x 100 Taxa de colises (%) =
ifOutUcastPkts + ifOutBroadcastPkts + ifOutMulticastPkts
Equao 10.2-4
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
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 E N L A C E )
250
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.
etherStatsCollisions
x 100 Taxa de colises (%) =
etherStatsPkts + etherStatsCollision
Equao 10.2-5
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 hostTopNOutPkts (2)
hostTopNTimeRemaining 900 segundos (15 minutos)
hostTopNRequestedSize 10
Tabela 10-4: Configurao de hostTopN para obter 10 maiores transmissores em 15
minutos.
10.2.3 Usando um anal i sador de pr ot oc ol os
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
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 E N L A C E )
251
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.
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 E N L A C E )
252
10.2.4 Usando uma i nt er f ac e de l i nha de c omando
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:
r ot eador # show i nt er f aces <t i po da i nt er f ace> <nmer o da i nt er f ace>
Este comando apresenta estatsticas da interface escolhida. Veja o resultado
deste comando em um roteador Cisco 7507:
r ot eador >show i nt er f ast 1/ 0/ 0
Fast Et her net 1/ 0/ 0 i s up, l i ne pr ot ocol i s up
Har dwar e i s cyBus Fast Et her net I nt er f ace, addr ess i s 0002. 1743. 9820 ( bi a
0002. 1743. 9820)
I nt er net addr ess i s 200. 129. 64. 139/ 24
MTU 1500 byt es, BW100000 Kbi t , DLY 100 usec, r el y 255/ 255, l oad 12/ 255
Encapsul at i on ARPA, l oopback not set
Keepal i ve set ( 10 sec)
Hal f - dupl ex, 100Mb/ s, 100BaseTX/ FX
ARP t ype: ARPA, ARP Ti meout 04: 00: 00
Last i nput 00: 00: 00, out put 00: 00: 00, out put hang never
Last cl ear i ng of "show i nt er f ace" count er s never
Queuei ng st r at egy: f i f o
Out put queue 0/ 40, 0 dr ops; i nput queue 0/ 75, 0 dr ops
5 mi nut e i nput r at e 3064000 bi t s/ sec, 931 packet s/ sec
5 mi nut e out put r at e 5078000 bi t s/ sec, 1002 packet s/ sec
245369996 packet s i nput , 3191315201 byt es, 0 no buf f er
Recei ved 54142 br oadcast s, 0 r unt s, 0 gi ant s, 0 t hr ot t l es
0 i nput er r or s, 0 CRC, 0 f r ame, 0 over r un, 0 i gnor ed
0 wat chdog, 0 mul t i cast
0 i nput packet s wi t h dr i bbl e condi t i on det ect ed
262296267 packets output, 653636588 byt es, 0 under r uns
1 out put er r or s, 12453993 collisions, 4 i nt er f ace r eset s
0 babbl es, 0 l at e col l i si on, 0 def er r ed
0 l ost car r i er , 0 no car r i er
0 out put buf f er f ai l ur es, 0 out put buf f er s 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:
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 E N L A C E )
253
consol e> show por t [ mdul o[ / por t a] ]
Para recuperar valores de contadores de quadros transmitidos e recebidos
execute o seguinte comando:
consol e> show mac [ mdul o[ / por t a] ]
Alm destes, o comando abaixo tambm pode ser utilizado.
consol e> show count er s
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 i f c onf i g
Esta seo apresenta como obter os dados necessrios para o clculo da taxa de
colises a partir de uma estao Linux.
O comando i f conf i g pode ser utilizado para recuperar contadores de
quadros transmitidos e colises. Recupere estes contadores com o comando:
# i f conf i g a <i nt er f ace>
Veja um exemplo da execuo deste comando:
# i f conf i g a et h0
et h0 Li nk encap: Et her net HWaddr 00: 60: 94: 63: 6E: 3A
i net addr : 10. 10. 10. 1 Bcast : 10. 10. 10. 255 Mask: 255. 255. 255. 0
UP BROADCAST RUNNI NG MULTI CAST MTU: 1500 Met r i c: 1
RX packet s: 658685 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 3
TX packets:555222 er r or s: 0 dr opped: 0 over r uns: 19 car r i er : 1
collisions:44644 t xqueuel en: 100
I nt er r upt : 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 Veri fi cando ocor rnci a de col i ses t ar di as
Neste procedimento descrevemos como verificar se colises tardias esto
ocorrendo na rede.
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 E N L A C E )
254
10.3.1 Desc r i o e di c as
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 est a o de ger nc i a 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: DeltaValue
Intervalo: 600 segundos (10 minutos)
Limiar crescente: 1
Limiar decrescente: 0
Tabela 10-5: Dados para configurao de alarme para ocorrncia de colises tardias.
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 E N L A C E )
255
O alarme deve gerar uma notificao (trap) para a estao de gerncia apenas
quando o limiar crescente for atingido.
10.3.3 Usando uma i nt er f ac e de l i nha de c omando
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:
r ot eador # show i nt er f ace <t i po> <nmer o>
Por exemplo:
r ot eador # show i nt er Fast Et her net 1/ 0/ 0
Fast Et her net 1/ 0/ 0 i s up, l i ne pr ot ocol i s up
Har dwar e i s cyBus Fast Et her net I nt er f ace, addr ess i s 0003. 2853. 0931 ( bi a
0003. 2853. 0931)
I nt er net addr ess i s 192. 168. 4. 1/ 24
MTU 1500 byt es, BW100000 Kbi t , DLY 100 usec, r el y 255/ 255, l oad 10/ 255
Encapsul at i on ARPA, l oopback not set
Keepal i ve set ( 10 sec)
Half-duplex, 100Mb/ s, 100BaseTX/ FX
ARP t ype: ARPA, ARP Ti meout 04: 00: 00
Last i nput 00: 00: 00, out put 00: 00: 00, out put hang never
Last cl ear i ng of "show i nt er f ace" count er s never
Queuei ng st r at egy: f i f o
Out put queue 0/ 40, 98 dr ops; i nput queue 0/ 75, 0 dr ops
5 mi nut e i nput r at e 901000 bi t s/ sec, 566 packet s/ sec
5 mi nut e out put r at e 4104000 bi t s/ sec, 678 packet s/ sec
2159137620 packet s i nput , 346328816 byt es, 0 no buf f er
Recei ved 1026648 br oadcast s, 0 r unt s, 0 gi ant s, 0 t hr ot t l es
0 i nput er r or s, 0 CRC, 4 f r ame, 0 over r un, 0 i gnor ed
0 wat chdog, 0 mul t i cast
0 i nput packet s wi t h dr i bbl e condi t i on det ect ed
1784610 packet s out put , 142194201 byt es, 0 under r uns
1664 out put er r or s, 48521009 col l i si ons, 11 i nt er f ace r eset s
0 babbl es, 1 late collision, 0 def er r ed
1663 l ost car r i er , 0 no car r i er
0 out put buf f er f ai l ur es, 0 out put buf f er s swapped out 0
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
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 E N L A C E )
256
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:
consol e> show por t [ mdul o [ / por t a] ]
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:
Consol e> show por t 1/ 1

Por t Name St at us Vl an Dupl ex Speed Type
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 connect 1 aut o aut o 10/ 100BaseTX

()

Por t Si ngl e- Col Mul t i - Col l Late-Coll Excess- Col Car r i - Sen Runt s Gi ant s
- - - - - - - - - - - - - - - - - - - - - - - - ---------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 0 0 1 0 0 0 0

Last - Ti me- Cl ear ed
- - - - - - - - - - - - - - - - - - - - - - - - - -
Wed J an 20 2002, 13: 03: 12
10.4 Obt endo est ado operaci onal de equi pament os
Neste procedimento sero apresentadas algumas formas de se obter o estado
operacional de um equipamento.
10.4.1 Desc r i o e di c as
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 est a o de ger nc i a 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
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 E N L A C E )
257
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 pi ng e t r ac er out e
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
pi ng. A partir de uma estao qualquer, direcione pi ng para o equipamento
cujo estado operacional voc deseja obter:
mar i a@pc10: ~$ pi ng 192. 168. 1. 1
Se o dispositivo no responder ao pi ng 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 t r acer out e. Em mquinas com sistema
operacional Windows esta ferramenta se chama t r acer t . Direcione
t r acer out e ao equipamento cujo estado operacional voc pretende obter:
mar i a@pc10: ~$ t r acer out e - n 192. 168. 1. 1
C: \ WI NNT> t r acer t d 192. 168. 1. 1
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 E N L A C E )
258
Os parmetros n e d passados ao t r acer out e e t r acer t 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 Obt endo est ado operaci onal de i nt erfaces
Neste procedimento descreveremos como recuperar o estado operacional de
interfaces de rede.
10.5.1 Desc r i o e Di c as
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 est a o de ger nc i a 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;
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 E N L A C E )
259
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 i nt er f ac e de l i nha de c omando
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.
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 E N L A C E )
260
Na maioria dos roteadores Cisco, execute o seguinte comando:
show i nt er f aces [ t i po da i nt er f ace] [ nmer o da i nt er f ace]
A primeira linha da resposta a este comando informa o estado da interface. Veja
um exemplo:
r ot eador # show i nt er f aces Fast Et her net 1/ 1/ 0
Fast Et her net 0 i s down, l i ne pr ot ocol i s 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:
Fast Et her net 1/ 1/ 0 i s admi ni st r at i vel y down, l i ne pr ot ocol i s down
Em comutadores Cisco execute o comando a seguir:
show por t st at us [ mdul o[ / por t a] ]
Este comando informa o estado das portas de um comutador. Veja um
exemplo de sua execuo:
Consol e> show por t st at us

Por t Name St at us Vl an Dupl ex Speed Type
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 connect ed 2 hal f 100 100BaseTX
1/ 2 f aul t y hal f 100 100BaseTX
1/ 3 i nact i ve 4 hal f 100 100BaseTX
1/ 4 di sabl ed hal f 100 100BaseTX
O resultado do comando show por t st at us 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 out r as f er r ament as de ger nc i a
Em mquinas Unix-like voc pode usar o comando i f conf i g para verificar o
estado de interfaces. Veja um exemplo do resultado do comando i f conf i g
abaixo:
r oot @ser vi dor # i f conf i g a et h0
et h0 Li nk encap: Et her net HWaddr 00: 60: 94: 63: 6E: 3A
i net addr : 10. 10. 10. 1 Bcast : 10. 10. 10. 255 Mask: 255. 255. 255. 0
UP BROADCAST RUNNING MULTI CAST MTU: 1500 Met r i c: 1
RX packet s: 658685 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 3
TX packet s: 555222 er r or s: 0 dr opped: 0 over r uns: 19 car r i er : 1
col l i si ons: 44644 t xqueuel en: 100
I nt er r upt : 5
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 E N L A C E )
261
Analisando o resultado do comando i f conf i g, 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 i f conf i g
para uma interface administrativamente ativa e em funcionamento deve sempre
apresentar as palavras UP e RUNNING. O i f conf i g no informa
quando o equipamento ligado interface est desligado ou com defeito. Mesmo
que no seja possvel a comunicao com o equipamento remoto, o i f conf i g
informar que a interface est up e running.
O i f conf i g 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 Obt endo ut i l i zao de CPU
Neste procedimento apresentaremos como obter a utilizao mdia de CPU em
roteadores, comutadores e hospedeiros.
10.6.1 Desc r i o e di c as
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 si nal de advert nci a para que voc fique atento e
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 E N L A C E )
262
j comece a analisar o porqu desta taxa. 90% de ut i l i zao mdi a de CPU
al armant e. 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 est a o de ger nc i a 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 CISCO-PROCESS
busyPer cpmCPUTotal5sec A taxa de utilizao mdia da
CPU nos ltimos 5
segundos.
avgBusy1 cpmCPUTotal1min A taxa de utilizao mdia da
CPU no ltimo minuto.
avgBusy5 cpmCPUTotal5min A taxa de utilizao mdia da
CPU nos ltimos 5 minutos.
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
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 E N L A C E )
263
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 i nt er f ac e de l i nha de c omando
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 ut i l i zat i on f or f i ve seconds: 1. 0%; one mi nut e: 1. 0%; f i ve
mi nut es: 1. %

PI D Runt i me( ms) I nvoked uSecs 5Sec 1Mi n 5mi n TTY Pr ocess
0 0 0 0 99. 1% 99. 0% 99. 0% 0 i dl e
1 1 36 1000 0. 0 % 0. 0 % 0. 0 % 0 Fl ash MI B Updat
2 1342 2846 46000 0. 0 % 0. 0 % 0. 0 % 0 SynDi ags
3 730172 4440594 40000 0. 0 % 0. 0 % 0. 0 % 0 SynConf i g
4 33752 424120 1000 0. 0 % 0. 0 % 0. 0 % 0 St at uspol l
5 7413 44916 1000 0. 0 % 0. 0 % 0. 0 % 0 SWPol l 64bCnt
6 9568 1588983 1000 0. 0 % 0. 0 % 0. 0 % 0 SL_TASK
7 746 636118 10500 0. 0 % 0. 0 % 0. 0 % 0 Redundant Task
Em roteadores Cisco use o comando show pr ocesses cpu como
exemplificado a seguir:
r ot eador 1# show pr ocesses cpu
CPU ut i l i zat i on f or f i ve seconds: 3%/ 3%; one mi nut e: 3%; f i ve mi nut es: 2%
PI D Runt i me( ms) I nvoked USecs 5Sec 1Mi n 5Mi n TTY Pr ocess
1 6040 1602152 3 1. 30% 1. 20% 0. 95% 0 Load Met er
2 63184 2449411 25 0. 95% 1. 05% 0. 85% 0 Load Met er
3 4840624 813473 5950 0. 65% 0. 60% 0. 15% 0 Check heaps
4 0 1 0 0. 10% 0. 15% 0. 05% 0 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.
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 E N L A C E )
264
10.6.4 Usando t op e vmst at
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 t op e o vmst at .
O comando t op 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 t op segue:
maria@server:~$ top d 300
8: 42pm up 140 days, 4: 35, 2 user s, l oad aver age: 3. 31, 3. 45, 3. 66
68 pr ocesses: 59 sl eepi ng, 9 r unni ng, 0 zombi e, 0 st opped
CPU st at es: 97. 7%user , 2. 2%syst em, 0. 0%ni ce, 0. 0%i dl e
Mem: 255772K av, 249484K used, 6288K f r ee, 0K shr d, 2360K buf f
Swap: 530136K av, 3828K used, 526308K f r ee 36616K cached

PI D USER PRI NI SI ZE RSS SHARE STAT LI B %CPU %MEM TI ME COMMAND
24462 f t p 16 0 260 16 4 R 0 38. 2 00. 0 8934m i n. f t pd
20259 r oot 10 0 19044 18M 1160 S 0 34. 4 7. 4 2: 33 net mngr
22234 r oot 20 0 10916 10M 1156 R 0 13. 5 4. 2 0: 40 net mngr
12200 r oot 9 0 22464 20M 780 R 0 0. 2 8. 2 46: 58 named
1 r oot 8 0 72 64 44 S 0 0. 0 0. 0 0: 04 i ni t
( )
No exemplo acima percebe-se que a CPU est com mais de 85% de utilizao
mdia nos ltimos 300 segundos. As aplicaes i n. f t pd e net mngr , 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 t op so atualizadas
60
. 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 t op. 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 vmst at :
mar i a@ser ver : ~$ vmst at 300
pr ocs memor y swap i o syst em cpu
r b w swpd f r ee buf f cache si so bi bo i n cs us sy i d
0 0 0 3008 21856 1828 33508 0 0 1 4 2 1 20 3 77
1 0 0 3008 21860 1828 33508 0 0 1 26 145 111 19 2 78

60
Use o comando interativo q para sair das estatsticas t op.
E M
A M B I E N T E
L I N U X
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 E N L A C E )
265
0 0 0 3008 21352 1828 33512 0 0 0 0 145 128 28 3 69
0 0 0 3008 22348 1828 33516 0 0 0 0 141 113 26 4 70
0 0 0 3008 22348 1828 33516 0 0 0 0 124 77 11 3 86
2 0 0 3008 11188 1840 35456 0 0 389 26 156 41 68 1 31
Como o parmetro 300 passado para o comando vmst at , 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 vmst at . 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.
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 Obt endo ut i l i zao de memri a em rot eadores e
comut adores
Neste procedimento informaremos como podemos obter a utilizao de
memria em roteadores e comutadores.
10.7.1 Desc r i o e di c as
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.
E M
A M B I E N T E
W I N D O W S
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 E N L A C E )
266
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 est a o de ger nc i a 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].
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 E N L A C E )
267
Outras variveis SNMP importantes para a monitorao de utilizao de
memria em roteadores Cisco [CISCO-MEMORY-POOL-MIB, OLD-
CISCO-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:
Qtde. total de memria Qtde. de memria livre
Utilizao de memria (%) = x 100
Qtde. total de memria
Equao 10.7-1
Qtde. de memria em uso
Utilizao de memria (%) = x 100
Qtde. total de memria
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;
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 E N L A C E )
268
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 i nt er f ac e de l i nha de c omando
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 memor y [ memor y- t ype] [ f r ee] [ summar y]
show pr ocesses memor y
Vejamos primeiro um exemplo da execuo do comando show memor y:
r ot eador > show memor y
Head Tot al ( b) Used( b) Fr ee( b) Lowest ( b) Lar gest ( b)
Pr ocessor 61345760 248228000 16818760 231409240 231201272 230393684
Fast 61325760 131080 24664 106416 106416 106364
( )
A primeira seo do resultado do comando show memor y 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 Descrio
Total(b) 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 pr ocesses memor y:
r ot eador >show pr oc mem
Tot al : 248228000, Used: 16820540, Fr ee: 231407460
PI D TTY Al l ocat ed Fr eed Hol di ng Get buf s Ret buf s Pr ocess
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 E N L A C E )
269
0 0 446636 65836 13942472 0 0 *I ni t *
0 0 912 686860 912 0 0 *Sched*
0 0 19590060 5218804 40688 5445248 0 *Dead*
1 0 268 268 3796 0 0 Load Met er
2 0 6476 63247816 7296 0 0 OSPF Hel l o
3 0 0 0 6796 0 0 Check heaps
4 0 21972 0 28768 0 0 Chunk Manager
5 0 96 0 6892 0 0 Pool Manager
6 0 268 268 6796 0 0 Ti mer s
( )
16815220 Tot al
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 Descrio
Allocated Quantidade de bytes da memria alocados para o processo.
Freed Quantidade de bytes da memria liberados pelo processo,
independente de os tenha alocado.
holding 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 pr oc [ 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:
Consol e> ( enabl e) show pr oc mem

Tot al : 10945712, Used: 1438992, Fr ee: 9506720
PI D TTY Al l ocat ed Fr eed Hol di ng Pr ocess
0 0 706240 2832 703408 i dl e
1 0 240 0 240 Fl ash MI B Updat
2 0 164944 164144 800 SynDi ags
3 0 208224 2992 205232 SynConf i g
4 0 96 0 96 St at uspol l
5 0 2592 2560 32 SWPol l 64bCnt
6 0 80 0 80 SL_TASK
7 0 2272 1952 320 Redundant Task
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.
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 E N L A C E )
270
10.8 Obt endo ut i l i zao de memri a em hospedei ros
Neste procedimento informaremos como podemos obter a utilizao de
memria em hospedeiros.
10.8.1 Desc r i o e di c as
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 est a o de ger nc i a 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:
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 E N L A C E )
271
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 t op
Neste procedimento mostraremos como obter a utilizao de memria em
hospedeiros com sistema operacional Linux ou Windows NT/2000.
O comando t op 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 t op segue:
maria@server:~$ top
8: 42pm up 140 days, 4: 35, 2 user s, l oad aver age: 3. 31, 3. 45, 3. 66
68 pr ocesses: 59 sl eepi ng, 9 r unni ng, 0 zombi e, 0 st opped
CPU st at es: 97. 7%user , 2. 2%syst em, 0. 0%ni ce, 0. 0%i dl e
Mem: 255772K av, 249484K used, 6288K free, 0K shrd, 2360K buff
Swap: 530136K av, 3828K used, 526308K free 36616K cached
PI D USER PRI NI SI ZE RSS SHARE STAT LI B %CPU %MEM TI ME COMMAND
24462 f t p 16 0 260 16 4 R 0 38. 2 00. 0 8934m i n. f t pd
20259 r oot 10 0 19044 18M 1160 S 0 34. 4 7. 4 2: 33 net mngr
22234 r oot 20 0 10916 10M 1156 R 0 13. 5 4. 2 0: 40 net mngr
12200 r oot 9 0 22464 20M 780 R 0 0. 2 8. 2 46: 58 named
1 r oot 8 0 72 64 44 S 0 0. 0 0. 0 0: 04 i ni t
( )
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
E M
A M B I E N T E
L I N U X
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 E N L A C E )
272
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 f r ee.
Com o comando t op 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 t op, 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 vmst at . Veja uma sada tpica deste comando:
mar i a@ser ver : ~$ vmst at 5
pr ocs memor y swap i o syst em cpu
r b w swpd f r ee buf f cache si so bi bo i n cs us sy i d
1 2 0 2592 2164 75204 25404 0 2 1368 28 457 706 20 10 70
0 0 0 2580 2144 75204 25124 2 0 7 10 121 42 23 1 77
3 0 0 2580 1928 75204 24972 0 0 8 13 125 38 13 3 84
2 0 0 2580 1120 75204 25300 0 0 91 3 156 107 48 33 19
1 0 0 2604 1132 74460 26524 0 5 1198 16 148 56 48 45 6
1 0 0 2604 1136 68336 33188 0 0 302 2542 177 132 11 40 49
0 0 0 2604 19768 63284 20768 0 0 10 6 123 38 13 21 66
0 0 0 2604 19680 63348 20788 0 0 0 16 123 29 12 1 87
0 0 0 2604 19672 63348 20788 0 0 0 7 111 17 13 1 86
0 0 0 2600 19704 63348 20760 1 0 0 29 115 23 10 1 89
1 0 0 2596 19616 63412 20788 1 0 2 5 114 22 15 1 84
0 1 0 2588 19584 63412 20808 2 0 1 890 142 79 27 2 72
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 vmst at . 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 memor y 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 Sub-
campos
Descrio
Procs w Nmero de processos levados para a rea de swap (em
disco) mas que esto em execuo.
swpd Quantidade de memria virtual em uso (KB). Memory
free Quantidade de memria livre (KB).
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 E N L A C E )
273
buff Quantidade de memria usada como buffers (KB).
si Quantidade de memria transportada do disco para a
memria (KB/s).
Swap
so Quantidade de memria transportada da memria para o
disco (KB/s).
Tabela 10-10 Descrio de sub-campos do resultado do comando vmstat.
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 Anal i sando quant i dade de t rfego de broadcast e
mul t i cast
Neste procedimento analisaremos a quantidade de trfego de difuso e multicast
em um domnio de difuso.
10.9.1 Desc r i o e di c as
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;
E M
A M B I E N T E
W I N D O W S
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 E N L A C E )
274
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
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 E N L A C E )
275
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 di f uso 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
Consumo de CPU
100 2%
1300 9%
3000 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:
Qtde. de quadros broadcast recebidos e transmitidos em T
Broadcasts por segundo =
Qtde. de segundos em T
Equao 10.9-1
Qtde. de quadros multicast recebidos e transmitidos em T
Multicasts por segundo =
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:
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 E N L A C E )
276
Qtde. de quadros multicast e broadcast recebidos e transmitidos em T
Multicasts/Broadcasts por segundo =
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:
Qtde. de quadros broadcast recebidos em T
Broadcasts por segundoin =
Qtde. de segundos em T
Equao 10.9-4
Qtde. de quadros broadcast transmitidos em T
Broadcasts por segundoout =
Qtde. de segundos em T
Equao 10.9-5
Qtde. de quadros multicast recebidos em T
Multicasts por segundoin =
Qtde. de segundos em T
Equao 10.9-6
Qtde. de quadros multicast transmitidos em T
Multicasts por segundoout =
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 est a o de ger nc i a 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:
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 E N L A C E )
277
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;
ifInNUcastPkts o nmero de quadros com endereo destino
broadcast ou multicast entregues a camadas superiores em um
determinado intervalo de tempo;
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.
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 ifInBroadcastPkts
0
= 1200
o ifOutBroadcastPkts
0
= 600
o ifInMulticastPkts
0
= 4
o ifOutMulticastPkts
0
= 4
5 minutos depois, em T1, os seguintes valores foram obtidos:
o ifInBroadcastPkts
1
= 20200
o ifOutBroadcastPkts
1
= 30800
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 E N L A C E )
278
o ifInMulticastPkts
1
= 34
o ifOutMulticastPkts
1
= 34
Substitumos os valores encontrados na Equao 10.9-1 e Equao 10.9-2 e
obtivemos o seguinte:
(20200 1200) + (30800 600)
Broadcasts por segundo =
300
= 164 broadcasts por segundo

(34 4) + (34 4)
Multicasts por segundo =
300
= 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.
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 E N L A C E )
279
10.9.3 Usando uma i nt er f ac e de l i nha de c omando
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 i p t r af f i c
Veja um exemplo da resposta deste comando:
r ot eador > show i p t r af f i c
I P st at i st i cs:
Rcvd: 2593286165 t ot al , 10600762 l ocal dest i nat i on
0 f or mat er r or s, 0 checksumer r or s, 885818 bad hop count
0 unknown pr ot ocol , 0 not a gat eway
0 secur i t y f ai l ur es, 0 bad opt i ons, 32532 wi t h opt i ons
Opt s: 72 end, 1 nop, 4 basi c secur i t y, 0 l oose sour ce r out e
0 t i mest amp, 0 ext ended secur i t y, 3 r ecor d r out e
0 st r eamI D, 0 st r i ct sour ce r out e, 32459 al er t , 0 ci pso
0 ot her
Fr ags: 0 r eassembl ed, 1 t i meout s, 226 coul dn' t r eassembl e
496166 f r agment ed, 0 coul dn' t f r agment
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:
i nt er f aces [ t i po da i nt er f ace] [ nmer o da i nt er f ace]
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 [ mdul o[ / por t a] ]
O comando abaixo tambm pode ser executado em comutadores cisco com
verso de software superior a 6.1:
show por t mac [ mdul o] / por t a] ]
Veja um exemplo da execuo do comando show por t mac:
Consol e> show por t mac 1

Por t Rcv- Uni cast Rcv- Mul t i cast Rcv- Br oadcast
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 E N L A C E )
280
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1/ 1 121200 0 5210
1/ 2 5800 1 2340
1/ 3 198210 6 72150
1/ 4 3450 10 1120

Por t Xmi t - Uni cast Xmi t - Mul t i cast Xmi t - Br oadcast
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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 anal i sador de pr ot oc ol os
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 out r as f er r ament as de ger nc i a
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 net st at como exemplificado a seguir:
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 E N L A C E )
281
C: \ WI NNT>net st at - ne
Est at st i cas de i nt er f ace
Recebi do Envi ado
Byt es 242119 30360
Pacot es uni cast 516 451
Pacotes no unicast 24 32
Descar t ados 1 1
Er r os 2 0
Pr ot . Desconheci dos 23
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 Obt endo ut i l i zao de enl aces
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 Desc r i o e Di c as
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.
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 E N L A C E )
282
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:
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 E N L A C E )
283
qtde de bytes recebidos em T + qtde de bytes transmitidos em T


x 8 x 100
Utilizao (%)=
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:
max(qtde de bytes recebidos em T, qtde de bytes transmitidos em T)
x 8 x 100 Utilizao (%) =
T x velocidade de operao da interface
Equao 10.10-2
qtde de bytes recebidos em T
x 8 x 100 Utilizao de entrada (%) =
T x velocidade de operao da interface
Equao 10.10-3
qtde de bytes transmitidos em T
x 8 x 100 Utilizao de sada (%) =
T x velocidade de operao da interface
Equao 10.10-4
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 est a o de ger nc i a 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]:
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 E N L A C E )
284
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:
(1225500000 200) x 8 x 100
Utilizao de entrada (%) =
300 x 100000000
32,68%

(450500000 3010) x 8 x 100
Utilizao de sada (%) =
300 x 100000000
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
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 E N L A C E )
285
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]:
[etherStatsPkts x (96 + 64)] + (etherStatsOctets x 8)
x 100 Utilizao (%) =
T x velocidade de operao do enlace
Equao 10.10-5
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)
velocidade de operao do enlace x 0,7 x 600
Limiar crescente:
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)
velocidade de operao do enlace x 0,7 x 600
Limiar crescente:
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
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 E N L A C E )
286
Tipo: deltaValue
Intervalo: 600 segundos (10 minutos)
velocidade de operao do enlace x 0,5 x 600
Limiar crescente:
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 i nt er f ac e de l i nha de c omando
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:
r ot eador # show i nt er f ace [ t i po da i nt er f ace] [ nmer o da i nt er f ace]
No exemplo a seguir so obtidas informaes sobre a interface Fast Ethernet
1/1/0 de um roteador Cisco:
r ot eador >show i nt er Fast Et her net 1/ 1/ 0
1. Fast Et her net 1/ 1/ 0 i s up, l i ne pr ot ocol i s up
2. Har dwar e i s cyBus Fast Et her net I nt er f ace, addr ess i s 0003. 2853. 0931
( bi a 0003. 2853. 0931)
3. I nt er net addr ess i s 192. 168. 4. 1/ 24
4. MTU 1500 byt es, BW 100000 Kbi t , DLY 100 usec, r el y 255/ 255, l oad
10/ 255
5. Encapsul at i on ARPA, l oopback not set
6. Keepal i ve set ( 10 sec)
7. Hal f - dupl ex, 100Mb/s, 100BaseTX/ FX
8. ARP t ype: ARPA, ARP Ti meout 04: 00: 00
9. Last i nput 00: 00: 00, out put 00: 00: 00, out put hang never
10. Last cl ear i ng of "show i nt er f ace" count er s never
11. Queuei ng st r at egy: f i f o
12. Out put queue 0/ 40, 98 dr ops; i nput queue 0/ 75, 0 dr ops
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 buf f er
16. Received 1026648 broadcasts, 0 r unt s, 0 gi ant s, 0 t hr ot t l es
17. 0 i nput er r or s, 0 CRC, 4 f r ame, 0 over r un, 0 i gnor ed
18. 0 wat chdog, 0 mul t i cast
19. 0 i nput packet s wi t h dr i bbl e condi t i on det ect ed
20. 1784610 packets output, 142194201 bytes, 0 under r uns
21. 1664 out put er r or s, 48521009 col l i si ons, 11 i nt er f ace r eset s
22. 0 babbl es, 0 l at e col l i si on, 0 def er r ed
23. 1663 l ost car r i er , 0 no car r i er
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 E N L A C E )
287
24. 0 out put buf f er f ai l ur es, 0 out put buf f er s swapped out 0
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:
taxa de entrada de dados
x 100 Utilizao de entrada (%)=
Velocidade da interface
Equao 10.10-6
taxa de entrada de dados (bits/s)
x 100 Utilizao de sada (%) =
Velocidade da interface
Equao 10.10-7
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:
901000 x 100
Utilizao de entrada =
10000000
= 0,901%

4104000 x 100
Utilizao de sada =
100000000
= 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 [ mdul o[ / por t a] ]
show mac ut i l i zat i on [ mdul o[ / por t a] ]
show por t mac [ modul o[ / por t a] ] ( 6. 2 e super i or es)
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 E N L A C E )
288
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 por t st at us [ mdul o[ / por t a] ]
Por exemplo, para obter contadores de trfego de entrada e sada da porta 1 do
mdulo 1 execute:
Consol e> show mac ut i l i zat i on 1/ 1
Consol e> show por t st at us 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:
Consol e> show count er s [ mdul o[ / por t a]
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 anal i sador de pr ot oc ol os
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).
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 E N L A C E )
289
10.10.5 Usando out r as f er r ament as de ger nc i a
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:
mar i a@ser ver : ~$ i f conf i g et h0
25. et h0 Li nk encap: Et her net HWaddr 00: 04: AC: 4C: 98: DF
26. i net addr : 192. 168. 5. 1 Bcast : 192. 168. 5. 255 Mask: 255. 255. 255. 0
27. UP BROADCAST RUNNI NG MULTI CAST MTU: 1500 Met r i c: 1
28. RX packet s: 2739527 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 0
29. TX packet s: 2240473 er r or s: 0 dr opped: 0 over r uns: 0 car r i er : 0
30. col l i si ons: 0 t xqueuel en: 100
31. RX bytes:538341940 (513.4 Mb) TX bytes:1142036917 (1089.1 Mb)
32. I nt er r upt : 15 Base addr ess: 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: \ WI NDOWS>netstat -ne
Est at st i cas de i nt er f ace
Recebi do Envi ado
Byt es 82161 31128
Pacot es uni cast 447 503
Pacot es no uni cast 38 38
Descar t ados 0 0
Er r os 0 0
Pr ot . desconheci dos 48
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
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 E N L A C E )
290
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 Veri fi cando exi st nci a de quadros mui t o l ongos
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 Desc r i o e Di c as
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 [GUIA-
ETHERNET].
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 est a o de ger nc i a 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.
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 E N L A C E )
291
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 i nt er f ac e de l i nha de c omando
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 i nt er f aces [ t i po da i nt er f ace] [ nmer o da i nt er f ace]
Veja abaixo um exemplo da execuo deste comando:
r ot eador > show i nt er f ace Fast Et her net 1/ 0/ 0
Fast Et her net 1/ 0/ 0 i s up, l i ne pr ot ocol i s up
( )
5 mi nut e i nput r at e 2984000 bi t s/ sec, 916 packet s/ sec
5 mi nut e out put r at e 5099000 bi t s/ sec, 987 packet s/ sec
407408230 packet s i nput , 3004139350 byt es, 0 no buf f er
Recei ved 87505 br oadcast s, 0 r unt s, 1 giants, 0 t hr ot t l es
0 i nput er r or s, 0 CRC, 0 f r ame, 0 over r un, 0 i gnor ed
0 wat chdog, 0 mul t i cast
( )
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 por t [ mdul o[ / por t a] ]
Veja a seguir um exemplo da resposta deste comando:
Consol e> show por t 9/ 5

Por t Name St at us Vl an Dupl ex Speed Type
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
9/ 5 connect ed 1 aut o aut o 10/ 100BaseTX

( )

Por t Al i gn- Er r FCS- Er r Xmi t - Er r Rcv- Er r Under Si ze
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
9/ 5 1 2 1 2 2

Por t Si ngl e- Col Mul t i - Col l Lat e- Col l Excess- Col Car r i - Sen Runt s Giants
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -------
9/ 5 32 0 0 0 0 30 2

Last - Ti me- Cl ear ed
- - - - - - - - - - - - - - - - - - - - - - - - - -
Wed Mar 13 2002, 21: 57: 31
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 E N L A C E )
292
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 anal i sador de pr ot oc ol os
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 J abber. 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 Obt endo NEXT e at enuao em cabos de pares
t ranados
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 Desc r i o e Di c as
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.
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 E N L A C E )
293
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 A
injetado
como sendo a amplitude
do sinal injetado e A
induzido
como a amplitude do sinal induzido no par de fios
adjacente. Idealmente, queremos que A
induzido
seja zero. Veja como NEXT
calculado na Equao 10.12-1:
Ainduzido
NEXT (dB) = 20 log
Ainjetado
Equao 10.12-1
Como A
induzido
< A
injetado
, o resultado ser um nmero negativo. Note tambm
que quanto menor for o valor de A
injetado
(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 A
entrada
como sendo a amplitude do sinal injetado no incio do cabo e
A
sada
a amplitude do sinal na sada. Idealmente queremos que A
sada
seja igual a
A
entrada
, o que significa que ao houve atenuao. Veja como a atenuao
calculada na Equao 10.12-2:
Asada
Atenuao (dB) = 20 log
Aentrada
Equao 10.12-2
Se A
sada
= A
entrada
, teramos atenuao zero, pois log 1 = 0. Como, na prtica,
A
sada
< A
entrada
, o resultado ser um nmero negativo. Note que quanto menor
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 E N L A C E )
294
for a diferena A
sada
A
entrada
(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 f er r ament a de c er t i f i c a o
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-NET-
NEXT].
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.

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 E N L A C E )
295
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
(100 MHz)
Categoria 5e
(100 MHz)
Categoria 6
(100
MHz/250
MHz)
Categoria 7
(100
MHz/600
MHz)
NEXT 27.1 dB 30.1 dB 39.9 dB/33.1
dB
62.1 dB/51
dB
Atenuao 24 dB 24 dB 21.7 dB/ 36
dB
20.8 dB/ 54.1
dB
Tabela 10-17: Valores limites de atenuao e NEXT em cabos de pares tranados
categorias 5, 5e, 6 e 7.
10.13 Obt endo est ado admi ni st rat i vo de i nt erfaces
Neste procedimento descreveremos como obter o estado administrativo de
interfaces de equipamentos de interconexo e estaes de trabalho.
10.13.1 Desc r i o e Di c as
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);
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 E N L A C E )
296
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 est a o de ger nc i a 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 i nt er f ac e de l i nha de c omando
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:
r ot eador # show i nt er account i ng
r ot eador # show i nt er f aces
r ot eador # show i nt er descr i pt i on
Se preferir, voc pode selecionar apenas uma interface. Por exemplo, em
roteadores Cisco famlia 7500, execute:
r ot eador # show i nt er f ace [ t i po_da_i nt er f ace] [ nmer o_da_i nt er f ace]
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:
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 E N L A C E )
297
#show i nt er f ace Fast Et her net 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:
Fast Et her net 1/ 1/ 0 i s up, l i ne pr ot ocol i s up
Caso a interface esteja administrativamente desativada, a primeira linha ser:
Fast Et her net 1/ 1/ 0 i s admi ni st r at i vel y down, l i ne pr ot ocol i s
down
O comando a seguir informa o estado das portas na maioria dos comutadores
Cisco Catalyst (a partir da famlia 29xx):
comut ador > show por t st at us [ mdul o[ / por t a] ]
Veja o exemplo a seguir:
Consol e> show por t st at us
Por t Name St at us Vl an Level Dupl ex Speed Type
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
1/ 1 di sabl ed 1 nor mal hal f 100
100BaseTX
1/ 2 not connect 1 nor mal hal f 100
100BaseTX
2/ 1 connect ed t r unk nor mal hal f 400
100BaseTX
3/ 1 not connect t r unk nor mal f ul l 155 OC3 MMF
ATM
5/ 1 not connect 1 nor mal hal f 100
100BaseTX
5/ 2 not connect 1 nor mal hal f 100
100BaseTX
Em comutadores Cisco, o estado di sabl ed indica que a porta est
desabilitada. A porta 1/1 do exemplo apresentado est inativa
administrativamente. Existem outros estados. O estado not connect , 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 i f c onf i g
Nesta seo veremos como obter o estado administrativo de interfaces em
mquinas Linux e Windows.
Em mquinas Linux o comando i f conf i g - 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 :
r oot # i f conf i g a
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 E N L A C E )
298
et h0 Li nk encap: Et her net HWaddr 00: 60: 94: 63: 6E: 3A
i net addr : 10. 10. 10. 1 Bcast : 10. 10. 10. 255 Mask: 255. 255. 255. 0
UP BROADCAST RUNNING MULTICAST MTU: 1500 Met r i c: 1
RX packet s: 658685 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 3
TX packet s: 555222 er r or s: 0 dr opped: 0 over r uns: 19 car r i er : 1
col l i si ons: 44644 t xqueuel en: 100
I nt er r upt : 5

et h1 Li nk encap: Et her net HWaddr 00: 60: 94: 63: 6E: 3A
i net addr : 10. 10. 12. 1 Bcast : 10. 10. 12. 255 Mask: 255. 255. 255. 0
BROADCAST MULTICAST MTU: 1500 Met r i c: 1
RX packet s: 85 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 0
TX packet s: 22 er r or s: 0 dr opped: 0 over r uns: 0 car r i er : 0
col l i si ons: 4 t xqueuel en: 100
I nt er r upt : 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 i f conf i g -
a como a interface eth1: no apresentando os flags UP e RUNNING.
O comando i f conf i g usado para ativar e desativar interfaces
administrativamente. provvel que a interface eth1 do exemplo dado tenha
sido desativada pelo comando:
r oot # i f conf i g et h1 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:
r oot # i f conf i g et h1 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;
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 E N L A C E )
299
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 Veri fi cando ocor rnci a de enchent es
Neste procedimento descreveremos como verificar se comutadores esto
enviando muitos quadros em enchente.
10.14.1 Desc r i o e Di c as
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 est a o de ger nc i a 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
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 E N L A C E )
300
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 anal i sador de pr ot oc ol os
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 Anal i sando t rfego de di fuso ARP
Neste procedimento apresentaremos como analisar solicitaes ARP em um
domnio de difuso.
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 E N L A C E )
301
10.15.1 Desc r i o e Di c as
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 anal i sador de pr ot oc ol os
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?
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 E N L A C E )
302
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 sub-
redes 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.
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 E N L A C E )
303

Figura 10-8: Tabela de estatsticas de captura.

Figura 10-9: Quadro de solicitao ARP.
10.16 Refernci as
10.16.1 Li vr os
[DESIGNING-CISCO] Teare, D. Designing Cisco Networks. Cisco Press.
Fevereiro, 1999.
[GUIA-ETHERNET] Spurgeon, C. E. Ethernet O Guia Definitivo.
Traduo Daniel Vieira, Editora Campus, 2000.
[HAUGDAHL] Haugdahl, J. 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 E N L A C E )
304
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 Rec ur sos onl i ne (I nt er net )
[CABLETESTING-NEXT] Near End Crosstalk (NEXT).
http://www.cabletesting.com/CableTesting/Test
ing/Definitions/Definitions_NEXT.htm
[CISCO-MEMORY-POOL-
MIB]
Johnson, J., Wang, S. CISCO-MEMORY-
POOL-MIB. Julho, 2001.
ftp://ftp.cisco.com/pub/mibs/v1/CISCO-
MEMORY-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-2001-
08.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.fluke-
net.com/consultants/testing/next.asp
[NIMDA] Informaes do CERT sobre o verme NIMDA.
http://www.cert.org/advisories/CA-2001-
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 E N L A C E )
305
26.html
[OLD-CISCO-MEMORY-
MIB]
Johnson, J., Wang, S. OLD-CISCO-MEMORY-
MIB. Fevereiro, 1994.
ftp://ftp.cisco.com/pub/mibs/v1/OLD-
CISCO-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-12-
17-demystifying.asp
[CISCO-PROCESS-MIB] CISCO-PROCESS-MIB Definitions.
ftp://ftp.cisco.com/pub/mibs/v1/CISCO-
PROCESS-MIB-V1SMI.my
[CPU-UTILIZATION-
HOWTO]
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-SYSTEM-
MIB]
Jeffrey, J. T. Cisco System MIB file. Julho de
1994.
ftp://ftp.cisco.com/pub/mibs/v1/OLD-
CISCO-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.
[RFC1514] Grillo, P., Waldbusser, S. Host Resources MIB. Setembro, 1993.
[RFC1757] Waldbusser, S. Remote Network Monitoring Management
Information Base. Fevereiro, 1995.
[RFC2233] McCloghrie, K., F. Kastenholz. The Interfaces Group MIB
using SMIv2. Novembro, 1997.
[RFC2358] Flick, J., Johnson, J. Definitions of Managed Objects for the
Ethernet-like Interface Types. Junho, 1998.
[RFC2665] Flick, J., Johnson, J. Definitions of Managed Objects for the
Ethernet-like Interface Types. Agosto de 1999.
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 E N L A C E )
306
[RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K.
Definitions of Managed Objects for Bridges. Julho, 1993


307
11 Procediment os referenciados nos
problemas de nvel de rede
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 Veri fi cando se duas mqui nas respondem mesma
consul t a ARP
Neste procedimento mostraremos como verificar se mais de uma interface est
respondendo a uma mesma consulta ARP.
11.1.1 Desc r i o e Di c as
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 anal i sador de pr ot oc ol os
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.
Capt ulo
11
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 )
308
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;
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 ar p 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: \ WI NDOWS> ar p d <ender eo I P da ent r ada a ser
r emovi da>
# ar p d <ender eo I P da ent r ada a ser r emovi da>
Em um roteador Cisco com IOS verso 10.0 ou superior, o comando a seguir
apagar todas as entradas da tabela ARP:
r ot eador # cl ear ar p- cache
Para causar o envio de uma consulta ARP envolvendo um determinado
endereo IP da mesma sub-rede, envie mensagens ICMP Echo (pi ng) para este
endereo IP. Para que esta mensagem seja enviada, ser necessrio fazer antes o
T E S T E A
T E S T E B
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 )
309
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 pi ng. Ao encerrar a captura, analise os quadros
capturados em busca de duas respostas mesma consulta ARP.
11.2 Veri fi cando ocor rnci a de consul t as ARP sem respost a
Neste procedimento mostraremos como verificar a existncia de consultas ARP
sem resposta em uma rede.
11.2.1 Desc r i o e Di c as
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 anal i sador de pr ot oc ol os
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.
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 )
310
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.
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 )
311

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 encontram-
se 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 (pi ng) 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
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 )
312
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 pi ng 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
pi ng 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 pi ng. Por isso recomendamos que
voc capture os dados e os analise.
11.3 Obt endo t abel a de rot as de rot eadores
Neste procedimento sero apresentadas algumas maneiras de obteno da tabela
de rotas de roteadores e estaes de trabalho.
11.3.1 Desc r i o e Di c as
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
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 )
313
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 est a o de ger nc i a 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 i nt er f ac e de l i nha de c omando
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:
r ot eador >show i p r out e
Codes: C - connect ed, S - st at i c, I - I GRP, R - RI P, M- mobi l e, B - BGP
D - EI GRP, EX - EI GRP ext er nal , O - OSPF, I A - OSPF i nt er ar ea
N1 - OSPF NSSA ext ernal t ype 1, N2 - OSPF NSSA ext er nal t ype 2
E1 - OSPF ext er nal t ype 1, E2 - OSPF ext ernal t ype 2, E - EGP
i - I S- I S, L1 - I S- I S l evel - 1, L2 - I S- I S l evel - 2, i a - I S- I S i nt er area
* - candi dat e def aul t , U - per - user st at i c r out e, o - ODR
Gat eway of l ast r esort i s 192. 143. 254. 174 t o net wor k 0. 0. 0. 0
C 192. 168. 64. 0/ 24 i s di rect l y connect ed, Fast Et her net 1/ 0/ 0
O E1 192. 17. 251. 0/ 24 [ 110/ 53] vi a 192. 143. 254. 174, 02: 28: 54, ATM4/ 0/ 0. 103
O E1 192. 18. 234. 0/ 24 [ 110/ 53] vi a 192. 143. 254. 174, 02: 28: 54, Fast Et hernet 1/ 0/ 0
192. 211. 38. 0/ 30 i s subnet t ed, 1 subnet s
O E1 192. 211. 38. 148 [ 110/ 52] vi a 192. 143. 254. 174, 02: 28: 54, ATM4/ 0/ 0. 103
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 )
314
O E1 192. 137. 174. 0/ 24 [ 110/ 54] vi a 192. 143. 254. 174, 02: 29: 24, ATM4/ 0/ 0. 103
O E1 192. 168. 174. 0/ 24 [ 110/ 54] vi a 192. 143. 254. 174, 02: 29: 24, Fast Et her net 1/ 1/ 0
S 192. 168. 65. 0/ 24 [ 1/ 0] vi a 192. 168. 64. 131
S 192. 168. 66. 0/ 24 [ 1/ 0] vi a 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:
r ot eador >show i p r out e 192. 168. 1. 0
Rout i ng ent r y f or 192. 168. 1. 0/ 24
Known vi a " st at i c" , di st ance 1, met r i c 0
Redi st r i but i ng vi a ospf 1916
Adver t i sed by ospf 1916 met r i c 50 met r i c- t ype 1 subnet s t ag 145 r out e-
map I
Rout i ng Descr i pt or Bl ocks:
* 192. 168. 64. 131
Rout e met r i c i s 0, t r af f i c shar e count i s 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 st at i c), as
redes diretamente conectadas (parmetro connect ed) ou apenas as rotas
aprendidas atravs de um determinado protocolo. Por exemplo, o comando
seguinte apresenta apenas as rotas aprendidas atravs do protocolo OSPF:
r ot eador # show i p r out e ospf
Outros protocolos que podem ser passados como parmetro so: bgp, egp,
ei gr p, hel l o, i gr p, i si s e r i p.
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 net st at e r out e
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:
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 )
315
# net st at nr
# r out e - n
Em mquinas com sistema operacional Windows execute o comando a seguir a
partir de um promp de comandos:
C: \ WI NNT> r out e pr i nt
11.4 Veri fi cando ocor rnci a de requi si es DHCP sem
respost a do ser vi dor
Neste procedimento mostraremos como verificar se um cliente DHCP fica sem
resposta do servidor DHCP aps enviar mensagens DHCPDISCOVER ou
DHCPREQUEST.
11.4.1 Desc r i o e Di c as
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 anal i sador de pr ot oc ol os
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
L e i a m a i s
s o b r e
D H C P n o
a p n d i c e
9
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 )
316
servidor. Isto pode ser feito em mquinas Windows com o comando
i pconf i g / r enew_al l . No Linux o comando a ser usado vai depender da
implementao do cliente DHCP em uso. As implementaes atualmente
existentes so: dhcpcd, pump e dhcl i ent . Para forar um cliente dhcpcd a
renovar configuraes de rede com o servidor passe a opo n:
# dhcpcd n [ i nt er f ace]
Em clientes pump passe o parmetro R:
# pump R [ - i i nt er f ace]
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 Ver i f i c ando l ogs do ser vi dor 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.
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
W I N D O W S
2 0 0 0
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 )
317
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.xxx
61
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 Descrio
ID Um cdigo de identificao de evento do servidor DHCP.
Data A data na qual a mensagem de log foi escrita no arquivo de
log do servidor DHCP.
Hora A hora em que a entrada foi escrita no arquivo de log do
servidor DHCP.
Descrio Uma descrio deste evento do servidor DHCP.
Endereo IP O endereo IP do cliente DHCP.
Nome do
Hospedeiro
O nome do cliente DHCP.
Endereo MAC O endereo MAC (Medium Access Control) do cliente
DHCP.
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 Um novo endereo IP foi concedido a um cliente.
11 Uma concesso foi renovada pelo cliente.
12 Uma concesso foi liberada pelo cliente.
15 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.
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 )
318
Tabela 11-2: Eventos que informam sobre a comunicao cliente/servidor DHCP.
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 Veri fi cando se l og do ser vi dor DHCP i ndi ca fal t a 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 Desc r i o e di c as
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 Ver i f i c ando l ogs do ser vi dor
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.
O servidor DHCP oferecido pela ISC (Internet Software Consortium) enviar
mensagens para o arquivo de log atravs do sysl og. Por default, as mensagens
de log do DHCP sero encontradas juntamente com mensagens de logs de todos
os outros daemons que tambm usam o sysl og. 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.
D H C P D
( L I N U X )
D H C P
I S C
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 )
319
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 [ANALYZING-
DHCP-LOG, WIN-TIP412].
11.6 Veri fi cando ocor rnci a 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 Desc r i o e Di c as
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.
D H C P
W I N D O W S
2 0 0 0
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 )
320
11.6.2 Usando um anal i sador de pr ot oc ol os
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 Ver i f i c ando l ogs do ser vi dor 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 Anal i sando requi si es de cl i ent es DHCP ext er nos
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 Desc r i o e Di c as
Um agente de repasse um hospedeiro ou roteador que repassa mensagens
DHCP entre clientes e servidores que no participam de um mesmo domnio de
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 )
321
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 anal i sador de pr ot oc ol os
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 i pconf i g / r enew_al l . 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 [ i nt er f ace]
Em clientes pump passe o parmetro R:
# pump R [ - i i nt er f ace]
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 certificar-
se 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:
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 )
322
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 Veri fi cando exi st nci a de mensagens ICMP de
redi reci onament o 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 Desc r i o e di c as
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;
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 )
323
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 est a o de ger nc i a 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 ipInRedirects
0
e
ipInRedirects
0+T
. Ento, durante o tempo T, o equipamento em questo
recebeu ipInRedirects
0+T
- ipInRedirects
0
mensagens ICMP de
redirecionamento.
11.8.3 Usando uma i nt er f ac e de l i nha de c omando
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.
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 )
324
Em roteadores Cisco com verso de IOS superior a 10.0, execute o comando a
seguir para visualizar estatsticas do trfego IP:
show i p t r af f i c
Veja um exemplo do resultado deste comando onde destacamos contadores de
mensagens ICMP de redirecionamento recebidas e enviadas:
r ot eador > show i p t r af f i c
( )
I CMP st at i st i cs:
Rcvd: 0 f or mat er r or s, 19 checksumer r or s, 1 redirects, 31 unr eachabl e
209227 echo, 11 echo r epl y, 0 mask r equest s, 0 mask r epl i es, 0
quench
0 par amet er , 0 t i mest amp, 0 i nf o r equest , 0 ot her
18 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s
Sent : 961458 redirects, 7934 unr eachabl e, 10 echo, 209227 echo r epl y
0 mask r equest s, 0 mask r epl i es, 0 quench, 0 t i mest amp
0 i nf o r epl y, 106591 t i me exceeded, 0 par amet er pr obl em
0 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s
( )
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 anal i sador de pr ot oc ol os
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
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 )
325
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.
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 )
326
11.9 Anal i sando t rfego de mensagens ICMP Ti me 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 Desc r i o e di c as
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 rot eador 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 hospedei ro 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 est a o de ger nc i a 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 icmpOutTimeExcds
0
continha o valor 8.000.000.
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 )
327
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 i nt er f ac e de l i nha de c omando
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:
r ot eador > show i p t r af f i c
I P st at i st i cs:
( )
I CMP st at i st i cs:
Rcvd: 0 f or mat er r or s, 1 checksumer r or s, 0 r edi r ect s, 5 unr eachabl e
27150 echo, 1 echo r epl y, 0 mask r equest s, 0 mask r epl i es, 0
quench
0 par amet er , 0 t i mest amp, 0 i nf o r equest , 0 ot her
0 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s
Sent : 146052 r edi r ect s, 36 unr eachabl e, 0 echo, 27150 echo r epl y
0 mask r equest s, 0 mask r epl i es, 0 quench, 0 t i mest amp
0 i nf o r epl y, 7863 time exceeded, 0 par amet er pr obl em
0 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s
( )
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 anal i sador de pr ot oc ol os
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.
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 )
328
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.
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 )
329
11.10 Anal i sando t rfego de mensagens ICMP de dest i no
i nal canvel
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 Desc r i o e Di c as
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.
1 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.
3 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 est a o de ger nc i a 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:
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 )
330
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 logs
62
e sesses de
t el net , 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 i nt er f ac e de l i nha de c omando
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:
r ot eador > show i p t r af f i c
I P st at i st i cs:
( )
I CMP st at i st i cs:
Rcvd: 0 f or mat er r or s, 1 checksumer r or s, 0 r edi r ect s, 5 unreachable
27150 echo, 1 echo r epl y, 0 mask r equest s, 0 mask r epl i es, 0
quench
0 par amet er , 0 t i mest amp, 0 i nf o r equest , 0 ot her
0 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s

62
O roteador pode estar configurado para escrever logs em um hospedeiro.
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 )
331
Sent : 146052 r edi r ect s, 36034 unreachable, 0 echo, 27150 echo r epl y
0 mask r equest s, 0 mask r epl i es, 0 quench, 0 t i mest amp
0 i nf o r epl y, 7863 t i me exceeded, 0 par amet er pr obl em
0 i r dp sol i ci t at i ons, 0 i r dp adver t i sement s
( )
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 anal i sador de pr ot oc ol os
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.

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 )
332
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.
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 )
333
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

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 )
334
ativado. Neste caso, devemos analisar bem a comunicao entre as duas
mquinas antes de identificar com certeza que porta est desativada.
11.11 Veri fi cando se pacot es est o sendo descar t ados por
fal t a de rot as
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 Desc r i o e di c as
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 est a o de ger nc i a 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 i nt er f ac e de l i nha de c omando
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:
r ot eador > show i p t r af f i c
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 )
335
I P st at i st i cs:
Rcvd: 2593286165 t ot al , 10600762 l ocal dest i nat i on
0 f or mat er r or s, 0 checksumer r or s, 885818 bad hop count
0 unknown pr ot ocol , 0 not a gat eway
0 secur i t y f ai l ur es, 0 bad opt i ons, 32532 wi t h opt i ons
Opt s: 72 end, 1 nop, 4 basi c secur i t y, 0 l oose sour ce r out e
0 t i mest amp, 0 ext ended secur i t y, 3 r ecor d r out e
0 st r eamI D, 0 st r i ct sour ce r out e, 32459 al er t , 0 ci pso
0 ot her
Fr ags: 0 r eassembl ed, 1 t i meout s, 226 coul dn' t r eassembl e
496166 f r agment ed, 0 coul dn' t f r agment
Bcast : 58033 r ecei ved, 12 sent
Mcast : 1893437 r ecei ved, 3482544 sent
Sent : 17569897 gener at ed, 1571770454 f or war ded
Dr op: 811982 encapsul at i on f ai l ed, 0 unr esol ved, 0 no adj acency
10070563 no route, 0 uni cast RPF, 0 f or ced dr op
()
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 Anal i sando a ori gem do t rfego de di fuso em um
domni o de di fuso
Neste procedimento apresentaremos como identificar as mquinas que esto
enviando quadros de difuso em um determinado domnio de difuso.
11.12.1 Desc r i o e Di c as
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
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 )
336
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 anal i sador de pr ot oc ol os
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.

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 )
337
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.
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 )
338
11.13 Anal i sando a confi gurao de rede em um hospedei ro
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 Desc r i o e di c as
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 out r as f er r ament as de ger nc i a
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 i pconf i g / Al l
pode ser utilizado. Veja o exemplo da sada deste comando na Figura 11-7.
Exceto no Windows NT/2000, o comando wi ni pcf g 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: \ > r out e pr i nt

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 )
339

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
et h0 Li nk encap: Et her net HWaddr 00: 04: AC: 4C: 98: DF
inet addr:192.168.10.15 Bcast:192.168.10.255
Mask:255.255.255.0
UP BROADCAST RUNNI NG MULTI CAST MTU: 1500 Met r i c: 1
RX packet s: 9103385 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 0
TX packet s: 8066438 er r or s: 0 dr opped: 0 over r uns: 0 car r i er : 0
col l i si ons: 0 t xqueuel en: 100
RX byt es: 2151783033 ( 2052. 1 Mb) TX byt es: 439771715 ( 419. 3 Mb)
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 )
340
I nt er r upt : 15 Base addr ess: 0x2180

l o Li nk encap: Local Loopback
i net addr : 127. 0. 0. 1 Mask: 255. 0. 0. 0
UP LOOPBACK RUNNI NG MTU: 16436 Met r i c: 1
RX packet s: 788372 er r or s: 0 dr opped: 0 over r uns: 0 f r ame: 0
TX packet s: 788372 er r or s: 0 dr opped: 0 over r uns: 0 car r i er : 0
col l i si ons: 0 t xqueuel en: 0
RX byt es: 111515980 ( 106. 3 Mb) TX byt es: 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
Ker nel I P r out i ng t abl e
Dest i nat i on Gat eway Genmask Fl ags Met r i c Ref Use I f ace
192. 168. 10. 0 0. 0. 0. 0 255. 255. 255. 0 U 0 0 0 et h0
192. 168. 22. 3
2
192. 168. 10. 13
1
255. 255. 255. 255 U 0 0 0 et h0
127. 0. 0. 0 0. 0. 0. 0 255. 0. 0. 0 U 0 0 0 l o
0.0.0.0 192.168.10.25
4
0.0.0.0 UG 0 0 0 eth0
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:
# host name f qdn
pc- 15. exempl o. com. br
Por fim, para ver quais os servidores DNS configurados para responder
consultas DNS deste hospedeiro veja o arquivo /etc/resolv.conf.
# mor e / et c/ r esol v. conf
domain exemplo.com.br
nameserver 192.168.1.53
nameserver 192.168.1.54
nameserver 192.168.1.55
A diretiva domai n indica o domnio de nomes a que o hospedeiro pertence. As
diretivas nameser ver informam os endereos IP dos servidores de nomes
deste hospedeiro, que sero consultados na ordem em que foram configurados
no arquivo.
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 )
341
11.14 Veri fi cando conect i vi dade vi a IP e conect i vi dade vi a
nome de domni o
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 Desc r i o e Di c as
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 pi ng
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:
# pi ng 192. 168. 23. 3
PI NG 192. 168. 23. 3 ( 192. 168. 23. 3) : 56 dat a byt es
64 byt es f r om192. 168. 23. 3: i cmp_seq=0 t t l =255 t i me=1. 0 ms
64 byt es f r om192. 168. 23. 3: i cmp_seq=1 t t l =255 t i me=0. 6 ms
64 byt es f r om192. 168. 23. 3: i cmp_seq=2 t t l =255 t i me=0. 6 ms
64 byt es f r om192. 168. 23. 3: i cmp_seq=3 t t l =255 t i me=0. 6 ms
64 byt es f r om192. 168. 23. 3: i cmp_seq=4 t t l =255 t i me=0. 6 ms

- - - 192. 168. 23. 3 pi ng st at i st i cs - - -
5 packet s t r ansmi t t ed, 5 packet s r ecei ved, 0%packet l oss
r ound- t r i p mi n/ avg/ max = 0. 6/ 0. 6/ 1. 0 ms
# pi ng r ot eador 23. exempl o. com. br
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 )
342
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 Refernci as
11.15.1 Rec ur sos onl i ne (I nt er net )
[ANALYZING-
DHCP-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] Senie, ,D. Changing the Default for Directed Broadcasts in
Routers. Agosto, 1999.
[RFC 792] Postel, J. Internet Control Message Protocol. Setembro, 1981
[RFC1122] Braden, R. Requirements for Internet Hosts - Communication
Layers. Outubro, 1989
[RFC1812] Baker, F. Requirements for IP Version 4 Routers. Junho, 1995.
[RFC1213] McCloghrie, K., Rose, M. Management Information Base for
Network Management of TCP/IP-based internets: MIB-II.
Maro, 1991.
[RFC2096] Baker, F. IP Forwarding Table MIB. Janeiro, 1997.
[RFC2131] Droms, R. Dynamic Host Configuration Protocol. 1997.

11.15.3 Li vr os base
[COMER] Comer, D. Internetworking with TCP/IP: Principles, Protocols, and
Architectures. Volume 1. Quarta edio. Prentice Hall, 2000.

343
12 Procediment os referenciados nos
problemas de nvel de aplicao
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 Veri fi cando consi st nci a de dados nos ser vi dores DNS
pri mri o e secundri os
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 Desc r i o e di c as
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
Capt ulo
12

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 )
344
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 nsl ook up, di g e host
Descreveremos nesta seo como verificar a consistncia dos dados entre
servidores DNS primrio e secundrios usando as seguintes ferramentas:
nsl ookup, di g 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 nsl ookup,
di g 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 nsl ookup 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
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: www. exempl o. com. br
Addr ess: 192. 168. 1. 80
> 192.168.1.80
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

80. 1. 168. 192. i n- addr . ar pa name = www. exempl o. com. br .
>
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 )
345
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 nsl ookup no modo interativo em ns1 (continuao dos comandos
apresentados anteriormente), execute os comandos a seguir:
> server ns2.exemplo.com.br
Def aul t ser ver : ns2. exempl o. com. br
Addr ess: 192. 168. 1. 54#53
> www.exemplo.com.br
Ser ver : ns2. exempl o. com. br
Addr ess: 192. 168. 1. 54#53

Name: www. exempl o. com. br
Addr ess: 192. 168. 1. 2
> 192.168.1.80
Ser ver : ns2. exempl o. com. br
Addr ess: 192. 168. 1. 54#53

** ser ver can' t f i nd 80. 1. 168. 192. i n- addr . ar pa. : NXDOMAI N
> 192.168.1.2
Ser ver : ns2. exempl o. com. br
Addr ess: 192. 168. 1. 54#53

2. 1. 168. 192. i n- addr . ar pa name = www. exempl o. com. br .
> server ns3.exemplo.com.br
Def aul t ser ver : ns3. exempl o. com. br
Addr ess: 192. 168. 1. 55#53
> www.exemplo.com.br
Ser ver : ns3. exempl o. com. br
Addr ess: 192. 168. 1. 55#53

Name: www. exempl o. com. br
Addr ess: 192. 168. 1. 2
> 192.168.1.80
Ser ver : ns3. exempl o. com. br
Addr ess: 192. 168. 1. 55#53

** ser ver can' t f i nd 80. 1. 168. 192. i n- addr . ar pa. : NXDOMAI N
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 )
346
> 192.168.1.2
Ser ver : ns3. exempl o. com. br
Addr ess: 192. 168. 1. 55#53

2. 1. 168. 192. i n- addr . ar pa name = www. exempl o. com. br .
O comando ser ver <nome do ser vi dor DNS> utilizado para
modificar o servidor que responde s consultas realizadas com nsl ookup.
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 nsl ookup 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 di g. Para realizar as mesmas consultas que acabamos
de fazer com nsl ookup conecte-se em ns1 e execute os seguintes comandos:
mar i a@ns1: ~$ di g www. exempl o. com. br
mar i a@ns1: ~$ di g x 192. 168. 1. 80
Assim como o nsl ookup, o di g 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 di g
oferece muito mais informaes que a sada do nsl ookup. Veja, por exemplo,
a resposta do dig para a consulta dig www.exemplo.com.br:
maria@ns1:~$ dig www.exemplo.com.br
; <<>> Di G 9. 2. 0r c3 <<>> www. exempl o. com. br
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NOERROR, i d: 45099
; ; f l ags: qr aa r d r a; QUERY: 1, ANSWER: 1, AUTHORI TY: 2, ADDI TI ONAL: 2

; ; QUESTI ON SECTI ON:
; www. exempl o. com. br . I N A

;; ANSWER SECTION:
www.exemplo.com.br. 86400 IN A 192.168.1.80

; ; AUTHORI TY SECTI ON:
exempl o. com. br . 86400 I N NS ns1. exempl o. com. br .

; ; ADDI TI ONAL SECTI ON:
ns1. exempl o. com. br . 86400 I N A 192. 168. 1. 53
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 )
347

; ; Quer y t i me: 1 msec
; ; SERVER: 192. 168. 1. 53#53( 192. 168. 1. 53)
; ; WHEN: Tue Mar 12 20: 38: 41 2002
; ; MSG SI ZE r cvd: 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:
mar i a@ns1: ~$ di g @ns2. exempl o. com. br www. exempl o. com. br
mar i a@ns1: ~$ di g @ns2. exempl o. com. br x 192. 168. 1. 80
mar i a@ns1: ~$ di g @ns3. exempl o. com. br www. exempl o. com. br
mar i a@ns1: ~$ di g @ns3. exempl o. 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 nsl ookup e di g:
mar i a@ns1: ~$ host www. exempl o. com. br
mar i a@ns1: ~$ host 192. 168. 1. 80
mar i a@ns1: ~$ host www. exempl o. com. br ns2. exempl o. com. br
mar i a@ns1: ~$ host 192. 168. 1. 80 ns2. exempl o. com. br
mar i a@ns1: ~$ host www. exempl o. com. br ns3. exempl o. com. br
mar i a@ns1: ~$ host 192. 168. 1. 80 ns3. exempl o. com. br
Veja um exemplo da resposta deste comando:
maria@ns1:~$ host 192.168.1.80
80. 1. 168. 192. i n- addr . ar pa domai n name poi nt er www. exempl o. com. br .
12.2 Anal i sando mensagens de l og do ser vi dor DNS BIND
Neste procedimento vamos falar um pouco sobre mensagens de log do servidor
DNS implementao BIND.
12.2.1 Desc r i o e Di c as
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
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 )
348
estaro presentes. interessante que voc entenda estas mensagens, pois elas
podem indicar algum problema.
12.2.2 Ver i f i c ando l ogs do ser vi dor 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 sysl og. Por default, as mensagens de log do DHCP sero
encontradas juntamente com mensagens de logs de todos os outros daemons que
tambm usam o sysl og. 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:
# mor e / var / l ogs/ messages
Para ver apenas as ltimas 50 linhas do arquivo:
# t ai l n 50 / var / l ogs/ messages
Para localizar a palavra TTL, por exemplo:
# gr ep TTL / var / l ogs/ messages
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
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
T T L D E F A U L T
N O
C O N F I G U R A D O
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
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 )
349
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
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 Wor dPad
(arquivo escrito no formato RTF).
12.3 Veri fi cando a resol uo de nomes de domni o ext er nos
Neste procedimento apresentaremos como verificar se um servidor de nomes
est resolvendo nomes de domnios externos.
12.3.1 Desc r i o e Di c as
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 nsl ook up, di g e host
Nesta seo apresentaremos como podemos verificar se um servidor de nomes
est resolvendo nomes de domnios externos. Para tal usaremos as ferramentas
nsl ookup, di g 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 nsl ookup, di g ou
S O B R E
L O G S D O
S E R V I D O R
D N S
W I N D O W S

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 )
350
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 nsl ookup, di g 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.
maria@ns1:~$ nslookup www.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: www. exempl o. com. br
Addr ess: 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:
maria@ns1:~$ nslookup www.cisco.com
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Non- aut hor i t at i ve answer :
Name: www. ci sco. com
Addr ess: xx. xx. xx. 25
maria@ns1:~$ dig www.cisco.com

; <<>> Di G 9. 2. 0r c3 <<>> www. ci sco. com
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NOERROR, i d: 20094
; ; f l ags: qr r d r a; QUERY: 1, ANSWER: 1, AUTHORI TY: 2, ADDI TI ONAL: 0

; ; QUESTI ON SECTI ON:
; www. ci sco. com. I N A

; ; ANSWER SECTI ON:
www. ci sco. com. 86400 I N A xx. xx. xx. 25

; ; AUTHORI TY SECTI ON:
ci sco. com. 86400 I N NS ns1. ci sco. com.
ci sco. com. 86400 I N NS ns2. ci sco. com.

; ; Quer y t i me: 908 msec
; ; SERVER: 192. 168. 1. 53#53( 192. 168. 1. 53)
; ; WHEN: Thu Apr 11 10: 52: 33 2002
; ; MSG SI ZE r cvd: 83
U S A N D O
N S L O O K U P
U S A N D O
N S L O O K U P
U S A N D O
D I G
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 )
351
maria@ns1:~$ host www.cisco.com
www. ci sco. comhas addr ess 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:
maria@ns1:~$ nslookup www.cisco.com
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

;; connection timed out; no servers could be reached
maria@ns1:~$ dig www.cisco.com

; <<>> Di G 9. 2. 0r c3 <<>> www. ci sco. com
; ; gl obal opt i ons: pr i nt cmd
;; connection timed out; no servers could be reached
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:
maria@ns1:~$ nslookup www.exemplp.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

** ser ver can' t f i nd www. exempl p. com. br . : NXDOMAIN
maria@ns1:~$ dig www.exemplp.com.br

; <<>> Di G 9. 2. 0r c3 <<>> www. exempl p. com. br
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NXDOMAIN, i d: 53108
; ; f l ags: qr r d r a; QUERY: 1, ANSWER: 0, AUTHORI TY: 1, ADDI TI ONAL: 0

; ; QUESTI ON SECTI ON:
; www. exempl p. com. br . I N A

; ; AUTHORI TY SECTI ON:
com. br . 10762 I N SOA NS. DNS. br .
Host mast er . REGI STRO. br . 2002041600 7200 3600 604800 86400

U S A N D O
H O S T
U S A N D O
N S L O O K U P
U S A N D O
D I G
U S A N D O
H O S T
U S A N D O
N S L O O K U P
U S A N D O
D I G
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 )
352
; ; Quer y t i me: 1 msec
; ; SERVER: 200. 129. 64. 130#53( 200. 129. 64. 130)
; ; WHEN: Tue Apr 16 08: 37: 22 2002
; ; MSG SI ZE r cvd: 99
maria@ns1:~$ host www.exemplp.com.br
Host www. exempl p. com. br . not f ound: 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
nsl ookup e di g com a opo que faz com que eles ofeream resultados mais
detalhados sobre a consulta. Veja exemplos:
maria@ns1:~$ nslookup -d2 www.cisco.com
mai n par si ng www. ci sco. com
( )
l ooki ng up www. ci sco. com
set up_syst em( )
got a nameser ver l i ne
make_ser ver ( 192. 168. 1. 53)
( )
st ar t _l ookup( )
set up_l ookup( 0x8161d50)
r eset t i ng l ookup count er .
( )
usi ng r oot or i gi n
r ecur si ve quer y
add_quest i on( )
st ar t i ng t o r ender t he message
( )
send_udp( 40123010)
br i ngup_t i mer ( )
have l ocal t i meout of 5
wor ki ng on l ookup 0x8161d50, quer y 0x40123010
( )
sendi ng a r equest
( )
send_done( )
( )
connect _t i meout ( )
( )
r esendi ng UDP r equest t o f i r st ser ver
( )
sendi ng a r equest
( )
; ; connect i on t i med out ; no ser ver s coul d be r eached
cancel _l ookup( )
( )
U S A N D O
H O S T
U S A N D O
N S L O O K U P
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 )
353
O comando dig tambm aceita a mesma opo d2. O comando di g
correspondente ao comando nsl ookup apresentado anteriormente :
# maria@ns1:~$ dig -d2 www.cisco.com
12.4 Anal i sando t rfego DNS de um ser vi dor de nomes de
domni o
Neste procedimento vamos analisar o trfego de entrada e sada de um servidor
DNS usando um analisador de protocolos.
12.4.1 Desc r i o e Di c as
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 anal i sador de pr ot oc ol os
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.
U S A N D O
D I G
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 )
354
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 Veri fi cando consi st nci a de mapeament os DNS di ret o e
rever so
Neste procedimento ser descrito como verificar se h descasamento de
mapeamento reverso e direto no servidor de nomes primrio.
12.5.1 Desc r i o e di c as
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
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 )
355
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 nsl ook up, di g e host
Nesta seo veremos como verificar se mapeamentos direto e reverso
correspondentes so consistentes utilizando as ferramentas nsl ookup, di g 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 nsl ookup conecte-se no servidor de nomes primrio da zona
exemplo.com.br e execute os seguintes comandos:
[maria@ns1 ~]$ nslookup
> pc1.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: pc1. exempl o. com. br
Addr ess: 192. 168. 11. 1
> 192.168.11.1
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

1. 11. 168. 192. i n- addr . ar pa name = pc- 1. exempl o. 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 nsl ookup:
[maria@ns1 ~]$ nslookup
> pc1.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: pc1. exempl o. com. br
Addr ess: 192. 168. 11. 1
> 192.168.11.1
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

** server can't find 1.11.168.192.in-addr.arpa.: NXDOMAIN
U S A N D O
N S L O O K U P
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 )
356
Sempre que realizarmos uma consulta via nsl ookup e recebermos a resposta
** ser ver can' t f i nd x. : NXDOMAI N significa que o servidor no foi capaz
de realizar o mapeamento solicitado.
Vamos verificar, com a ferramenta di g, se o mapeamento direto e reverso
envolvendo pc1 esto casados:
[maria@ns1 ~]$ dig pc1.exemplo.com.br

; <<>> Di G 9. 2. 0r c3 <<>> ns1. exempl o. com. br
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NOERROR, i d: 51758
; ; f l ags: qr aa r d r a; QUERY: 1, ANSWER: 1, AUTHORI TY: 1, ADDI TI ONAL: 0

; ; QUESTI ON SECTI ON:
; pc1. exempl o. com. br . I N A

;; ANSWER SECTION:
pc1.exemplo.com.br. 43200 IN A 192.168.11.1

; ; AUTHORI TY SECTI ON:
exempl o. com. br . 43200 I N NS ns1. exempl o. com. br .

; ; Quer y t i me: 2 msec
; ; SERVER: 192. 168. 1. 53#53( 192. 168. 1. 53)
; ; WHEN: Thu Mar 21 19: 33: 47 2002
; ; MSG SI ZE r cvd: 67

[maria@ns1 ~]$ dig x 150.165.75.21

; <<>> Di G 9. 2. 0r c3 <<>> - x 192. 168. 1. 53
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NOERROR, i d: 4408
; ; f l ags: qr aa r d r a; QUERY: 1, ANSWER: 1, AUTHORI TY: 1, ADDI TI ONAL: 1

; ; QUESTI ON SECTI ON:
; 1. 11. 168. 192. i n- addr . ar pa. I N PTR

;; ANSWER SECTION:
1.11.168.192.in-addr.arpa. 43200 IN PTR pc-1.exemplo.com.br.

; ; AUTHORI TY SECTI ON:
11. 168. 192. i n- addr . ar pa. 43200 I N NS ns1. exempl o. com. br .

; ; ADDI TI ONAL SECTI ON:
ns1. exempl o. com. br . 43200 I N A 192. 168. 1. 53

; ; Quer y t i me: 2 msec
; ; SERVER: 192. 168. 1. 53#53( 192. 168. 1. 53)
; ; WHEN: Thu Mar 21 19: 31: 11 2002
; ; MSG SI ZE r cvd: 107
U S A N D O
D I G
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 )
357
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 :
[maria@ns1 ~]$ host pc1.exemplo.com.br
pc1. exempl o. com. br has addr ess 192. 168. 11. 1

[maria@ns1 ~]$ host 192.168.11.1
1. 11. 168. 192. i n- addr . ar pa domai n name poi nt er pc- 1. exempl o. com. br .
Quando o mapeamento solicitado no for possvel a resposta ser:
[maria@ns1 ~]$ host pc-1.exemplo.com.br
Host pc- 1. exempl o. com. br . not f ound: 3( NXDOMAI N)
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 nsl ookup, di g 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 nsl ookup e host informam que ftp apelido de
servidor.exemplo.com.br.
[maria@ns1 ~]$ nslookup
> ftp.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

f t p. exempl o. com. br canoni cal name = ser vi dor . exempl o. com. br .
Name: ser vi dor . exempl o. com. br
Addr ess: 192. 168. 1. 20
[maria@ns1 ~]$ host ftp.exemplo.com.br
f t p. exempl o. com. br i s an al i as f or ser vi dor . exempl o. com. br .
ser vi dor . exempl o. com. br has addr ess 192. 168. 1. 20
Quando for solicitado via di g um mapeamento direto de um apelido a seo de
resposta vir como exemplificado a seguir:
; ; ANSWER SECTI ON:
ftp.exemplo.com.br. 43200 IN CNAME servidor.exemplo.com.br.
ser vi dor . exempl o. com. br . 43200 I N A 192. 168. 1. 20
U S A N D O
H O S T
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 )
358
12.6 Consul t ando o ser vi dor DNS e obt endo respost as com
nomes de domni o dupl i cados
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 Desc r i o e Di c as
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 nsl ook up, di g e host
Mostraremos nesta seo como realizar algumas consultas usando nsl ookup,
di g 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.
maria@ns1:~$ nslookup www.exemplp.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

** ser ver can' t f i nd www. exempl o. com. br . : NXDOMAI N
> 192.168.1.80
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

80. 1. 168. 192. i n- addr . ar pa name = www. exempl o. com. br .
U S A N D O
N S L O O K U P
No existe
www???
Mas
192.168.1.80
www!!!
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 )
359
> www.exemplo.com.br.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: www. exempl o. com. br . exempl o. com. br .
Addr ess: 192. 168. 1. 80
> ftp.exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

Name: f t p. exempl o. com. br .
Addr ess: 192. 168. 1. 20
> 192.168.1.20
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

20. 1. 168. 192. i n- addr . ar pa name = f t p. exempl o. com. br . 1. 168. 192. i n- addr . ar pa.
> set type=MX
> exemplo.com.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

exempl o. com. br mai l exchanger = 10 mai l . exempl o. com. br . exempl o. com. br .
> set type=NS
> pop-pb.rnp.br
Ser ver : 192. 168. 1. 53
Addr ess: 192. 168. 1. 53#53

exempl o. com. br nameser ver = ns1. exempl o. com. br .
exempl o. com. br nameser ver = ns2. exempl o. com. br . exempl o. com. br .
exempl o. com. br nameser ver = ns3. exempl o. com. br . exempl o. com. br .
As mesmas consultas realizadas com nsl ookup podem ser realizadas com dig.
Veja as consultas e algumas respostas:
maria@ns1:~$ dig www.exemplo.com.br
; <<>> Di G 9. 2. 0r c3 <<>> www. exempl o. com. br
; ; gl obal opt i ons: pr i nt cmd
; ; Got answer :
; ; - >>HEADER<<- opcode: QUERY, st at us: NXDOMAI N, i d: 32077
; ; f l ags: qr aa r d r a; QUERY: 1, ANSWER: 0, AUTHORI TY: 1, ADDI TI ONAL: 1
( )
maria@ns1:~$ dig x 192.168.1.80
( )
; ; ANSWER SECTI ON:
U S A N D O
D I G
Ser que
esqueci do
.? Sim!
Quem so os
servidores
SMTP?
Quem so os
servidores de
nomes?
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 )
360
80. 1. 168. 192. i n- addr . ar pa. 43200 I N PTR www. exempl o. com. br .
( )
maria@ns1:~$ dig www.exemplo.com.br.exemplo.com.br
( )
; ; QUESTI ON SECTI ON:
; www. exempl o. com. br . exempl o. com. br . I N A

; ; ANSWER SECTI ON:
www. exempl o. com. br . exempl o. com. br . 43200 I N A 192. 168. 1. 80
( )
maria@ns1:~$ dig ftp.exemplo.com.br
( )
; ; QUESTI ON SECTI ON:
; f t p. exempl o. com. br . I N A

; ; ANSWER SECTI ON:
f t p. exempl o. com. br . 43200 I N A 192. 168. 1. 20
( )
maria@ns1:~$ dig x 192.168.1.20
( )
; ; ANSWER SECTI ON:
20. 1. 168. 192. i n- addr . ar pa. 43200 I N PTR f t p. exempl o. com. br . 1. 168. 192. i n- addr . ar pa.
( )
maria@ns1:~$ dig mx exemplo.com.br
( )
; ; QUESTI ON SECTI ON:
; exempl o. com. br . I N MX

; ; ANSWER SECTI ON:
exempl o. com. br . 43200 I N MX 10 mai l . exempl o. com. br . exempl o. com. br .
( )
maria@ns1:~$ dig ns exemplo.com.br
( )
; ; QUESTI ON SECTI ON:
; exempl o. com. br . I N NS

; ; ANSWER SECTI ON:
exempl o. com. br . 86400 I N NS ns1. exempl o. com. br .
exempl o. com. br . 86400 I N NS ns2. exempl o. com. br . exempl o. com. br .
exempl o. com. br . 86400 I N NS ns3. exempl o. com. br . exempl o. com. br .
( )

Usando o comando host , as pesquisas correspondentes s apresentadas
usando nsl ookup e dig so as seguintes:
maria@ns1:~$ host www.exemplo.com.br
U S A N D O
H O S T
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 )
361
Host www. exempl o. com. br not f ound: 3( NXDOMAI N)
maria@ns1:~$ host 192.168.1.80
80. 1. 168. 192. i n- addr . ar pa domai n name poi nt er www. exempl o. com. br .
maria@ns1:~$ host www.exemplo.com.br.exemplo.com.br
www. exempl o. com. br . exempl o. com. br has addr ess 192. 168. 1. 80
maria@ns1:~$ host ftp.exemplo.com.br
f t p. exempl o. com. br has addr ess 192. 168. 1. 20
maria@ns1:~$ host 192.168.1.20
20. 1. 168. 192. i n- addr . ar pa domai n name poi nt er f t p. exempl o. com. br . 1. 168. 192. i n- addr . ar pa
maria@ns1:~$ host -t mx exemplo.com.br
exempl o. com. br mai l i s handl ed by 10 mai l . exempl o. com. br . exempl o. com. br .
maria@ns1:~$ host -t ns exemplo.com.br
exempl o. com. br name ser ver ns1. exempl o. com. br .
exempl o. com. br name ser ver ns2. exempl o. com. br . exempl o. com. br .
exempl o. com. br name ser ver ns3. exempl o. com. br . exempl o. com. br .
Aproveitamos este procedimento para mostrar como realizar tipos diferentes de
consultas (NS e MX) no servidor DNS usando nsl ookup, host e di g.
12.7 Veri fi cando se um ser vi dor SMTP est com repasse
t ot al ment e 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 Desc r i o e Di c as
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 i nt er f ac e de l i nha de c omando
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.
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 )
362
Conecte-se em uma mquina cliente da rede. Execute nesta mquina o seguinte
comando:
# t el net I P_do_ser vi dor _SMTP 25
Este comando pode ser executado a partir de um prompt de comando no
Windows. Se voc estiver usando um cliente t el net Windows, configure-o
para realizar eco local do que voc digitar. Caso contrrio os seus comandos no
sero apresentados na tela do t el net , pois o servidor de correio no faz echo
do que recebe do cliente t el net .
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 t el net na porta
25 para servidor de correio eletrnico. Veja como procedemos para test-lo:
# telnet mail.exemplo.com.br 25
220 mai l . exempl o. com. br ESMTP
mail from:<maria@exemplo.com.br>
250 ok
rcpt to:<maria@cisco.com>
553 sor r y, t hat domai n i sn' t i n my l i st of al l owed r cpt host s
( #5. 7. 1)
quit
Cl osi ng connect i on. Good bye.
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 mai l . exempl o. com. br ESMTP
mail from:<maria@exemplo.com.br>
250 ok
rcpt to:<cris@cisco.com>
250 ok
Data
354 go ahead
teste
.
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 )
363
250 ok 1018961859 qp 18197
quit
Cl osi ng connect i on. Good bye.
12.8 Veri fi cando se um ser vi dor SMTP est com rel ay
t ot al ment e aber t o
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 Desc r i o e Di c as
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 i nt er f ac e de l i nha de c omando
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 t el net . Conecte-
se em uma mquina que certamente no pode ser cliente do servidor SMTP e
faa um t el net na porta 25 do servidor a ser testado:
# t el net I P_do_ser vi dor 25
Este comando pode ser executado a partir de um prompt de comando no
Windows. Se usar cliente t el net 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 t el net na porta 25 do servidor de
correio eletrnico. Veja a seguir como procedemos para test-lo:
# telnet mail.exemplo.com.br 25
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 )
364
220 mai l . exempl o. com. br ESMTP
helo teste.com.br
250 mai l . exempl o. 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
Cl osi ng connect i on. 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 ser vi os of er ec i dos por i nst i t ui es
ant i -spam
Nesta seo apresentamos uma outra forma de testar se um servidor de correio
eletrnico est com relay aberto.
Como apresentado no problema SERVIDOR DE CORREIO ELETRNICO COM REPASSE
TOTALMENTE ABERTO, 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 Refernci as
12.9.1 Li vr os
[DNS&BIND] 33. Albitz, P. Liu, C. DNS and BIND. Quarta Edio.
OReilly. Abril, 2001.


N D I C E R E M I S S I V O
365
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
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
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
N D I C E R E M I S S I V O
366
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
N D I C E R E M I S S I V O
367
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
N D I C E R E M I S S I V O
368
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
N D I C E R E M I S S I V O
369
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
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
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
N D I C E R E M I S S I V O
370
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 anti-
spam, 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
N D I C E R E M I S S I V O
371
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
U
Utilizao
de CPU, 57, 85, 92, 139, 188, 261, 262,
263, 264, 265, 275, 281
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
Windows
controlador de domnio, 144
logon, 37, 139, 144, 274
WINS, 121, 144

Potrebbero piacerti anche