Parte-1-Cisco Top-Down (PT)

Machine Translated by Google
Design de rede de cima para baixo

Terceira edição
Priscila Oppenheimer
Imprensa Cisco
Rua 96 Leste, 800
Indianápolis, IN 46240
ii Projeto de rede de cima para baixo
Design de rede de cima para baixo, terceira edição

Direitos autorais© 2011 Cisco Systems, Inc.
Publicado por:
Imprensa Cisco
Rua 96 Leste, 800
Indianápolis, IN 46240 EUA
Todos os direitos reservados. Nenhuma parte deste livro pode ser reproduzida ou transmitida de qualquer forma ou por qualquer meio,
eletrônico ou mecânico, incluindo fotocópia, gravação ou por qualquer sistema de armazenamento e recuperação de informações, sem
permissão por escrito do editor, exceto para a inclusão de breves citações. em uma revisão.
Impresso nos Estados Unidos da América
Primeira impressão, agosto de 2010
Os dados de catalogação na publicação da Biblioteca do Congresso estão arquivados.
ISBN-13: 978-1-58720-283-4
ISBN-10: 1-58720-283-2
Aviso e isenção de responsabilidade
Este livro foi projetado para fornecer informações sobre o projeto de redes de cima para baixo. Foram feitos todos os esforços para
tornar este livro tão completo e preciso quanto possível, mas nenhuma garantia ou adequação está implícita.
As informações são fornecidas “como estão”. O autor, a Cisco Press e a Cisco Systems, Inc. não terão obrigação nem responsabilidade
perante qualquer pessoa ou entidade com relação a quaisquer perdas ou danos decorrentes das informações contidas neste livro ou do uso
dos discos ou programas que podem acompanhar isto.
As opiniões expressas neste livro pertencem ao autor e não são necessariamente as da Cisco Systems, Inc.
Reconhecimentos de marcas registradas
Todos os termos mencionados neste livro que são conhecidos como marcas registradas ou marcas de serviço foram devidamente
capitalizados. A Cisco Press ou a Cisco Systems, Inc. não podem atestar a exatidão destas informações. O uso de um termo neste livro não
deve ser considerado como afetando a validade de qualquer marca registrada ou marca de serviço.
iii
Vendas Corporativas e Governamentais

A editora oferece excelentes descontos neste livro quando solicitado em grandes quantidades para compras em grandes
quantidades ou vendas especiais, que podem incluir versões eletrônicas e/ou capas personalizadas e conteúdo específico para
seu negócio, objetivos de treinamento, foco de marketing e interesses de marca. Para obter mais informações, entre
em contato com: Vendas Corporativas e Governamentais dos EUA 1-800-382-3419 corpsales@pearsontechgroup.com
Para vendas fora dos Estados Unidos, entre em contato com: Vendas Internacionais international@pearsoned.com
Informações de feedback
Na Cisco Press, nosso objetivo é criar livros técnicos aprofundados da mais alta qualidade e valor. Cada livro
é elaborado com cuidado e precisão, passando por um desenvolvimento rigoroso que envolve a experiência única de
membros da comunidade técnica profissional.
O feedback dos leitores é uma continuação natural deste processo. Se você tiver algum comentário sobre como nós
poderia melhorar a qualidade deste livro ou alterá-lo para melhor atender às suas necessidades, você pode entrar em contato conosco
por e-mail em feedback@ciscopress.com. Certifique-se de incluir o título do livro e o ISBN em seu
mensagem.
Agradecemos sua assistência.
Editor: Paul Boger Gerente, Certificação Global: Erik Ullanderson
Editor associado: Dave Dusthimer Gerente de operações comerciais, Cisco Press: Anand Sundaram
Editora Executiva: Mary Beth Ray Editores Técnicos: Keith Nabozny, Joe Wilson
Editora-chefe: Sandra Schroeder Editor de texto: Bill McManus
Editor sênior de desenvolvimento: Christopher Cleveland Designer do livro: Louisa Adair
Editora Sênior do Projeto: Tonya Simpson Revisor: Serviços de edição de apóstrofo
Assistente Editorial: Vanessa Evans
Composição: Mark Shirar
Indexador: Tim Wright

iv Design de rede de cima para baixo
Sobre o autor
Priscilla Oppenheimer desenvolve sistemas de comunicação de dados e redes desde 1980, quando
obteve seu mestrado em ciência da informação pela Universidade de Michigan. Depois de muitos
anos como desenvolvedora de software, ela se tornou instrutora técnica e desenvolvedora de treinamento
e ensinou mais de 3.000 engenheiros de rede da maioria das empresas da Fortune 500. Seu emprego
em empresas como Apple Computer, Network General e Cisco deu-lhe a oportunidade de
solucionar problemas de projeto de rede do mundo real e a oportunidade de desenvolver uma
metodologia prática para projeto de rede empresarial. Priscilla foi uma das desenvolvedoras do curso
Cisco Internetwork Design e idealizadora do curso Designing Cisco Networks. Priscilla ensina
projeto, configuração e solução de problemas de redes em todo o mundo e pratica o que prega em seu
negócio de consultoria de redes.
Sobre os revisores técnicos

Keith Nabozny é consultor de tecnologia da HP, professor adjunto do Macomb Community College
e graduado pela Oakland University em Rochester, Michigan. Ele possui três certificações profissionais
da Cisco e é Certified Information Systems Security Professional (CISSP). Keith tem apoiado
grandes clientes corporativos nos últimos 14 anos em funções de operações, implementação e
engenharia. Atualmente, ele oferece suporte aos firewalls de um grande fabricante com locais em todo
o mundo. Mais recentemente, ele ministrou aulas de projeto de rede e solução de problemas no
Macomb Community College.
Keith e sua família moram no sudeste de Michigan.
Joe Wilson, MSCS, PMC, CISSP No. 100304, é engenheiro sênior de projeto de rede da TelcoCapital
Systems, LLC. A TelcoCapital é fornecedora líder de soluções de comunicações unificadas
da Cisco para pequenas e médias empresas. Joe está concluindo sua dissertação para doutorado em
tecnologia da informação na Capella University (Minneapolis, MN), com especializações em ensino
universitário e segurança e garantia de TI. Joe trabalhou com tecnologia da informação nos últimos
20 anos e é engenheiro de sistemas aposentado da The Boeing Company em Seattle, Washington,
onde projetou soluções NMS aerotransportadas para aeronaves comerciais. Enquanto trabalhava
para a AT&T Broadband Network Solutions como engenheiro de sistemas de banda larga,
Joe projetou redes comerciais de banda larga usando tecnologias de comunicação avançadas,
como ATM, SONET, DWDM e Gigabit Ethernet. Joe é CISSP desde 2006 e se destacou como um
parceiro confiável no fornecimento de soluções e serviços de comunicações seguras para
organizações públicas e privadas. Joe ministra cursos no programa Cisco Networking Academy na
DeVry University em Federal Way, Washington.
Dedicação
Aos meus pais, Dr. Stephen T. Worland, PhD, e Sra. Roberta Worland, MS. Eles me deram uma
apreciação pelo conhecimento, pela lógica e pela análise, e me ensinaram que “onde há vontade, há
um caminho”.
Agradecimentos
Gostaria de agradecer a Mary Beth Ray, editora executiva da Cisco Press, por me dar a oportunidade
de atualizar este livro e por reunir as pessoas e os recursos necessários para concluir o projeto.
Gostaria de agradecer especialmente a Christopher Cleveland, Tonya Simpson e Bill McManus
pelo seu trabalho árduo no livro. Também sou grato pelo trabalho dos editores técnicos Keith
Nabozny e Joe Wilson. Em muitos aspectos, atualizar um livro é ainda mais difícil do que escrevê-lo,
e eu não teria conseguido sem a ajuda de Chris, Tonya, Bill, Keith e Joe.
Gostaria também de agradecer aos editores técnicos das duas primeiras edições, Matthew
Birkner, Blair Buchanan, Dr. Peter Welcher, Dr. Alex Cannara, David Jansson e Hank Mauldin.
Suas excelentes contribuições ainda são evidentes na terceira edição.
Gostaria de agradecer a outros profissionais de networking que me inspiraram ao longo dos

anos, incluindo Joseph Bardwell e Anita Lenk do Connect802, Laura Chappell e sua fantástica
Wireshark University, Howard Berkowitz, Paul Borghese, John Neiberger, Leigh Anne Chisholm,
Marty Adkins, Matthias David Moore, Tom Lisa, Scott Vermillion e muitos mais.
Sou grato aos meus colegas e estudantes em Ashland, Oregon, que me inspiraram e divertiram,
incluindo Dr. Lynn Ackler, Jeff McJunkin, Andrew Krug, Brandon Kester, Stephen Perkins, Daniel
DeFreeze, Christina Kaiserman, Nicole Colbert, Corey Smith, Stefan Hutchison, Jesse Williamson,
Jonathan McCoy, Jennifer Comstock, Linda Sturgeon, Kathleen Marrs, Vinnie Moscaritolo,
Louis Kowolowski e Robert Luaders por suas ideias sobre os cenários de design.
Gostaria de agradecer a Gary Rubin, Rob Stump e Kip Peterson, da Advanced Network
Information, pelas muitas oportunidades que me deram ao longo dos anos, em especial a excelente
oportunidade de trabalhar na Cisco. Aos meus colegas da Cisco, Patrick Stark, ao nosso gerente,
Lisa Bacani, Walt Sacharok, Dax Mickelson, David Daverso e Paul Azzi; você é ótimo!
Por fim, gostaria de agradecer a Alan Oppenheimer, que ao longo deste projeto atuou como meu
consultor técnico, terapeuta, chef e melhor amigo. Fico feliz que ele não se importe porque
finalmente chegou a hora de remover o AppleTalk.
vi Design de rede de cima para baixo
Resumo do conteúdo
Introdução xxii
Parte I Identificando as necessidades e objetivos do seu cliente 1
Capítulo 1 Analisando Metas e Restrições de Negócios 3
Capítulo 2 Analisando Metas Técnicas e Compensações 25
Capítulo 3 Caracterizando a Rede Existente 59
Capítulo 4 Caracterizando o Tráfego de Rede 87
parte II Projeto de Rede Lógica 117
Capítulo 5 Projetando uma Topologia de Rede 119
Capítulo 6 Projetando Modelos para Endereçamento e Numeração 167
Capítulo 7 Selecionando protocolos de comutação e roteamento 199
Capítulo 8 Desenvolvendo estratégias de segurança de rede 233
Capítulo 9 Desenvolvendo estratégias de gerenciamento de rede 263
Parte III Projeto de Rede Física 281
Capítulo 10 Selecionando Tecnologias e Dispositivos para Redes de Campus 283
Capítulo 11 Selecionando Tecnologias e Dispositivos para Redes Empresariais 319
Parte IV Testando, otimizando e documentando sua rede

Projeto 351
Capítulo 12 Testando seu projeto de rede 353
Capítulo 13 Otimizando seu projeto de rede 367
Capítulo 14 Documentando seu projeto de rede 393
Glossário 407
Índice 435
vii
Conteúdo
Introdução xxii
Parte I Identificando as necessidades e objetivos do seu cliente 1
Capítulo 1 Analisando Metas e Restrições de Negócios 3
Usando uma metodologia de design de rede de cima para baixo 3
Usando um processo de design de rede estruturada 5
Ciclos de Vida de Desenvolvimento de Sistemas 6
Planejar Projeto Implementar Operar Otimizar (PDIOO) Ciclo de Vida da Rede 7
Analisando Metas de Negócios 8
Trabalhando com seu cliente 8
Mudanças nas Redes Empresariais 10

As redes devem fazer sentido para os negócios 10
Redes oferecem um serviço 11
A necessidade de apoiar usuários móveis 12
A importância da segurança e resiliência da rede 12
Metas de negócios típicas de design de rede 13
Identificando o Escopo de um Projeto de Design de Rede 14
Identificando os Aplicativos de Rede de um Cliente 16
Analisando Restrições de Negócios 19

Política e Políticas 19
Restrições Orçamentárias e de Pessoal 20
Cronograma do Projeto 21
Lista de verificação de metas de negócios 22
Resumo 23
Perguntas de revisão 23
Cenário de Projeto 24
Capítulo 2 Analisando Metas Técnicas e Compensações 25
Escalabilidade 25
Planejando a Expansão 26
Expandindo o Acesso aos Dados 26
Restrições à Escalabilidade 27
Disponibilidade 27
Recuperação de Desastres 28
Especificando Requisitos de Disponibilidade 29

viii Projeto de rede de cima para baixo
Disponibilidade de cinco noves 30
O custo do tempo de inatividade 31
Tempo médio entre falhas e tempo médio para reparo 31

Desempenho da Rede 32
Definições de desempenho de rede 33
Utilização ideal da rede 34
Taxa de transferência 35
Taxa de transferência de dispositivos de interligação de redes 36
Taxa de transferência da camada de aplicativo 37
Precisão 38
Eficiência 39
Atraso e Variação de Atraso 40
Causas do Atraso 41
Variação de Atraso 43
Tempo de Resposta 44
Segurança 44
Identificando Ativos de Rede 45
Analisando Riscos de Segurança 46

Ataques de Reconhecimento 47
Ataques de negação de serviço 48
Desenvolvendo Requisitos de Segurança 48
Capacidade de gerenciamento 49
Usabilidade 50
Adaptabilidade 50
Acessibilidade 51
Fazendo compensações no design de rede 52

Lista de Verificação de Metas Técnicas 54
Resumo 55
Capítulo 3 Caracterizando a Rede Existente 59
Caracterizando a Infraestrutura de Rede 59
Desenvolvendo um Mapa de Rede 60
Caracterizando Grandes Internetworks 60
Caracterizando a Arquitetura Lógica 62
Desenvolvendo um Diagrama de Bloco Modular 64
Caracterizando Endereçamento e Nomenclatura de Rede 64

ix
Caracterizando Fiação e Mídia 65
Verificando Restrições Arquitetônicas e Ambientais 68
Verificando um local para uma instalação sem fio 69
Realizando uma pesquisa de site sem fio 70
Verificando a integridade da rede existente 71
Desenvolvendo uma Linha de Base de Desempenho de Rede 72
Analisando a Disponibilidade da Rede 73
Analisando a utilização da rede 73
Medindo a utilização da largura de banda pelo protocolo 75
Analisando a Precisão da Rede 76
Analisando Erros em Redes Ethernet Comutadas 77
Analisando a Eficiência da Rede 79
Analisando Atraso e Tempo de Resposta 80
Verificando o status dos principais roteadores, switches e firewalls 82

Lista de verificação de integridade da rede 83
Resumo 84
Projeto prático 85
Capítulo 4 Caracterizando o Tráfego de Rede 87
Caracterizando o Fluxo de Tráfego 87
Identificando as principais fontes de tráfego e lojas 87
Documentando o fluxo de tráfego na rede existente 89
Caracterizando Tipos de Fluxo de Tráfego para Novas Aplicações de Rede 90
Fluxo de Tráfego Terminal/ Host 91
Fluxo de tráfego cliente/ servidor 91
Fluxo de tráfego ponto a ponto 93
Fluxo de Tráfego Servidor/ Servidor 94
Fluxo de tráfego de computação distribuída 94
Fluxo de tráfego em redes de voz sobre IP 94
Documentando o fluxo de tráfego para redes novas e existentes

Aplicações 95
Caracterizando a Carga de Tráfego 96
Cálculo da carga de tráfego teórica 97
Documentando padrões de uso de aplicativos 99
Refinando estimativas de carga de tráfego causada por aplicativos 99
Estimando a carga de tráfego causada pelos protocolos de roteamento 101

x Projeto de rede de cima para baixo
Caracterizando o Comportamento do Tráfego 101

Comportamento de transmissão/multicast 101
Eficiência da Rede 102

Tamanho do quadro 103
Janelas e controle de fluxo 103
Mecanismos de recuperação de erros 104
Caracterizando Requisitos de Qualidade de Serviço 105
Especificações de QoS ATM 106
Categoria de serviço de taxa de bits constante 107
Categoria de serviço de taxa de bits variável em tempo real 107
Categoria de serviço de taxa de bits variável em tempo não real 107
Categoria de serviço de taxa de bits não especificada 108
Categoria de serviço de taxa de bits disponível 108
Categoria de serviço de taxa de quadros garantida 108
Especificações de QoS do Grupo de Trabalho de Serviços Integrados IETF 109

Serviço de Carga Controlada 110
Serviço Garantido 110
Especificações de QoS do Grupo de Trabalho de Serviços Diferenciados da IETF 111
Requisitos de grau de serviço para aplicações de voz 112
Documentando Requisitos de QoS 113

Lista de verificação de tráfego de rede 114
Resumo 114
Resumo da Parte I 115
parte II Projeto de Rede Lógica 117
Capítulo 5 Projetando uma Topologia de Rede 119
Projeto de Rede Hierárquica 120
Por que usar um modelo hierárquico de design de rede? 121
Topologias planas versus topologias hierárquicas
122 Topologias WAN planas 122
Topologias LAN planas 123
Topologias de malha versus topologias de malha hierárquica
124 Modelo hierárquico clássico de três camadas 125
Camada central 127
Camada de distribuição 127

XI
Camada de Acesso 128
Diretrizes para Projeto de Rede Hierárquica 128
Topologias de Design de Rede Redundante 130
Caminhos de Backup 131
Compartilhamento de Carga 132
Projeto de Rede Modular 133
Arquitetura de referência de segurança Cisco SAFE 133
Projetando uma topologia de design de rede de campus 135
Protocolo Spanning Tree 135
Valores de Custo da Árvore Geradora 136
Protocolo Spanning Tree Rápido 137
Convergência e Reconvergência RSTP 138
Selecionando a Bridge Raiz 139
Dimensionando o Protocolo Spanning Tree 140

LANs Virtuais 141
Projetos VLAN Fundamentais 142

LANs sem fio 144
Posicionando um Ponto de Acesso para Cobertura Máxima 145

WLANs e VLANs 146
Pontos de acesso sem fio redundantes 146
Redundância e compartilhamento de carga em LANs com fio 147
Redundância de Servidor 148
Redundância de estação de trabalho para roteador 150
Protocolo de roteador em espera ativa 152
Protocolo de balanceamento de carga do gateway 153
Projetando a Topologia Enterprise Edge 153
Segmentos WAN Redundantes 153
Diversidade de Circuito 154
Multihoming da conexão com a Internet 154
Rede Privada Virtual 157

VPNs site a site 158
VPNs de acesso remoto 159
Provedor de Serviços Edge 160
Topologias de Design de Rede Segura 162
Planejamento para Segurança Física 162
Atendendo às metas de segurança com topologias de firewall 162

xii Projeto de rede de cima para baixo
Resumo 163
Capítulo 6 Projetando Modelos para Endereçamento e Numeração 167
Diretrizes para Atribuição de Endereços de Camada de Rede 168
Usando um modelo estruturado para endereçamento de camada de rede 168
Administrando Endereços por uma Autoridade Central 169
Autoridade de Distribuição para Endereçamento 170
Usando Endereçamento Dinâmico para Sistemas Finais 170
Endereçamento IP Dinâmico 171
Endereçamento Dinâmico IP Versão 6 174
Rede de Configuração Zero 175
Usando endereços privados em um ambiente IP 175
Advertências com Endereçamento Privado 177

Tradução de endereços de rede 177
Usando um modelo hierárquico para atribuir endereços 178
Por que usar um modelo hierárquico para endereçamento e roteamento? 178
Roteamento Hierárquico 179
Roteamento Interdomínio Sem Classe 179
Roteamento Classless versus Roteamento Classful 180
Sumarização de Rota (Agregação) 181
Exemplo de Resumo de Rota 182
Dicas de Resumo de Rota 183
Sub-redes descontíguas 183

Hosts Móveis 184
Mascaramento de sub-rede de comprimento variável 185
Hierarquia em Endereços IP Versão 6 186

Endereços Link-Local 187
Endereços Unicast Globais 188
Endereços IPv6 com endereços IPv4 incorporados 189
Projetando um Modelo para Nomenclatura 189
Autoridade de Distribuição para Nomeação 190
Diretrizes para Atribuição de Nomes 191
Atribuindo nomes em um ambiente NetBIOS 192
Atribuindo Nomes em um Ambiente IP 193
O Sistema de Nomes de Domínio 193

xiii
Nomes DNS Dinâmicos 194

Resolução de nomes IPv6 195
Resumo 195
Capítulo 7 Selecionando protocolos de comutação e roteamento 199
Tomando Decisões como Parte do Processo de Design de Rede Top-Down 200
Selecionando protocolos de comutação 201
Comutação e as camadas OSI 202
Ponte Transparente 202
Selecionando Aprimoramentos do Protocolo Spanning Tree 203

PortoFast 204
UplinkFast e BackboneFast 204

Detecção de link unidirecional 205
LoopGuard 206
Protocolos para transporte de informações de VLAN 207 IEEE
802.1Q 207
Protocolo de Tronco Dinâmico 208
Protocolo de entroncamento VLAN 208
Selecionando Protocolos de Roteamento 209
Caracterizando Protocolos de Roteamento 209
Protocolos de roteamento de vetor de distância 210
Protocolos de roteamento Link-State 212
Métricas do Protocolo de Roteamento 214
Protocolos de roteamento hierárquicos versus não hierárquicos 214
Protocolos de roteamento interno versus externo 214
Protocolos de roteamento com classe versus sem classe 214
Roteamento dinâmico versus estático e padrão 215
Roteamento sob demanda 216
Restrições de escalabilidade para protocolos de roteamento 216
Convergência do Protocolo de Roteamento 217
Roteamento IP 218
Protocolo de Informações de Roteamento 218
Protocolo de roteamento de gateway interno aprimorado 219
Abra o caminho mais curto primeiro 221
Sistema Intermediário para Sistema Intermediário 224
Protocolo de Gateway de Fronteira 225

xiv Projeto de rede de cima para baixo
Usando vários protocolos de roteamento em uma rede 225
Protocolos de roteamento e o modelo de design hierárquico 226
Redistribuição entre protocolos de roteamento 227
Roteamento Integrado e Ponte 229
Um Resumo dos Protocolos de Roteamento 230
Resumo 231
Capítulo 8 Desenvolvendo estratégias de segurança de rede 233
Projeto de Segurança de Rede 233
Identificando Ativos de Rede 234
Analisando Riscos de Segurança 234
Analisando Requisitos de Segurança e Compensações 235
Desenvolvendo um Plano de Segurança 235
Desenvolvendo uma Política de Segurança 236
Componentes de uma Política de Segurança 237
Desenvolvendo Procedimentos de Segurança 237
Mantendo a Segurança 237
Mecanismos de Segurança 238
Segurança Física 238

Autenticação 239
Autorização 239
Contabilidade (Auditoria) 240
Criptografia de dados 240
Criptografia de chave pública/ privada 241

Filtros de Pacotes 243
Firewalls 244
Sistemas de Detecção e Prevenção de Intrusão 244
Modularizando Design de Segurança 245
Protegendo conexões com a Internet 245
Protegendo Servidores Públicos 246
Protegendo Servidores de Comércio Eletrônico 247
Protegendo acesso remoto e VPNs 248
Protegendo Tecnologias de Acesso Remoto 248
Protegendo VPNs 249
Protegendo Serviços de Rede e Gerenciamento de Rede 250
Protegendo Farms de Servidores 251

xv
Protegendo os Serviços do Usuário 252
Protegendo Redes Sem Fio 253

Autenticação em Redes Sem Fio 254
Privacidade de dados em redes sem fio 258
Resumo 261
Capítulo 9 Desenvolvendo estratégias de gerenciamento de rede 263
Projeto de gerenciamento de rede 263
Gerenciamento Proativo de Rede 264
Processos de gerenciamento de rede 264
Gerenciamento de Falhas 265
Gerenciamento de Configuração 266
Gestão Contábil 266
Gestão de Desempenho 266
Gestão de Segurança 268
Arquiteturas de gerenciamento de rede 269
Monitoramento dentro da banda versus monitoramento fora da banda 270
Monitoramento Centralizado Versus Distribuído 270
Selecionando ferramentas e protocolos de gerenciamento de rede 271
Selecionando Ferramentas para Gerenciamento de Rede 271
Protocolo Simples de Gerenciamento de Rede 271
Bases de Informação de Gestão (MIB) 272
Monitoramento Remoto (RMON) 273
Protocolo de descoberta Cisco 274

Contabilidade Cisco NetFlow 276
Estimando o tráfego de rede causado pelo gerenciamento de rede 276
Resumo 277
Resumo da Parte II 279
Parte III Projeto de Rede Física 281
Capítulo 10 Selecionando Tecnologias e Dispositivos para Redes de Campus 283
Projeto de planta de cabeamento LAN 284
Topologias de Cabeamento 284
Topologias de cabeamento predial 285

xvi Projeto de rede de cima para baixo
Topologias de cabeamento de campus 285

Tipos de Cabos 285
Tecnologias LAN 289
Noções básicas de Ethernet 290
Ethernet e IEEE 802.3 290
Escolhas de tecnologia Ethernet 291
Ethernet Half-Duplex e Full-Duplex 292
Ethernet 292 de 100 Mbps

Ethernet Gigabit 293
Ethernet 295 de 10 Gbps

Selecionando dispositivos de interligação de redes para um projeto de rede de campus 299
Critérios para Seleção de Dispositivos de Interligação de Redes Campus 300
Recursos de otimização em dispositivos de interligação de redes de campus 302
Exemplo de projeto de rede de campus 303
Informações básicas para o projeto de design de rede de campus 303

Metas de negócios 304
Metas Técnicas 304
Aplicações de Rede 305

Comunidades de usuários 306
Armazenamentos de Dados (Servidores) 307
Rede atual em WVCC 307
Características de Tráfego de Aplicações de Rede 310

Resumo dos Fluxos de Tráfego 311
Características de Desempenho da Rede Atual 312

Redesenho de rede para WVCC 313
Endereçamento e roteamento IP otimizados para o backbone do campus 313

Rede sem fio 314
Desempenho e segurança aprimorados para a borda da rede 315

Resumo 316
Capítulo 11 Selecionando Tecnologias e Dispositivos para Redes Empresariais 319
Tecnologias de acesso remoto 320

PPP 321
Multilink PPP e Multichassis Multilink PPP 321
Protocolo de autenticação de senha e handshake de desafio

Protocolo de Autenticação 322
xvii
Acesso remoto ao modem a cabo 323
Desafios associados aos sistemas de modem a cabo 324
Acesso Remoto à Linha de Assinante Digital 325
Outras Implementações DSL 326

PPP e ADSL 326
Selecionando dispositivos de acesso remoto para uma empresa

Projeto de Rede 327
Selecionando Dispositivos para Usuários Remotos 327
Selecionando Dispositivos para o Local Central 328
Tecnologias WAN 328
Sistemas para Provisionamento de Largura de Banda WAN 329

Linhas Alugadas 330
Rede Óptica Síncrona 331
Frame Relay 332
Topologias e subinterfaces Frame Relay Hub-and-Spoke 333
Mecanismos de Controle de Congestionamento Frame Relay 335
Controle de Tráfego Frame Relay 335
Interligação Frame Relay/ ATM 336

Caixa eletrônico 337
Ethernet sobre ATM 337
Metro Ethernet 338
Selecionando roteadores para um projeto de WAN empresarial 339
Selecionando um Provedor de Serviços WAN 340
Exemplo de projeto de WAN 341
Informações básicas para o projeto de design WAN 341

Metas comerciais e técnicas 342

Comunidades de usuários 343
Armazenamentos de Dados (Servidores) 344
Rede Atual 344
Características de tráfego da WAN 345 existente
Projeto WAN para produtos de papel Klamath 346
Resumo 348
Resumo da Parte III 350

xviii Projeto de rede de cima para baixo
Parte IV Testando, otimizando e documentando seu design de rede 351
Capítulo 12 Testando seu projeto de rede 353
Usando testes da indústria 354
Construindo e Testando um Protótipo de Sistema de Rede 355
Determinando o Escopo de um Sistema Protótipo 355
Testando um Protótipo em uma Rede de Produção 356
Escrevendo e implementando um plano de teste para seu projeto de rede 357
Desenvolvendo Objetivos de Teste e Critérios de Aceitação 357
Determinando os tipos de testes a serem executados 358
Documentando Equipamentos de Rede e Outros Recursos 359
Escrevendo scripts de teste 360
Documentando o cronograma do projeto 361
Implementando o Plano de Teste 361
Ferramentas para testar um design de rede 362
Tipos de ferramentas 362
Exemplos de ferramentas de teste de rede 363
Monitor de desempenho de rede CiscoWorks 364
Ferramentas de planejamento e análise de rede WANDL 364
Tecnologias OPNET 364

Ferramentas Ixia 365
Solução de gerenciamento de voz e vídeo NetIQ 365

NetPredictor 365 da NetPredict
Resumo 366
Capítulo 13 Otimizando seu projeto de rede 367
Otimizando o uso da largura de banda com tecnologias IP Multicast 368
Endereçamento Multicast IP 369
Protocolo de gerenciamento de grupo da Internet 370
Protocolos de roteamento multicast 370
Protocolo de roteamento multicast de vetor de distância 371
Multicast Independente de Protocolo 371
Reduzindo o Atraso de Serialização 372
Fragmentação e intercalação de camada de link 373
Protocolo de Transporte em Tempo Real Comprimido 374

XIX
Otimizando o desempenho da rede para atender à qualidade do serviço

Requisitos 374
Precedência de IP e Tipo de Serviço 375
Campo de Serviços Diferenciados IP 376

Protocolo de Reserva de Recursos 377
Protocolo de serviço de política aberta comum 379
Classificando o Tráfego LAN 379
Recursos do Cisco IOS para otimizar o desempenho da rede 380
Técnicas de Troca 380
Métodos Clássicos para Comutação de Pacotes da Camada 3 381
Comutação NetFlow 382
Encaminhamento Expresso Cisco 382
Serviços de filas 383
Fila Primeiro a Entrar, Primeiro a Sair 383
Enfileiramento Prioritário 384
Enfileiramento Personalizado 384
Fila Justa Ponderada 385
Enfileiramento Justo Ponderado Baseado em Classe 386
Enfileiramento de Baixa Latência 387
Detecção Precoce Aleatória 388
Detecção Precoce Aleatória Ponderada 388
Modelagem de Tráfego 389

Taxa de acesso comprometida 389
Resumo 389
Capítulo 14 Documentando seu projeto de rede 393
Respondendo à solicitação de proposta de um cliente 394
Conteúdo de um documento de design de rede 395
Resumo Executivo 396
Meta do Projeto 396
Escopo do Projeto 396
Requisitos de Projeto 397

Metas de Negócios 397
Metas Técnicas 398
Comunidades de usuários e armazenamentos de dados 399

xx Projeto de rede de cima para baixo

Estado Atual da Rede 399
Projeto Lógico 400
Projeto Físico 400

Resultados do teste de design de rede 401
Plano de Implementação 401
Cronograma do Projeto 402
Orçamento do Projeto 403

Retorno do Investimento 403
Apêndice do Documento de Design 404

Resumo 404
Glossário 407
Índice 435
xxi
Ícones usados neste livro
Comunicação computador PC com Sol Macintosh Acesso

Servidor Programas Posto de trabalho Servidor
terminal Arquivo Rede Cisco funciona Modem Impressora

Servidor Servidor Posto de trabalho
DSU/CSU
Porta de entrada Roteador Ponte Eixo DSU/CSU
Catalisador Multicamada Caixa eletrônico

Computador portátil
Trocar Trocar Trocar
Nuvem de rede Linha: Ethernet Linha: Serial IBM

Mainframe
Convenções de sintaxe de comando

As convenções usadas para apresentar a sintaxe de comando neste livro são as mesmas convenções
usado na referência de comandos do Cisco IOS. A Referência de Comando descreve estes
convenções da seguinte forma:
ÿ Negrito indica comandos e palavras-chave que são inseridos literalmente conforme mostrado. Em
exemplos reais de configuração e saída (não sintaxe de comando geral), negrito
indica comandos que são inseridos manualmente pelo usuário (como um comando show ).
ÿ Itálico indica argumentos para os quais você fornece valores reais.
ÿ Barras verticais (|) separam elementos alternativos e mutuamente exclusivos.
ÿ Colchetes ([ ]) indicam um elemento opcional.
ÿ Chaves ({ }) indicam uma escolha obrigatória.
ÿ Chaves entre colchetes ([{ }]) indicam uma escolha obrigatória dentro de um elemento opcional.
xxii Projeto de rede de cima para baixo
Introdução
Novas práticas empresariais estão impulsionando mudanças nas redes empresariais. A transição de um
industrial para uma economia da informação mudou a forma como os funcionários realizam seu trabalho, e o
A emergência de uma economia global com uma competitividade sem precedentes acelerou a
velocidade com que as empresas devem se adaptar às mudanças tecnológicas e financeiras.
Para reduzir o tempo de desenvolvimento e comercialização de produtos, as empresas estão capacitando os funcionários
para tomar decisões estratégicas que exigem acesso a dados de vendas, marketing, financeiros e de engenharia.
Funcionários na sede corporativa e em escritórios de campo em todo o mundo, e
teletrabalhadores em escritórios domésticos precisam de acesso imediato aos dados, independentemente de o
os dados estão em servidores centralizados ou departamentais.
Para desenvolver, vender e distribuir produtos nos mercados interno e externo, as empresas
estão formando alianças com parceiros locais e internacionais. As empresas estão planejando cuidadosamente seus
projetos de rede para atender às metas de segurança e, ao mesmo tempo, oferecer acesso à rede para
revendedores, fornecedores, clientes, clientes em potencial e trabalhadores contratados localizados todos
pelo mundo.
Para acomodar requisitos crescentes de acesso remoto, segurança, largura de banda, escalabilidade e confiabilidade,
fornecedores e órgãos de padronização introduzem novos protocolos e tecnologias em um ritmo rápido. Os designers
de redes são desafiados a desenvolver redes de última geração
mesmo que o estado da arte esteja em constante mudança.
Quer você seja um projetista de rede iniciante ou um arquiteto de rede experiente, provavelmente você se preocupa em
como projetar uma rede que possa acompanhar as mudanças aceleradas no setor de interligação de redes. O objetivo
deste livro é ensinar uma abordagem sistemática
metodologia de design que pode ajudá-lo a atender aos requisitos de uma organização, independentemente de
a novidade ou complexidade de aplicações e tecnologias.
Objetivos
O objetivo do Top-Down Network Design, Terceira Edição, é ajudá-lo a projetar redes que atendam às metas técnicas
e de negócios do cliente. Quer o seu cliente seja
outro departamento da sua própria empresa ou de um cliente externo, este livro fornece
processos e ferramentas testados para ajudá-lo a entender o fluxo de tráfego, o comportamento do protocolo e as
tecnologias de interligação de redes. Depois de completar este livro, você estará equipado
para projetar redes corporativas que atendam aos requisitos de funcionalidade do cliente,
capacidade, desempenho, disponibilidade, escalabilidade, acessibilidade, segurança e capacidade de gerenciamento.
Público
Este livro é para você, se você é um profissional de interligação de redes responsável por projetar
e manutenção de redes empresariais de médio e grande porte. Se você é um engenheiro de rede, arquiteto ou técnico
que possui conhecimento prático de protocolos de rede e
XXIII
tecnologias, este livro fornecerá conselhos práticos sobre como aplicar seu conhecimento ao projeto de redes
interconectadas.
Este livro também inclui informações úteis para consultores, engenheiros de sistemas e vendedores
engenheiros que projetam redes corporativas para clientes. No ambiente acelerado de pré-vendas de muitos engenheiros
de sistemas, muitas vezes é difícil desacelerar e insistir em uma abordagem de análise de sistemas estruturada e de
cima para baixo. Sempre que possível, este livro inclui atalhos e suposições que podem ser feitas para acelerar o processo
de projeto de rede.
Finalmente, este livro é útil para estudantes de graduação e pós-graduação em ciência da computação.
e disciplinas de tecnologia da informação. Alunos que fizeram um ou dois cursos em
teoria das redes encontrará o Top-Down Network Design, Terceira Edição, uma abordagem acessível
introdução às questões de engenharia e negócios relacionadas ao desenvolvimento de redes do mundo real que resolvem
problemas típicos de negócios.
Mudanças para a Terceira Edição

As redes mudaram de muitas maneiras desde a publicação da segunda edição. Muitos
as tecnologias legadas desapareceram e não são mais abordadas no livro. Além disso,
As redes modernas tornaram-se multifacetadas, fornecendo suporte para inúmeras aplicações que exigem muita largura de
banda e uma variedade de dispositivos, desde smartphones a tablet PCs e
servidores de última geração.
Os usuários modernos esperam que a rede esteja disponível o tempo todo, em qualquer dispositivo, e que permita
eles colaboram com segurança com colegas de trabalho, amigos e familiares. As redes hoje suportam
voz, vídeo, TV de alta definição, compartilhamento de área de trabalho, reuniões virtuais, treinamento on-line,
realidade e aplicações que nem podemos imaginar que estudantes universitários brilhantes estejam ocupados
criando em seus dormitórios.
À medida que as aplicações mudam rapidamente e colocam mais demanda nas redes, surge a necessidade de ensinar um
abordagem sistemática ao projeto de rede é ainda mais importante do que nunca. Com essa necessidade
Em mente, a terceira edição foi reformulada para torná-la um livro-texto ideal para estudantes universitários. A terceira
edição apresenta questões de revisão e cenários de design no final de cada
capítulo para ajudar os alunos a aprender o design de rede de cima para baixo.
Para atender às novas demandas das redes modernas, a terceira edição do Top-Down Network
Design também conta com material atualizado sobre os seguintes temas:
ÿ Redundância de rede
ÿ Modularidade em projetos de rede
ÿ A arquitetura de referência de segurança Cisco SAFE
ÿ O protocolo Rapid Spanning Tree (RSTP)
ÿ Protocolo de Internet versão 6 (IPv6)
ÿ Opções de escalabilidade Ethernet, incluindo Ethernet de 10 Gbps e Metro Ethernet
ÿ Ferramentas de design e gerenciamento de rede

xxiv Projeto de rede de cima para baixo
Organização
Este livro foi elaborado com base nas etapas do projeto de rede de cima para baixo. Está organizado em quatro
partes que correspondem às principais fases do projeto da rede.
Parte I: Identificando as necessidades e objetivos do seu cliente

A Parte I cobre a fase de análise de requisitos. Esta fase começa com a identificação do negócio
objetivos e requisitos técnicos. Segue-se a tarefa de caracterizar a rede existente, incluindo a arquitetura e o
desempenho dos principais segmentos e dispositivos de rede.
A última etapa desta fase é analisar o tráfego de rede, incluindo fluxo e carga de tráfego,
comportamento do protocolo e requisitos de qualidade de serviço (QoS).
Parte II: Projeto de Rede Lógica

Durante a fase de projeto da rede lógica, o projetista da rede desenvolve uma topologia de rede. Dependendo do
tamanho da rede e das características do tráfego, a topologia pode
variam do simples ao complexo, exigindo hierarquia e modularidade. Durante esta fase, o
O designer de rede também desenvolve um modelo de endereçamento de camada de rede e seleciona comutação
e protocolos de roteamento. O projeto lógico também inclui planejamento de segurança, projeto de gerenciamento
de rede e a investigação inicial sobre quais provedores de serviços podem atender WAN e
requisitos de acesso remoto.
Parte III: Projeto de Rede Física

Durante a fase de projeto físico, são selecionadas tecnologias e produtos específicos que realizam o projeto lógico. O
projeto da rede física começa com a seleção de tecnologias
e dispositivos para redes de campus, incluindo cabeamento, switches Ethernet, acesso sem fio
pontos, pontes sem fio e roteadores. Segue-se a seleção de tecnologias e dispositivos para acesso remoto e
necessidades de WAN. Além disso, a investigação sobre os prestadores de serviços, que
iniciado durante a fase de projeto lógico, deve ser concluído durante esta fase.
Parte IV: Testando, Otimizando e Documentando Seu Projeto de Rede

As etapas finais no projeto de rede top-down são escrever e implementar um plano de teste, construir
um protótipo ou piloto, otimize o projeto da rede e documente seu trabalho com uma proposta de projeto de rede. Se
os resultados do seu teste indicarem algum problema de desempenho, durante este
fase, você deve atualizar seu design para incluir recursos de otimização como tráfego
modelagem e mecanismos avançados de enfileiramento e comutação de roteadores. Um glossário de termos de rede
conclui o livro.
Site complementar
Top-Down Network Design, Terceira Edição, tem um site complementar em www.topdownbook.com.
O site complementar inclui atualizações do livro, links para white papers e informações complementares
sobre recursos de design.
Parte I
Identificando o seu cliente

Necessidades e objetivos
Capítulo 1 Analisando metas e restrições de negócios
Capítulo 2 Analisando metas técnicas e compensações
Capítulo 3 Caracterizando a rede existente
Capítulo 4 Caracterizando o tráfego de rede

Esta página foi intencionalmente deixada em branco

Capítulo 1
Analisando Negócios
Metas e restrições
Este capítulo serve como uma introdução ao resto do livro, descrevendo de cima para baixo
Design de rede. A primeira seção explica como usar um processo sistemático e descendente
ao projetar redes de computadores para seus clientes. Dependendo do seu trabalho, seu
os clientes podem consistir em outros departamentos da sua empresa, aqueles para os quais você
estão tentando vender produtos ou clientes de sua empresa de consultoria.
Depois de descrever a metodologia, este capítulo se concentra na primeira etapa do projeto de rede de cima para
baixo: analisar as metas de negócios do cliente. As metas de negócios incluem a capacidade de executar
aplicativos de rede para atender aos objetivos de negócios corporativos e a necessidade de
trabalhar dentro das restrições de negócios, como orçamentos, pessoal de rede limitado e
prazos apertados.
Este capítulo também aborda uma importante restrição de negócios que algumas pessoas chamam de
oitava camada do modelo de referência Open System Interconnection (OSI): política no local de trabalho. Para
garantir o sucesso do seu projeto de design de rede, você deve entender todas as políticas corporativas e
políticas nas instalações do seu cliente que possam afetar
seu projecto.
O capítulo termina com uma lista de verificação para ajudá-lo a determinar se você abordou o problema
questões de negócios em um projeto de design de rede.
Usando uma metodologia de design de rede de cima para baixo

De acordo com Albert Einstein:
“O mundo que criamos como resultado do nível de pensamento que desenvolvemos até agora cria
problemas que não podemos resolver no mesmo nível em que os criamos.”
Parafraseando Einstein, os profissionais de redes têm a capacidade de criar redes que

são tão complexos que quando surgem problemas eles não podem ser resolvidos usando o mesmo tipo de
pensamento que foi usado para criar as redes. Acrescente a isso o fato de que cada atualização,
patch e modificação em uma rede também podem ser criadas usando sistemas complexos e às vezes
4 Projeto de rede de cima para baixo
pensamento complicado, e você logo percebe que o resultado é uma rede difícil de entender e
solucionar problemas. Uma rede criada com essa complexidade muitas vezes não tem o desempenho
esperado, não se expande conforme surge a necessidade de crescimento (como acontece quase sempre)
e não atende aos requisitos do cliente. Uma solução para este problema é utilizar uma metodologia
simplificada e sistemática na qual a rede ou atualização é projetada de cima para baixo.
Muitas ferramentas e metodologias de design de rede em uso hoje se assemelham ao jogo “conecte os
pontos” que alguns de nós jogávamos quando crianças. Essas ferramentas permitem colocar dispositivos
de interligação de redes em uma paleta e conectá-los à mídia LAN ou WAN. O problema dessa metodologia
é que ela ignora as etapas de análise dos requisitos do cliente e seleção de dispositivos e mídias com
base nesses requisitos.
Um bom projeto de rede deve reconhecer que os requisitos de um cliente incorporam muitos objetivos
comerciais e técnicos, incluindo requisitos de disponibilidade, escalabilidade, acessibilidade, segurança e
capacidade de gerenciamento. Muitos clientes também desejam especificar um nível exigido de
desempenho da rede, geralmente chamado de nível de serviço. Para atender a essas necessidades,
devem ser feitas escolhas e compensações difíceis no projeto da rede ao projetar a rede lógica, antes
que qualquer dispositivo físico ou mídia seja selecionado.
Quando um cliente espera uma resposta rápida a uma solicitação de projeto de rede, uma metodologia
de projeto de rede ascendente (ligar os pontos) pode ser usada, se as aplicações e objetivos do cliente
forem bem conhecidos. Entretanto, os projetistas de rede muitas vezes pensam que entendem as aplicações
e os requisitos de um cliente apenas para descobrir, após a instalação da rede, que eles não capturaram
as necessidades mais importantes do cliente. Problemas inesperados de escalabilidade e desempenho
aparecem à medida que o número de usuários da rede aumenta. Esses problemas podem ser evitados se
o projetista da rede usar métodos top-down que realizem análise de requisitos antes da seleção da
tecnologia.
O projeto de rede de cima para baixo é uma metodologia para projetar redes que começa nas camadas
superiores do modelo de referência OSI antes de passar para as camadas inferiores. A metodologia top-
down concentra-se em aplicações, sessões e transporte de dados antes da seleção de roteadores,
switches e mídias que operam nas camadas inferiores.
O processo de projeto de rede de cima para baixo inclui a exploração de estruturas organizacionais e de
grupo para encontrar as pessoas para quem a rede fornecerá serviços e de quem o projetista deverá obter
informações valiosas para que o projeto seja bem-sucedido.
O design de rede de cima para baixo também é iterativo. Para evitar ficar atolado em detalhes muito
rapidamente, é importante primeiro obter uma visão geral dos requisitos do cliente. Posteriormente,
mais detalhes poderão ser coletados sobre o comportamento do protocolo, requisitos de escalabilidade,
preferências tecnológicas e assim por diante. O projeto de rede de cima para baixo reconhece que o
modelo lógico e o projeto físico podem mudar à medida que mais informações são coletadas.
Como a metodologia top-down é iterativa, alguns tópicos são abordados mais de uma vez neste livro. Por
exemplo, este capítulo discute aplicações de rede. O Capítulo 4, “Caracterizando o tráfego de
rede”, aborda detalhadamente os aplicativos de rede, com ênfase no tráfego de rede causado por padrões
de uso de aplicativos e protocolos. De cima para baixo
Capítulo 1: Analisando Metas e Restrições de Negócios 5
Essa abordagem permite que um projetista de rede tenha uma “visão geral” primeiro, antes de avançar
para especificações e requisitos técnicos detalhados.
Usando um processo de design de rede estruturada

O projeto de rede de cima para baixo é uma disciplina que surgiu do sucesso da programação de software
estruturado e da análise de sistemas estruturados. O principal objetivo da análise estruturada de sistemas
é representar com mais precisão as necessidades dos usuários, que infelizmente muitas vezes são
ignoradas ou mal representadas. Outro objetivo é tornar o projeto gerenciável, dividindo-o em módulos que
possam ser mais facilmente mantidos e alterados.
A análise de sistemas estruturados possui as seguintes características:
ÿ O sistema é projetado em uma sequência de cima para baixo.
ÿ Durante o projeto de design, diversas técnicas e modelos podem ser usados para caracterizar o sistema
existente, determinar novos requisitos do usuário e propor uma estrutura para o sistema futuro.
ÿ O foco é colocado no fluxo de dados, nos tipos de dados e nos processos que acessam ou alteram
os dados.
ÿ O foco é colocado na compreensão da localização e das necessidades das comunidades de usuários que
acessam ou alteram dados e processos.
ÿ Um modelo lógico é desenvolvido antes do modelo físico. O modelo lógico representa os blocos de
construção básicos, divididos por função, e a estrutura do sistema. O modelo físico representa
dispositivos e tecnologias e implementações específicas.
ÿ As especificações são derivadas dos requisitos coletados no início do

sequência de cima para baixo.
Em grandes projetos de design de rede, a modularidade é essencial. O design deve ser dividido
funcionalmente para tornar o projeto mais gerenciável. Por exemplo, as funções executadas em LANs
de campus podem ser analisadas separadamente das funções executadas em redes de acesso
remoto, redes privadas virtuais (VPN) e WANs.
A Cisco recomenda uma abordagem modular com seu modelo hierárquico de três camadas. Este
modelo divide as redes em camadas principais, de distribuição e de acesso. A arquitetura Cisco SAFE,
discutida na Parte II deste livro, “Projeto lógico de rede”, é outra abordagem modular para projeto de rede.
Com uma abordagem estruturada para projeto de rede, cada módulo é projetado separadamente, mas em
relação a outros módulos. Todos os módulos são projetados usando uma abordagem top-down que se
concentra nos requisitos, nas aplicações e em uma estrutura lógica antes da seleção dos dispositivos
físicos e produtos para implementar o projeto.
Ciclos de vida de desenvolvimento de sistemas
Os estudantes de análise de sistemas estão familiarizados com o conceito de que sistemas típicos são desenvolvidos e
continuam a existir durante um período de tempo, muitas vezes chamado de ciclo de vida de desenvolvimento de sistemas.
Muitos livros de análise de sistemas usam a sigla SDLC para se referir ao ciclo de vida do sistema, o que pode
parecer estranho para estudantes de redes mais velhos que conhecem SDLC como Synchronous Data
Link Control, um protocolo full-duplex orientado a bits usado em links seriais síncronos, frequentemente encontrado em
um ambiente legado de Systems Network Architecture (SNA).
No entanto, é importante perceber que a maioria dos sistemas, incluindo sistemas de rede, segue um conjunto cíclico
de fases, onde o sistema é planejado, criado, testado e otimizado.
O feedback dos usuários do sistema faz com que o sistema seja redesenhado ou modificado, testado e otimizado
novamente. Novos requisitos surgem à medida que a rede abre a porta para novos usos. À medida que as pessoas se
habituam à nova rede e tiram partido dos serviços que ela oferece, rapidamente a consideram um dado adquirido e
esperam que ela faça mais.
Neste livro, o projeto de rede é dividido em quatro fases principais que são realizadas de forma cíclica:
ÿ Analisar requisitos: nesta fase, o analista de rede entrevista usuários e técnicos

pessoal técnico para obter uma compreensão dos objetivos comerciais e técnicos de um sistema novo ou
aprimorado. Segue-se a tarefa de caracterizar a rede existente, incluindo a topologia lógica e física e o
desempenho da rede. A última etapa desta fase é analisar o tráfego de rede atual e futuro, incluindo fluxo e carga
de tráfego, comportamento do protocolo e requisitos de qualidade de serviço (QoS).
ÿ Desenvolver o projeto lógico: Esta fase trata de uma topologia lógica para a rede nova ou aprimorada,
endereçamento da camada de rede, nomenclatura e protocolos de comutação e roteamento. O projeto lógico
também inclui planejamento de segurança, projeto de gerenciamento de rede e a investigação inicial sobre quais
provedores de serviços podem atender aos requisitos de WAN e acesso remoto.
ÿ Desenvolver o projeto físico: Durante a fase de projeto físico, tecnologias específicas

São selecionados produtos e produtos que realizam o design lógico. Além disso, a investigação sobre os
prestadores de serviços, que começou durante a fase de concepção lógica, deve ser concluída durante esta
fase.
ÿ Testar, otimizar e documentar o projeto: As etapas finais do projeto de rede de cima para baixo são escrever e
implementar um plano de teste, construir um protótipo ou piloto, otimizar o projeto de rede e documentar seu
trabalho com uma proposta de projeto de rede.
Essas principais fases do projeto de rede se repetem à medida que o feedback do usuário e o monitoramento da rede
sugerem melhorias ou a necessidade de novos aplicativos. A Figura 1-1 mostra o ciclo de projeto e implementação da
rede.
Analisar
Requisitos
Monitore Desenvolver
e otimize Lógico
Rede
Projeto
Desempenho
Implementar Desenvolver
e testar Físico
Rede Projeto
Teste, otimize
e documente
Projeto
Figura 1-1 Ciclo de projeto e implementação de rede
Planejar, projetar, implementar, operar, otimizar (PDIOO) ciclo de vida da rede

A documentação da Cisco refere-se ao conjunto de fases Plan Design Implement Operate Optimize (PDIOO)
para o ciclo de vida de uma rede. Não importa qual ciclo de vida você usa, desde que você perceba que o projeto
da rede deve ser realizado de forma estruturada, planejada e modular, e que o feedback dos usuários da rede
operacional deve ser realimentado em novos projetos de rede para melhorar ou redesenhar a rede. O ciclo de vida
do PDIOO inclui as seguintes etapas:
ÿ Planejar: Os requisitos de rede são identificados nesta fase. Esta fase inclui também uma análise das áreas
onde a rede será instalada e uma identificação dos usuários que necessitarão dos serviços da rede.
ÿ Projeto: Nesta fase, os projetistas da rede realizam a maior parte do projeto lógico e físico, de acordo com os
requisitos coletados durante a fase de planejamento.
ÿ Implementar: Após a aprovação do projeto, a implementação começa. A rede é construída de acordo com
as especificações do projeto. A implementação também serve para verificar o design.
ÿ Operar: A operação é o teste final da eficácia do projeto. A rede é monitorada durante esta fase em busca de
problemas de desempenho e quaisquer falhas para fornecer informações para a fase de otimização do
ciclo de vida da rede.
ÿ Otimizar: A fase de otimização baseia-se no gerenciamento proativo da rede que identifica e resolve problemas
antes que surjam interrupções na rede. A fase de otimização pode levar a um redesenho da rede se
surgirem muitos problemas devido a erros de projeto ou à medida que o desempenho da rede se degrada ao
longo do tempo, à medida que o uso e as capacidades reais divergem.
O redesenho também pode ser necessário quando os requisitos mudam significativamente.
ÿ Desativar: quando a rede, ou parte da rede, estiver desatualizada, poderá ser retirada de produção.
Embora a Aposentação não esteja incorporada ao nome do ciclo de vida (PDIOO), não deixa de ser
uma fase importante. A fase de aposentadoria envolve a fase de planejamento. O ciclo de vida do
PDIOO se repete à medida que os requisitos da rede evoluem.
A Figura 1-2 mostra uma representação gráfica do ciclo de vida da rede Cisco PDIOO.
P Plano P
Ó Projeto D
R Eu implemento
D
Ó operar
Ó Ó Otimizar
Aposentar-se
EU
Figura 1-2 Ciclo de vida da rede PDIOO
Analisando metas de negócios

Compreender as metas e restrições de negócios do seu cliente é um aspecto crítico do projeto da rede.
Armado com uma análise completa dos objetivos de negócios do seu cliente, você pode propor um projeto
de rede que terá a aprovação do seu cliente.
É tentador ignorar a etapa de análise das metas de negócios, porque a análise de metas técnicas
como capacidade, desempenho, segurança e assim por diante é mais interessante para muitos
engenheiros de rede. O Capítulo 2, “Analisando Metas Técnicas e Compensações”, aborda a análise de
metas técnicas. Neste capítulo, você aprenderá a importância de analisar as metas de negócios e
aprenderá algumas técnicas para combinar uma proposta de projeto de rede com os objetivos de negócios
de um cliente.
Trabalhando com seu cliente

Antes de se reunir com seu cliente para discutir as metas de negócios do projeto de design de rede, é
uma boa ideia pesquisar o negócio do seu cliente. Descubra em que setor o cliente atua. Aprenda algo
sobre o mercado, fornecedores, produtos, serviços e vantagens competitivas do cliente. Com o
conhecimento do negócio do seu cliente e de suas relações externas, você pode posicionar
tecnologias e produtos para ajudar a fortalecer o status do cliente em seu próprio setor.
Na sua primeira reunião com seus clientes, peça-lhes que expliquem a estrutura organizacional da
empresa. Seu projeto final de interligação de redes provavelmente refletirá a estrutura corporativa, por
isso é uma boa ideia entender como a empresa está estruturada em departamentos, linhas de negócios,
fornecedores, parceiros e escritórios remotos ou de campo.
Compreender a estrutura corporativa pode ajudá-lo a localizar as principais comunidades de usuários e
caracterizar o fluxo de tráfego. O Capítulo 4 aborda o fluxo de tráfego com mais detalhes. Compreender
a estrutura corporativa também pode ajudá-lo a compreender a cultura corporativa, o que pode afetar o
design da rede. Por exemplo, uma empresa com uma estrutura de gestão centralizada pode exigir que
os produtos e fornecedores sejam escolhidos pela gestão da sede. Uma empresa descentralizada
pode permitir que as filiais tenham mais voz.
Nota Compreender a estrutura corporativa também pode ajudá-lo a reconhecer a hierarquia de

gerenciamento. Um dos seus principais objetivos nos estágios iniciais de um projeto de design de rede
deve ser determinar quem são os tomadores de decisão. Quem terá autoridade para aceitar ou rejeitar sua
proposta de projeto de rede? Por vezes, esta pode ser uma questão bastante complicada, conforme discutido
na secção “Política e Políticas”, mais adiante neste capítulo.
Peça ao seu cliente para definir um objetivo geral do projeto de design de rede. Explique que você
deseja uma declaração curta e voltada para os negócios que destaque o propósito comercial da nova rede.
Por que o cliente está embarcando neste novo projeto de rede? Para que será usada a nova rede? Como
a nova rede ajudará o cliente a ter mais sucesso nos negócios do cliente?
Depois de discutir as metas comerciais gerais do projeto de design de rede, peça ao seu cliente para
ajudá-lo a entender os critérios do cliente para o sucesso. Quais metas devem ser cumpridas para que o
cliente fique satisfeito? Às vezes, o sucesso baseia-se em poupanças operacionais porque a nova
rede permite que os funcionários sejam mais produtivos. Às vezes, o sucesso se baseia na capacidade de
aumentar a receita ou construir parcerias com outras empresas.
Certifique-se de saber antecipadamente como o “sucesso” é definido por executivos, gerentes,
usuários finais, engenheiros de rede e quaisquer outras partes interessadas. Além disso, determine se
a definição de sucesso do cliente mudará à medida que as metas fiscais anuais mudarem.
Além de determinar os critérios de sucesso, você deve verificar as consequências do fracasso:
ÿ O que acontecerá se o projeto de design da rede falhar ou se a rede, quando em

parado, não funciona conforme a especificação?
ÿ Quão visível é o projeto para a gestão de nível superior?
ÿ O sucesso (ou possível fracasso) do projeto ficará visível para os executivos?
ÿ Até que ponto o comportamento imprevisto da nova rede poderia perturbar as operações comerciais
ações?
Em geral, reúna informações suficientes para se sentir confortável ao compreender a extensão e a

visibilidade do projeto de design de rede.
Você deve tentar obter uma visão geral sobre se a nova rede é crítica para a missão da empresa.
Investigue as ramificações da falha ou problemas da rede. O Capítulo 2 discute os detalhes da análise
de desempenho e confiabilidade, mas neste ponto do processo de design você deve começar a abordar
essas questões. (Lembre-se disso
o design de rede de cima para baixo é iterativo. Muitos requisitos de projeto de rede são abordados
mais de uma vez.)
Mudanças nas redes empresariais

As redes empresariais em muitas corporações têm passado por grandes mudanças. O valor de
disponibilizar grandes quantidades de dados a funcionários, clientes e parceiros de negócios foi
reconhecido. Funcionários corporativos, funcionários de campo, funcionários contratados e
teletrabalhadores precisam de acesso a dados de vendas, marketing, engenharia e financeiros,
independentemente de os dados estarem armazenados em servidores centralizados ou distribuídos
ou em quadros principais. Fornecedores, vendedores e clientes também precisam de acesso a muitos tipos de dados.
Uma rede usada apenas por usuários internos não é mais a norma em muitas empresas.
As empresas procuram formas de construir redes que se assemelhem mais às organizações modernas.
Muitas organizações modernas baseiam-se num ambiente aberto e colaborativo que proporciona
acesso a informações e serviços a muitos constituintes diferentes, incluindo clientes, potenciais clientes,
vendedores, fornecedores e funcionários.
Para permanecerem competitivas, as empresas precisam de formas de reduzir o tempo de

desenvolvimento de produtos e tirar partido dos princípios de produção just-in-time. Muitas empresas
alcançam esses objetivos estabelecendo parcerias com fornecedores e promovendo um
relacionamento online e interativo com seus fornecedores. Um exemplo é a fabricação de automóveis. Em
vez de produzir internamente todos os componentes automotivos, muitos fabricantes contratam
parceiros especializados em componentes e tecnologias específicas. Por exemplo, um parceiro pode
produzir o motor enquanto outro produz a carroceria. Se todos os parceiros puderem acessar dados e
serviços na rede do fabricante, os custos de produção serão reduzidos, a fabricação just-in-time poderá
ser realizada e será mais fácil planejar em torno da escassez de componentes. A capacidade de
compartilhar informações economiza tempo e dinheiro para o fabricante de automóveis e para seus
parceiros.
Um projetista de rede deve considerar cuidadosamente os requisitos para estender a rede a usuários
externos. Por razões de segurança, o acesso externo não deve significar acesso total à rede.
Usar uma abordagem modular para o projeto de rede é importante aqui, para que exista um limite claro
entre as redes privadas da empresa e as partes da rede que os parceiros podem acessar.
As redes devem fazer sentido para os negócios
Embora no passado muitas empresas tenham feito escolhas “tecnologia pela tecnologia”, este já não é
o caso. Os líderes empresariais estão mais envolvidos nas decisões de Tecnologia da Informação (TI)
do que antes, e os gestores de TI contam com os gestores de negócios para ajudá-los a priorizar e
financiar projetos de TI. As atualizações de rede não são feitas porque alguma nova tecnologia pareça
interessante para os engenheiros, mas porque ajudará uma empresa a aumentar os lucros, a
produtividade, a participação no mercado e o fluxo de caixa. Os designers de redes devem
escolher soluções que abordem os dilemas empresariais enfrentados pelos gestores empresariais.
Os aplicativos de rede tornaram-se de missão crítica. Apesar desta tendência, grandes orçamentos para
operações de redes e telecomunicações foram reduzidos em algumas empresas.
Muitas empresas passaram por difíceis projetos de reengenharia para reduzir custos operacionais
e ainda buscam maneiras de gerenciar redes com menos recursos e de reduzir os custos recorrentes
dos circuitos WAN.
As empresas estão pesquisando maneiras de tornar seus data centers mais eficientes no uso de
energia, cabeamento, racks, armazenamento e circuitos WAN. As empresas procuram reduzir os
custos dos centros de dados e torná-los mais “verdes” (pelo que a utilização de energia é reduzida). Os
gerentes de data centers descobriram que muitas das CPUs de seus servidores são subutilizadas.
Uma tendência importante no design de redes corporativas é a virtualização de servidores, onde
uma plataforma de hardware suporta vários servidores virtuais. Em vez de muitas caixas de hardware
subutilizadas, existem agora apenas algumas caixas de hardware, cada uma das quais suporta vários servidores virtuais.
Cada servidor virtual parece e funciona como um servidor físico, incluindo um sistema operacional
totalmente funcional e um ou mais aplicativos.
A racionalização de processos e protocolos também levou a um aumento da utilização da telefonia IP e

à convergência contínua de redes de voz e dados. Para economizar dinheiro e reduzir a necessidade
de engenheiros especializados de dados ou voz, as empresas continuam a adotar tecnologias de
telefonia IP. Nos projetos de rede anteriores, as redes de telecomunicações e de voz eram separadas.
Os engenheiros de telecomunicações sabiam pouco sobre redes de dados, e os engenheiros de
comunicações de dados não sabiam a diferença entre um multiplexador por divisão de tempo (TDM) e
um sistema de comutação tandem (TSS). No ambiente atual, as redes de voz, dados e vídeo estão
mescladas.
Redes oferecem um serviço
Os departamentos de TI modernos são mais orientados a serviços do que costumavam ser. Para
atender às necessidades de seus clientes, os departamentos de TI estão gastando mais tempo
analisando e documentando seus processos de prestação de serviços. O foco nos processos ajuda
a garantir a prestação eficaz de serviços e a evitar gastos desperdiçados em tecnologia que não
fornece um serviço necessário.
Como designer de rede, você pode trabalhar com arquitetos de TI que aderem à disciplina de
gerenciamento de serviços de TI (ITSM). ITSM define estruturas e processos que podem ajudar uma
organização a combinar a entrega de serviços de TI com as necessidades de negócios da organização.
O ITSM concentra-se em processos e não em tecnologia e ajuda uma organização de TI a pensar
em seus usuários como clientes valiosos, em vez de adversários geradores de problemas. Uma versão
do ITSM está documentada na Information Technology Infrastructure Library (ITIL), uma série de
livros publicados pelo Escritório de Comércio Governamental do Reino Unido (OGC), cada um dos quais
cobre um tópico de gerenciamento de TI. Os detalhes do ITSM e do ITIL estão fora do escopo deste
livro, mas vale a pena notar que tanto o ITSM quanto o projeto de rede de cima para baixo atendem
à necessidade de alinhar a entrega de serviços de TI às necessidades de negócios de uma
organização. Este livro o ajudará a projetar redes que cumpram as práticas de ITSM.
Outras tendências na gestão de TI que afetam o projeto da rede estão relacionadas à governança e à
conformidade. Governança refere-se ao foco em decisões, políticas e processos consistentes e coesos
que protegem uma organização contra má gestão e atividades ilegais de usuários de serviços de TI.
Compliance refere-se à adesão a regulamentos que protegem contra fraude
e divulgação inadvertida de dados privados de clientes. Por exemplo, nos Estados Unidos, as organizações
retalhistas devem cumprir o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) e
as organizações de saúde devem cumprir a Lei de Portabilidade e Responsabilidade de Seguros de
Saúde (HIPAA).
A necessidade de oferecer suporte aos usuários móveis
Os notebooks finalmente se tornaram pequenos o suficiente para serem transportados, e os trabalhadores

agora esperam realizar o trabalho em casa, no trem, nos hotéis, nas salas de reuniões, nas instalações dos
clientes e até mesmo enquanto tomam seu café com leite matinal na cafeteria local. . Os notebooks são
fornecidos com rede sem fio integrada para facilitar aos usuários a realização de trabalhos fora do escritório.
Não deveria importar (pelo menos para o usuário) onde estão os dados e em que formato. Os usuários da rede
esperam que o desempenho da rede seja uniforme, independentemente de onde o usuário ou os dados residem.
Um usuário deve ser capaz de ler e-mails em um telefone celular, por exemplo, e ler mensagens de voz em
um navegador da Web enquanto toma um café em um cibercafé. Os usuários devem ter acesso seguro e
confiável a ferramentas e dados onde quer que estejam. O desafio para os projetistas de redes é construir redes
que permitam que os dados entrem e saiam da rede corporativa a partir de vários portais com e sem fio,
sem contrair vírus e sem serem lidos por pessoas a quem não se destinam.
Uma das maiores tendências no design de redes são as redes privadas virtuais (VPN), nas quais as redes
privadas utilizam a Internet para chegar a locais remotos ou possivelmente a outras organizações. Os
clientes envolvidos em projetos de VPN têm preocupações com segurança, desempenho confiável e previsível
e requisitos de transferência de dados. O Capítulo 5, “Projetando uma topologia de rede”, aborda VPNs
com mais detalhes.
As arquiteturas de rede estão assumindo uma forma virtual e onipresente para os usuários, embora permaneçam
altamente estruturadas e gerenciadas do ponto de vista dos engenheiros de rede. O designer é desafiado
a desenvolver soluções seguras, resilientes e gerenciáveis que permitam aos usuários trabalhar com eficiência
e segurança onde quer que estejam fisicamente localizados.
A importância da segurança e resiliência da rede

A segurança de rede chegou ao topo da lista de objetivos de negócios em muitas empresas.
Embora a segurança sempre tenha sido importante, tornou-se ainda mais importante à medida que as redes se
tornam indispensáveis e que as ferramentas para invadir redes se tornam omnipresentes.
As empresas devem proteger as suas redes tanto dos “script kiddies” pouco sofisticados como de ataques
mais avançados lançados por criminosos ou inimigos políticos. Há também uma necessidade contínua de
proteger as redes contra cavalos de Tróia e vírus.
Muitos gestores empresariais relatam agora que a rede deve estar disponível 99,999% do tempo. Embora este
objectivo possa não ser alcançável sem redundância dispendiosa de pessoal e equipamento, pode ser um
objectivo razoável para empresas que sofreriam uma grave perda de receitas ou credibilidade se a rede ficasse
inactiva, mesmo por curtos períodos de tempo. Este objectivo está ligado a objectivos de segurança, uma vez
que a rede não pode estar disponível se a segurança
violações e vírus estão desativando dispositivos e aplicativos de rede. Quando ocorrem problemas
operacionais e de segurança, as redes devem se recuperar rapidamente. As redes devem ser resilientes.
Mais do que nunca, os gerentes de TI e de negócios exigem recursos de alta disponibilidade e resiliência
para seus equipamentos e protocolos de rede, pois percebem até que ponto o tempo de inatividade
da rede pode comprometer o sucesso dos negócios.
Além da segurança, outra meta que foi filtrada para o topo da lista de metas de negócios é a
necessidade de continuidade dos negócios durante e após um desastre. As empresas que sobreviveram
a furacões, terremotos, incêndios e ataques terroristas aprenderam a importância de um plano de
recuperação de desastres que promova a continuidade dos negócios, apesar da perda de dispositivos
e serviços de rede críticos. Muitas empresas não tiveram a infelicidade de aprender estas lições da
maneira mais difícil, mas mesmo assim estão a embarcar em projectos de concepção de redes com
o objectivo de desenvolver uma rede que se recupere rapidamente caso ocorra um desastre natural ou
não natural.
Um aspecto da análise das metas de negócios de um cliente é o processo de análise de vulnerabilidades

relacionadas a desastres e o impacto nas operações de negócios. Ajude seu cliente a determinar
quais recursos de rede são críticos e quais instalações os fornecem.
Considere quanto da rede poderia ser danificada sem interromper completamente a missão da empresa.
Determine se outros locais da empresa estão preparados para assumir funções de missão crítica.
Nos últimos anos, as redes tornaram-se mais interconectadas e complexas, o que pode dificultar o
cumprimento das metas de continuidade dos negócios e resiliência da rede.
Muitas redes empresariais estão ligadas a redes domésticas de teletrabalhadores, redes de filiais,
extranets que oferecem acesso a parceiros de negócios e clientes e à Internet.
A diversidade e a quantidade de portais na rede corporativa representam muitos riscos de segurança e
estabilidade. Por outro lado, a diversidade geográfica de capacidades de missão crítica revelou-se um
salva-vidas para algumas empresas atingidas por desastres. Uma razão pela qual o Wall Street
Journal conseguiu publicar o seu jornal no dia seguinte aos ataques de 11 de Setembro foi porque tinha
aprendido com os cortes de energia na década de 1990 sobre a necessidade de dispersar funções
críticas em muitos locais diferentes.
No atual ambiente de negócios, a segurança e a recuperação de desastres devem ser consideradas em

todas as opções de projeto de rede, e o projetista da rede deve propor soluções que proporcionem
resiliência e estabilidade. Um processo de design sistemático e modular, conforme ensinado neste
livro, é ainda mais importante do que já foi, à medida que as redes se tornam cada vez mais
complexas e vitais para o sucesso de uma organização.
Metas típicas de negócios de design de rede

Depois de considerar as mudanças nas estratégias de negócios e nas redes corporativas discutidas nas
seções anteriores, é possível listar alguns objetivos típicos de negócios de design de rede:
ÿ Aumentar a receita e o lucro
ÿ Aumentar a participação no mercado

ÿ Expandir para novos mercados
ÿ Aumentar as vantagens competitivas sobre empresas do mesmo mercado
ÿ Reduzir custos
ÿ Aumentar a produtividade dos funcionários
ÿ Encurtar os ciclos de desenvolvimento de produtos
ÿ Use a fabricação just-in-time
ÿ Planeje em torno da escassez de componentes
ÿ Oferecer novos serviços ao cliente
ÿ Ofereça melhor suporte ao cliente
ÿ Abrir a rede para os principais constituintes (potenciais clientes, investidores, clientes, parceiros de
negócios, fornecedores e funcionários)
ÿ Evite interrupções nos negócios causadas por problemas de segurança de rede
ÿ Evitar interrupções nos negócios causadas por desastres naturais e não naturais
ÿ Modernizar tecnologias obsoletas
ÿ Reduzir os custos de telecomunicações e de rede, incluindo despesas gerais associadas a

redes separadas para voz, dados e vídeo
ÿ Tornar os data centers mais eficientes no uso de energia, cabeamento, racks, armazenamento e
Circuitos WAN
ÿ Cumprir as metas de design e governança da arquitetura de TI
Identificando o escopo de um projeto de design de rede

Um dos primeiros passos para iniciar um projeto de design de rede é determinar seu escopo. Alguns dos projetos
de design de rede mais comuns atualmente são de escopo pequeno – por exemplo, projetos que permitem
que algumas pessoas em um escritório de vendas acessem a rede corporativa por meio de uma VPN. Por outro
lado, alguns projetos de design são de grande alcance. Peça ao seu cliente para ajudá-lo a entender se o projeto
é para um único segmento de rede, um conjunto de LANs, um conjunto de WANs ou redes de acesso remoto ou
toda a rede corporativa. Pergunte também ao seu cliente se o projeto é para uma nova rede ou uma
modificação de uma rede existente.
Explique ao seu cliente quaisquer preocupações que você tenha sobre o escopo do projeto, incluindo questões
técnicas e comerciais. As seções subsequentes deste capítulo discutem política e programação, que estão
intimamente ligadas ao escopo de um projeto de design de rede. (Muitos projetistas de rede aprenderam da
maneira mais difícil o que acontece quando você não ajuda seus clientes a adequar os cronogramas de seus
projetos ao escopo.)
Certifique-se de que seus clientes contem tudo o que puderem sobre a rede e o projeto de design. Você pode
querer fuçar fora do escopo declarado do projeto, apenas para ter certeza de que nada essencial foi omitido.
Verifique novamente se você reuniu todos
os requisitos e que você tenha informações precisas sobre sites, links e dispositivos. Se o projeto abordar
segurança de rede, certifique-se de conhecer todos os links externos, incluindo qualquer acesso
discado legado.
Nota Os designers raramente têm a oportunidade de projetar uma rede do zero. Normalmente, um projeto
de design de rede envolve uma atualização de uma rede existente. No entanto, nem sempre é esse o caso.
Alguns projetistas de redes experientes desenvolveram redes completamente novas de próxima geração
para substituir redes antigas. Outros designers projetaram redes para um novo edifício ou novo campus.
Mesmo nesses casos, porém, a nova rede geralmente precisa se ajustar a uma infraestrutura existente
— por exemplo, uma nova rede de campus que precisa se comunicar com uma WAN existente. Quando já
existir uma rede, o projecto de concepção deve incluir planos de migração para a nova concepção com
o mínimo de perturbações e riscos.
Ao analisar o escopo de um projeto de rede, você pode consultar as sete camadas do modelo de
referência OSI para especificar os tipos de funcionalidade que o novo projeto de rede deve abordar. Por
exemplo, você pode decidir que o projeto de design se preocupa apenas com questões da camada de
rede, como roteamento e endereçamento IP. Ou você pode decidir que o design também diz respeito à
camada de aplicação porque o foco está em aplicações de voz, como Resposta de Voz Interativa
(IVR), que direciona os clientes para o local correto em uma central de atendimento, ou mensagens
unificadas, onde o e-mail pode ser recuperado via correio de voz e mensagens de texto podem ser
convertidas em fala. A Figura 1-3 mostra o modelo de referência OSI.
Camada 7 Aplicativo
Camada 6 Apresentação
Camada 5 Sessão
Camada 4 Transporte
Camada 3 Rede
Camada 2 Link de dados
Camada 1 Físico
Figura 1-3 Modelo de referência de interconexão de sistema aberto (OSI)
Além de usar o modelo de referência OSI, este livro também usa os seguintes termos para definir o
escopo de uma rede e o escopo de um projeto de design de rede:
ÿ Segmento: Uma única rede delimitada por um switch ou roteador e baseada em um protocolo específico
de Camada 1 e Camada 2, como Fast Ethernet.
ÿ LAN: Um conjunto de segmentos comutados baseados em um protocolo específico de Camada 2, como

Fast Ethernet, e um protocolo de entroncamento entre comutadores, como o padrão IEEE 802.1Q.
ÿ Rede predial: múltiplas LANs dentro de um prédio, geralmente conectadas a um prédio

rede principal.
ÿ Rede de campus: Vários edifícios dentro de uma área geográfica local (dentro de alguns
milhas), geralmente conectado a uma rede backbone do campus.
ÿ Acesso remoto: soluções de rede que oferecem suporte a usuários remotos individuais ou pequenos
filiais remotas acessando a rede.
ÿ WAN: Uma rede geograficamente dispersa, incluindo ponto a ponto, Frame Relay,
ATM e outras conexões de longa distância.
ÿ Rede sem fio: Uma LAN ou WAN que utiliza o ar (em vez de um cabo) para sua
médio.
ÿ Rede empresarial: uma rede grande e diversificada, composta por campi, centros remotos
serviços de acesso e uma ou mais WANs ou LANs de longo alcance. Uma rede corporativa também é
chamada de interligação de redes.
Identificando os aplicativos de rede de um cliente

Neste ponto do processo de design, você identificou os objetivos de negócios do seu cliente e o
escopo do projeto. Agora é hora de nos concentrarmos na verdadeira razão pela qual as redes
existem: os aplicativos. A identificação das aplicações do seu cliente deve incluir tanto as aplicações
atuais como as novas aplicações. Peça ao seu cliente para ajudá-lo a preencher uma tabela, como
a da Tabela 1-1.
Observação A Tabela 1-1 identifica os aplicativos de rede. Nos Capítulos 2 e 4, será aprimorado para
incluir requisitos técnicos e características de tráfego de rede. Neste ponto, seu objetivo é
simplesmente identificar aplicações de rede.
Tabela 1-1 Aplicações de Rede
Nome de Tipo de Nova aplicação? (Sim ou não) Comentários de criticidade

Aplicativo Aplicativo
Para Nome do aplicativo, basta usar o nome fornecido pelo cliente. Pode ser um nome padrão do setor,
como Lotus Notes, ou pode ser um nome de aplicativo que signifique algo apenas para o cliente
(especialmente para um aplicativo desenvolvido internamente). Para novos aplicativos, o nome
pode ser um codinome para um projeto de desenvolvimento de software.
Para Tipo de aplicativo, você pode usar qualquer texto apropriado que descreva o tipo de aplicativo ou
pode classificar o aplicativo como um dos seguintes aplicativos de rede padrão:
ÿ E-mail
ÿ Transferência, compartilhamento e acesso de arquivos
ÿ Acesso e atualização do banco de dados
ÿ Navegação na Web
ÿ Jogo em rede
ÿ Terminal remoto
ÿ Calendário
ÿ Imagens médicas
ÿ Videoconferência
ÿ Vídeo sob demanda (VoD)
ÿ Vídeo multicast programado
ÿ Vídeo de câmeras de vigilância e segurança
ÿ Voz da Internet ou intranet (telefonia IP)
ÿ Fax via Internet ou intranet
ÿ Entrada de pedido de venda
ÿ Relatórios de gestão
ÿ Acompanhamento de vendas
ÿ Projeto auxiliado por computador
ÿ Imagem de documentos
ÿ Controle de estoque e envio
ÿ Telemetria
ÿ Resposta de voz interativa (IVR)
ÿ Mensagens unificadas
ÿ Editoração eletrônica
ÿ Publicação na Web
ÿ Quadro branco eletrônico
ÿ Emulação de terminal
ÿ Diretório online (lista telefônica)

ÿ Ensino à distância
ÿ Ponto de vendas (loja de varejo)
ÿ Comércio eletrônico
ÿ Modelagem financeira
ÿ Gestão de recursos humanos
ÿ Fabricação auxiliada por computador
ÿ Controle de processo e chão de fábrica
A lista anterior inclui aplicativos de usuário. O gráfico da Tabela 1-1 também deve incluir aplicações do
sistema . (Ou, se preferir, você pode fazer um gráfico separado para aplicativos do sistema.) Os aplicativos
do sistema incluem os seguintes tipos de serviços de rede:
ÿ Autenticação e autorização do usuário
ÿ Nomenclatura de host e resolução de nomes
ÿ Endereçamento de host dinâmico
ÿ Inicialização remota
ÿ Download de configuração remota
ÿ Serviços de diretório
ÿ Backup de rede
ÿ Gerenciamento de rede
ÿ Distribuição de software
Na coluna Criticidade do gráfico Aplicativos de Rede, você pode atribuir a cada aplicativo uma classificação
de 1 a 3 com os seguintes significados:
1. Extremamente crítico
2. Um tanto crítico
3. Não é crítico
Posteriormente, você poderá coletar informações mais específicas sobre a importância da missão, incluindo
exatamente quanto tempo de inatividade é aceitável (se o cliente puder quantificar os requisitos de disponibilidade).
Na coluna Comentários, adicione quaisquer observações relevantes para o projeto da rede. Por exemplo, inclua
qualquer informação que você tenha sobre orientações corporativas, como planos para parar de usar um
aplicativo no futuro ou cronogramas de lançamento específicos e planos de uso regional.
Analisando restrições de negócios

Além de analisar as metas de negócios e determinar a necessidade de suporte do seu cliente
aplicações novas e existentes, é importante analisar quaisquer restrições de negócios que
afetar o design da sua rede.
Política e Políticas
Já foi dito que há duas coisas que não se deve conversar com os amigos: política e religião. Seria bom se você pudesse
escapar das discussões sobre política de escritório e tecnologia
religião (preferências tecnológicas) com um cliente de design de rede, mas evitar esses tópicos coloca seu projeto em risco.
No caso da política de escritório, a sua melhor aposta é ouvir em vez de falar. Seu objetivo é
aprender sobre quaisquer agendas ocultas, guerras territoriais, preconceitos, relações de grupo ou história por trás do
projeto que poderia causar seu fracasso. Em alguns casos, um projecto semelhante já foi tentado e
não funcionou. Você deve determinar se isso aconteceu no seu caso e, se aconteceu, as razões pelas quais o projeto
falhou ou nunca teve a chance de se concretizar.
Preste atenção às questões de pessoal que podem afetar o projeto. Que gerente ou gerentes iniciaram o projeto e
quanto eles têm em jogo? Há algum gerente,
engenheiros de rede ou usuários que desejam que o projeto falhe por algum motivo? Descubra quem
seus defensores e oponentes são. Em alguns casos, não importa quão tecnicamente sólido seja o seu
design de rede, haverá pessoas que terão uma reação negativa a ele.
Certifique-se de descobrir se o seu projeto fará com que algum trabalho seja eliminado. Alguma rede
projetos de design envolvem a automação de tarefas que antes eram realizadas por trabalhadores bem remunerados.
Estes trabalhadores terão obviamente razões para querer que o projecto fracasse.
Descubra se existe um plano estratégico de negócios ou de TI. O design da sua rede precisa se ajustar
numa arquitectura global baseada no planeamento estratégico? Existem pressões regulatórias externas ou governamentais
sobre o processo de planejamento ou sobre a arquitetura? Esses tipos
Muitas vezes, as pressões podem levar a batalhas políticas complicadas que podem afetar o design da sua rede.
Esteja preparado para a possibilidade de políticas de escritório formidáveis se o seu projeto de rede envolver a fusão de
redes de voz e dados. Especialistas em voz e especialistas em dados têm
tradicionalmente viviam em seus próprios mundos. Eles podem se enfrentar com alguma desconfiança
e medo pelo futuro. Muitas vezes você pode reduzir a incerteza realizando seminários curtos sobre telefonia IP para
técnicos de voz e seminários de telefonia tradicional para a rede de dados.
administradores.
Ao trabalhar com um cliente, você adquirirá uma noção do estilo de negócios do cliente. Um
Um aspecto do estilo que é importante entender é a tolerância ao risco. Correr riscos é recompensado
na empresa ou a maioria das pessoas tem medo de mudanças? Conhecendo o histórico de emprego
dos tomadores de decisão irão ajudá-lo a selecionar as tecnologias apropriadas. O emprego
A história dos decisores afecta a sua tolerância ao risco e os seus preconceitos em relação a determinadas tecnologias.
Compreender estas questões irá ajudá-lo a determinar se a sua rede
o design do trabalho deve ser conservador ou se pode incluir tecnologias novas e de última geração
e processos.
Outro aspecto do estilo de negócios do cliente tem a ver com o teste do design. Em algum
empresas, os testadores podem alegar que testaram cuidadosamente uma nova voz sobre IP (VoIP)
implementação, por exemplo, quando o que eles realmente fizeram foi concluir uma chamada VoIP. Sua ideia
de teste, por outro lado, poderia ser fazer inúmeras chamadas sob diversas condições de carga. Consulte o Capítulo
12, “Testando seu projeto de rede”, para obter mais informações sobre testes.
Você precisa discutir com seu cliente quaisquer políticas sobre protocolos, padrões e
fornecedores. Tente aprender sobre quaisquer “tecnologias proibidas” onde os usuários ou engenheiros de rede
decidiram, possivelmente pelas razões erradas, que um determinado protocolo é lento ou
instável.
Descubra se a empresa padronizou qualquer transporte, roteamento, desktop ou

outros protocolos. Determine se existe alguma doutrina sobre soluções abertas versus soluções proprietárias.
Descubra se existem políticas sobre fornecedores ou plataformas aprovadas. Em
Em muitos casos, uma empresa já escolheu tecnologias e produtos para a nova rede e o seu design deve se
enquadrar nos planos. Pergunte ao seu cliente se existe alguma política
em relação à autoridade distribuída para projeto e implementação de rede. Por exemplo, são
existem departamentos que controlam suas próprias compras de interligação de redes? Descubra se os
departamentos e os usuários finais estão envolvidos na escolha de seus próprios aplicativos. Assegure-se de que você
saiba quem são os tomadores de decisão do seu projeto de design de rede.
Muitas organizações precisam implementar políticas em resposta a requisitos legais, regulatórios ou contratuais.
Nos Estados Unidos, Princípios Contábeis Geralmente Aceitos
(GAAP) orientam muitas políticas contábeis. Na profissão médica, os projetos de rede
pode ser afetado por políticas de segurança e privacidade regulamentadas pela HIPAA. Em outro
partes do mundo, as escolhas de equipamentos de rede podem ser regulamentadas pelos Correios governamentais,
Organizações telegráficas e telefônicas (PTT).
Na pressa de atender aos requisitos técnicos, os projetistas de redes às vezes ignoram questões não técnicas,
o que é um erro. Muitos projetos de rede brilhantes foram rejeitados por
um cliente porque o designer focou nas camadas inferiores do modelo de referência OSI
e esqueci a política da empresa e os preconceitos técnicos.
Restrições orçamentárias e de pessoal

O design da sua rede deve caber no orçamento do cliente. O orçamento deve incluir dotações para aquisição
de equipamentos, licenças de software, contratos de manutenção e suporte,
testes, treinamento e pessoal. O orçamento também pode incluir honorários de consultoria (incluindo
suas taxas) e despesas de terceirização.
Ao longo do projeto, trabalhe com seu cliente para identificar requisitos para novos funcionários, como gerentes
de rede adicionais. Apontar a necessidade de treinamento de pessoal,
o que afetará o orçamento do projeto.
Em geral, é uma boa ideia analisar as habilidades da equipe de networking. Quanto conhecimento
interno existe? Você deveria recomendar algum treinamento ou terceirização para operações e
gerenciamento de rede? As tecnologias e protocolos que você recomenda dependerão das
habilidades da equipe interna. Não é uma boa ideia recomendar um protocolo de roteamento
complexo, como Open Shortest Path First (OSPF), por exemplo, se a equipe de engenharia estiver
apenas começando a aprender conceitos de interligação de redes (a menos que você também
recomende um plano de treinamento abrangente).
Analisar a experiência interna é especialmente importante e desafiador para empresas que fundem
suas redes de voz e dados. Considerar a necessidade de formar os especialistas em voz
tradicionais em tecnologias de dados e os especialistas em dados em tecnologias de voz. Além
disso, a implementação de voz e vídeo muitas vezes requer conhecimento avançado de QoS que
pode exigir treinamento.
Para garantir o sucesso do seu projeto, determine quem controla o orçamento da rede – o
departamento de Sistemas de Informação (SI), os gerentes de rede ou os departamentos de
usuários? Quanto controle os usuários e grupos têm sobre os gastos da rede? Existem
esquemas de estornos departamentais?
Independentemente de quem controla o orçamento, um objetivo comum do projeto de rede é conter

custos. Orçamentos reduzidos ou recursos limitados muitas vezes forçam os projetistas de rede a
selecionar a solução mais acessível em vez da melhor solução. É útil conhecer as áreas nas quais
o projeto da rede pode ser alterado com o menor efeito no desempenho para atender aos requisitos
orçamentários. O Capítulo 2 discute compensações típicas que devem ser feitas para atingir a meta
de acessibilidade e, ao mesmo tempo, alcançar bom desempenho e confiabilidade.
Se possível, trabalhe com seu cliente para desenvolver uma análise de retorno sobre o investimento
(ROI) para o projeto da rede. Apresente ao cliente um caso de negócios que explique a rapidez com
que a nova rede se pagará, devido à redução dos custos operacionais, à melhoria da produtividade
dos funcionários ou à possibilidade de maior potencial de receita e expansão do mercado.
Agendamento de projetos
Um tópico adicional de negócios que você deve revisar com seu cliente é o prazo para o projeto de
design de rede. Quando é a data de vencimento final e quais são os marcos intermediários e
principais? Na maioria dos casos, o gerenciamento do cronograma do projeto é obrigação do cliente,
não sua, mas você deve pedir ao cliente que lhe forneça uma cópia do cronograma e que o mantenha
informado sobre quaisquer deslizes no cronograma.
Observação É importante incluir marcos intermediários no cronograma do projeto. Eles oferecem a

você e ao seu cliente uma maneira de detectar falhas no cronograma.
Considere o estado da fiação do edifício, que pode ser de baixa qualidade e não suportar novas
aplicações. Se a fiação precisar ser substituída, isso terá um grande impacto no cronograma.
Além disso, certifique-se de incluir a desconexão do circuito ou alterações na capacidade do circuito no
cronograma do projeto. Muitas vezes há um longo prazo para essas mudanças. Planeje documentar
quando o circuito mudar e outras mudanças importantes ocorrerem para que, se ocorrerem problemas,
você possa analisar o que mudou para ajudá-lo a solucionar problemas.
Existem muitas ferramentas para desenvolver um cronograma que inclua marcos, atribuições de
recursos, análise de caminho crítico e assim por diante. Dê uma olhada nesses aspectos do cronograma
e expresse sua opinião sobre se o cronograma é prático, considerando o que você aprendeu sobre o
escopo do projeto. Um cronograma de implementação agressivo pode exigir uma redução no escopo
do projeto ou uma redução na qualidade do planejamento e dos testes que serão conduzidos. Durante
a fase de análise técnica e as fases de design lógico e físico do projeto, lembre-se do cronograma. À
medida que você desenvolve iterativamente uma compreensão concreta do escopo técnico do projeto de
design de rede, aponte quaisquer preocupações que você tenha sobre o cronograma.
Lista de verificação de metas de negócios
Você pode usar a lista de verificação a seguir para determinar se abordou os objetivos e preocupações
de negócios do seu cliente. Se você não conseguir reunir todos os dados mencionados na lista de
verificação, certifique-se de documentar o que está faltando, caso se torne crítico, mas não atrase o
projeto para coletar todos os detalhes. Este livro ensina uma metodologia ideal de projeto de rede
que você deve tentar seguir, mas se restrições do mundo real, como clientes de projeto de rede não
cooperativos, cortes orçamentários e restrições de tempo, dificultarem sua capacidade de seguir a
metodologia com precisão, basta segui-la tanto quanto possível. como você puder. Em geral, a metodologia
ainda funciona mesmo que faltem alguns dados após a análise.
ÿ Pesquisei o setor e a concorrência do cliente.
ÿ Entendo a estrutura corporativa do cliente.
ÿ Compilei uma lista das metas comerciais do cliente, começando com uma meta comercial geral que
explica o objetivo principal do projeto de design de rede.
ÿ O cliente identificou quaisquer operações de missão crítica.
ÿ Entendo os critérios de sucesso do cliente e as ramificações do fracasso.
ÿ Entendo o escopo do projeto de design de rede.
ÿ Identifiquei os aplicativos de rede do cliente (usando o gráfico Aplicativos de Rede).
ÿ O cliente explicou as políticas relativas a fornecedores, protocolos ou

plataformas.
ÿ O cliente explicou quaisquer políticas relativas a soluções abertas versus soluções proprietárias.
ÿ O cliente explicou quaisquer políticas relativas à autoridade distribuída para rede

design e implementação.
ÿ Conheço o orçamento deste projeto.

ÿ Conheço o cronograma deste projeto, incluindo o prazo final e os principais marcos, e acredito que
seja prático.
ÿ Tenho um bom conhecimento da experiência técnica dos meus clientes e de qualquer pessoal interno ou
externo relevante.
ÿ Discuti um plano de educação do pessoal com o cliente.
ÿ Estou ciente de qualquer política do escritório que possa afetar o projeto da rede.
Resumo
Este capítulo abordou metas e restrições típicas de negócios de projeto de rede. Também falou sobre o
processo descendente de coleta de informações sobre metas e a importância do uso de métodos
sistemáticos para o projeto de redes. O uso de métodos sistemáticos o ajudará a acompanhar as
mudanças nas tecnologias e nas necessidades dos clientes. O próximo capítulo aborda a análise de metas
e restrições técnicas.
Este capítulo também falou sobre a importância de analisar o estilo de negócios do cliente, a tolerância
ao risco, os preconceitos e o conhecimento técnico. Você também deve trabalhar com seu cliente para
entender o orçamento e o cronograma do projeto de design de rede para garantir que os prazos e marcos
sejam práticos.
Finalmente, você precisa começar a compreender a estrutura corporativa do seu cliente.

Compreender a estrutura corporativa o ajudará a analisar o fluxo de dados e a desenvolver uma topologia
de rede, que geralmente é paralela à estrutura corporativa. Também o ajudará a identificar os gerentes que
terão autoridade para aceitar ou rejeitar seu projeto de rede, o que o ajudará a preparar e apresentar seu
projeto de rede de forma adequada.
Perguntas de revisão
1. Por que é importante utilizar um método estruturado e sistemático para projetar redes?
Que problemas podem ocorrer se tais métodos não forem utilizados?
2. Compare e contraste o método de projeto de rede de cima para baixo mostrado na Figura 1-1
com o método PDIOO mostrado na Figura 1-2.
3. Por que é importante explorar as estruturas divisionais e de grupo de uma organização

ao iniciar um projeto de design de rede?
4. A seção “Redes oferecem um serviço” mencionou ITSM e ITIL. Pesquise esses tópicos com mais
detalhes. O que são ITSM e ITIL? Como um projeto de design de rede pode se beneficiar dos
princípios do ITSM? Como o ITSM pode impedir um projeto de design de rede?
Cenário de projeto
Você é um consultor de rede que foi convidado a participar de uma reunião inicial com o
equipe de gerenciamento executivo da ElectroMyCycle, LLC. ElectroMyCycle fabrica
motocicletas. Sua nova motocicleta elétrica acaba de ser adquirida por uma grande rede varejista.
A ElectroMyCycle está atualizando sua capacidade de produção e contratando novos funcionários.
Recentemente, os funcionários da ElectroMyCycle começaram a dizer: “A Internet é lenta”. Eles são

também tendo problemas para enviar e-mails, acessar aplicativos baseados na Web e imprimir. Antigamente,
quando a empresa era pequena, não tinha esses problemas. O gerente de operações terceirizou serviços de
informática para uma empresa local chamada Network Rogues,
que instalou novas estações de trabalho e servidores conforme necessário, forneceu suporte de desktop e
gerenciou os switches, roteador e firewall. A ElectroMyCycle agora está considerando trazer
serviços de informática internamente e está se perguntando como sua rede deve evoluir à medida que aumenta a
produção de sua motocicleta elétrica.
1. Que pesquisas você fará antes de sua reunião inicial com o gerenciamento executivo
equipe de gerenciamento?
2. Que problemas gerais o ElectroMyCycle parece estar enfrentando? Que rede

princípios de design de trabalho podem ter sido ignorados quando a Network Rogues projetou e
operava a rede existente?
3. Liste quatro principais partes interessadas para um novo projeto de rede para ElectroMyCycle. Para cada
parte interessada, liste alguns objetivos de design, restrições e preconceitos.
4. Liste cinco perguntas que você fará à equipe de gestão executiva. Por que você vai
colocar essas questões?
Capítulo 2
Analisando Técnico
Metas e compensações
Este capítulo fornece técnicas para analisar as metas técnicas de um cliente para um novo projeto de rede ou
atualização de rede. Analisar as metas técnicas do seu cliente pode ajudá-lo
recomende com confiança tecnologias que atenderão às expectativas de seus clientes.
As metas técnicas típicas incluem escalabilidade, disponibilidade, desempenho de rede, segurança,

capacidade de gerenciamento, usabilidade, adaptabilidade e acessibilidade. Claro, existem compensações
associados a esses objetivos. Por exemplo, atender a requisitos rigorosos de desempenho
pode dificultar o cumprimento de uma meta de acessibilidade. A seção “Fazendo Design de Rede
Compensações” mais adiante neste capítulo discute as compensações com mais detalhes.
Um dos objetivos deste capítulo é fornecer uma terminologia que o ajudará a discutir metas técnicas com
seu cliente. Designers e usuários de rede têm muitos termos
para objetivos técnicos e, infelizmente, muitos significados diferentes para os termos. Este capítulo pode ajudá-
lo a escolher uma terminologia que tenha mérito técnico e seja compreensível por
clientes empresariais e de TI.
Este capítulo termina com uma lista de verificação para ajudá-lo a determinar se você tem
abordou todas as metas e restrições técnicas do seu cliente.
Escalabilidade
Escalabilidade refere-se a quanto crescimento um projeto de rede deve suportar. Para muitos clientes
empresariais de design de rede, a escalabilidade é o objetivo principal. Muitas grandes empresas adicionam
usuários, aplicativos, sites adicionais e conexões de rede externas em um ritmo rápido. O
O projeto de rede que você propõe a um cliente deve ser capaz de se adaptar aos aumentos no uso e no
escopo da rede.
Planejando a Expansão
Seu cliente deve ajudá-lo a entender o quanto a rede se expandirá no próximo ano e nos próximos 2 anos. (Peça
ao seu cliente para analisar também as metas de crescimento nos próximos 5 anos, mas esteja ciente de que poucas
empresas têm uma visão clara para os próximos 5 anos.)
Você pode usar a seguinte lista de perguntas para analisar as metas de expansão de curto prazo do seu cliente:
ÿ Quantos locais serão adicionados no próximo ano? Os próximos 2 anos?
ÿ Qual será a extensão das redes em cada novo local?
ÿ Quantos usuários a mais acessarão a rede corporativa no próximo ano? O

próximos 2 anos?
ÿ Quantos servidores a mais serão adicionados à rede no próximo ano? O

próximos 2 anos?
Expandindo o acesso aos dados

O Capítulo 1, “Analisando metas e restrições de negócios”, falou sobre um objetivo comercial comum de expandir o
acesso aos dados para funcionários que usam redes corporativas. Os gerentes capacitam os funcionários a tomar
decisões estratégicas que exigem acesso a dados de vendas, marketing, engenharia e financeiros. Na década de
1970 e início da década de 1980, esses dados eram armazenados em mainframes. No final da década de 1980
e na década de 1990, esses dados eram armazenados em servidores em LANs departamentais. Hoje, esses
dados são novamente armazenados em mainframes e servidores centralizados.
Na década de 1990, livros de rede e aulas de treinamento ensinavam a regra 80/20 para planejamento de
capacidade: 80% do tráfego permanece local em LANs departamentais e 20% do tráfego é destinado a outros
departamentos ou redes externas. Esta regra já não é universal e está a passar rapidamente para o outro lado da
balança. Muitas empresas possuem servidores centralizados residentes em data centers. Além disso, as empresas
implementam cada vez mais intranets que permitem aos funcionários aceder a servidores web centralizados
utilizando tecnologias de Protocolo Internet (IP).
Em algumas empresas, os funcionários podem acessar servidores da intranet para organizar viagens de negócios,
pesquisar listas telefônicas on-line, solicitar equipamentos e participar de aulas de treinamento à distância. Os
servidores web estão localizados centralmente, o que quebra a regra clássica 80/20.
Como também foi mencionado no Capítulo 1, tem havido uma tendência de empresas que conectam trabalhos na
Internet com outras empresas para colaborar com parceiros, revendedores, fornecedores e clientes estratégicos. O
termo extranet às vezes é usado para descrever uma rede interna que pode ser acessada por terceiros. Se o seu
cliente tiver planos de implementar uma extranet, você deverá documentar isso em sua lista de metas técnicas para
poder projetar uma topologia e provisionar largura de banda adequadamente.
Nas décadas de 1980 e 1990, os mainframes que executavam protocolos de Systems Network Architecture (SNA)
armazenavam a maior parte dos dados financeiros e de vendas de uma empresa. Nos últimos anos, foi
reconhecido o valor de disponibilizar estes dados para mais do que apenas analistas financeiros. O
Capítulo 2: Analisando Metas Técnicas e Compensações 27
O objetivo comercial de disponibilizar dados para mais departamentos geralmente resulta em um objetivo
técnico de usar o mainframe como um servidor de banco de dados incrivelmente poderoso.
A meta comercial de disponibilizar mais dados aos usuários resulta nas seguintes metas técnicas para
dimensionar e atualizar redes corporativas:
ÿ Conecte LANs departamentais separadas à rede corporativa.
ÿ Resolver problemas de gargalos de LAN/WAN causados por grandes aumentos na interligação de redes
tráfego.
ÿ Fornecer servidores centralizados que residam em um data center.
ÿ Tornar os dados do mainframe acessíveis à rede IP corporativa.
ÿ Adicionar novos locais para apoiar escritórios locais e teletrabalhadores.
ÿ Adicione novos sites e serviços para oferecer suporte à comunicação segura com clientes, fornecedores,
revendedores e outros parceiros de negócios.
Restrições na escalabilidade
Ao analisar as metas de escalabilidade de um cliente, é importante ter em mente que existem impedimentos
à escalabilidade inerentes às tecnologias de rede. A seleção de tecnologias que possam atender às metas
de escalabilidade de um cliente é um processo complexo com ramificações significativas se não for feito
corretamente. Por exemplo, selecionar uma topologia de rede plana com switches de Camada 2 pode causar
problemas à medida que o número de usuários aumenta, especialmente se os aplicativos ou protocolos
de rede dos usuários enviam vários quadros de transmissão. (Muda os quadros de transmissão da ala para
todos os segmentos conectados.)
Os capítulos subsequentes deste livro consideram a escalabilidade novamente. O Capítulo 4, “Caracterizando

o tráfego de rede”, discute o fato de que o tráfego de rede (por exemplo, tráfego de broadcast) afeta a
escalabilidade de uma rede. A Parte II, “Projeto de Rede Lógica”, fornece detalhes sobre a escalabilidade
dos protocolos de roteamento e comutação. A Parte III, “Projeto de Rede Física”, fornece informações sobre a
escalabilidade das tecnologias LAN e WAN e dos dispositivos de interligação de redes. Lembre-se de que o
projeto de rede de cima para baixo é um processo iterativo. As metas e soluções de escalabilidade são
revisadas durante muitas fases do processo de design de rede.
Disponibilidade
Disponibilidade refere-se à quantidade de tempo que uma rede fica disponível para os usuários e costuma ser
uma meta crítica para clientes de projeto de rede. A disponibilidade pode ser expressa como uma porcentagem
de tempo de atividade por ano, mês, semana, dia ou hora, em comparação com o tempo total nesse período.
Por exemplo, em uma rede que oferece serviço 24 horas por dia, 7 dias por semana, se a rede estiver
ativa 165 horas na semana de 168 horas, a disponibilidade será de 98,21%.
Os clientes de design de rede não usam a palavra disponibilidade no inglês cotidiano e tendem a pensar que
ela significa mais do que realmente significa. Em geral, disponibilidade significa quanto tempo a rede está
operacional. A disponibilidade está ligada à confiabilidade, mas tem um significado mais específico.
significado (porcentagem de tempo de atividade) do que confiabilidade. A confiabilidade se refere a uma variedade de
questões, incluindo precisão, taxas de erro, estabilidade e a quantidade de tempo entre falhas.
Nota Às vezes, os engenheiros de rede classificam a capacidade como parte da disponibilidade. A ideia é que mesmo
que uma rede esteja disponível na Camada 1 (a camada física), ela não estará disponível do ponto de vista do usuário
se não houver capacidade suficiente para enviar o tráfego do usuário.
Por exemplo, o Modo de Transferência Assíncrona (ATM) possui uma função de controle de admissão de conexão
que regula o número de células permitidas em uma rede ATM. Se a capacidade e a qualidade de serviço (QoS)
solicitadas para uma conexão não estiverem disponíveis, as células para a conexão não poderão entrar na rede. Este
problema pode ser considerado um problema de disponibilidade. No entanto, este livro classifica capacidade com
metas de desempenho. A disponibilidade é considerada simplesmente uma meta de percentual de tempo de atividade.
A disponibilidade também está ligada à redundância, mas a redundância não é um objetivo da rede.
A redundância é uma solução para uma meta de alta disponibilidade. Redundância significa adicionar links ou
dispositivos duplicados a uma rede para evitar tempo de inatividade. Topologias de rede redundantes estão se
tornando cada vez mais importantes para muitos clientes de projetos de rede que desejam garantir a continuidade dos
negócios após uma falha grave ou desastre. O Capítulo 5, “Projetando uma topologia de rede”, aborda o
projeto de topologias de rede redundantes com mais detalhes.
Disponibilidade também está associada à resiliência, palavra que está se tornando mais popular na área de
redes. Resiliência significa quanto estresse uma rede pode suportar e quão rapidamente a rede pode se recuperar
de problemas, incluindo violações de segurança, desastres naturais e não naturais, erro humano e falhas
catastróficas de software ou hardware. Uma rede que possui boa resiliência geralmente possui boa disponibilidade.
Recuperação de desastres
A maioria das grandes instituições reconheceu a necessidade de um plano para sustentar as operações comerciais
e técnicas após desastres naturais, como inundações, incêndios, furacões e terramotos.
Além disso, algumas grandes empresas (especialmente prestadores de serviços) devem planear como recuperar das
interrupções dos satélites. As interrupções nos satélites podem ser causadas por tempestades de meteoritos,
colisões com detritos espaciais, explosões solares ou falhas no sistema. Infelizmente, as instituições também
descobriram a necessidade de especificar um plano de recuperação para desastres não naturais, tais como
bombas, ataques terroristas, motins ou situações com reféns. Um plano de recuperação de desastres inclui um
processo para manter o backup dos dados em um ou mais locais que provavelmente não serão atingidos por
um desastre, e um processo para mudar para tecnologias de backup se as principais tecnologias forem afetadas
por um desastre.
Embora este livro não cubra os detalhes do planejamento de recuperação de desastres, os conceitos deste livro podem
ser aplicados ao processo de planejamento para um desastre. Não é de surpreender que seja recomendada uma
abordagem descendente, com ênfase no planeamento antes da implementação. Um objectivo do processo de
planeamento deve ser reconhecer quais as partes da rede que são críticas e que devem ser apoiadas. É necessário
um bom entendimento do propósito comercial da organização para entender quais dispositivos, links de rede,
aplicativos e pessoas são críticos.
cal. Tal como acontece com o projeto de rede de cima para baixo, os objetivos de negócios devem ser analisados
antes de selecionar tecnologias e dispositivos que serão um componente da implementação.
Observação Não subestime a importância de ter pessoal suficiente para ativar um plano de recuperação de
desastres. Você já descobriu o que fazer se o desastre envolver uma doença grave em que o servidor e os
administradores de rede precisem ficar em quarentena? Isto poderia ser uma justificativa para fornecer acesso VPN
de alta velocidade a partir das casas dos trabalhadores e testar essa capacidade antes que ocorra um desastre.
Uma das etapas mais importantes no planejamento de recuperação de desastres são os testes. Não só a tecnologia
deve ser testada, mas os funcionários devem ser treinados sobre as ações que devem tomar em caso de desastre.
Se as pessoas não sobreviverem, a tecnologia não ajudará muito. Além disso, as pessoas devem praticar o
trabalho com a rede na configuração que ela provavelmente terá após um desastre, quando servidores ou sites
redundantes estiverem em uso. Embora os funcionários possam opor-se aos exercícios de emergência, especialmente
se forem demasiado frequentes, a prática periódica é uma parte necessária para alcançar a continuidade dos
negócios quando ocorre um verdadeiro desastre. Os exercícios devem ser levados a sério e devem ser projetados
para incluir pressões de tempo e estresse para simular a situação real.
Especificando Requisitos de Disponibilidade

Você deve incentivar seus clientes a especificarem os requisitos de disponibilidade com precisão.
Considere a diferença entre um tempo de atividade de 99,70% e um tempo de atividade de 99,95%. Um tempo de
atividade de 99,70% significa que a rede fica inativa 30 minutos por semana, o que não é aceitável para muitos
clientes. Um tempo de atividade de 99,95% significa que a rede fica inativa 5 minutos por semana, o que pode ser
aceitável, dependendo do tipo de negócio. Os requisitos de disponibilidade devem ser especificados com pelo
menos dois dígitos após a vírgula.
Também é importante especificar um prazo com requisitos percentuais de tempo de atividade. Volte ao exemplo de
99,70% de tempo de atividade, o que equivale a 30 minutos de tempo de inatividade por semana. Um tempo
de inatividade de 30 minutos no meio de um dia de trabalho provavelmente não é aceitável. Mas um tempo de
inatividade de 30 minutos todos os sábados à noite para manutenção programada regularmente pode ser suficiente.
Seus clientes não apenas devem especificar um período com requisitos percentuais de tempo de atividade, mas
também devem especificar uma unidade de tempo. Os requisitos de disponibilidade devem ser especificados
como tempo de atividade por ano, mês, semana, dia ou hora. Considere novamente um tempo de atividade de 99,70%.
Esse tempo de atividade significa 30 minutos de inatividade durante uma semana. O tempo de inatividade pode
ocorrer de uma só vez, o que pode ser um problema se não ocorrer durante uma janela de manutenção programada
regularmente, ou pode ser distribuído ao longo da semana. Um tempo de atividade de 99,70% pode significar
que aproximadamente a cada hora a rede fica inativa por 10,70 segundos. Os usuários notarão um tempo de
inatividade de 10,70 segundos? Certamente alguns usuários o farão, mas para alguns aplicativos, um tempo
de inatividade de 10,70 segundos a cada hora é tolerável. As metas de disponibilidade devem ser baseadas em
resultado da primeira etapa do projeto de rede de análise das metas de negócios, onde você obteve uma
compreensão dos aplicativos do cliente.
Disponibilidade de cinco noves
Embora os exemplos citados até agora utilizem números na faixa de 99,70 a 99,95 por cento, muitas
empresas exigem maior disponibilidade, especialmente durante períodos críticos. Alguns clientes podem
insistir em um tempo de atividade da rede de 99,999%, o que às vezes é chamado de disponibilidade
de cinco noves. Para alguns clientes, esse requisito pode estar vinculado a um processo ou período de
negócios específico. Por exemplo, o requisito pode referir-se ao fechamento mensal de registros financeiros
ou à época de festas de fim de ano para uma empresa que vende presentes de Natal por meio de pedidos
por catálogo e pela web. Por outro lado, alguns clientes de design podem precisar, ou pensar que precisam,
de disponibilidade de cinco noves o tempo todo.
A disponibilidade de cinco noves é extremamente difícil de conseguir. Você deve explicar a um cliente
de projeto de rede que, para atingir esse nível, serão necessários equipamentos e links redundantes, assim
como, possivelmente, pessoal extra e hardware e software extremamente confiáveis.
Alguns gestores desistirão de tal exigência quando souberem do custo, mas, para outros, a meta pode ser
apropriada. Se uma empresa sofrer uma grave perda de receita ou reputação se a rede não estiver
operacional, mesmo por curtos períodos de tempo, a disponibilidade de cinco noves é uma meta razoável.
Muitos fabricantes de hardware especificam um tempo de atividade de 99,999% para seus dispositivos e
sistemas operacionais e têm exemplos reais de clientes onde esse nível de tempo de atividade foi alcançado.
Isso pode levar um cliente ingênuo de projeto de rede a presumir que uma rede complexa também pode ter
99,999% de tempo de atividade sem muito esforço ou custo extra. Alcançar um nível tão alto em uma rede
complexa, entretanto, é muito mais difícil do que alcançá-lo para componentes específicos da rede. As falhas
potenciais incluem interrupções de operadora, software defeituoso em roteadores e switches, um aumento
inesperado e repentino na largura de banda ou no uso do servidor, problemas de configuração, erros humanos,
falhas de energia, violações de segurança e falhas de software em aplicativos de rede.
Observação Alguns especialistas em redes dizem que 80 a 90 por cento das falhas são devidas a erros
humanos, sejam erros cometidos por administradores locais ou erros cometidos por funcionários de
prestadores de serviços (ou pelo infame operador de retroescavadeira). Evitar e recuperar-se de erros
humanos requer habilidade e bons processos. Você precisa de pessoas inteligentes que pensem na
disponibilidade o tempo todo e em processos precisos, sem sufocar o pensamento. Um bom gerenciamento
de rede e solução de problemas desempenham um papel importante. As ferramentas de gerenciamento
de rede devem fornecer alertas imediatos sobre falhas e informações suficientes para que um administrador
de rede possa fazer uma solução rápida.
Considere uma rede usada 24 horas por dia, 365 dias por ano. Isso equivale a 8.760 horas. Se a rede
puder ficar inativa apenas 0,001% do tempo, ela poderá ficar inativa por apenas 0,0876 avos de hora ou
cerca de 5 minutos por ano. Se o cliente disser que a rede deve estar disponível 99,999% do tempo, é
melhor deixar claro que isso
não inclui tempo de manutenção programado regularmente, ou é melhor certificar-se de que a rede terá
capacidade para suportar atualizações em serviço. As atualizações em serviço referem-se a mecanismos para
atualizar equipamentos e serviços de rede sem interromper as operações. A maioria dos fornecedores de
interconexão de redes vende dispositivos de interconexão de alta tecnologia que incluem componentes hot-
swap para atualização em serviço.
Para situações em que a troca a quente não é prática, pode ser necessário ter equipamentos extras para
que nunca haja necessidade de desabilitar serviços para manutenção. Em algumas redes, cada componente
crítico possui redundância tripla, sendo um ativo, um em hot standby pronto para uso imediato e um em standby
ou manutenção. Com redundância tripla, você pode desativar um roteador em espera para atualizá-lo ou
reconfigurá-lo. Depois de atualizado, você pode designá-lo como hot standby, desativar o hot standby anterior e
atualizá-lo. Você pode então alternar do ativo para o modo de espera ativo e atualizar o ativo.
Dependendo do projeto da rede, você poderá compartilhar a carga entre os componentes redundantes
durante as operações normais. A principal decisão de design é se os usuários podem aceitar a
degradação do desempenho quando alguns dos componentes ficam inutilizáveis. Se tudo isso parece
muito complicado ou caro, outra possibilidade é não fazer tudo sozinho, mas colocar recursos em centros de
colocação que possam amortizar o equipamento altamente redundante de muitos clientes.
O custo do tempo de inatividade
Em geral, a meta de disponibilidade de um cliente é manter os aplicativos de missão crítica funcionando

perfeitamente, com pouco ou nenhum tempo de inatividade. Um método para ajudar você, o projetista da rede
e seu cliente a entender os requisitos de disponibilidade é especificar um custo de tempo de inatividade.
Para cada aplicação crítica, documente quanto dinheiro a empresa perde por hora de inatividade. (Para algumas
aplicações, como processamento de pedidos, especificar o dinheiro perdido por minuto pode ter mais impacto.)
Se as operações de rede forem terceirizadas para uma empresa terceirizada de gerenciamento de rede,
explicar o custo do tempo de inatividade pode ajudar a empresa a compreender a criticidade das aplicações
para a missão de uma empresa. Especificar o custo do tempo de inatividade também pode ajudar a esclarecer
se as atualizações em serviço ou a redundância tripla devem ser suportadas.
Tempo médio entre falhas e tempo médio para reparo
Além de expressar a disponibilidade como a porcentagem de tempo de atividade, você pode definir a
disponibilidade como o tempo médio entre falhas (MTBF) e o tempo médio para reparo (MTTR). Você pode
usar o MTBF e o MTTR para calcular metas de disponibilidade quando o cliente quiser especificar períodos
explícitos de tempo de atividade e tempo de inatividade, em vez de um simples valor percentual de tempo de atividade.
MTBF é um termo que vem da indústria de informática e é mais adequado para especificar quanto tempo um
computador ou componente de computador durará antes de falhar. Ao especificar requisitos de disponibilidade
no campo de rede, o MTBF às vezes é designado com a frase mais complicada, tempo médio entre interrupções
de serviço (MTBSO), para explicar o fato de que uma rede é um serviço, não um componente. Da mesma
forma, o MTTR pode ser substituído
com a frase tempo médio para reparo (MTTSR). Este livro usa os termos mais simples e conhecidos
MTBF e MTTR.
Uma meta típica de MTBF para uma rede altamente confiável é de 4.000 horas. Em outras palavras,
a rede não deve falhar mais do que uma vez a cada 4.000 horas ou 166,67 dias. Uma meta típica de
MTTR é de 1 hora. Em outras palavras, a falha da rede deve ser corrigida dentro de 1 hora. Neste caso, a
meta de disponibilidade média é a seguinte:
4000/4001 = 99,98 por cento
Uma meta de 99,98% é típica para muitas empresas.
Ao especificar a disponibilidade usando MTBF e MTTR, a equação a ser usada é a seguinte:
Disponibilidade = MTBF / (MTBF + MTTR)
O uso dessa equação de disponibilidade permite que um cliente indique claramente a frequência e a
duração aceitáveis das interrupções da rede.
Lembre-se de que o que é calculado é a média. A variação nos tempos de falha e reparo pode ser alta
e também deve ser considerada. Não basta apenas considerar as taxas médias, especialmente se você
depende de agentes de serviços externos (fornecedores ou prestadores de serviços) que não estão sob
seu rígido controle. Além disso, esteja ciente de que os clientes podem precisar especificar diferentes
metas de MTBF e MTTR para diferentes partes de uma rede. Por exemplo, as metas para o núcleo da
rede corporativa são provavelmente muito mais rigorosas do que as metas para uma porta de switch
que afeta apenas um usuário.
Embora nem todos os clientes possam especificar requisitos detalhados de aplicação, é uma boa ideia
identificar metas de disponibilidade para aplicações específicas, além da rede como um todo. As metas de
disponibilidade do aplicativo podem variar amplamente dependendo do custo do tempo de inatividade.
Para cada aplicação que tenha um alto custo de tempo de inatividade, você deve documentar o MTBF e
o MTTR aceitáveis.
Para valores MTBF para componentes de rede específicos, geralmente você pode usar dados
fornecidos pelo fornecedor do componente. A maioria dos fabricantes de roteadores, switches e hubs
pode fornecer valores de MTBF e MTTR para seus produtos. Você também deve investigar outras
fontes de informação, como publicações comerciais, para evitar quaisquer problemas de credibilidade com
os números publicados pelos fabricantes. Pesquise valores de variabilidade e valores médios. Além disso,
tente obter compromissos por escrito para MTBF, MTTR e valores de variabilidade dos
fornecedores de equipamentos e serviços.
Desempenho da rede
Ao analisar os requisitos técnicos para um projeto de rede, você deve isolar os critérios do cliente para
aceitar o desempenho de uma rede, incluindo rendimento, precisão, eficiência, atraso e tempo de
resposta.
Muitos tratados matemáticos foram escritos sobre desempenho de redes. Este livro aborda o
desempenho da rede de uma forma prática e principalmente não matemática,
evitando as equações assustadoras que aparecem nos tratamentos matemáticos de desempenho.

Embora as equações sejam muito mais simples do que parecem, geralmente não são necessárias para a
compreensão dos objetivos do cliente. O objetivo desta seção é oferecer uma visão descomplicada do
desempenho da rede, incluindo conclusões do mundo real que você pode tirar quando não há tempo para fazer
uma análise matemática.
A análise das metas de desempenho da rede de um cliente está intimamente ligada à análise da rede existente,
que é abordada no Capítulo 3, “Caracterizando a rede existente”.
A análise da rede existente pode ajudá-lo a determinar quais mudanças precisam ser feitas para atingir as metas de
desempenho. As metas de desempenho da rede também estão intimamente ligadas às metas de escalabilidade.
Você deve compreender os planos de crescimento da rede antes de analisar as metas de desempenho.
Definições de desempenho de rede
Muitos clientes de design de rede não conseguem quantificar suas metas de desempenho além de “ela tem que
funcionar sem reclamações dos usuários”. Se for esse o caso, você poderá fazer suposições sobre a taxa de
transferência, o tempo de resposta e assim por diante. Por outro lado, alguns clientes têm requisitos específicos
de desempenho, baseados num nível de serviço acordado com os utilizadores da rede.
A lista a seguir fornece definições para metas de desempenho de rede que você pode usar ao analisar requisitos
precisos:
ÿ Capacidade (largura de banda): A capacidade de transporte de dados de um circuito ou rede, geralmente

medida em bits por segundo (bps)
ÿ Utilização: a porcentagem da capacidade total disponível em uso
ÿ Utilização ideal: utilização média máxima antes da rede ser considerada

saturado
ÿ Taxa de transferência: quantidade de dados sem erros transferidos com sucesso entre nós por
unidade de tempo, geralmente segundos
ÿ Carga oferecida: soma de todos os dados que todos os nós da rede têm prontos para enviar em um determinado
horário normal
ÿ Precisão: A quantidade de tráfego útil que é transmitido corretamente, em relação

tráfego total
ÿ Eficiência: uma análise de quanto esforço é necessário para produzir uma determinada quantidade de
transferência de dados
ÿ Atraso (latência): Tempo entre um quadro estar pronto para transmissão de um nó e a entrega do quadro
em outro lugar da rede
ÿ Variação do atraso: a quantidade média de atraso varia
ÿ Tempo de resposta: o tempo entre uma solicitação de algum serviço de rede e uma resposta à solicitação
Utilização ideal da rede

A utilização da rede é uma medida de quanta largura de banda é usada durante um determinado
período de tempo. A utilização é comumente especificada como uma porcentagem da capacidade. Por exemplo,
uma ferramenta de monitoramento de rede pode afirmar que a utilização da rede em um segmento Ethernet é
30%, o que significa que 30% da capacidade está em uso.
As ferramentas de análise de rede usam vários métodos para medir o uso da largura de banda e calcular a média do
uso ao longo do tempo decorrido. O uso pode ser calculado a cada milissegundo, a cada segundo,
cada minuto, cada hora e assim por diante. Algumas ferramentas usam uma média ponderada em que mais
os valores recentes são ponderados de forma mais proeminente do que os valores mais antigos. O Capítulo 3 discute a
medição da utilização da rede com mais profundidade.
Seu cliente pode ter uma meta de projeto de rede para a utilização média máxima da rede permitida em um segmento.
Na verdade, esta é mais uma restrição de design do que uma questão de design.
meta. A restrição de projeto afirma que se a utilização de um segmento for superior a um limite predefinido, o
segmento deverá ser dividido em múltiplos segmentos ou largura de banda.
deve ser adicionado.
A utilização média ideal da rede é de cerca de 70%. Um limite de 70 por cento para
utilização média significa que os picos no tráfego de rede provavelmente podem ser tratados sem
degradação óbvia do desempenho. A maioria das WANs tem menos capacidade que as LANs, portanto, mais
é necessário cuidado ao selecionar a largura de banda da WAN que possa cobrir variações reais e razoáveis. Os
clientes têm muitas opções de tecnologias que podem reduzir a utilização de largura de banda em WANs, incluindo
recursos avançados de protocolo de roteamento e compactação. O Capítulo 13, “Otimizando seu projeto de rede”,
aborda a otimização da utilização da largura de banda em
Mais detalhes.
Com LANs, é dada menos atenção ao monitoramento da utilização da rede porque muitas LANs
já estão sobrecarregados com links Gigabit Ethernet full-duplex para servidores e 100 Mbps ou
Links Gigabit Ethernet para clientes. Se configurado para operações full-duplex, o que é típico
hoje em dia, um link Fast ou Gigabit Ethernet suporta transmissão e recepção simultâneas. Assim, em teoria, um
segmento Fast Ethernet de 100 Mbps poderia suportar 100% de utilização do canal de transmissão e 100% de
utilização do canal de recepção, usando
200Mbps. Entretanto, a largura de banda total em ambas as direções não é usada o tempo todo na maioria
casos. Considere o caso de um sistema cliente comunicando-se com um servidor. O cliente envia
solicitações e o servidor responde, na etapa de bloqueio. O cliente não tenta enviar ao mesmo
tempo como o servidor, para que o uso da largura de banda não duplique no link do cliente para o
Comutador Ethernet.
Um link full-duplex ponto a ponto que conecta um switch a um servidor ou a outro switch,
por outro lado, poderia usar toda a largura de banda, dependendo dos padrões de tráfego. A Ethernet Full
Duplex tornou-se o método padrão para conectar servidores, switches e
máquinas dos usuários finais. É um aumento de desempenho essencial para servidores, em particular. Com
Ethernet full-duplex, um switch pode transmitir a solicitação do próximo cliente ao mesmo tempo que o
servidor está enviando uma resposta a uma solicitação anterior. Entretanto, se a utilização exceder cerca de 70% da
largura de banda full-duplex, provavelmente é hora de atualizar para uma largura de banda maior.
largura. O tráfego de rede está em rajadas. Você deve provisionar capacidade de LAN e WAN com a suposição
de que a utilização média será excedida durante intermitências.
Taxa de transferência
A taxa de transferência é definida como a quantidade de dados sem erros que são transmitidos por unidade
de tempo. A taxa de transferência geralmente é definida para uma conexão ou sessão específica, mas em
alguns casos a taxa de transferência total de uma rede é especificada. Os novatos em rede usam
consistentemente mal as palavras taxa de transferência e largura de banda. Lembre-se de que largura de banda
significa capacidade e geralmente é fixa. A taxa de transferência é uma avaliação da quantidade de dados
que pode ser transmitida por unidade de tempo. Você mede o rendimento, que pode variar dependendo das
características de desempenho da rede e de como você faz a medição. A largura de banda é um dado adquirido.
Observação Para entender a largura de banda e o rendimento, pense em um tubo de aço com capacidade de
100 galões por minuto. O tubo possui capacidade fixa (largura de banda). Se apenas um fio estiver passando, o
rendimento será baixo. Se a taxa de transferência estiver em 70%, poderá haver uma inundação.
Idealmente, o rendimento deve ser igual à capacidade. Contudo, este não é o caso em redes reais. A
capacidade depende das tecnologias da camada física em uso. A capacidade de uma rede deve ser adequada
para suportar a carga oferecida, mesmo quando há picos de tráfego na rede. (A carga oferecida são os dados
que todos os nós devem enviar em um determinado momento.) Teoricamente, a taxa de transferência deveria
aumentar à medida que a carga oferecida aumenta, até um máximo da capacidade total da rede. No entanto,
o rendimento da rede depende do método de acesso (por exemplo, passagem de token ou detecção de
portadora), da carga na rede e da taxa de erro.
A Figura 2-1 mostra a situação ideal, onde o rendimento aumenta linearmente com a carga oferecida, e o
mundo real, onde o rendimento real diminui à medida que a carga oferecida atinge um determinado máximo.
100% da capacidade
Real
Taxa
Ideal
100% da capacidade
Carga Oferecida
Figura 2-1 Carga e rendimento oferecidos

Taxa de transferência de dispositivos de interligação de redes
Alguns clientes especificam metas de rendimento em termos do número de pacotes por segundo
(pps) que um dispositivo de interligação de redes deve processar. (No caso de um dispositivo ATM, o objetivo é
células por segundo, ou [cps].) A taxa de transferência para um dispositivo de interligação de redes é o máximo
taxa na qual o dispositivo pode encaminhar pacotes sem descartar nenhum pacote.
A maioria dos fornecedores de interconexão publica classificações de pps para seus produtos, com base em suas próprias
testes e testes independentes. Para testar um dispositivo de interconexão de redes, os engenheiros colocam o dispositivo
entre geradores de tráfego e um verificador de tráfego. Os geradores de tráfego enviam pacotes com tamanhos
que variam de 64 bytes a 1.518 bytes para Ethernet. Ao operar vários geradores, o
investigação pode testar dispositivos com múltiplas portas.
Os geradores enviam rajadas de tráfego através do dispositivo a uma taxa inicial que é metade da
o que é teoricamente possível para condições de teste. Se todos os pacotes forem recebidos, a taxa é
aumentou. Se todos os pacotes não forem recebidos, a taxa diminui. Este processo é repetido
até que a taxa mais alta na qual os pacotes podem ser encaminhados sem perdas seja determinada. Pps
os valores para quadros pequenos são muito mais altos do que os valores pps para quadros grandes, portanto, certifique-se de
entenda qual valor você está observando ao ler os resultados dos testes do fornecedor para um dispositivo de
inter-rede.
Muitos dispositivos de interconexão de redes podem encaminhar pacotes no máximo teórico, que é
também chamada de velocidade do fio . O máximo teórico é calculado dividindo a largura de banda por
tamanho do pacote, incluindo quaisquer cabeçalhos, preâmbulos e lacunas entre quadros. A Tabela 2-1 mostra o
pps máximo teórico para um fluxo Ethernet de 100 Mbps, com base no tamanho do quadro.
Para avaliar o valor pps de um dispositivo multiporta, os testadores enviam vários fluxos de dados através
o dispositivo para múltiplas portas de saída. Os números extremos que você às vezes vê no material de marketing
do fornecedor (por exemplo, 400 milhões de pps para o switch Cisco Catalyst 6500)
vêm de medições feitas com vários fluxos de dados Gigabit Ethernet, cada um usando
Pacotes de 64 bytes.
Tabela 2-1 Máximo Teórico de Pacotes por Segundo (pps)
Tamanho do quadro (em Máximo Ethernet de 100 Mbps Máximo Ethernet de 1 Gbps
Bytes) pps pps
64 148.800 1.488.000
128 84.450 844.500
256 45.280 452.800
512 23.490 234.900
768 15.860 158.600
1024 11.970 119.700
1280 9610 96.100
1518 8120 81.200

Taxa de transferência da camada de aplicação
A maioria dos usuários finais está preocupada com a taxa de transferência das aplicações. Os materiais de marketing de
alguns fornecedores de redes referem-se ao rendimento da camada de aplicação como bom rendimento . Chamá-lo de
goodput esclarece o fato de que é uma medida de dados bons e relevantes da camada de aplicação transmitidos por
unidade de tempo.
É possível melhorar o rendimento, de modo que mais dados por segundo sejam transmitidos, mas não aumentar o
rendimento, porque os dados extras transmitidos são sobrecarga ou retransmissões.
Tenha em mente o que significa taxa de transferência (bytes por segundo). Esses bytes da camada de aplicação são
bons (úteis) ou simplesmente bytes usados pelo protocolo para realizar seu trabalho? Também é possível aumentar o
rendimento sem usar compactação. Mais dados são transmitidos por unidade de tempo, mas o usuário observa um
desempenho pior.
Uma simples meta de rendimento baseada em taxas de dados por segundo entre estações não identifica os requisitos
para aplicações específicas. Ao especificar metas de rendimento para aplicativos, deixe claro que a meta especifica dados
bons (livres de erros) da camada de aplicativo por unidade de tempo. O rendimento da camada de aplicação geralmente
é medido em quilobytes por segundo (KBps) ou megabytes por segundo (MBps).
Trabalhe com seu cliente para identificar requisitos de rendimento para todos os aplicativos que podem se beneficiar do
rendimento maximizado da camada de aplicativos, como transferência de arquivos e aplicativos de banco de dados. (O
rendimento não é importante para todos os aplicativos; por exemplo, alguns aplicativos interativos baseados em
caracteres não precisam de atualizações em telas grandes.) Explique ao seu cliente os fatores que restringem o
rendimento da camada do aplicativo, que incluem o seguinte:
ÿ Taxas de erro ponta a ponta
ÿ Funções de protocolo, como handshake, janelas e confirmações
ÿ Parâmetros de protocolo, como tamanho de quadro e temporizadores de retransmissão
ÿ A taxa pps ou cps de dispositivos interligados
ÿ Pacotes ou células perdidas em dispositivos interligados
ÿ Fatores de desempenho de estações de trabalho e servidores:
ÿ Velocidade de acesso ao disco
ÿ Tamanho do cache de disco
ÿ Desempenho do driver de dispositivo
ÿ Desempenho do barramento do computador (capacidade e métodos de arbitragem)
ÿ Desempenho do processador (CPU)
ÿ Desempenho da memória (tempo de acesso para memória real e virtual)
ÿ Ineficiências do sistema operacional
ÿ Ineficiências ou bugs de aplicativos

Se necessário, trabalhe com seu cliente para identificar problemas de rendimento de aplicativos causados por
erros ou ineficiências em protocolos, sistemas operacionais e aplicativos.
Os analisadores de protocolo são ferramentas importantes para isso. O Capítulo 3 discute o isolamento de problemas de
desempenho com mais detalhes.
Precisão
O objetivo geral da precisão é que os dados recebidos no destino sejam iguais aos dados enviados pela origem. As
causas típicas de erros de dados incluem picos ou picos de energia, problemas de incompatibilidade de
impedância, conexões físicas ruins, dispositivos com falha e ruído causado por máquinas elétricas. Às vezes, bugs
de software também podem causar erros de dados, embora problemas de software sejam uma causa menos
comum de erros do que problemas de camada física. Os quadros que apresentam erro devem ser retransmitidos, o
que tem um efeito negativo no rendimento. No caso de redes IP, o Transmission Control Protocol (TCP) fornece
retransmissão de dados.
Para links WAN, as metas de precisão podem ser especificadas como um limite de taxa de erro de bit (BER). Se a taxa
de erro ultrapassar o BER especificado, a precisão é considerada inaceitável. Os links analógicos têm um limite BER
típico de cerca de 1 em 105. Os circuitos digitais têm uma taxa de erro muito menor do que os circuitos analógicos,
especialmente se for usado cabo de fibra óptica. Os links de fibra óptica têm uma taxa de erro de cerca de 1 em
1011. Os links de cobre têm uma taxa de erro de cerca de 1 em 106.
Para LANs, um BER geralmente não é especificado, principalmente porque ferramentas de medição, como analisadores
de protocolo, concentram-se em quadros, não em bits; entretanto, você pode aproximar um BER comparando o número
de quadros com erros com o número total de bytes vistos pela ferramenta de medição. Um bom limite a ser usado é
que não deve haver mais de um quadro defeituoso por 106 bytes de dados.
Na Ethernet compartilhada, os erros geralmente são resultado de colisões. Duas estações tentam enviar um quadro
ao mesmo tempo e a colisão resultante danifica os quadros, causando erros de verificação de redundância cíclica
(CRC). Dependendo do tamanho da rede Ethernet, muitas dessas colisões acontecem no preâmbulo de 8 bytes dos
quadros e não são registradas pelas ferramentas de solução de problemas. Se a colisão ocorrer após o preâmbulo e
em algum lugar nos primeiros 64 bytes do quadro de dados, isso será registrado como uma colisão legal e o quadro
será chamado de quadro runt. Um objetivo geral para colisões Ethernet é que menos de 0,1% dos quadros sejam
afetados por uma colisão legal (sem contar as colisões que acontecem no preâmbulo).
Uma colisão que ocorre além dos primeiros 64 bytes de um quadro é uma colisão tardia. Colisões tardias são ilegais e
nunca deveriam acontecer. Redes Ethernet muito grandes sofrem colisões tardias porque as estações que enviam
quadros de tamanho mínimo não conseguem ouvir outras estações dentro do intervalo de tempo permitido. O atraso
extra de propagação causado pelo tamanho excessivo da rede causa colisões tardias entre os nós mais distantes.
Repetidores e placas de interface de rede (NIC) com defeito também podem causar colisões tardias.
As colisões nunca devem ocorrer em links Ethernet full-duplex. Se isso acontecer, provavelmente há uma incompatibilidade
duplex. Colisões em um link full-duplex configurado corretamente não têm significado.
Ambas as estações enviando ao mesmo tempo são normais. Receber durante o envio é normal. Então,
não há necessidade de detecção de colisão e colisões não devem ocorrer. O capítulo 3 tem mais
dizer sobre problemas de incompatibilidade duplex e como reconhecer se eles causam erros
suas redes.
As colisões também nunca ocorrem em links WAN. Infelizmente, a saída do comando show interface serial
em roteadores Cisco inclui uma contagem de colisões. Deve ser ignorado.
Os programadores da Cisco usaram um modelo para esta parte do resultado. O modelo é baseado em
a saída do comando show interface ethernet . Não há colisões em uma série
interface, independentemente do encapsulamento ou tecnologia. Colisões ocorrem apenas na transportadora
detectar redes de acesso múltiplo (CSMA), incluindo Ethernet, 802.3, LocalTalk, Aloha e
Redes 802.11. As colisões são uma parte normal do “gerenciamento por contenção”
abordagem que define CSMA. (E embora o LocalTalk e o 802.11 usem CSMA para evitar colisões, ainda podem
ocorrer colisões.)
A precisão geralmente se refere ao número de quadros sem erros transmitidos em relação ao

número total de quadros transmitidos. A precisão também pode caracterizar a frequência com que a rede
reordena sequências de pacotes. A reordenação de pacotes ocorre em muitas situações, incluindo o uso de
malhas de comutação paralelas dentro de um único dispositivo de rede e o uso de links paralelos entre
roteadores. Embora os protocolos de camada superior, como TCP e Real-Time
Transport Protocol (RTP), correto para reordenação de pacotes, o problema pode causar
pequena degradação de desempenho. Alguns aplicativos não usam um protocolo que corrija o
problema e, portanto, pode ser mais gravemente afetado. Como o problema é frequentemente corrigido, pode
ser difícil detectá-lo. Os roteadores IP não são projetados para detectar e muito menos corrigir o reordenamento
de pacotes e, como não detectam essa condição, não podem relatar o problema.
problema para software de gerenciamento de rede. As medições devem ser feitas nos hosts finais.
Por exemplo, você poderia usar um analisador de protocolo em um host de estação final para detectar o
reordenação de pacotes.
Eficiência
Eficiência é um termo emprestado das áreas de engenharia e científicas. É uma medida
de quão eficaz é uma operação em comparação com o custo em esforço, energia, tempo ou
dinheiro. A eficiência especifica quanta sobrecarga é necessária para produzir o resultado desejado. Por
exemplo, você poderia medir a eficiência de um método para ferver água.
A maior parte da energia vai para a fervura da água ou grande parte da energia é obtida
desperdiçado aquecendo a fiação elétrica, a panela onde está a água e o ar ao seu redor? Como
muita sobrecarga é necessária para produzir o resultado desejado?
A eficiência também fornece uma maneira útil de falar sobre o desempenho da rede. Por exemplo,
a Ethernet compartilhada é ineficiente quando a taxa de colisão é alta. (A quantidade de esforço para enviar um
quadro com sucesso torna-se considerável porque muitos quadros sofrem colisões.) A eficiência da rede
especifica quanta sobrecarga é necessária para enviar tráfego,
se essa sobrecarga é causada por colisões, passagem de token, relatório de erros, redirecionamento,
confirmações, cabeçalhos de quadros grandes, design de rede incorreto e assim por diante.
Cabeçalhos de quadros grandes são uma das causas da ineficiência. Nos preocupamos muito menos com o quadro
cabeçalhos do que costumávamos quando a largura de banda era mais escassa. No entanto, para redes onde
Embora a largura de banda ainda seja (ou possa se tornar) escassa, uma boa meta de desempenho de
rede é que os aplicativos que enviam dados em massa minimizem a quantidade de largura de banda usada
pelos cabeçalhos, usando o maior quadro possível permitido pela camada MAC. O uso de um quadro grande
maximiza a quantidade de dados úteis do aplicativo em comparação aos dados do cabeçalho e melhora o
rendimento da camada do aplicativo.
A Figura 2-2 mostra um tubo de largura de banda usado por quadros pequenos e o mesmo tubo usado por quadros
grandes. O cabeçalho de cada quadro está sombreado. Observe que há um intervalo entre cada quadro, além
dos cabeçalhos. No gráfico, você pode ver que os quadros grandes usam a largura de banda com mais
eficiência do que os quadros pequenos.
Quadros pequenos (menos eficientes)
Quadros grandes (mais eficientes)
Figura 2-2 Eficiência de utilização de largura de banda para

quadros pequenos versus grandes
O tamanho máximo do quadro é uma compensação com o BER discutido na seção anterior.
Quadros maiores têm mais bits e, portanto, são mais propensos a serem atingidos por um erro. Se não houvesse
erros, um quadro infinitamente grande seria o mais eficiente (embora não o mais justo para outros remetentes).
Se um quadro for atingido por um erro, ele deverá ser retransmitido, o que desperdiça tempo e esforço e reduz a
eficiência. Quanto maior o quadro, mais largura de banda é desperdiçada na retransmissão. Assim, como as
redes apresentam erros, os tamanhos dos quadros são limitados para maximizar a eficiência e a imparcialidade.
O tamanho máximo do quadro para Ethernet, por exemplo, é 1522 bytes, incluindo o cabeçalho, CRC e uma
etiqueta VLAN 802.1Q.
Como é o caso de muitos objetivos de projeto de rede, existem compensações associadas ao objetivo de melhorar
a eficiência usando tamanhos de quadros grandes. Em links WAN lentos, o tempo para enviar um quadro
grande é significativo. O tempo para produzir um quadro é chamado de atraso de serialização.
O atraso na serialização se torna um problema quando aplicativos que enviam quadros grandes, como transferência
de arquivos, compartilham um link WAN com aplicativos sensíveis a atrasos, como voz e vídeo. Uma solução
é usar o ATM, que divide os frames em células. Outras soluções incluem o uso de opções de fragmentação
e intercalação de camada de enlace, como Frame Relay FRF.12, Multilink Frame Relay (FRF.16) e Multilink PPP.
Atraso e variação de atraso

Os usuários de aplicativos interativos esperam um atraso mínimo no recebimento de feedback da rede. Os
aplicativos de voz e vídeo também exigem atraso mínimo. Além disso, as aplicações de voz e vídeo exigem
uma variação mínima na quantidade de atraso que os pacotes
experiência. Variações no atraso, chamadas jitter, causam interrupções na qualidade da voz e

instabilidade nas transmissões de vídeo.
Os aplicativos que usam o protocolo Telnet também são sensíveis a atrasos porque o usuário espera
um feedback rápido ao digitar caracteres. O Telnet está se tornando obsoleto, mas ainda não desapareceu.
Com a opção de eco remoto Telnet, o caractere digitado por um usuário não aparece na tela até que tenha
sido reconhecido e ecoado pela extremidade remota, e a extremidade próxima tenha enviado uma
confirmação para o eco. Para ajudá-lo a reconhecer a necessidade de projetar uma rede com atraso baixo,
você deve determinar se seu cliente planeja executar aplicativos sensíveis a atraso, como voz ou vídeo, ou
aplicativos baseados em protocolos sensíveis a atraso, como Telnet.
Causas do Atraso
Quaisquer objetivos relativos ao atraso devem levar em conta a física fundamental. Apesar das histórias de
ficção científica dizerem o contrário, qualquer sinal sofre um atraso de propagação resultante da velocidade
finita da luz, que é de cerca de 300.000 quilómetros por segundo (186.000 milhas por segundo). Os
projetistas de rede também podem lembrar 1 nanossegundo por pé. Esses valores são para a luz viajando
no vácuo. Um sinal em um cabo ou fibra óptica viaja aproximadamente dois terços da velocidade da
luz no vácuo.
O atraso é relevante para todas as tecnologias de transmissão de dados, mas especialmente para ligações
de satélite e cabos terrestres longos. Os satélites geoestacionários estão em órbita acima da Terra a uma
altura de cerca de 36.000 quilômetros, ou 24.000 milhas. Esta longa distância leva a um atraso de
propagação de cerca de 270 milissegundos (ms) para um salto de satélite intercontinental. No caso de
ligações por cabo terrestre, o atraso de propagação é de cerca de 1 ms por cada 200 quilómetros (120
milhas).
Outra causa fundamental do atraso é o atraso na serialização, o tempo para colocar dados digitais em uma
linha de transmissão, que depende do volume de dados e da velocidade da linha. Por exemplo, para transmitir
um pacote de 1.024 bytes em uma linha T1 de 1,544 Mbps leva cerca de 5 ms.
Um atraso fundamental adicional é o atraso na comutação de pacotes. O atraso na comutação de pacotes

refere-se à latência acumulada quando os switches e roteadores encaminham dados. A latência depende
da velocidade dos circuitos internos e da CPU, e da arquitetura de comutação do dispositivo de inter-rede.
A latência também depende do tipo de RAM que o dispositivo usa.
A RAM dinâmica (DRAM) precisa ser atualizada milhares de vezes por segundo. A RAM estática (SRAM)
não precisa ser atualizada, o que a torna mais rápida, mas também é mais cara que a DRAM. Dispositivos
de interconexão de redes de baixo custo geralmente usam DRAM para manter o custo baixo.
O atraso na comutação de pacotes pode ser bem pequeno em switches de última geração, na faixa de 5 a
20 microssegundos para quadros Ethernet de 64 bytes. Os roteadores tendem a apresentar mais
latência do que os switches. A quantidade de latência que um roteador causa para a comutação de
pacotes depende de muitas variáveis, incluindo a arquitetura do roteador, a configuração e os recursos
de software que otimizam o encaminhamento de pacotes. Apesar das afirmações de marketing dos vendedores
de switches, você não deve presumir que um roteador tenha latência maior que um switch. Um roteador de última geração
com uma CPU rápida, SRAM, software otimizado e uma estrutura de comutação altamente evoluída pode
superam muitos switches de gama baixa ou média.
É claro que um roteador tem uma tarefa mais complicada do que um switch de Camada 2. Em termos gerais,
quando um pacote chega a um roteador, o roteador verifica sua tabela de roteamento, decide qual
interface deve enviar o pacote e encapsula o pacote com o link de dados correto
cabeçalho e trailer da camada. Fornecedores de roteamento, como a Cisco, possuem mecanismos avançados
de cache para que um quadro destinado a um destino conhecido possa receber seu novo encapsulamento.
rapidamente sem exigir que a CPU faça qualquer pesquisa de tabela ou outro processamento. Esses
mecanismos minimizam o atraso na comutação de pacotes.
A velocidade da comutação de pacotes depende do tipo e do número de recursos avançados que são
habilitado em um dispositivo de comutação de pacotes. Ao projetar uma malha de interligação de redes, considere
o poder que você precisará incorporar ao projeto para implementar qualidade de serviço (QoS), tradução de
endereço de rede (NAT), IPsec, filtragem e assim por diante. Considere o
políticas que seu cliente de design deseja aplicar e o efeito que elas terão sobre
atraso na comutação de pacotes.
O atraso na comutação de pacotes também pode incluir atraso na fila . O número médio de pacotes
em uma fila em um dispositivo de comutação de pacotes aumenta exponencialmente à medida que a utilização aumenta, à medida que
você pode ver na Figura 2-3. Se a utilização for de 50%, a profundidade média da fila será um
pacote. Se a utilização for de 90%, a profundidade média da fila será de nove pacotes. Sem ir
na teoria matemática das filas, a regra geral para a profundidade da fila é a seguinte:
Profundidade da fila = Utilização / (1 – Utilização)
15
12
9
Profundidade
0
0,5 0,6 0,7 0,8 0,9 1
Utilização média
Figura 2-3 Profundidade da fila e utilização da largura de banda
Considere o seguinte exemplo. Um switch de pacotes tem cinco usuários, cada um oferecendo pacotes em um determinado momento.
taxa de 10 pp. O comprimento médio dos pacotes é de 1024 bits. O switch de pacotes precisa
transmitir esses dados através de um circuito WAN de 56 kbps. Juntando tudo isso, você tem o
seguintes equações:
Carga = 5 × 10 × 1024 = 51.200 bps
Utilização = 51.200/56.000 = 91,4 por cento Número
médio de pacotes na fila = (0,914) / (1 – 0,914) = 10,63 pacotes
Ao aumentar a largura de banda em um circuito WAN, você pode diminuir a profundidade da fila e, portanto,
diminuir o atraso. Alternativamente, para melhorar o desempenho, você pode usar um algoritmo de enfileiramento
avançado que gera primeiro certos tipos de pacotes – por exemplo, pacotes de voz ou vídeo. O Capítulo 13
aborda técnicas avançadas de enfileiramento de roteadores com mais detalhes.
Variação de atraso À
medida que os clientes implementam novas aplicações digitais de voz e vídeo, eles ficam preocupados com
atrasos e variações de atraso. Além disso, os clientes estão cada vez mais conscientes dos problemas
associados ao suporte de tráfego em rajadas na mesma rede que transporta tráfego sensível a atrasos. Se as
interrupções no tráfego causarem instabilidade, os fluxos de áudio e vídeo apresentarão problemas que
interromperão as comunicações.
Os aplicativos de áudio/vídeo de desktop podem minimizar o jitter fornecendo um buffer de jitter. O software ou
hardware de exibição extrai dados do buffer. O buffer isolante reduz o efeito do jitter porque as variações no lado
da entrada são menores que o tamanho total do buffer e, portanto, não são óbvias no lado da saída. Os
dados são suavizados na saída e o usuário não sente efeitos nocivos do tremor de entrada.
Se possível, você deve reunir requisitos exatos de variação de atraso de um cliente. Para clientes que não
conseguem fornecer metas exatas, uma boa regra é que a variação seja inferior a 1 ou 2% do atraso. Por
exemplo, para uma meta de atraso médio de 40 ms, a variação não deve ser superior a 400 ou 800
microssegundos.
Células curtas de comprimento fixo, como células ATM de 53 bytes, são inerentemente melhores que quadros
para atender às metas de atraso e variação de atraso. Para ajudar a compreender este conceito, considere a
analogia de pessoas tentando subir em uma escada rolante. A escada rolante é como um tubo de largura de banda.
No início, cada pessoa sobe na escada rolante de forma ordenada e o atraso é previsível. Aí chega uma
turma da escola e as crianças estão todas de mãos dadas, esperando subir na escada rolante todas de uma
vez! O que acontece com o seu atraso se você estiver atrás das crianças?
Um grupo de crianças em idade escolar de mãos dadas é análogo a um quadro grande, causando atraso
extra em quadros pequenos. Considere o caso de um usuário iniciando uma transferência de arquivo usando
quadros de 1.518 bytes. Os dados deste usuário afetam o uso da largura de banda e os mecanismos de
enfileiramento em dispositivos que funcionam na Internet, causando atrasos inesperados para outro tráfego.
Um bom rendimento para um aplicativo causa problemas de atraso para outro aplicativo.
As tecnologias de retransmissão celular (ATM, por exemplo) foram projetadas para suportar tráfego sensível a
atrasos e jitter. Dependendo da classe de serviço, o ATM permite que uma sessão especifique um atraso
máximo de transferência de célula (MCTD) e uma variação máxima de atraso de célula (MCDV).
O Capítulo 4 descreve as classes de serviço ATM com mais detalhes.
Tempo de resposta
O tempo de resposta é a meta de desempenho da rede que mais preocupa os usuários. Os usuários não
saber sobre atraso de propagação e jitter. Eles não entendem o rendimento em pps ou em
MBps. Eles não estão preocupados com os BERs, embora talvez devessem estar! Os usuários reconhecem a
quantidade de tempo para receber uma resposta do sistema de rede. Eles também reconhecem pequenas mudanças
no tempo de resposta esperado e ficam frustrados quando o
o tempo de resposta é longo.
Os usuários começam a ficar frustrados quando o tempo de resposta é superior a 100 ms ou 1/10 do tempo de resposta.
um segundo. Além de 100 ms, os usuários percebem que estão esperando que a rede exiba uma web
página, ecoar um caractere digitado, iniciar o download de e-mail e assim por diante. Se a resposta ocorrer dentro
de 100 ms, a maioria dos usuários não notará nenhum atraso.
O limite de 100 ms é frequentemente usado como valor de temporizador para protocolos que oferecem transporte
confiável de dados. Por exemplo, muitas implementações TCP retransmitem dados não reconhecidos
após 100 ms por padrão.
Nota Boas implementações de TCP também ajustam o temporizador de retransmissão com base nas condições da rede.
O TCP deve acompanhar o tempo médio para receber uma resposta e
ajuste dinamicamente o temporizador de retransmissão com base no atraso esperado.
O limite de tempo de resposta de 100 ms se aplica a aplicativos interativos. Para aplicações em massa, como
transferência de arquivos grandes ou páginas gráficas da Web, os usuários estão dispostos a esperar
pelo menos 10 a 20 segundos. Usuários tecnicamente experientes esperam esperar ainda mais se souberem
o arquivo é grande e o meio de transmissão é lento. Se os usuários da sua rede não tiverem conhecimento técnico,
você deverá fornecer algumas orientações sobre quanto tempo esperar, dependendo da situação.
tamanho dos arquivos e as tecnologias utilizadas (modems, redes digitais de alta velocidade, satélites
geoestacionários, etc.).
Segurança
A segurança é um objetivo técnico fundamental e o design de segurança é um dos aspectos mais importantes
do projeto de redes corporativas. O aumento das ameaças provenientes tanto de dentro como de fora da rede
empresarial exige regras e tecnologias de segurança mais atualizadas. Um geral
O objetivo da maioria das empresas é que os problemas de segurança não atrapalhem a capacidade da empresa de
conduzir negócios. Os clientes de design de rede precisam de garantias de que um
design oferece proteção contra dados de negócios e outros ativos que sejam danificados ou
acessado de forma inadequada. Toda empresa possui segredos comerciais, operações comerciais e
equipamento a proteger.
A primeira tarefa no design de segurança é o planejamento. O planejamento envolve a identificação de ativos de rede
que devem ser protegidos, analisando riscos e desenvolvendo requisitos. Este capítulo brevemente
discute o planejamento de segurança. O Capítulo 8, “Desenvolvendo estratégias de segurança de rede”, aborda
planejamento de redes seguras com mais detalhes.
Como acontece com a maioria dos requisitos de projeto técnico, atingir as metas de segurança significa fazer
concessões. As implementações de segurança podem aumentar o custo de implantação e operação de uma
rede. Políticas de segurança rigorosas também podem afectar a produtividade dos utilizadores, especialmente
se alguma facilidade de utilização tiver de ser sacrificada para proteger recursos e dados. Implementações de
segurança deficientes podem incomodar os usuários, fazendo-os pensar em maneiras de contornar as
políticas de segurança. A segurança também pode afetar a redundância de um projeto de rede se todo o
tráfego precisar passar por dispositivos de criptografia, por exemplo.
É prática comum construir sistemas com segurança suficiente para reduzir as perdas potenciais decorrentes de
uma violação de segurança até um nível desejado. Um objetivo prático é garantir que o custo para implementar
a segurança não exceda o custo para recuperar-se de incidentes de segurança.
Alternativamente, algumas organizações podem querer implementar medidas mais fortes para mitigar riscos
imprevistos. Ao trabalhar com seu cliente, você deve analisar o custo associado a incidentes de segurança que
interrompem os negócios e determinar se o cliente deseja tentar resolver problemas inesperados.
Identificando ativos de rede

O primeiro passo no projeto de segurança é identificar os ativos que devem ser protegidos, o valor dos ativos e
o custo esperado associado à perda desses ativos caso ocorra uma violação de segurança. Os ativos de
rede incluem hardware, software, aplicativos e dados. Os ativos também incluem propriedade intelectual,
segredos comerciais e a reputação de uma empresa.
Considere a possibilidade de um hacker prejudicar a reputação de uma empresa alterando as páginas públicas
da empresa. Você deve ter lido sobre alguns casos de hackers que alteraram páginas da web do governo
dos EUA. Estas falhas de segurança afectaram a reputação do governo de duas maneiras: as páginas web
alteradas tinham gráficos e textos ridículos, e o governo perdeu credibilidade porque parecia ser fácil invadir
redes governamentais.
Os dados que uma empresa utiliza para cumprir a sua missão são um ativo frequentemente esquecido. Os
dados podem incluir projetos de engenharia, documentos de planejamento financeiro, informações de
relacionamento com clientes, documentos de análise competitiva, informações de configuração de hardware e
software, números de Seguro Social de funcionários, informações de crachás de funcionários e assim por diante.
A integridade e confidencialidade destes dados devem ser protegidas contra danos intencionais ou não
intencionais.
Alguns dos ativos de rede mais importantes são os próprios dispositivos de rede, incluindo servidores,
switches e roteadores, e especialmente os firewalls e sistemas de detecção de intrusão (IDS) que fornecem
serviços de segurança aos usuários da rede. Esses dispositivos são alvos atrativos para hackers e devem
ser reforçados (fortalecidos) contra invasões. Como o Capítulo 8 discute com mais detalhes, fortalecer
dispositivos de rede envolve executar apenas os serviços mínimos necessários, estabelecer confiança apenas
com parceiros autenticados, usar canais seguros de gerenciamento de dispositivos e corrigir o software do
dispositivo para instalar correções para problemas de segurança conhecidos.
Você deve considerar mais do que apenas dados e dispositivos ao identificar ativos. O tempo do usuário da rede
pode ser considerado um ativo. Sempre que um vírus ataca um sistema, leva tempo para
livre-se dele, mesmo que seja inócuo. O fato de esse tempo ser desperdiçado é semelhante a um ataque de
negação de serviço (D0S). Um ativo também pode ser a capacidade de oferecer serviços aos clientes.
Isto é especialmente verdadeiro para provedores de serviços de Internet (ISP), mas também para muitas
outras empresas que oferecem serviços médicos, educacionais, financeiros e outros tipos de serviços.
Cada cliente de design tem ativos de negócios diferentes e necessidades variadas em relação à
importância dos ativos. Como designer de rede, você deve trabalhar com gerentes técnicos e de negócios
para identificar quais ativos são essenciais para a missão de uma empresa. Uma empresa de serviços
financeiros, por exemplo, possui ativos diferentes de uma organização de saúde ou de uma empresa de
pesquisa biomédica. Como parte da primeira etapa do projeto de rede, analisando os requisitos de negócios,
você deve ter desenvolvido um bom entendimento da missão comercial geral do cliente de projeto de rede
(que, aliás, pode ser diferente da declaração de missão corporativa, que geralmente é escrita em formato
maneira elevada de motivar os funcionários e impressionar os acionistas).
Analisando riscos de segurança
Além de identificar ativos, uma etapa importante no planejamento de segurança é analisar ameaças
potenciais e compreender sua probabilidade e impacto nos negócios.
A análise de risco e a consequente construção de uma política de segurança e design de rede segura é um
processo contínuo, uma vez que os riscos mudam regularmente em termos de gravidade e probabilidade.
Por exemplo, o algoritmo de criptografia de uma empresa e o comprimento da chave de criptografia podem
precisar ser reconsiderados se um computador de quebra de código relativamente barato e excepcionalmente
rápido estiver disponível, o que permite uma descriptografia mais fácil de segredos valiosos.
A avaliação de risco inclui uma análise do perigo de não tomar nenhuma ação. Peça ao seu cliente para
ajudá-lo a compreender os riscos associados à não implementação de uma rede segura. Quão sensíveis são
os dados do cliente? Qual seria o custo financeiro de alguém acessar os dados e roubar segredos
comerciais? Qual seria o custo financeiro de alguém alterar os dados? Qual seria o custo financeiro
associado à queda da rede devido a uma violação de segurança, impossibilitando os funcionários de realizar
seu trabalho?
Conforme mencionado anteriormente, um dos maiores riscos que devem ser gerenciados é o risco de um
hacker minar a segurança de um dispositivo de rede, como um switch, roteador, servidor, firewall ou IDS.
Quando um dispositivo de rede é comprometido, surgem as seguintes ameaças:
ÿ Os dados que fluem pela rede podem ser interceptados, analisados, alterados ou excluídos,
comprometer a integridade e a confidencialidade.
ÿ Serviços de rede adicionais relacionados, que dependem da confiança entre dispositivos de rede, podem ser
comprometidos. Por exemplo, dados de roteamento incorretos ou informações de autenticação incorretas
podem ser injetados na rede.
ÿ As senhas dos usuários podem ser comprometidas e usadas para novas invasões e talvez para alcançar e
atacar outras redes.
ÿ A configuração do dispositivo pode ser alterada para permitir conexões que não deveriam ser
permitido ou proibir conexões que deveriam ser permitidas.
Alguns clientes se preocupam com o fato de hackers usarem analisadores de protocolo para detectar pacotes e ver
senhas, números de cartão de crédito ou outros dados privados. Este não é um risco tão grande quanto
parece. Os números de cartão de crédito são quase sempre enviados criptografados, usando tecnologias como
como o protocolo Secure Sockets Layer (SSL). As senhas também são enviadas criptografadas e são
geralmente é bom para apenas um uso, se senhas de uso único (OTP) forem usadas. Mesmo quando
senhas ou cartões de crédito não são criptografados, é extremamente difícil encontrá-los
pedaços de dados em meio a milhões de pacotes detectados. Além disso, para detectar pacotes relevantes, um
O hacker precisa de acesso físico a um link que transporta tráfego relevante ou precisa ter um switch prometido que
suporte monitoramento de porta.
Os hackers estão ficando mais criativos. Sabe-se que hackers disfarçados de clientes, técnicos de reparos e empreiteiros
entram em organizações e ganham rede.
acesso através de uma conexão de rede em um cubículo vazio ou sala de conferências. Às vezes
as empresas possuem salas de demonstração, onde apresentam seus produtos. Para facilidade de uso do
pessoas que configuram os produtos, essas salas às vezes têm acesso aos dados da empresa
intranet e à Internet. Os hackers adoram esse tipo de configuração. Hackers que são menos descarados,
e não querem entrar no prédio de uma organização, muitas vezes sentam-se no estacionamento
com um notebook habilitado para 802.11 sem fio ou dispositivo portátil sem fio e
acessar redes corporativas onde a segurança não foi bem planejada.
Além de considerar os hackers externos como um risco à segurança, as empresas devem prestar atenção aos problemas
causados por usuários ineptos ou mal-intencionados da rede interna. Os ataques podem vir de erros inadvertidos do
usuário, incluindo o download de software de sites não confiáveis que introduzem malware. Os ataques também podem
vir de atos maliciosos de usuários internos, incluindo
funcionários insatisfeitos com os cortes de custos, funcionários que se tornam gananciosos durante tempos
econômicos difíceis e funcionários com uma agenda política. As organizações devem ter programas de treinamento e
conscientização em segurança da informação para mitigar o risco de ataques de usuários internos.
Ataques de reconhecimento
Um conjunto de riscos de segurança cai na categoria de ataque de reconhecimento , pois o ataque . Um reconhecimento
fornece informações sobre alvos potenciais e seus pontos fracos e é

geralmente realizado em preparação para um ataque mais focado contra um alvo específico.
Os invasores de reconhecimento usam ferramentas para descobrir a acessibilidade de hosts, sub-redes, serviços,
e aplicações. Em alguns casos, as ferramentas são relativamente sofisticadas e podem quebrar
através de firewalls. Um hacker menos sofisticado poderia convencer os usuários a baixar um arquivo
de um suposto site de música, vídeo, pornografia ou jogo. O arquivo poderia na verdade ser um
Cavalo de Tróia que coleta dados de reconhecimento.
Durante um ataque de reconhecimento, o invasor pode fazer as seguintes tentativas para aprender
mais sobre a rede:
ÿ Coletar informações sobre a configuração e o gerenciamento da rede no domínio

Registros do sistema de nomes (DNS).
ÿ Descobrir possibilidades de acesso usando “discagem de guerra” (tentativas de descobrir e conectar-se a

pontos de acesso dial-up) e “condução de guerra” (tentativas de descobrir e conectar-se a pontos de acesso sem
fio mal concebidos).
ÿ Coletar informações sobre a topologia e o endereçamento de uma rede usando ferramentas de mapeamento de
rede. Algumas ferramentas, como consultas traceroute e Simple Network Management Protocol
(SNMP), são primitivas. Outros são sofisticados e podem enviar pacotes aparentemente legítimos para
mapear uma rede.
ÿ Descubra a acessibilidade de hosts, serviços e aplicativos usando varreduras de ping e

varreduras de portas.
ÿ Descubra versões de sistemas operacionais e aplicativos e investigue falhas de segurança conhecidas no software.
ÿ Descubra brechas temporárias criadas enquanto sistemas, configurações e software são refeitos
os arrendamentos estão sendo atualizados.
Ataques de negação de serviço
Os ataques de negação de serviço (DoS) visam a disponibilidade de uma rede, host ou aplicativo, impossibilitando
o acesso de usuários legítimos. Os ataques DoS representam um grande risco porque podem interromper
facilmente os processos de negócios e são relativamente simples de conduzir, mesmo por um invasor não qualificado.
Os ataques DoS incluem a inundação de servidores públicos com enormes números de solicitações de
conexão, fazendo com que o servidor deixe de responder aos usuários legítimos, e a inundação de conexões
de rede com tráfego aleatório, na tentativa de consumir o máximo de largura de banda possível. Os ataques
distribuídos de negação de serviço (DDoS) são ainda piores que os ataques DoS porque o invasor agrupa vários
hosts, de diversas redes, para atacar o alvo.
Os ataques DoS geralmente são consequência da incapacidade de uma rede, host ou aplicativo de lidar com uma
enorme quantidade de dados, o que trava o sistema ou interrompe serviços no sistema. Os ataques DoS também
aproveitam a falha de um host ou aplicativo em lidar com condições inesperadas, como dados de entrada
formatados maliciosamente ou um buffer overflow.
Os ataques DoS são um dos riscos mais significativos que uma empresa deve reconhecer e gerir, porque têm
a capacidade de causar tempos de inatividade significativos.
Desenvolvimento de requisitos de segurança

Os problemas de segurança não devem perturbar a capacidade de uma organização conduzir negócios.
Esse é o requisito de segurança mais básico que toda organização possui. Um requisito secundário de segurança é
proteger os ativos de serem incapacitados, roubados, alterados ou danificados.
Embora cada cliente de projeto tenha diferentes requisitos de segurança detalhados, os requisitos básicos
resumem-se à necessidade de desenvolver e selecionar procedimentos e tecnologias que garantam o seguinte:
ÿ Confidencialidade dos dados para que apenas usuários autorizados possam visualizar informações confidenciais
ÿ Integridade dos dados para que apenas usuários autorizados possam alterar informações confidenciais e para
que os usuários autorizados dos dados possam confiar em sua autenticidade
ÿ Disponibilidade de sistemas e dados, que deve fornecer acesso ininterrupto a importantes

recursos de computação
Outros requisitos mais específicos podem incluir um ou mais dos seguintes objetivos:
ÿ Permitir que pessoas externas (clientes, vendedores, fornecedores) acessem dados em servidores públicos da Web
ou de protocolo de transferência de arquivos (FTP), mas não acessem dados internos.
ÿ Autorizar e autenticar usuários de filiais, usuários móveis e teletrabalhadores.
ÿ Detecte intrusos e isole a quantidade de danos que eles causam.
ÿ Autenticar atualizações da tabela de roteamento recebidas de roteadores internos ou externos.
ÿ Proteja os dados transmitidos para locais remotos através de uma VPN.
ÿ Hosts e dispositivos de interligação de redes fisicamente seguros (por exemplo, manter os dispositivos em um
quarto trancado).
ÿ Hosts e dispositivos de interligação de redes logicamente seguros com contas de usuário e acesso
direitos para diretórios e arquivos.
ÿ Proteja aplicativos e dados contra vírus de software.
ÿ Treinar usuários e gerentes de rede sobre riscos de segurança e como evitá-los.

problemas de dignidade.
ÿ Implementar direitos autorais ou outros métodos legais de proteção de produtos e direitos intelectuais
propriedade.
ÿ Atender aos requisitos regulamentares e de conformidade.
Capacidade de gerenciamento
Cada cliente tem objetivos diferentes em relação à capacidade de gerenciamento de uma rede. Alguns clientes têm
objetivos precisos, como planejar usar SNMP para registrar o número de bytes que cada roteador recebe e envia. Outros
clientes têm objetivos menos específicos. Se o seu cliente tiver planos definidos, certifique-se de documentá-los, pois
você precisará consultá-los ao selecionar o equipamento. Em alguns casos, o equipamento tem de ser descartado
porque não suporta as funções de gestão que um cliente necessita.
O gerenciamento de rede é discutido com mais detalhes no Capítulo 9, “Desenvolvendo estratégias de gerenciamento
de rede”, mas também é importante considerar o gerenciamento no início de um projeto de design. Durante a coleta inicial
de requisitos técnicos para um novo projeto ou atualização de rede, você pode usar a terminologia da Organização
Internacional de Padronização (ISO) para simplificar a discussão das metas de gerenciamento de rede com seu cliente
de projeto. ISO usa o acrônimo FCAPS para ajudá-lo a lembrar as seguintes funções de gerenciamento de rede:
ÿ Gerenciamento de falhas: detecção, isolamento e correção de problemas; relatar problemas aos usuários finais e
gerentes; rastrear tendências relacionadas a problemas
ÿ Gerenciamento de configuração: controlar, operar, identificar e coletar dados de dispositivos gerenciados

ÿ Gerenciamento contábil: contabilização do uso da rede para alocar custos aos usuários da rede e/ou planejar
mudanças nos requisitos de capacidade
ÿ Gerenciamento de desempenho: análise do comportamento do tráfego e dos aplicativos para otimizar uma rede,
cumprir acordos de nível de serviço e planejar expansão
ÿ Gerenciamento de segurança: monitoramento e teste de políticas de segurança e proteção,

manter e distribuir senhas e outras informações de autenticação e autorização, gerenciar chaves de
criptografia e auditar a adesão a políticas de segurança
Usabilidade
Um objetivo que está relacionado à capacidade de gerenciamento, mas não é exatamente o mesmo que
capacidade de gerenciamento, é a usabilidade. Usabilidade refere-se à facilidade de uso com que os usuários da
rede podem acessar a rede e os serviços. Enquanto a gerenciabilidade se concentra em facilitar o trabalho dos
gerentes de rede, a usabilidade se concentra em facilitar o trabalho dos usuários da rede.
É importante compreender o quão importante é a usabilidade para o seu cliente de projeto de rede, porque
alguns componentes do projeto de rede podem ter um efeito negativo na usabilidade. Por exemplo, políticas de
segurança rigorosas podem ter um efeito negativo na usabilidade (que é uma compensação que a maioria dos
clientes está disposta a fazer, mas não todos os clientes). Você pode planejar maximizar a usabilidade implantando
esquemas de nomenclatura de host fáceis de usar e métodos de configuração fáceis de usar que fazem uso
de protocolos dinâmicos, como o Dynamic Host Configuration Protocol (DHCP).
A usabilidade também pode incluir a necessidade de mobilidade. Conforme mencionado no Capítulo 1, os usuários
esperam realizar seu trabalho independentemente de sua localização física. Eles esperam ter acesso à rede em
salas de conferência, em casa, nas instalações do cliente e assim por diante. Documentar esse requisito como
parte dos requisitos técnicos ajudará você a reconhecer a necessidade de selecionar soluções sem fio e VPN
durante as fases de design lógico e físico do projeto de design de rede. Também o ajudará a reconhecer a
necessidade de realizar uma pesquisa no local para se preparar para uma infra-estrutura sem fio, conforme discutido
em maiores detalhes na seção “Verificando Restrições Arquitetônicas e Ambientais” do Capítulo 3.
Adaptabilidade
Ao projetar uma rede, você deve tentar evitar incorporar quaisquer elementos que dificultem a implementação
de novas tecnologias no futuro. Um bom projeto de rede pode se adaptar a novas tecnologias e mudanças. As
mudanças podem vir na forma de novos protocolos, novas práticas empresariais, novas metas fiscais, nova
legislação e uma infinidade de outras possibilidades. Por exemplo, alguns estados promulgaram leis ambientais
que exigem uma redução no número de empregados que se deslocam para o trabalho. Para cumprir o requisito
legal de redução das emissões dos automóveis, as empresas precisam que os seus designs de acesso
remoto sejam suficientemente flexíveis para se adaptarem ao número crescente de funcionários que trabalham em
casa. A adaptabilidade de uma rede afeta sua disponibilidade. Por exemplo, algumas redes devem operar em
ambientes que mudam drasticamente do dia para a noite ou do inverno para o verão. Extremo
mudanças na temperatura podem afetar o comportamento dos componentes eletrônicos de uma rede. Uma
rede que não consegue se adaptar não pode oferecer boa disponibilidade.
Um projeto de rede flexível também pode se adaptar às mudanças nos padrões de tráfego e nos requisitos
de QoS. Para alguns clientes, a tecnologia WAN ou LAN selecionada deve se adaptar à entrada aleatória
de novos usuários na rede para usar aplicativos que exigem um serviço de taxa de bits constante. O
Capítulo 4 discute os requisitos de QoS com mais detalhes.
Um outro aspecto da adaptabilidade é a rapidez com que os dispositivos interligados devem se adaptar aos
problemas e às atualizações. Por exemplo, com que rapidez os switches e pontes se adaptam à falha de
outro switch, causando uma mudança na topologia spanning tree? Com que rapidez os roteadores se
adaptam às novas redes que ingressam na topologia? Com que rapidez os protocolos de roteamento se
adaptam às falhas de link? O Capítulo 7, “Selecionando protocolos de comutação e roteamento”, discute
essas questões com mais detalhes.
Acessibilidade
O objectivo técnico final que este capítulo cobre é a acessibilidade , que por vezes é chamada de relação
custo-eficácia. A maioria dos clientes tem como meta a acessibilidade, embora às vezes outras metas,
como desempenho e disponibilidade, sejam mais importantes. A acessibilidade é, em parte, uma meta
comercial e foi discutida no Capítulo 1. Ela é abordada novamente neste capítulo devido às questões
técnicas envolvidas.
Para que um projeto de rede seja acessível, ele deve transportar a quantidade máxima de tráfego por um
determinado custo financeiro. Os custos financeiros incluem custos não recorrentes de equipamentos e custos
recorrentes de operação de rede. Conforme mencionado no Capítulo 1, você deve conhecer o orçamento
do seu cliente para poder recomendar soluções acessíveis.
Nas redes de campus, o baixo custo costuma ser o objetivo principal. Os clientes esperam poder adquirir
switches acessíveis, com inúmeras portas e um baixo custo por porta. Eles esperam que os custos de
cabeamento sejam mínimos e que as tarifas dos provedores de serviços sejam mínimas ou inexistentes. Eles
também esperam que as NICs para sistemas finais e servidores sejam baratas. Dependendo das aplicações
executadas nos sistemas finais, o baixo custo é muitas vezes mais importante do que a disponibilidade e o
desempenho nos projetos de redes de campus. Para redes empresariais, a disponibilidade geralmente é mais
importante que o baixo custo. No entanto, os clientes procuram formas de conter custos para redes
empresariais. Cobranças mensais recorrentes para circuitos WAN são o aspecto mais caro da operação de
uma rede grande.
Para reduzir o custo de operação de uma WAN, os clientes geralmente têm uma ou mais das seguintes metas
técnicas para alcançar a acessibilidade:
ÿ Use um protocolo de roteamento que minimize o tráfego WAN.
ÿ Consolidar linhas alugadas paralelas que transportam voz e dados em menos troncos WAN.
ÿ Selecione tecnologias que aloquem dinamicamente largura de banda WAN — por exemplo, ATM
em vez de multiplexação por divisão de tempo (TDM).
ÿ Melhore a eficiência em circuitos WAN usando recursos como compactação.

ÿ Elimine troncos subutilizados da rede e economize dinheiro eliminando

custos de circuito e hardware de tronco.
ÿ Use tecnologias que suportem o excesso de assinaturas.
Com as redes TDM antigas, a capacidade central do backbone tinha que ser pelo menos a soma das velocidades
das redes de acesso de entrada. Com a comutação de células e quadros, o excesso de assinaturas é
comum. Devido à natureza intermitente do tráfego baseado em quadros, as velocidades das portas de
acesso podem ser superiores à velocidade de uma rede backbone, dentro do razoável.
Os gestores de redes empresariais que têm como objectivo reduzir os custos operacionais estão especialmente
interessados em soluções que lhes permitam sobrecarregar os seus troncos, mantendo ao mesmo tempo
as garantias de serviço que oferecem aos seus utilizadores.
O segundo aspecto mais caro da operação de uma rede, depois do custo dos circuitos WAN, é o custo de
contratação, treinamento e manutenção de pessoal para operar e gerenciar a rede. Para reduzir esse aspecto
dos custos operacionais, os clientes podem exigir que você faça o seguinte ao desenvolver o projeto da rede:
ÿ Selecione equipamentos de interligação de redes que sejam fáceis de configurar, operar, manter e
gerenciar.
ÿ Selecione um projeto de rede que seja fácil de entender e solucionar problemas.
ÿ Desenvolva uma boa documentação de rede que possa ajudar a reduzir o tempo de solução de problemas.
ÿ Selecione aplicativos e protocolos de rede que sejam fáceis de usar para que os usuários possam se
sustentar até certo ponto.
Fazendo compensações no design de rede

Apesar do que os políticos nos dizem sobre os orçamentos estaduais e federais durante um ano eleitoral, no
mundo real, cumprir metas exige fazer concessões. Esta seção descreve algumas compensações típicas de
projeto de rede.
Para atender às altas expectativas de disponibilidade, muitas vezes são necessários componentes
redundantes, o que aumenta o custo de implementação de uma rede. Para atender aos rigorosos
requisitos de desempenho, são necessários circuitos e equipamentos de alto custo. Para impor políticas de
segurança rigorosas, pode ser necessário um monitoramento caro e os usuários devem renunciar a alguma facilidade de uso.
Para implementar uma rede escalável, a disponibilidade pode ser prejudicada, porque uma rede escalável está
sempre em fluxo à medida que novos usuários e sites são adicionados. A implementação de um bom
rendimento para um aplicativo pode causar problemas de atraso para outro aplicativo. A falta de pessoal
qualificado pode sugerir a necessidade de treinamento caro ou a necessidade de abandonar certos recursos.
O projeto de rede que você desenvolve deve levar em consideração essas compensações.
Uma das causas dos problemas de rede pode ser a falta de pessoal e a redução do treinamento devido ao
excesso de zelo na redução de custos. A compensação com a redução de custos pode ser uma rede que
não seja robusta ou tenha um desempenho abaixo do padrão até que o problema seja reconhecido, o que
geralmente leva um ou dois anos. Se o pessoal da rede interna fosse reduzido, a terceirização poderia se tornar uma
necessidade, o que poderia acabar sendo mais caro do que teria sido para manter o pessoal interno.
O processo de design de rede geralmente é progressivo. Isso significa que equipamentos legados
devem coexistir com novos equipamentos. Seu design pode não ser tão elegante quanto você gostaria
porque pode ser necessário que ele suporte dispositivos e aplicativos antigos. Se a nova rede não for introduzida ao
mesmo tempo que novas aplicações, o design deverá proporcionar compatibilidade com aplicações antigas. Além
disso, esteja ciente de que largura de banda insuficiente em
partes da rede, onde a largura de banda não pode ser aumentada devido a restrições técnicas ou comerciais, devem
ser resolvidas por outros meios.
Para ajudá-lo a analisar as compensações, peça ao seu cliente para identificar uma única rede motriz
objetivo do projeto. Esse objetivo pode ser o mesmo objetivo geral de negócios do projeto de design de rede identificado
no Capítulo 1, ou pode ser uma reformulação desse objetivo para incluir questões técnicas. Além disso, peça ao seu
cliente para priorizar o restante das metas. Priorizando
ajudará o cliente a passar pelo processo de fazer concessões.
Uma analogia que ajuda a priorizar metas é a do “garoto na loja de doces com um dólar
analogia da conta”. Usando a analogia da nota de um dólar, explique aos clientes que eles são como
crianças em uma loja de doces que têm exatamente um dólar para gastar. O dólar pode ser gasto
em diferentes tipos de doces: chocolates, alcaçuz, jujubas e assim por diante. Mas cada vez
mais dinheiro é gasto em um tipo de doce, menos dinheiro está disponível para gastar em outro
tipos. Peça aos clientes que somem quanto desejam gastar em escalabilidade, disponibilidade,
desempenho da rede, segurança, capacidade de gerenciamento, usabilidade, adaptabilidade e acessibilidade.
Por exemplo, um cliente poderia fazer as seguintes seleções:
Escalabilidade: 20
Disponibilidade: 30
Desempenho da rede: 15
Segurança: 5
Capacidade de gerenciamento: 5
Usabilidade: 5
Adaptabilidade: 5
Acessibilidade: 15
Total (deve somar 100): 100
Tenha em mente que, às vezes, fazer concessões é mais complexo do que tem sido
descrito porque os objetivos podem diferir para várias partes de uma rede interligada. Um grupo de
os usuários podem valorizar mais a disponibilidade do que a acessibilidade. Outro grupo pode implantar aplicativos de
última geração e valorizar mais o desempenho do que a disponibilidade. Além disso, algumas vezes os objetivos de
um determinado grupo são diferentes dos objetivos gerais da rede, pois
um todo. Se for esse o caso, documente as metas individuais do grupo e as metas da rede conforme
um todo. Posteriormente, ao selecionar tecnologias de rede, você poderá ver algumas oportunidades
para atender a ambos os tipos de objetivos — por exemplo, escolhendo tecnologias LAN que atendam às metas
individuais do grupo e tecnologias WAN que atendam às metas gerais.
Lista de verificação de metas técnicas

Você pode usar a lista de verificação a seguir para determinar se abordou todos os objetivos e
preocupações técnicas do seu cliente:
ÿ Documentei os planos do cliente para expandir o número de sites, usuários e

servidores para o próximo 1 ano e os próximos 2 anos.
ÿ O cliente me contou sobre quaisquer planos de migrar servidores departamentais para um centro
data center tralizado.
ÿ O cliente me informou sobre quaisquer planos para integrar dados armazenados em um main frame
legado com a rede corporativa.
ÿ O cliente me informou sobre quaisquer planos de implementar uma extranet para comunicação com
parceiros ou outras empresas.
ÿ Documentei uma meta para disponibilidade de rede em porcentagem de tempo de atividade e/ou MTBF
e MTTR.
ÿ Documentei todas as metas para utilização média máxima da rede.
ÿ Documentei metas para o rendimento da rede.
ÿ Documentei metas para a taxa de transferência de pps de dispositivos de interligação de redes.
ÿ Documentei metas de precisão e BERs aceitáveis.
ÿ Discuti com o cliente a importância de usar estruturas grandes para maximizar a eficiência.
ÿ Discuti com o cliente as vantagens e desvantagens associadas aos tamanhos de quadros grandes e ao
atraso na serialização.
ÿ Identifiquei quaisquer aplicativos que tenham um requisito de tempo de resposta mais restritivo do que o
padrão da indústria, inferior a 100 ms.
ÿ Discuti os riscos e requisitos de segurança da rede com o cliente.
ÿ Reuni requisitos de capacidade de gerenciamento, incluindo metas de desempenho, falhas, configuração,

segurança e gerenciamento de contabilidade.
ÿ Atualizei o gráfico de Aplicativos de Rede para incluir os objetivos técnicos de aplicação mostrados na
Tabela 2-2.
Tabela 2-2 Requisitos Técnicos de Aplicações de Rede
Nome de Tipo de Novo Criticamente Custo de Aceitável

Aplicativo aplicativo Aplicativo? Tempo de inatividade MTBF
(Sim ou não)
ÿ Trabalhando com meu cliente, desenvolvi uma lista de metas de projeto de rede, incluindo metas
comerciais e técnicas. A lista começa com uma meta geral e inclui as demais metas em ordem
de prioridade. As metas críticas são marcadas como tal.
O Capítulo 1 forneceu um gráfico de aplicativos de rede. Neste ponto do processo de design, você pode
expandir o gráfico para incluir requisitos técnicos de aplicação, como MTBF, MTTR e metas de rendimento
e atraso, conforme mostrado na Tabela 2-2.
Resumo
Este capítulo abordou os requisitos técnicos para um projeto de rede, incluindo escalabilidade,
disponibilidade, desempenho da rede, segurança, capacidade de gerenciamento, usabilidade,
adaptabilidade e preço acessível. Também cobriu compensações típicas que devem ser feitas para atingir esses objetivos.
A análise das metas técnicas e de negócios do seu cliente prepara você para executar as próximas
etapas no processo de projeto de rede de cima para baixo, incluindo a tomada de decisões sobre
tecnologias de rede a serem recomendadas a um cliente. Pesquisadores que estudam modelos de decisão
dizem que um dos aspectos mais importantes para tomar uma decisão acertada é ter uma boa lista de
metas.
Neste ponto do processo de projeto de rede, você reuniu metas comerciais e técnicas. Você deve fazer
uma lista das metas técnicas mais importantes do seu cliente e mesclar essa lista com a lista de metas de
negócios que você fez no Capítulo 1. Você deve colocar as metas na lista em ordem de prioridade,
começando com a meta comercial e técnica geral mais importante. , e seguindo com metas críticas e
depois com metas menos críticas. Posteriormente, você poderá fazer uma lista de opções e correlacioná-las
com os objetivos. Quaisquer opções que não atendam aos objetivos críticos podem ser eliminadas.
Outras opções podem ser classificadas de acordo com o quão bem atendem a uma meta. Este processo
pode ajudá-lo a selecionar componentes de rede que atendam aos requisitos do cliente.
MTTR aceitável Taxa de transferência Atraso obrigatório Variação de atraso Comentários

Meta Seja menos que Deve ser menos
Que
1. Discuta o termo “escalabilidade”. O que isso significa? Por que é uma rede importante
objetivo do projeto? Quais são alguns desafios que os designers enfrentam ao projetar visando escalabilidade?
2. Um cliente de projeto de rede tem uma meta de 99,80% de tempo de atividade. Quanto abaixo
o tempo será permitido em horas por semana? Quanto tempo de inatividade será permitido em minutos por dia
e segundos por hora? Quais valores são aceitáveis em quais circunstâncias?
3. Suponha que você esteja na cidade de Nova York, nos Estados Unidos, e esteja baixando uma página da Web
de 100 KB de um servidor na Cidade do Cabo, África do Sul. Suponha que a largura de banda entre as duas
cidades seja de 1 Gbps. Que tipo de atraso será mais significativo, atraso de propagação ou atraso de
transmissão? Defenda sua resposta.
4. O capítulo mencionou ataques de reconhecimento. Faça alguma pesquisa para saber mais
sobre as ferramentas que os invasores usam em uma missão de reconhecimento. Com suas próprias
palavras, descreva duas ferramentas que você pesquisou.
Cenário de projeto
A Harriet's Fruit and Chocolate Company foi fundada em 1935 no noroeste do Pacífico dos Estados Unidos para
enviar cestas de pêssegos e peras cultivadas localmente para clientes nos Estados Unidos. A empresa também
fabrica chocolates e assados para incluir nas cestas de presentes. Ela cresceu bastante ao longo dos anos e é
atualmente uma das maiores empresas do Noroeste Pacífico.
Recentemente, os descendentes de Harriet, que ainda dirigem a empresa, identificaram a necessidade de

informar imediatamente quando as frutas estão começando a amadurecer e devem ser colhidas e colocadas
em câmaras frigoríficas. Os funcionários do departamento de marketing identificaram a necessidade de acessar
dados de inventário das frutas nos pomares e no armazenamento refrigerado. Com esses dados, eles podem
desenhar e vender cestas de presentes que aproveitam a fruta madura. Esses dados também devem ser inseridos
em aplicativos de comércio eletrônico para que os pedidos pela web possam especificar corretamente a
disponibilidade do produto.
Além disso, a empresa contratou recentemente uma programadora ambiciosa que está ansiosa por utilizar o seu
conhecimento de programação SAS, SQL e DB2 para conceber aplicações de relatórios para a gestão sénior. Ela
liga para você todos os dias com novas ideias sobre o que ela poderia realizar se a rede fosse atualizada para
que ela pudesse obter dados atualizados dos pomares e dos armazéns frigoríficos.
Como projetista de rede desta empresa, você foi encarregado de selecionar tecnologias de rede para chegar aos
pomares e aos edifícios frigoríficos. Cada um dos seis pomares possui um barraco com um ou dois PCs
independentes e uma impressora. Os três edifícios de armazenamento refrigerado são enormes armazéns que
incluem alguns PCs e impressoras independentes. A companhia telefônica local sugeriu que você alugasse links
T1 fracionários, mas esses links são caros e possivelmente estão além do seu orçamento. As tecnologias
sem fio também são possíveis, mas você já ouviu falar que as árvores frutíferas, especialmente as árvores adultas,
altas e frondosas, podem absorver um sinal de radiofrequência (RF) sem fio. Você também já ouviu falar que
o armazenamento refrigerado
os edifícios apresentam riscos de gelo, dificultando a instalação de equipamentos. Mas você não deixará que
esses desafios o perturbem.
1. Que investigação você fará em relação à infraestrutura física do ou

acelgas, barracos de pomar e câmaras frigoríficas?
2. Faça uma lista de metas de negócios para a Harriet's Fruit and Chocolate Company. O que são
algumas restrições que afetarão esses objetivos?
3. Faça uma lista de metas técnicas para a Harriet's Fruit and Chocolate Company. O que
compensações que você precisa fazer para atingir essas metas?
4. Uma solução sem fio suportará o baixo atraso necessário para atender às necessidades das aplicações?
Defenda sua resposta.
5. Que preocupações de segurança você deve abordar ao projetar a atualização da rede?

Esta página foi intencionalmente deixada em branco

Capítulo 3
Caracterizando o
Rede existente
De acordo com Abraham Lincoln:
“Se pudéssemos primeiro saber onde estamos e para onde estamos indo, poderíamos julgar
melhor o que fazer e como fazer.”
Um passo importante no projeto de rede de cima para baixo é examinar a rede existente de um
cliente para avaliar melhor como atender às expectativas de escalabilidade, desempenho e
disponibilidade da rede. Examinar a rede existente inclui aprender sobre a topologia e a estrutura
física e avaliar o desempenho da rede.
Ao desenvolver uma compreensão da estrutura, dos usos e do comportamento da rede existente,

você pode determinar se as metas de design de um cliente são realistas. Você pode documentar
quaisquer gargalos ou problemas de desempenho de rede e identificar dispositivos e links de
interligação de redes que precisarão ser substituídos porque o número de portas ou a capacidade são
insuficientes para o novo design. Identificar problemas de desempenho pode ajudá-lo a selecionar
soluções para resolver problemas e desenvolver uma linha de base para futuras medições de desempenho.
A maioria dos projetistas de redes não projeta redes do zero. Em vez disso, eles projetam
melhorias nas redes existentes. O desenvolvimento de um projeto de rede bem-sucedido exige que
você desenvolva habilidades na caracterização de uma rede existente para garantir a
interoperabilidade entre as redes existentes e as previstas. Este capítulo descreve técnicas e
ferramentas para ajudá-lo a desenvolver essas habilidades. Este capítulo termina com uma lista
de verificação de integridade da rede que documenta limites típicos para diagnosticar uma rede como “íntegra”.
Caracterizando a infraestrutura de rede

Caracterizar a infraestrutura de uma rede significa desenvolver um conjunto de mapas de rede e
aprender a localização dos principais dispositivos e segmentos de rede. Também inclui a documentação
dos nomes e endereços dos principais dispositivos e segmentos e a identificação de quaisquer
métodos padrão de endereçamento e nomenclatura. Documentar os tipos e comprimentos do
cabeamento físico e investigar as restrições arquitetônicas e ambientais também são aspectos
importantes da caracterização da infraestrutura de rede. Arquitetônico e
as restrições ambientais estão se tornando cada vez mais importantes nos projetos de redes modernas
que devem acomodar redes sem fio, que podem não funcionar se o sinal for bloqueado por paredes de cimento,
por exemplo.
Desenvolvendo um mapa de rede

Aprender a localização dos principais hosts, dispositivos de interconexão e segmentos de rede é uma boa maneira
de começar a desenvolver uma compreensão do fluxo de tráfego. Juntamente com dados sobre as características
de desempenho dos segmentos de rede, as informações de localização fornecem informações sobre onde os
usuários estão concentrados e o nível de tráfego que um projeto de rede deve suportar.
Neste ponto do processo de projeto da rede, seu objetivo é obter um mapa (ou conjunto de mapas) da rede
existente. Alguns clientes de design também podem ter mapas para o novo design de rede. Se for esse o caso,
você pode estar um passo à frente, mas tome cuidado com quaisquer suposições que não sejam baseadas
em sua análise detalhada dos requisitos técnicos e de negócios.
Para desenvolver um desenho de rede, você deve investir em uma boa ferramenta de diagramação de rede.
As ferramentas incluem produtos Tivoli da IBM, WhatsUp Gold da Ipswitch e LANsurveyor da SolarWinds. O
produto Microsoft Visio Professional também é altamente recomendado para diagramação de rede. Para grandes
empresas e provedores de serviços, a Visionael Corporation oferece produtos de documentação de
rede cliente/servidor.
Nota Ferramentas que diagramam automaticamente uma rede podem ser úteis, mas os mapas gerados podem exigir
muita limpeza para torná-los úteis.
Caracterizando Grandes Internetworks

O desenvolvimento de um mapa de rede único pode não ser possível para redes interligadas de grande porte.
Existem muitas abordagens para resolver este problema, incluindo simplesmente o desenvolvimento de muitos
mapas, um para cada local. Outra abordagem é aplicar um método de cima para baixo. Comece com um mapa
ou conjunto de mapas que mostre as seguintes informações de alto nível:
ÿ Informações geográficas, como países, estados ou províncias, cidades e campi
ÿ Conexões WAN entre países, estados e cidades
ÿ Conexões WAN e LAN entre edifícios e entre campi
Para cada rede de campus, você pode desenvolver mapas mais precisos que mostram as seguintes informações
mais detalhadas:
ÿ Edifícios e pisos e possivelmente salas ou cubículos
ÿ A localização dos principais servidores ou farms de servidores
ÿ A localização de roteadores e switches

Capítulo 3: Caracterizando a Rede Existente 61
ÿ A localização de firewalls, dispositivos de tradução de endereços de rede (NAT), sistemas de detecção

de intrusões (IDS) e sistemas de prevenção de intrusões (IPS)
ÿ A localização dos mainframes
ÿ A localização das principais estações de gerenciamento de rede
ÿ A localização e o alcance das LANs virtuais (VLAN)
ÿ Alguma indicação de onde residem as estações de trabalho, embora não necessariamente a explícita
localização de cada estação de trabalho
Outro método para caracterizar redes grandes e complexas é usar uma abordagem descendente que
é influenciada pelo modelo de referência OSI. Primeiro, desenvolva um mapa lógico que mostre os aplicativos
e serviços usados pelos usuários da rede. Este mapa pode chamar servidores internos de web, e-mail, FTP
e servidores de impressão e compartilhamento de arquivos. Também pode incluir servidores externos da Web,
e-mail e FTP.
Nota Certifique-se de mostrar servidores de cache da web em seus mapas de rede, pois eles podem afetar
o fluxo de tráfego. Documentar a localização dos servidores de cache da web facilitará a solução de quaisquer
problemas que cheguem aos servidores da web durante as fases de implementação e operação do ciclo de
design da rede.
Em seguida, desenvolva um mapa que mostre os serviços de rede. Este mapa pode representar a localização
dos servidores de segurança; por exemplo, servidores Terminal Access Controller Access Control
System (TACACS) e Remote Authentication Dial-In User Service (RADIUS). Outros serviços de rede incluem
Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS) e Simple Network Management
Protocol (SNMP) e outros serviços de gerenciamento. A localização e o alcance de quaisquer redes
privadas virtuais (VPN) que conectam sites corporativos através da WAN de um provedor de serviços ou da
Internet podem ser representados, incluindo os principais dispositivos VPN, como concentradores VPN. Os
servidores de discagem de entrada e saída também podem ser mostrados neste mapa.
Você também pode desenvolver um mapa que represente a topologia da Camada 3 do trabalho da Internet.
Este mapa pode deixar de fora switches e hubs, mas deve representar roteadores, links lógicos entre os
roteadores e informações de configuração de protocolo de roteamento de alto nível (por exemplo, a localização
do roteador designado desejado [DR] se Open Shortest Path First [OSPF ] está sendo usado).
Os desenhos da Camada 3 também devem incluir nomes de interface de roteador na nomenclatura abreviada
da Cisco (como s0/0) se roteadores Cisco forem usados. Outras informações úteis incluem agrupamentos
de roteadores Hot Standby Router Protocol (HSRP), pontos de redistribuição entre protocolos de roteamento
e pontos de demarcação onde ocorrem filtros de rota. O desenho da Camada 3 também deve incluir a
localização e configuração de alto nível de firewalls e dispositivos NAT, IDS e IPS.
Um mapa ou conjunto de mapas que mostra informações detalhadas sobre links e dispositivos da camada
de enlace de dados costuma ser extremamente útil. Este mapa revela dispositivos e interfaces LAN
conectado a WANs públicas ou privadas. Este mapa pode ocultar a topologia de roteamento lógico
da Camada 3, mostrada no(s) mapa(s) anterior(es), mas deve fornecer uma boa caracterização da
topologia física. Um mapa da camada de enlace de dados inclui as seguintes informações:
ÿ Uma indicação da tecnologia da camada de enlace de dados para WANs e LANs (Frame Relay,
Protocolo ponto a ponto [PPP], VPN, Ethernet de 100 Mbps ou 1000 Mbps e assim por diante)
ÿ O nome do provedor de serviços para WANs
ÿ IDs de circuito WAN
ÿ A localização e as informações de configuração de alto nível para switches LAN (por exemplo, a
localização da ponte raiz desejada se o Spanning Tree Protocol [STP] for usado)
ÿ A localização e o alcance de qualquer configuração de VLANs e VLAN Trunking Protocol (VTP)

rações
ÿ A localização e configuração de alto nível de troncos entre switches LAN
ÿ A localização e configuração de alto nível de qualquer firewall de Camada 2
Caracterizando a Arquitetura Lógica

Ao documentar a infraestrutura de rede, dê um passo atrás nos diagramas que você desenvolve e tente
caracterizar a topologia lógica da rede e os componentes físicos. A topologia lógica ilustra a
arquitetura da rede, que pode ser hierárquica ou plana, estruturada ou não estruturada, em camadas ou
não, entre outras possibilidades.
A topologia lógica também descreve métodos para conectar dispositivos em uma forma geométrica (por
exemplo, estrela, anel, barramento, hub e spoke ou malha).
Ao caracterizar a topologia lógica, procure por “bombas-relógio” ou implementações que possam

prejudicar a escalabilidade. As bombas-relógio incluem grandes domínios STP de Camada 2 que levarão
muito tempo para convergir e redes excessivamente complexas ou superdimensionadas que podem
levar a problemas de SIA (Enhanced Interior Gateway Routing Protocol) e outros problemas de
roteamento. Se o cliente tiver equipamentos de rede e cabeamento totalmente redundantes, mas os
servidores forem todos single-homed (conectados a um único switch), tenha isso em mente ao planejar
o redesenho da rede. Esta poderia ser outra bomba-relógio que pode ser corrigida com um redesenho.
A topologia lógica pode afetar a capacidade de atualizar uma rede. Por exemplo, uma topologia plana
não é escalonável tão bem quanto uma topologia hierárquica. Uma topologia hierárquica típica que pode
ser escalonada é uma camada central de roteadores e switches de última geração otimizados para
disponibilidade e desempenho, uma camada de distribuição de roteadores e switches que implementam
políticas e uma camada de acesso que conecta usuários por meio de hubs, switches e outros dispositivos.
As topologias lógicas são discutidas com mais detalhes no Capítulo 5, “Projetando uma topologia
de rede”.
A Figura 3-1 mostra um diagrama de rede de alto nível para uma empresa fabricante de eletrônicos.
O desenho mostra uma topologia física, mas não é difícil recuar e visualizar que a topologia lógica é uma
forma hub-and-spoke com três camadas. A camada central da rede é uma rede Gigabit Ethernet. A
camada de distribuição inclui roteadores e
switches e links Frame Relay e T1. A camada de acesso é composta por 10 Mbps e
Redes Ethernet de 100 Mbps. Uma rede Ethernet hospeda o servidor web da empresa. Como
você pode ver na figura que a rede incluía alguns componentes de design bastante antigos.
A empresa precisava de consultoria de design para selecionar novas tecnologias e atender novas
metas de alta disponibilidade e segurança.
Medford Ashland
Ethernet de 100 Mbps Ethernet de 100 Mbps
50 usuários 30 usuários
Transferência de quadro
Transferência de quadro
CIR = 56 Kbps
CIR = 56 Kbps DLCI = 4
DLCI = 5
Gigabit
Ethernet
Passe de subsídios Passe de subsídios
QG QG
Ethernet de 100 Mbps gigbit
75 usuários Ethernet
FEP
(Front-end
Processador)
T1 IBM
Mainframe
Servidor Web/FTP
Eugênio
Ethernet de 10 Mbps T1 Internet
20 usuários
Figura 3-1 Diagrama de Rede para uma Empresa de Fabricação de Eletrônicos

Desenvolvendo um diagrama de blocos modular

Além de desenvolver um conjunto de mapas detalhados, muitas vezes é útil desenhar um diagrama
de blocos simplificado da rede ou de partes da rede. O diagrama pode representar as principais funções
da rede de forma modular. A Figura 3-2 mostra um mapa de topologia de rede modularizada em bloco
baseado no modelo de rede composta corporativa da Cisco.
Campus Empresarial Empreendimento

Serviço
Prédio Borda Fornecedor
Acesso Borda
Rede
Gestão
Prédio Comércio eletrônico
Distribuição ISPB
arafonC
arutusrtuspem dI
Borda
Distribuição
Internet
Campus Conectividade
Espinha dorsal
ISP A
VPN/Remoto
Acesso
PSTN
Fazenda de Servidores
WAN
Quadro
Retransmissão/
Caixa eletrônico
Figura 3-2 Exemplo de topologia de rede modularizada
Caracterizando endereçamento e nomenclatura de rede

Caracterizar a infraestrutura lógica de uma rede envolve documentar quaisquer estratégias que seu
cliente tenha para endereçamento e nomenclatura de rede. Endereçamento e nomenclatura são
discutidos com mais detalhes na Parte II deste livro, “Projeto de Rede Lógica”.
Ao desenhar mapas de rede detalhados, inclua os nomes dos principais sites, roteadores, segmentos de
rede e servidores. Documente também quaisquer estratégias padrão que seu cliente use para
nomear elementos de rede. Por exemplo, alguns clientes nomeiam sites usando códigos de aeroporto
(São Francisco = SFO, Oakland = OAK e assim por diante). Você pode descobrir que um cliente fixa
nomes com um alias que descreve o tipo de dispositivo (por exemplo, RTR para roteador).
Alguns clientes usam um sistema de nomenclatura padrão, como DNS, para redes IP, ou
NetBIOS Windows Internet Naming Service (WINS) em redes Windows. Nesses casos, você deve
documentar a localização dos servidores DNS e WINS e as informações relevantes de configuração
de alto nível.
Você também deve investigar os endereços da camada de rede que seu cliente usa. O esquema de
endereçamento do seu cliente (ou a falta de qualquer esquema) pode influenciar a sua capacidade de
adaptar a rede aos novos objetivos de projeto. Por exemplo, seu cliente pode usar endereços IP
não registrados que precisarão ser alterados ou traduzidos antes de se conectar à Internet.
Como outro exemplo, o mascaramento de sub-rede IP atual pode limitar o número de nós em uma
LAN ou VLAN.
Seu cliente pode ter como objetivo usar o resumo de rotas, que também é chamado de agregação de rotas
ou super-redes. O resumo de rotas reduz as rotas em uma tabela de roteamento, o tráfego de atualização
da tabela de roteamento e a sobrecarga geral do roteador. A sumarização de rotas também melhora
a estabilidade e a disponibilidade da rede, porque é menos provável que problemas em uma parte da rede
afetem toda a rede. A sumarização é mais eficaz quando os prefixos de endereço são atribuídos
de maneira consistente e contígua, o que muitas vezes não é o caso.
O esquema de endereçamento existente do seu cliente pode afetar os protocolos de roteamento que
você pode selecionar. Alguns protocolos de roteamento não suportam endereçamento sem classe,
mascaramento de sub-rede de comprimento variável (VLSM) ou sub-redes descontíguas. Uma sub-rede
descontígua é uma sub-rede dividida, conforme mostrado na Figura 3-3. A sub-rede 108 da rede 10 está
dividida em duas áreas separadas pela rede 192.168.49.0.
Área 0
Rede
192.168.49.0
Sub- Área 2
redes da Área 1 10.108.16.0- Sub-redes 10.108.32.0-
10.108.31.0 10.108.47.0
Figura 3-3 Exemplo de uma sub-rede descontígua
Caracterizando Fiação e Mídia

Para ajudá-lo a atingir as metas de escalabilidade e disponibilidade do seu novo projeto de rede, é
importante compreender o projeto de cabeamento e a fiação da rede existente.
Documentar o projeto de cabeamento existente pode ajudá-lo a planejar melhorias e identificar possíveis
problemas. Se possível, você deve documentar os tipos de cabeamento em uso, bem como as distâncias
dos cabos. As informações de distância são úteis ao selecionar tecnologias da camada de enlace de
dados com base em restrições de distância.
Ao explorar o projeto do cabeamento, avalie quão bem os equipamentos e cabos estão rotulados na rede
atual. A extensão e a precisão da rotulagem afetarão sua capacidade de implementar e testar melhorias
na rede.
Seu diagrama de rede deve documentar as conexões entre edifícios. O diagrama deve incluir informações
sobre o número de pares de fios e o tipo de fiação (ou tecnologia sem fio) em uso. O diagrama também
deve indicar a distância entre os edifícios. As informações de distância podem ajudá-lo a selecionar um
novo cabeamento. Por exemplo, se você planeja atualizar o cabeamento de cobre para o cabeamento
de fibra, a distância entre os edifícios pode ser muito maior.
Provavelmente a fiação (ou tecnologia sem fio) entre edifícios é uma das seguintes:
ÿ Fibra monomodo
ÿ Fibra multimodo
ÿ Cobre de par trançado blindado (STP) ÿ Cobre
de par trançado não blindado (UTP)

ÿ Cabo coaxial
ÿ Microondas
ÿ Laser
ÿ Rádio
ÿ Infravermelho
Dentro dos edifícios, tente localizar armários de fiação de telecomunicações, salas de conexão cruzada
e quaisquer laboratórios ou salas de informática. Se possível, determine o tipo de cabeamento instalado
entre os armários de telecomunicações e nas áreas de trabalho. (Algumas tecnologias, como
Ethernet 100BASE-TX, exigem cabeamento de Categoria 5 ou posterior, portanto, certifique-se de
documentar a existência de qualquer cabeamento de Categoria 3 que precise ser substituído.) Reúna
informações sobre cabeamento vertical e horizontal. Conforme mostrado na Figura 3-4, a fiação
vertical passa entre os andares. A fiação horizontal vai desde armários de telecomunicações
até placas de parede em cubículos ou escritórios. A fiação da área de trabalho vai do espelho até uma
estação de trabalho em um cubículo ou escritório.
Horizontal Área de trabalho
Fiação Fiação
Telecomunicações Placa de parede
Armário de fiação
Fiação vertical
(Construindo espinha dorsal)
Sala principal de conexão cruzada Sala Intermediária de Crossconnect (ou

(ou quadro de distribuição principal) Quadro de Distribuição Intermediário)
Edifício A – Sede Edifício B

Espinha dorsal do campus
Figura 3-4 Exemplo de fiação de rede de campus

Na maioria dos edifícios, o cabeamento de um armário de telecomunicações até uma estação de trabalho tem
aproximadamente 100 metros (cerca de 300 pés), incluindo a fiação da área de trabalho, que geralmente tem
apenas alguns metros. Se você tiver alguma indicação de que o cabeamento pode ter mais de 100 metros,
você deve usar um refletômetro no domínio do tempo (TDR) para verificar suas suspeitas. (A funcionalidade
TDR está incluída na maioria dos testadores de cabos.) Muitos projetos de rede baseiam-se na suposição de
que as estações de trabalho não estão a mais de 100 metros do armário de telecomunicações.
Peça ao cliente uma cópia dos testes de certificação de cobre ou fibra que foram concluídos quando o
cabeamento foi instalado pela primeira vez. Os resultados dos testes ajudarão você a saber o tipo de
cabeamento instalado, sua certificação e o período de garantia para o trabalho de instalação.
Muitos projetistas de redes modernos realizam apenas essa etapa para verificar se o cabo foi testado e
certificado, em vez de passar por uma análise detalhada da infraestrutura de cabeamento. Por outro lado, muitos
projetistas de redes ainda se concentram no cabeamento porque aprenderam da maneira mais difícil que pode
ser difícil atingir as metas de disponibilidade quando o cabeamento não foi instalado corretamente.
Para cada edifício, você pode preencher o gráfico mostrado na Tabela 3-1. Os dados que você preenche
dependem de quanto tempo você tem para coletar informações e da importância que você acha que os detalhes
do cabeamento terão para o projeto da sua rede. Se você não tiver muita informação, basta colocar um X
para cada tipo de cabeamento presente e documentar quaisquer suposições (por exemplo, uma suposição de
que as estações de trabalho não estejam a mais de 100 metros do armário de telecomunicações). Se tiver
tempo para reunir mais detalhes, inclua informações sobre o comprimento e a quantidade de pares de cabos.
Se preferir, você pode documentar as informações da fiação do edifício em um diagrama de rede em vez de
em uma tabela.
Tabela 3-1 Fiação Predial
Nome do edifício
Localização dos armários de telecomunicações
Localização de salas de conexão cruzada e

demarcações para redes externas
Topologia de fiação lógica (estruturada, estrela,

barramento, anel, centralizada, distribuída, malha,
árvore ou o que for adequado)
Fiação vertical
Fibra Coaxial STP Categoria 3 UTP Categoria 5 ou 6 UTP Outros
Eixo vertical 1
Eixo vertical 2
Eixo vertical n
Fiação Horizontal
Andar 1
Piso 2
Piso 3
Andar n
Fiação da área de trabalho
Andar 1
Piso 2
Piso 3
Andar n
Verificando restrições arquitetônicas e ambientais

Ao investigar o cabeamento, preste atenção a questões ambientais, como a possibilidade de o cabeamento
passar perto de riachos que podem inundar, trilhos de ferrovia ou rodovias onde o tráfego pode atrapalhar
os cabos, ou áreas de construção ou fabricação onde equipamentos pesados ou escavações podem
quebrar os cabos.
Certifique-se de determinar se há algum problema legal de direito de passagem que deva ser resolvido
antes que o cabeamento possa ser instalado. Por exemplo, o cabeamento precisará atravessar uma
via pública? Será necessário passar cabos em propriedades de outras empresas?
Para tecnologias de linha de visão, como laser ou infravermelho, certifique-se de que não haja obstáculos
bloqueando a linha de visão.
Dentro dos edifícios, preste atenção às questões arquitetônicas que podem afetar a viabilidade de
implementação do seu projeto de rede. Certifique-se de que os seguintes elementos arquitetônicos
sejam suficientes para apoiar seu projeto:
ÿ Ar condicionado
ÿ Aquecimento
ÿ Ventilação
ÿ Poder
ÿ Proteção contra interferência eletromagnética
ÿ Portas que podem travar

ÿ Espaço para:
ÿ Conduítes de cabeamento
ÿ Painéis de patch
ÿ Racks de equipamentos
ÿ Áreas de trabalho para técnicos que instalam e solucionam problemas de equipamentos
Observação Tenha em mente que o cabeamento e a alimentação são altamente influenciados por fatores humanos.
A instalação de novo cabeamento pode exigir o trabalho com sindicatos, por exemplo. Manter a confiabilidade do
cabeamento pode exigir o monitoramento do infame operador da retroescavadeira ou do zelador que espalha os cabos.
Também não é incomum que guardas de segurança se encostem em uma parede tarde da noite e acidentalmente
ativem o desligamento de emergência (EPO) ou descarreguem o supressor de incêndio. Para evitar problemas,
certifique-se de que os botões EPO e supressor de incêndio tenham tampas de segurança e estejam fora do caminho.
Verificando se há uma instalação sem fio em um local Um objetivo
comum para projetos de rede de campus modernos é instalar uma LAN sem fio (WLAN) baseada nos padrões
IEEE 802.11. Um aspecto importante da inspeção das restrições arquitetônicas e ambientais de um local é determinar
a viabilidade do uso da transmissão sem fio. O termo pesquisa de site sem fio é frequentemente usado para
descrever o processo de análise de um site para ver se ele será apropriado para transmissão sem fio.
De certa forma, fazer uma pesquisa de local sem fio não é diferente de verificar se há recursos com fio em uma
arquitetura, onde pode ser necessário documentar obstruções ou áreas com vazamentos de água, por exemplo. Mas, em
muitos aspectos, um levantamento de local sem fio é bem diferente de um levantamento de local com fio porque a
transmissão não passa por fios guiados; está sendo enviado em ondas de radiofrequência (RF) pelo ar. Aprender a
fundo a teoria da transmissão de RF requer muito tempo e uma boa formação em física. Para projetos e preocupações
complexas de RF, geralmente faz sentido contratar um especialista em RF. No entanto, para fazer uma pesquisa
básica do site, talvez você não precise de ajuda.
Uma pesquisa de local começa com um projeto preliminar de WLAN. Usando uma planta baixa ou planta do local, o
projetista decide a localização inicial dos pontos de acesso sem fio. Um ponto de acesso é uma estação que transmite e
recebe dados para usuários da WLAN. Geralmente serve também como ponto de interconexão entre a WLAN e a
rede Ethernet com fio. Um projetista de rede pode decidir onde colocar os pontos de acesso para testes iniciais com
base em algum conhecimento de onde os usuários estarão localizados, nas características das antenas dos pontos
de acesso e na localização das principais obstruções.
A colocação inicial de um ponto de acesso é baseada numa estimativa da perda de sinal que ocorrerá entre o ponto de
acesso e os utilizadores do ponto de acesso. O ponto de partida para uma estimativa depende de quanta perda de
potência um sinal sofreria no vácuo do espaço, sem quaisquer obstruções ou outras interferências. Isso é chamado de
perda no caminho do espaço livre e é especificado em decibéis (dB). A estimativa é ajustada com um entendimento
que a perda de sinal real esperada depende do meio através do qual o sinal será
viagens, que sem dúvida não são um vácuo. Um sinal de RF viajando através de objetos de vários tipos pode ser
afetado por muitos problemas diferentes, incluindo os seguintes:
ÿ Reflexão: A reflexão faz com que o sinal retorne a si mesmo. O sinal pode interferir consigo mesmo no ar e
afetar a capacidade do receptor de discriminar entre
o sinal e o ruído no ambiente. A reflexão é causada por superfícies metálicas como
como vigas de aço, andaimes, estantes, pilares de aço e portas metálicas. Por exemplo, implementar uma
WLAN em um estacionamento pode ser complicado por causa dos carros de metal.
(fontes de reflexão) que vêm e vão.
ÿ Absorção: Parte da energia eletromagnética do sinal pode ser absorvida por

o material nos objetos através dos quais ele passa, resultando em um nível de sinal reduzido.
A água tem propriedades de absorção significativas e objetos como árvores ou
estruturas de madeira podem ter alto teor de água. Implementar uma WLAN em uma cafeteria pode ser
complicado se houver grandes latas de café líquido. Cafeteria
Os usuários de WLAN também notaram que as pessoas entrando e saindo podem afetar o sinal
nível. (Em Star Trek, um personagem não-humano certa vez chamou um humano de “um saco gigante feio
principalmente água”!)
ÿ Refração: Quando um sinal de RF passa de um meio com uma densidade para um meio com outra densidade,
o sinal pode ser desviado, tal como a luz que passa através de um
prisma. O sinal muda de direção e pode interferir no sinal não refratado.
Pode seguir um caminho diferente e encontrar outras obstruções inesperadas e chegar
em destinatários danificados ou mais tarde do que o esperado. Por exemplo, um tanque de água não só
introduz absorção, mas também a diferença de densidade entre a atmosfera
e a água pode dobrar o sinal de RF.
ÿ Difração: A difração, que é semelhante à refração, ocorre quando uma região através
onde o sinal de RF pode passar facilmente é adjacente a uma região na qual existem obstruções reflexivas.
Assim como a refração, o sinal de RF é curvado em torno da borda da região difrativa e pode então interferir
na parte do sinal de RF que não está curvada.
Os projetistas dos dispositivos de transmissão 802.11 tentam compensar os fatores ambientais variáveis que
podem causar reflexão, absorção, refração ou difração, aumentando o nível de potência acima do que seria
necessário se o caminho do espaço livre fosse a única consideração. A potência adicional adicionada a uma
transmissão é chamada de margem de fade.
Realizando uma pesquisa de site sem fio

Uma pesquisa no local confirma a propagação, a força e a precisão do sinal em diferentes locais.
Muitas placas de interface de rede sem fio (NIC) são fornecidas com utilitários que permitem medir a intensidade
do sinal. As NICs Cisco 802.11 são fornecidas com o Cisco Aironet Client Utility (ACU),
que é uma ferramenta gráfica para configurar, monitorar e gerenciar a NIC e seu ambiente sem fio. Uma pesquisa
de local pode ser tão simples quanto andar por aí com um notebook sem fio e usar o utilitário para medir a
intensidade do sinal.
A intensidade do sinal também pode ser determinada com um analisador de protocolo. O analisador
WildPackets AiroPeek, por exemplo, apresenta a intensidade do sinal para cada quadro recebido.
Um ponto de acesso normalmente envia um quadro de beacon a cada 100 milissegundos (ms). Você pode
dividir a área que está sendo pesquisada em uma grade e, em seguida, mover seu analisador de protocolo
de ponto de grade para ponto de grade e traçar em um diagrama a intensidade do sinal dos quadros de beacon.
Ao avaliar as diversas métricas fornecidas pelos utilitários sem fio, certifique-se de medir a corrupção do
quadro e não apenas a intensidade do sinal. Com um analisador de protocolo, capture quadros e verifique erros
de verificação de redundância cíclica (CRC). Os erros de CRC são o resultado de corrupção causada por ruído
ambiental ou colisões entre quadros.
Você também pode medir indiretamente a qualidade do sinal, determinando se os quadros estão sendo perdidos
na transmissão. Se o seu analisador de protocolo estiver capturando relativamente perto de um ponto de acesso
e um cliente móvel estiver executando ping em um servidor, através do ponto de acesso, na Ethernet com fio,
você poderá determinar se os pacotes de ping estão sendo perdidos.
Como parte da pesquisa do site, você também pode observar as confirmações (ACK) e as novas tentativas
de quadro após a falta de um ACK. Com WLANs 802.11, tanto o cliente quanto o ponto de acesso enviam
ACKs um ao outro. Um quadro ACK é um dos seis quadros especiais chamados quadros de controle.
Todo o tráfego direcionado (quadros endereçados a qualquer destino não-broadcast e não-multicast) é confirmado
positivamente com um ACK. Clientes e pontos de acesso usam ACKs para implementar um mecanismo de
retransmissão semelhante ao processo de nova tentativa Ethernet que ocorre após uma colisão.
Em uma Ethernet com fio, a estação transmissora detecta colisões através das regras de acesso múltiplo com
detecção de portadora com detecção de colisão (CSMA/CD). O 802.11 usa acesso múltiplo com detecção de
portadora com prevenção de colisão (CSMA/CA) como método de acesso e não depende de detecção de
colisão para operar. Em vez disso, um quadro de controle ACK é retornado a um remetente para cada pacote
direcionado recebido. Se um quadro direcionado não receber um ACK, o quadro será retransmitido.
A rede sem fio será abordada novamente em capítulos posteriores, mas lembre-se de considerá-la no início do
planejamento do projeto. Usando um utilitário sem fio, como Cisco ACU, WildPackets OmniPeek ou
NetStumbler, verifique a intensidade e a precisão do sinal com possíveis posicionamentos de pontos de
acesso para determinar se a arquitetura do site físico será um problema.
A realização de uma pesquisa básica do local sem fio é uma parte importante do processo de projeto de
rede descendente para verificação de restrições arquitetônicas e ambientais.
Verificando a integridade da rede existente

Estudar o desempenho da rede existente fornece uma medida básica a partir da qual é possível medir o
desempenho da nova rede. Armado com medições da rede atual, você pode demonstrar ao seu cliente o
desempenho da nova rede depois que seu projeto for implementado.
Muitas das metas de desempenho de rede discutidas no Capítulo 2, “Analisando metas técnicas e
compensações”, são metas gerais para uma interligação de redes. Porque o desempenho de
segmentos de rede existentes afetarão o desempenho geral, você precisa estudar o desempenho dos segmentos
existentes para determinar como atingir as metas gerais de desempenho da rede.
Se uma rede for muito grande para estudar todos os segmentos, você deverá analisar os segmentos que irão
interoperar mais com o novo projeto de rede. Preste atenção especial às redes backbone e às redes que
conectam áreas antigas e novas.
Em alguns casos, os objetivos de um cliente podem estar em desacordo com a melhoria do desempenho da rede.
O cliente pode querer reduzir custos, por exemplo, e não se preocupar com o desempenho. Nesse caso,
você ficará feliz por ter documentado o desempenho original para poder provar que a rede não foi otimizada para
começar e que seu novo design não piorou o desempenho.
Ao analisar as redes existentes, você também pode reconhecer sistemas legados que devem ser
incorporados ao novo design. Às vezes, os clientes não estão cientes de que protocolos mais antigos ainda
estão em execução em suas redes. Ao capturar o tráfego de rede com um analisador de protocolo como parte de
sua análise de linha de base, você pode identificar quais protocolos estão realmente em execução na rede e
não confiar nas crenças dos clientes.
Desenvolvendo uma linha de base de desempenho de rede

Desenvolver uma linha de base precisa do desempenho de uma rede não é uma tarefa fácil. Um aspecto
desafiador é selecionar um momento para fazer a análise. É importante que você aloque bastante tempo (vários
dias) se quiser que a linha de base seja precisa. Se as medições forem feitas num período de tempo muito curto,
os erros temporários parecem mais significativos do que realmente são.
Além de alocar tempo suficiente para uma análise de base, também é importante encontrar um período de tempo
típico para fazer a análise. Uma linha de base de desempenho normal não deve incluir problemas atípicos
causados por cargas de tráfego excepcionalmente grandes. Por exemplo, em algumas empresas, o
processamento de vendas no final do trimestre coloca uma carga anormal na rede. Num ambiente de retalho,
o tráfego de rede pode aumentar cinco vezes na época do Natal. O tráfego de rede para um servidor web
pode aumentar inesperadamente dez vezes se o site for vinculado a outros sites populares ou listado em
mecanismos de pesquisa.
Em geral, erros, perda de pacotes/células e latência aumentam com a carga. Para obter uma medição
significativa da precisão e atraso típicos, tente fazer sua análise de linha de base durante períodos de carga de
tráfego normal. Por outro lado, se o objetivo principal do seu cliente é melhorar o desempenho durante os picos
de carga, não deixe de estudar o desempenho durante os picos de carga. A decisão de medir o desempenho
normal, o desempenho durante picos de carga ou ambos depende dos objetivos do projeto da rede.
Alguns clientes não reconhecem o valor de estudar a rede existente antes de projetar e implementar
melhorias. As expectativas do seu cliente em relação a uma proposta de design rápida podem dificultar que
você dê um passo atrás e insista no tempo para desenvolver uma linha de base de desempenho na rede
existente. Além disso, suas outras tarefas e metas de trabalho, especialmente se você for um engenheiro de
vendas, podem tornar impraticável passar dias desenvolvendo uma linha de base precisa.
O trabalho que você faz antes da etapa de linha de base na metodologia de projeto de rede de cima para baixo
pode aumentar sua eficiência no desenvolvimento de uma linha de base. Uma boa compreensão das metas técnicas
e de negócios do seu cliente pode ajudá-lo a decidir quão minucioso será o seu
estudar. Suas discussões com seu cliente sobre metas de negócios podem ajudá-lo a identificar segmentos que são
importantes para estudar porque transportam tráfego crítico e/ou de backbone.
Você também pode pedir ao seu cliente para ajudá-lo a identificar segmentos típicos dos quais você
pode extrapolar outros segmentos.
Analisando a disponibilidade da rede

Para documentar as características de disponibilidade da rede existente, reúna quaisquer estatísticas que
o cliente tem o tempo médio entre falhas (MTBF) e o tempo médio para reparar
(MTTR) para a rede como um todo e para os principais segmentos da rede. Compare essas estatísticas com as
informações que você reuniu sobre as metas do MTBF e do MTTR, conforme discutido em
Capítulo 2. O cliente espera que seu novo projeto aumente o MTBF e diminua
MTTR? As metas do cliente são realistas considerando o estado atual da rede?
Converse com os engenheiros e técnicos de rede sobre as causas dos problemas mais recentes.
e períodos de inatividade mais perturbadores. Assumindo o papel de um investigador forense,
tente obter muitos lados da história. Às vezes, surgem mitos sobre o que causou uma interrupção na rede.
(Geralmente é possível obter uma visão mais precisa das causas dos problemas através de engenheiros e
técnicos do que de usuários e gerentes.)
Você pode usar a Tabela 3-2 para documentar as características de disponibilidade da rede atual.
Tabela 3-2 Características de Disponibilidade da Rede Atual
MTBF MTTR Data e Causa de Correção para o último
Duração do Último Última Major Grande tempo de inatividade

Grande tempo de inatividade Tempo de inatividade
Empresa
(como um todo)
Segmento 1
Segmento 2
Segmento 3
Segmento n
Analisando a utilização da rede

A utilização da rede é uma medida da quantidade de largura de banda que está em uso durante um
intervalo de tempo específico. A utilização é comumente especificada como uma porcentagem da capacidade. Se um
ferramenta de monitoramento de rede diz que a utilização da rede em um segmento Fast Ethernet é de 70
por cento, por exemplo, isso significa que 70 por cento da capacidade de 100 Mbps está em uso, em média durante
um período ou janela especificada.
Diferentes ferramentas usam diferentes janelas de média para utilização da rede computacional. Algumas
ferramentas permitem ao usuário alterar a janela. Usar um intervalo longo pode ser útil para reduzir a
quantidade de dados estatísticos que devem ser analisados, mas a granularidade é sacrificada.
Como mostra a Figura 3-5, pode ser informativo (embora tedioso) observar um gráfico que mostra a
utilização média da rede a cada minuto.
16:40:00
16:43:00
16:46:00
16:49:00
16:52:00
Tempo 16:55:00
16:58:00
17:01:00
17:04:00
17:07:00
17:10:00
0 1 2 3 4 5 6 7
Utilização
Figura 3-5 Utilização da rede em intervalos de minutos
A Figura 3-6 mostra a média dos mesmos dados em intervalos de 1 hora. Observe que a rede não estava
muito ocupada, portanto nenhum gráfico ultrapassa 7% de utilização. Observe também que mudar para
um intervalo longo pode ser enganoso porque os picos de tráfego são calculados em média (os detalhes
são perdidos). Na Figura 3-5, você pode ver que a rede estava relativamente ocupada por volta das 16h50.
Você não pode ver isso na Figura 3-6, quando a média dos dados foi calculada de hora em hora.
Em geral, você deve registrar a utilização da rede com granularidade suficiente a tempo de ver picos
de curto prazo no tráfego de rede, para poder avaliar com precisão os requisitos de capacidade dos
dispositivos e segmentos. Entretanto, alterar o intervalo para um pequeno período de tempo, digamos
uma fração de segundo, também pode ser enganoso. Para entender a preocupação, considere um
pequeno intervalo de tempo. Numa janela do tamanho de um pacote, no momento em que uma estação
está enviando tráfego, a utilização é de 100%, que é o que se deseja.
O tamanho da janela média para medições de utilização da rede depende dos seus objetivos. Ao solucionar
problemas de rede, mantenha o intervalo pequeno, minutos ou segundos. Um pequeno intervalo ajuda a
reconhecer picos causados por problemas como transmissão
tempestades ou estações retransmitindo rapidamente devido a um temporizador mal configurado. Para desempenho
para fins de análise e linha de base, use um intervalo de 1 a 5 minutos. Para carga de longo prazo
análise, para determinar horários, dias ou meses de pico, defina o intervalo para 10 minutos.
13:00:00
14:00:00
Tempo 15:00:00
16:00:00
17:00:00
0 0,5 1 1,5 2 2,5 3 3.5 4 4,5

Utilização
Figura 3-6 Utilização da rede em intervalos de horas
Ao desenvolver uma linha de base, geralmente é uma boa ideia errar e também coletar
muitos dados. Você sempre pode resumir os dados mais tarde. Ao caracterizar a utilização da rede, use
analisadores de protocolo ou outras ferramentas de monitoramento para medir a utilização em intervalos de 1 a 2.
Intervalos de 5 minutos em cada segmento principal da rede. Se for prático, deixe as ferramentas de monitoramento
funcionando por pelo menos 1 ou 2 dias normais. Se as metas do cliente incluem melhorar o desempenho
durante horários de pico, meça a utilização durante horários de pico e horários normais. Para
determinar se a utilização medida está íntegra, use a lista de verificação de integridade da rede que
aparece no final deste capítulo.
Medindo a utilização da largura de banda por protocolo

O desenvolvimento de uma linha de base do desempenho da rede também deve incluir a medição da utilização
do tráfego de transmissão versus tráfego unicast e por cada protocolo principal. Como discutido em
Capítulo 4, “Caracterizando o tráfego de rede”, alguns protocolos enviam mensagens de broadcast excessivas.
tráfego, o que pode degradar seriamente o desempenho, especialmente em redes comutadas.
Para medir a utilização da largura de banda por protocolo, coloque um analisador de protocolo ou uma sonda de
monitoramento remoto (RMON) em cada segmento principal da rede e preencha um gráfico como aquele
mostrado na Tabela 3-3. Se o analisador suportar porcentagens relativas e absolutas, especifique o
largura de banda usada pelos protocolos como relativa e absoluta. O uso relativo especifica quanto
a largura de banda é usada pelo protocolo em comparação com a largura de banda total atualmente em uso
no segmento. O uso absoluto especifica quanta largura de banda é usada pelo protocolo
em comparação com a capacidade total do segmento (por exemplo, em comparação com
100 Mbps em Fast Ethernet).
Tabela 3-3 Utilização de largura de banda por protocolo
Rede Relativa Rede Absoluta Transmissão/Multitransmissão

Utilização Utilização Avaliar
Protocolo 1
Protocolo 2
Protocolo 3
Protocolo n
Analisando a precisão da rede

O Capítulo 2 falou sobre a especificação da precisão da rede como uma taxa de erro de bit (BER).
Você pode usar um testador BER (também chamado de BERT) em linhas seriais para testar o número
de bits danificados em comparação com o total de bits. Conforme discutido na seção “Verificando
o status dos principais roteadores, switches e firewalls” posteriormente neste capítulo, você também
pode usar os comandos show da Cisco para entender os erros em uma interface serial, que é uma
prática mais comum em interfaces modernas. redes do que usar um BERT.
Com redes comutadas por pacotes, faz mais sentido medir erros de quadro (pacote) porque um quadro
inteiro é considerado ruim se um único bit for alterado ou descartado. Em redes comutadas por pacotes,
uma estação emissora calcula um CRC com base nos bits de um quadro. A estação emissora coloca o
valor do CRC no quadro. Uma estação receptora determina se um bit foi alterado ou eliminado calculando
novamente o CRC e comparando o resultado com o CRC no quadro. Um quadro com CRC incorreto é
descartado e deve ser retransmitido pelo remetente. Normalmente, um protocolo de camada superior tem
a função de retransmitir quadros que não são reconhecidos.
Um analisador de protocolo pode verificar o CRC nos quadros recebidos. Como parte de sua análise
de linha de base, você deve acompanhar o número de quadros recebidos com um CRC incorreto a cada
hora durante 1 ou 2 dias. Como é normal que os erros aumentem com a utilização, documente os erros
em função do número de bytes vistos pela ferramenta de monitoramento. Um bom limite para considerar
erros não saudáveis é que uma rede não deve ter mais de um quadro defeituoso por megabyte de
dados. (Calcular erros desta forma permite simular um BERT serial. O simples cálculo de uma porcentagem
de quadros ruins em comparação com quadros bons não leva em conta o tamanho dos quadros e,
portanto, não dá uma boa indicação de quantos bits estão realmente sendo danificados.)
Além de rastrear erros da camada de enlace de dados, como erros de CRC, uma análise de linha
de base deve incluir informações sobre problemas da camada superior. Um analisador de protocolo que
inclui um sistema especialista, como o analisador Wireshark da CACE Technologies ou o
analisador OmniPeek da WildPackets, acelera a identificação de problemas de camada superior gerando
automaticamente diagnósticos e sintomas para conversas e aplicativos de rede.
A precisão também deve incluir uma medição de pacotes perdidos. Você pode medir pacotes perdidos
enquanto mede o tempo de resposta, que será abordado posteriormente neste capítulo na seção “Analisando
Seção Atraso e Tempo de Resposta”. Ao enviar pacotes para medir quanto tempo leva para receber uma
resposta, documente todos os pacotes que não recebem uma resposta, provavelmente porque a solicitação
ou a resposta foram perdidas. Correlacione as informações sobre pacotes perdidos com outras medidas de
desempenho para determinar se os pacotes perdidos indicam uma necessidade de aumentar a largura de
banda, diminuir erros de CRC ou atualizar dispositivos de interligação de redes.
Você também pode medir os pacotes perdidos observando as estatísticas mantidas pelos roteadores sobre o
número de pacotes descartados das filas de entrada ou saída.
Analisando Erros em Redes Ethernet Comutadas

Os switches substituíram os hubs na maioria das redes de campus. Uma porta de switch que está no
modo half duplex segue as regras normais do CSMA/CD. A porta verifica se há tráfego no meio, observando
o sinal de detecção da portadora, adia o tráfego se necessário, detecta colisões, recua e retransmite. A
ocorrência de uma colisão depende do que está conectado à porta comutada. Se um meio compartilhado
estiver conectado ao switch, poderão ocorrer colisões. Uma boa regra é que menos de 0,1% dos quadros
devem encontrar colisões. Não deve haver colisões tardias. Colisões tardias são colisões que
acontecem depois que uma porta ou interface envia os primeiros 64 bytes de um quadro. Colisões tardias
indicam cabeamento defeituoso, cabeamento maior que o padrão de 100 metros, uma NIC defeituosa ou uma
incompatibilidade duplex.
Se a porta do switch conectar um único dispositivo, como outro switch, um servidor ou uma única estação
de trabalho, ambas as extremidades desse link ponto a ponto deverão ser configuradas para full duplex. Neste
caso, colisões nunca devem ocorrer. Ethernet full-duplex não é CSMA/CD. Existem apenas duas estações
que podem enviar porque o full duplex requer um link ponto a ponto e cada estação possui seu próprio
canal de transmissão privado. Portanto, full duplex não é acesso múltiplo (MA). Não há necessidade de
uma estação verificar o meio para ver se alguém está enviando em seu canal de transmissão. Não há mais
ninguém. Portanto, o full duplex não usa o sentido da portadora (CS). Não há colisões. Ambas as estações
enviando ao mesmo tempo são normais. Receber durante o envio é normal. Portanto, também não há detecção
de colisão (CD).
Infelizmente, a negociação automática de half versus full duplex tem sido repleta de problemas ao longo dos
anos, resultando em uma extremidade de um link ponto a ponto sendo definida como half duplex e a outra
como full duplex. Esta é uma configuração incorreta e deve ser corrigida.
Problemas de negociação automática podem resultar de incompatibilidades de hardware e drivers de software
Ethernet antigos ou defeituosos. As NICs ou switches de alguns fornecedores não estão exatamente em
conformidade com a especificação IEEE 802.3u, o que resulta em incompatibilidades. A incompatibilidade de
hardware também pode ocorrer quando os fornecedores adicionam recursos avançados, como autopolaridade,
que não estão na especificação IEEE 802.3u. (A autopolaridade corrige a polaridade invertida nos pares
trançados de transmissão e recepção.)
A negociação automática de velocidade geralmente não é um problema. Se a velocidade não for negociada
corretamente, a interface não funciona e o administrador percebe e corrige o problema imediatamente. A
configuração manual da velocidade para 10 Mbps, 100 Mbps ou 1000 Mbps geralmente não é necessária
(exceto nos casos em que a interface do usuário exige isso antes de permitir a configuração manual do modo
duplex). Se uma LAN ainda tiver cabeamento de Categoria 3, é recomendável configurar manualmente a
velocidade para 10 Mbps. Erros
pode aumentar em uma LAN que tenha negociação automática para 100 Mbps ou 1000 Mbps se houver
Cabeamento de categoria 3 que não suporta o sinal de alta frequência usado em 100 ou
Ethernet de 1000 Mbps.
A negociação duplex acontece depois que a velocidade é negociada. Problemas com negociação duplex são
mais difíceis de detectar porque qualquer impacto no desempenho depende da transmissão simultânea dos
parceiros do link. Um usuário de estação de trabalho que não envia muito tráfego
pode não notar um problema, enquanto um servidor pode ser gravemente afetado por uma incompatibilidade
duplex. Como parte da análise do desempenho da rede existente, certifique-se de verificar
para problemas de incompatibilidade duplex. Um número surpreendentemente elevado de redes tem enfrentado
dificuldades durante anos com problemas de desempenho relacionados à incompatibilidade duplex.
Para detectar uma incompatibilidade duplex, observe o número e o tipo de erros em cada extremidade do
link. Você pode visualizar erros com o comando show interface ou show port no Cisco
roteadores e switches. Procure erros de CRC e runt de um lado e colisões do outro.
outro lado do link. O lado configurado para full duplex pode enviar quando quiser. Isto
não precisa verificar o tráfego. O lado configurado para half duplex verifica o tráfego
e interromperá a transmissão se detectar uma transmissão simultânea do outro lado. Isto
irá recuar, retransmitir e relatar uma colisão. O resultado da estação half-duplex
interromper a transmissão geralmente é um quadro runt (menor que 64 bytes) e é sempre um quadro com erro de
CRC.
O lado full-duplex recebe runts e quadros com erros de CRC e relata esses erros. O
estação half-duplex relata colisões. A maioria destas colisões serão legais; alguns podem
ser colisões tardias ilegais. Ao verificar a integridade das LANs Ethernet, verifique estes
erros. Observe a assimetria dos erros quando há uma incompatibilidade duplex. Se você ver
colisões e erros de CRC em ambos os lados do link, o problema provavelmente é algo
além de uma incompatibilidade duplex, talvez um problema de fiação ou uma placa de rede com defeito.
Até recentemente, a maioria dos engenheiros recomendava evitar a negociação automática, mas isso está
mudando. As melhorias na interoperabilidade da autonegociação e a maturidade da tecnologia significam que é
geralmente mais seguro confiar na autonegociação do que não depender dela.
Existem vários problemas em não usar a negociação automática. O mais óbvio é

erro humano. O engenheiro de rede configura uma extremidade do link e esquece de configurar a outra
fim. Outro problema é que algumas NICs e portas de switch não participam da negociação automática se forem
configuradas manualmente. Isso significa que eles não enviam pulsos de link para relatar sua configuração.
Como o parceiro deve reagir a tal situação? A resposta é indefinida. Algumas placas de rede
e as portas do switch assumem que o outro lado é muito antigo para entender o full duplex e deve ser
usando metade. Isso faz com que a NIC ou a porta do switch se ajustem à metade. Este é um problema sério
se o outro lado for configurado manualmente para full. Por outro lado, há casos
onde a negociação automática simplesmente não funciona e pode ser necessário configurar cuidadosamente
o modo manualmente.
Analisando a eficiência da rede

O Capítulo 2 falou sobre a importância de usar tamanhos máximos de quadros para aumentar a eficiência da
rede. A utilização da largura de banda é otimizada para eficiência quando aplicativos e protocolos são configurados
para enviar grandes quantidades de dados por quadro, minimizando assim o número de quadros e os atrasos de
ida e volta necessários para uma transação. O número de quadros por transação também pode ser minimizado se o
receptor for configurado com uma janela de recebimento grande, permitindo aceitar vários quadros antes de
enviar uma confirmação.
O objetivo é maximizar o número de bytes de dados em comparação com o número de bytes nos cabeçalhos e
nos pacotes de confirmação enviados pelo outro lado da conversa.
Alterar os tamanhos dos quadros e das janelas de recepção em clientes e servidores pode resultar em maior
eficiência. Aumentar a unidade máxima de transmissão (MTU) nas interfaces do roteador também pode melhorar a
eficiência, embora isso não seja apropriado em links de baixa largura de banda usados para voz ou outro tráfego em
tempo real. (Como mencionado no Capítulo 2, você não deseja aumentar o atraso de serialização.)
Por outro lado, às vezes é necessário aumentar o MTU em interfaces de roteador que usam túneis. Podem ocorrer
problemas quando o cabeçalho extra adicionado pelo túnel faz com que os quadros sejam maiores que o
MTU padrão, especialmente nos casos em que um aplicativo define o bit IP Don't Fragment (DF) e um firewall
está bloqueando o Internet Control Message Protocol (ICMP). ) pacotes que notificam o remetente da necessidade
de fragmentação. Um sintoma típico desse problema é que os usuários podem executar ping e telnet, mas não
podem usar HTTP, FTP e outros protocolos que usam quadros grandes. Uma solução é aumentar o MTU na
interface do roteador.
Para determinar se as metas de eficiência da rede do seu cliente são realistas, você deve usar um analisador de
protocolo para examinar os tamanhos de quadro atuais na rede. Muitos analisadores de protocolo permitem gerar
um gráfico, como o da Figura 3-7, que documenta quantos quadros se enquadram em categorias padrão para
tamanhos de quadros. A Figura 3-7 mostra os tamanhos dos pacotes em um provedor de serviços de Internet
(ISP). Muitos dos quadros eram confirmações de 64 bytes. Grande parte do tráfego era HTTP, que usava pacotes de
1.500 bytes na maioria dos casos, mas também enviava pacotes de 500 e 600 bytes. Se muitos clientes de
hospedagem na Web transferissem páginas para um servidor Web usando um protocolo de transferência ou
compartilhamento de arquivos, haveria muito mais quadros de 1.500 bytes. O outro tráfego consistia em pesquisas e
respostas de DNS e pacotes SMTP (Simple Mail Transfer Protocol), Post Office Protocol (POP) e Address
Resolution Protocol (ARP).
Uma maneira simples de determinar o tamanho médio do quadro é dividir o número total de megabytes
vistos em um segmento pelo número total de quadros em um período de tempo especificado.
Infelizmente, este é um caso em que uma simples técnica estatística não resulta em dados úteis. O tamanho médio
do quadro não é uma informação significativa. Na maioria das redes, existem muitos quadros pequenos, muitos
quadros grandes, mas poucos quadros de tamanho médio.
Quadros pequenos consistem em confirmações e informações de controle. Os quadros de dados se enquadram
nas categorias de tamanho de quadro grande. Os tamanhos dos quadros normalmente se enquadram no que é
chamado de distribuição bimodal, também conhecida como distribuição camel-back. Há uma “protuberância” em
ambos os lados da média, mas poucos valores estão próximos da média.
Figura 3-7 Gráfico de tamanhos de pacotes em um provedor de serviços de Internet

Estrutura Ethernet
Observação Os dados de desempenho da rede costumam ser bimodais, multimodais ou desviados da

média. (Média é outra palavra para média.) O tamanho do quadro costuma ser bimodal. Os tempos de
resposta de um servidor também podem ser bimodais, se às vezes os dados estiverem rapidamente
disponíveis no cache RAM e às vezes os dados forem recuperados de uma unidade de disco mecânica lenta.
Quando os dados de desempenho da rede são bimodais, multimodais ou desviados da média, você deve
documentar um desvio padrão com quaisquer medições da média. O desvio padrão é uma medida de
quão amplamente os dados se dispersam da média.
A análise dos tamanhos dos quadros pode ajudá-lo a compreender a integridade de uma rede, não apenas
a eficiência. Por exemplo, um número excessivo de quadros runt Ethernet (menos de 64 bytes) pode
indicar muitas colisões em um segmento Ethernet compartilhado. É normal que as colisões aumentem com a
utilização resultante da contenção de acesso. Se as colisões aumentarem mesmo quando a utilização não
aumentar ou mesmo quando apenas alguns nós estiverem transmitindo, poderá haver um problema mais
sério, como uma NIC defeituosa ou um problema de incompatibilidade duplex.
Analisando Atraso e Tempo de Resposta

Para verificar se o desempenho de um novo projeto de rede atende aos requisitos do cliente, é necessário
medir o tempo de resposta entre dispositivos de rede significativos antes e depois da implementação de um
novo projeto de rede. O tempo de resposta pode ser medido de várias maneiras. Usando um analisador de
protocolo, você pode observar a quantidade de tempo entre os quadros e obter uma estimativa aproximada
do tempo de resposta na camada de enlace de dados, na camada de transporte e na camada de aplicação.
(Esta é uma estimativa aproximada porque os tempos de chegada de pacotes em um analisador só podem aproximar
os tempos de chegada de pacotes nas estações finais.)
Uma maneira mais comum de medir o tempo de resposta é enviar pacotes de ping e medir o tempo de resposta.
tempo de ida e volta (RTT) para enviar uma solicitação e receber uma resposta. Ao medir o RTT,
você também pode medir uma variação RTT. As medições de variação são importantes para
aplicações que não toleram muita instabilidade (por exemplo, aplicações de voz e vídeo). Você
também pode documentar qualquer perda de pacotes.
Você pode usar a Tabela 3-4 para documentar as medições do tempo de resposta. A tabela usa o termo
nó significa roteador, servidor, cliente ou mainframe.
Tabela 3-4 Medições de Tempo de Resposta
Nó A Nó B Nó C Nó D
Nó A X
Nó B X
Nó C X
Nó D X
Dependendo da quantidade de tempo que você tem para sua análise e dependendo do seu
objetivos de design de rede do cliente, você também deve medir o tempo de resposta do usuário
ponto de vista. Em uma estação de trabalho típica, execute alguns aplicativos representativos e
meça quanto tempo leva para obter uma resposta para operações típicas, como verificar e-mail,
enviar um arquivo para um servidor, baixar uma página web, atualizar um pedido de venda, imprimir um
relatório e assim por diante.
Às vezes, aplicações ou implementações de protocolos são notoriamente lentas ou mal escritas.

Sabe-se que alguns periféricos causam atraso extra devido a incompatibilidades com
sistemas operacionais ou hardware. Ao ingressar em listas de discussão e grupos de notícias e ler
informações em periódicos e na World Wide Web, você poderá aprender sobre as causas dos
problemas de tempo de resposta. Porém, certifique-se de fazer alguns testes por conta própria,
porque cada ambiente é diferente.
Além de testar aplicativos de usuário, teste o tempo de resposta para protocolos de serviços de rede (por
exemplo, consultas DNS, solicitações DHCP para um endereço IP, solicitações de autenticação
RADIUS e assim por diante). O Capítulo 4 aborda questões de protocolo com mais detalhes.
Você também deve medir quanto tempo uma estação de trabalho leva para inicializar. Alguma estação de trabalho
os sistemas operacionais demoram muito para inicializar devido à quantidade de tráfego de rede que
eles enviam e recebem durante a inicialização. Você pode incluir medições de tempo de inicialização em seu
análise da rede existente para que você tenha uma linha de base. Quando a nova rede
é implementado, você pode comparar a quantidade de tempo que uma estação de trabalho leva para inicializar
com o tempo base. Esperamos que você possa usar esses dados para provar que seu projeto é um
melhoria.
Embora seu cliente possa não lhe dar permissão para simular problemas de rede, faz sentido fazer
alguns testes de tempos de resposta quando a rede estiver enfrentando problemas ou alterações.
Por exemplo, se possível, meça os tempos de resposta enquanto os protocolos de roteamento estão
convergindo após a queda de um link. Meça novamente os tempos de resposta durante a convergência,
depois que seu novo design for implementado, para ver se os resultados melhoraram. Conforme abordado
no Capítulo 12, “Testando seu projeto de rede”, você pode testar problemas de rede em uma
implementação piloto.
Verificando o status dos principais roteadores, switches e firewalls

A etapa final na caracterização da rede existente é verificar o comportamento dos dispositivos de
interligação na rede. Isso inclui roteadores e switches que conectam camadas de uma topologia
hierárquica e dispositivos que terão as funções mais significativas no seu novo projeto de rede. Não é
necessário verificar todos os switches LAN, apenas os principais switches, roteadores e firewalls.
A verificação do comportamento e da integridade de um dispositivo de interligação de redes inclui

determinar o quão ocupado o dispositivo está (utilização da CPU), quantos pacotes ele processou,
quantos pacotes foram descartados e o status dos buffers e das filas. Seu método para avaliar a
integridade de um dispositivo de interligação de redes depende do fornecedor e da arquitetura do
dispositivo. No caso de roteadores, switches e firewalls Cisco, você pode usar os seguintes comandos
do Cisco IOS:
ÿ show buffers: exibe informações sobre tamanhos de buffer, criação e exclusão de buffer, uso de
buffer e uma contagem de tentativas bem-sucedidas e malsucedidas de obter buffers quando
necessário.
ÿ mostrar detalhes dos vizinhos do cdp: exibe informações sobre dispositivos vizinhos, incluindo
quais protocolos estão habilitados, endereços de rede para protocolos habilitados, o número e
tipo de interfaces, o tipo de plataforma e seus recursos e a versão do Cisco IOS Software.
ÿ mostrar ambiente: exibe informações sobre temperatura, voltagem e ventilador nos roteadores
Cisco série 7000, Cisco 7200 e Cisco 7500 e no Cisco 12000 Series Gigabit Switch Router.
ÿ show interfaces: exibe estatísticas para interfaces, incluindo a taxa de entrada e saída de pacotes,
uma contagem de pacotes descartados de filas de entrada e saída, o tamanho e uso de filas, uma
contagem de pacotes ignorados devido à falta de espaço de buffer de E/S em uma placa, erros
de CRC, contagens de colisões e frequência de reinicialização das interfaces.
ÿ mostrar fluxo de cache IP: exibe informações sobre o NetFlow, uma tecnologia da Cisco que coleta
e mede dados à medida que eles entram nas interfaces do roteador e do switch, incluindo
endereços IP de origem e destino, números de porta TCP ou UDP de origem e destino, ponto de
código de serviços diferenciados (DSCP). valores, contagens de pacotes e bytes, carimbos de
data e hora de início e término, números de interface de entrada e saída e informações de
roteamento (endereço do próximo salto, números de sistema autônomo de origem e destino e
máscaras de prefixo de origem e destino).
ÿ show memory: exibe estatísticas sobre a memória do sistema, incluindo total de bytes, bytes usados e bytes
livres. Também mostra informações detalhadas sobre blocos de memória.
ÿ mostrar processos: exibe a utilização da CPU nos últimos 5 segundos, 1 minuto e 5 minutos e a
porcentagem de CPU usada por vários processos, incluindo processos de protocolo de roteamento,
gerenciamento de buffer e processos de interface do usuário. (Os comandos show Process CPU e
show Process CPU History são variações úteis do comando show Process .)
ÿ show running-config: Exibe a configuração do roteador armazenada na memória e atual

alugado em uso.
ÿ show startup-config: Exibe a configuração que o roteador usará na próxima

reinício.
ÿ mostrar versão: Exibe a versão e os recursos do software, os nomes e fontes dos arquivos de configuração,
as imagens de inicialização, o registro de configuração, o tempo de atividade do roteador e o motivo da
última reinicialização.
Lista de verificação de integridade da rede
Você pode usar a seguinte lista de verificação de integridade da rede para ajudá-lo a verificar a integridade de
uma rede existente. A lista de verificação de integridade da rede é de natureza genérica e documenta o melhor
cenário possível. Os limites podem não se aplicar a todas as redes.
ÿ A topologia da rede e a infraestrutura física estão bem documentadas.
ÿ Os endereços e nomes de rede são atribuídos de maneira estruturada e bem

documentado.
ÿ A fiação da rede é instalada de maneira estruturada e bem identificada.
ÿ A fiação da rede foi testada e certificada.
ÿ A fiação de rede entre os armários de telecomunicações e as estações finais não ultrapassa 100 metros.
ÿ A disponibilidade da rede atende às metas atuais dos clientes.
ÿ A segurança da rede atende às metas atuais dos clientes.
ÿ Nenhum segmento LAN ou WAN está ficando saturado (média de 70% da utilização da rede
lização em uma janela de 10 minutos).
ÿ Não há colisões em links Ethernet full-duplex.
ÿ O tráfego de difusão representa menos de 20% de todo o tráfego em cada segmento de rede.
(Algumas redes são mais sensíveis ao tráfego de transmissão e devem usar um limite de 10%.)
ÿ Sempre que possível e apropriado, os tamanhos dos quadros foram otimizados para serem os maiores possíveis
para a camada de enlace de dados em uso.
ÿ Nenhum roteador é usado em demasia (a utilização da CPU em 5 minutos é inferior a 75%).
ÿ Em média, os roteadores não descartam mais do que 1% dos pacotes. (Para rede
obras que são intencionalmente sobrecarregadas para manter os custos baixos, um limite mais alto pode ser
usado.)
ÿ Configurações atualizadas de roteadores, switches e outros dispositivos foram coletadas, arquivadas e analisadas
como parte do estudo de projeto.
ÿ O tempo de resposta entre clientes e hosts é geralmente inferior a 100 ms (1/10 de

um segundo).
Resumo
Este capítulo abordou técnicas e ferramentas para caracterizar uma rede antes de projetar melhorias para a rede.
Caracterizar uma rede existente é uma etapa importante no projeto de rede de cima para baixo porque ajuda a verificar
se as metas técnicas do projeto do cliente são realistas. Também ajuda a entender a topologia atual e localizar segmentos
de rede e equipamentos existentes, o que será uma informação útil quando chegar a hora de instalar novos equipamentos.
Como parte da tarefa de caracterizar a rede existente, você deve desenvolver uma linha de base do desempenho atual.
As medições de desempenho de linha de base podem ser comparadas a novas medições assim que seu projeto for
implementado para demonstrar ao cliente que seu novo projeto (espero) melhora o desempenho.
1. O que é uma rede descontígua? Por que isso representa desafios para uma rede de
signatário?
2. Por que é importante caracterizar a topologia lógica de uma rede e não apenas a sua
topologia física? Que informações uma topologia lógica ilustra que podem ser perdidas apenas com uma topologia
física?
3. A Associação Cooperativa para Análise de Dados da Internet (CAIDA) coleta informações

ção sobre recursos de medição e visualização de rede. Como o trabalho da CAIDA poderia ajudar um projetista de
rede a caracterizar uma rede existente?
4. O grupo de trabalho IPPM (Internet Protocol Performance Metrics) da IETF desenvolve métricas padrão que podem
ser aplicadas à qualidade, ao desempenho e à confiabilidade de uma rede. Como o trabalho deste grupo
poderia ajudar um projetista de redes a caracterizar uma rede existente?
Projeto prático
O capítulo mencionou o uso de um analisador de protocolo para caracterizar uma rede. Baixe e instale
o analisador de protocolo Wireshark em www.wireshark.org. A menos que você tenha assinado um
documento de Política de Uso Aceitável (AUP) que não permita isso, capture o tráfego de sua empresa
ou rede escolar ativa. (Se você assinou uma AUP que não permite a captura de tráfego de rede, faça a
captura da sua rede doméstica.) Responda às seguintes perguntas.
1. No Wireshark, vá para Estatísticas > Resumo. Qual é a média de Mbps?
2. Vá para Estatísticas > Hierarquia de Protocolo. Quais protocolos usam a maior parte da banda
largura?
3. Vá para Estatísticas > Comprimentos de Pacote > Criar Estatística. Qual porcentagem de
pacotes tem menos de 80 bytes? Qual porcentagem de pacotes tem de 80 a 1279 bytes? Qual é
a porcentagem de pacotes maiores que 1279 bytes?
4. Capture o tráfego de rede ao acessar um site com seu navegador. Em

Wireshark, vá para Estatísticas > HTTP > Contador de Pacotes >Criar Estatística. Quantos
pacotes de resposta você capturou? Que tipos de pacotes de resposta e quantos de cada tipo você
capturou?
Cenário de projeto
A cidade de Mapleland, Oregon, que possui e opera a sua própria concessionária de energia, construiu
uma rede de fibra óptica para monitorar medidores de energia nas casas dos moradores. A rede é
chamada Mapleland Fiber Network (MFN). Como a MFN tinha mais capacidade do que o necessário
para monitorizar contadores, a cidade expandiu os seus serviços para oferecer acesso à rede às
empresas da cidade. As empresas usam a rede para se comunicarem entre si e para acessar a
Internet. No headend da MFN, localizado junto às prefeituras, três roteadores e links WAN se
conectam à Internet para uso da cidade. As empresas na MFN também utilizam estes roteadores para
acessar a Internet.
Além do serviço empresarial, a MFN também oferece serviço de modem a cabo para residências. Um
roteador de modem a cabo no headend MFN se conecta à rede de fibra óptica. Nos bairros da cidade,
nós híbridos de fibra coaxial levam cabeamento coaxial a cada rua e às residências para acesso à
Internet por modem a cabo.
O backbone MFN consiste em uma rede Gigabit Ethernet de fibra óptica que percorre a cidade em uma
topologia em anel. O anel de fibra óptica conecta os nós híbridos de fibra coaxial que levam o cabeamento
coaxial para cada vizinhança. Também conectados ao anel estão seis roteadores de dados.
Cada roteador conecta uma ou mais empresas Mapleland ao MFN por meio de conexões simples
ponto a ponto. Na empresa, a rede de fibra óptica entra no prédio e se conecta a um conversor de mídia.
Um cabo UTP se conecta ao conversor de mídia e normalmente a um switch Ethernet de 100 Mbps.
O switch conecta os computadores e servidores da empresa em uma topologia em estrela por meio de
cabeamento UTP.
1. Desenhe um mapa de rede que mostre a topologia do MFN e como funciona a composição principal.
estão conectados.
2. Que outras informações você reuniria para melhorar seu mapa e adicionar mais detalhes?
3. Mapleland está considerando expandir a MFN para incluir acesso sem fio em suas residências. Que
investigação adicional você fará para se preparar para uma rede sem fio em toda a cidade?
rede?
4. Que preocupações de segurança você tem em relação à rede sem fio?

Capítulo 4
Caracterizando o tráfego de rede
Este capítulo descreve técnicas para caracterizar o fluxo de tráfego, o volume de tráfego e o comportamento do
protocolo. As técnicas incluem o reconhecimento de fontes de tráfego e armazenamentos de dados, a
documentação do uso de aplicativos e protocolos e a avaliação do tráfego de rede causado por protocolos
comuns. Após a conclusão deste capítulo, você será capaz de analisar a rede
padrões de tráfego para ajudá-lo a selecionar soluções de design de rede lógica e física apropriadas para
atender às metas do cliente.
O capítulo anterior tratou da caracterização da rede existente em termos de sua

estrutura e desempenho. Porque analisar a situação existente é um passo importante
em uma abordagem de análise de sistemas para projeto, este capítulo discute a caracterização da rede
existente em termos de fluxo de tráfego. O capítulo também cobre novos requisitos de projeto de rede, com base
nos dois primeiros capítulos que abordaram o projeto comercial e técnico.
metas. Este capítulo se concentra novamente nos requisitos de projeto e descreve os requisitos em termos
de fluxo de tráfego, carga de tráfego, comportamento do protocolo e requisitos de qualidade de serviço (QoS).
Caracterizando o Fluxo de Tráfego

Caracterizar o fluxo de tráfego envolve identificar fontes e destinos do tráfego de rede e analisar a direção e a
simetria dos dados que trafegam entre fontes e destinos. Em algumas aplicações, o fluxo é bidirecional e
simétrico. (ambas as extremidades do
fluxo envia tráfego aproximadamente na mesma taxa.) Em outras aplicações, o fluxo é bidirecional
e assimétrico. (Os clientes enviam pequenas consultas e os servidores enviam grandes fluxos de dados.) Em um
aplicação de transmissão, o fluxo é unidirecional e assimétrico. Esta seção fala sobre
caracterizando a direção e simetria do fluxo de tráfego em uma rede existente e
analisando o fluxo para novas aplicações de rede.
Identificando as principais fontes de tráfego e lojas

Para entender o fluxo de tráfego de rede, você deve primeiro identificar as comunidades de usuários e os dados
armazena para aplicativos existentes e novos.
Observe que o Capítulo 3, “Caracterizando a rede existente”, falou sobre a localização dos principais
hosts, dispositivos de interconexão e segmentos de rede na rede de um cliente. As tarefas discutidas no Capítulo 3 facilitam
as tarefas discutidas neste capítulo de identificação dos principais usuários
comunidades e armazenamentos de dados.
Uma comunidade de usuários é um conjunto de trabalhadores que utilizam uma determinada aplicação ou conjunto de
aplicações. Uma comunidade de usuários pode ser um departamento corporativo ou um conjunto de departamentos. Em muitos
em ambientes corporativos, no entanto, o uso de aplicativos ultrapassa as fronteiras departamentais. À medida que mais
empresas utilizam o gerenciamento matricial e formam equipes virtuais para concluir projetos ad hoc, mais
torna-se cada vez mais necessário caracterizar as comunidades de usuários pelo uso de aplicativos e protocolos, e não por
limites departamentais.
Para documentar comunidades de usuários, peça ao seu cliente para ajudá-lo a preencher o campo Usuário
Gráfico de comunidades mostrado na Tabela 4-1. Para a coluna Locais da comunidade em
Tabela 4-1, use nomes de locais que você já documentou em um mapa de rede. Para o
Na coluna Aplicativos usados pela comunidade, use nomes de aplicativos que você já documentou nos gráficos de
aplicativos de rede no Capítulo 1, “Analisando metas de negócios e
Restrições” e Capítulo 2, “Analisando Metas Técnicas e Compensações”. O estudo de caso
no Capítulo 10, “Selecionando tecnologias e dispositivos para redes de campus”, fornece uma
exemplo de gráfico preenchido.
Tabela 4-1 Comunidades de usuários
Do utilizador Tamanho da comunidade Locais de Aplicativos usados por

Comunidade (Número de usuários) Comunidade Comunidade
Nome
Além de documentar as comunidades de usuários, a caracterização do fluxo de tráfego também requer

que você documente os principais armazenamentos de dados. Um armazenamento de dados (às vezes chamado de coletor de dados) é um
área em uma rede onde residem os dados da camada de aplicativo. Um armazenamento de dados pode ser um servidor, um
farm de servidores, uma rede de área de armazenamento (SAN), um mainframe, uma unidade de backup em fita, um
videoteca ou qualquer dispositivo ou componente de uma rede onde grandes quantidades de dados são armazenadas.
Para ajudá-lo a documentar os principais armazenamentos de dados, peça ao seu cliente para ajudá-lo a preencher
a Tabela 4-2. Para o local, aplicativos e usados pelo usuário
Colunas da comunidade usam nomes que você já documentou em um mapa de rede e outros gráficos.
Capítulo 4: Caracterizando o Tráfego de Rede 89
Tabela 4-2 Armazenamentos de Dados
Banco de dados Localização Formulários Usado pela comunidade de usuários (ou

Comunidades)
Documentando o fluxo de tráfego na rede existente

Documentar o fluxo de tráfego envolve identificar e caracterizar fluxos de tráfego individuais
entre fontes de tráfego e lojas. Os fluxos de tráfego tornaram-se recentemente um tema quente de discussão na
comunidade da Internet. Muito progresso está sendo feito na definição de fluxos,
medir o comportamento do fluxo e permitir que uma estação final especifique requisitos de desempenho
para fluxos.
Para entender melhor o comportamento do fluxo de tráfego, você pode ler Request For Comments (RFC)
2722, “Medição de Fluxo de Tráfego: Arquitetura”. RFC 2722 descreve uma arquitetura para
a medição e relatórios de fluxos de tráfego de rede e discute como a arquitetura se relaciona com uma
arquitetura geral de fluxo de tráfego para intranets e Internet.
Nota Você pode encontrar todos os RFCs online em http://www.ietf.org/rfc/rfcxxxx.txt , onde xxxx é
o número da RFC.
Medir o comportamento do fluxo de tráfego pode ajudar um projetista de rede a determinar quais roteadores
devem ser pares em protocolos de roteamento que usam um sistema de peering, como o Border
Protocolo de gateway (BGP). Medir o comportamento do fluxo de tráfego também pode ajudar os projetistas
de redes a fazer o seguinte:
ÿ Caracterizar o comportamento das redes existentes.
ÿ Planejar o desenvolvimento e expansão da rede.
ÿ Quantificar o desempenho da rede.
ÿ Verifique a qualidade do serviço de rede.
ÿ Atribuir o uso da rede a usuários e aplicativos.
Um fluxo de tráfego de rede individual pode ser definido como informações de protocolo e aplicação transmitidas
entre entidades comunicantes durante uma única sessão. Um fluxo tem
atributos como direção, simetria, caminho de roteamento e opções de roteamento, número de
pacotes, número de bytes e endereços para cada extremidade do fluxo. Uma entidade comunicante
pode ser um sistema final (host), uma rede ou um sistema autônomo (AS).
O método mais simples para caracterizar o tamanho de um fluxo é medir o número de megabytes
por segundo (MBps) entre entidades comunicantes. Para caracterizar o tamanho de um fluxo, use
um analisador de protocolo ou sistema de gerenciamento de rede para registrar a carga entre fontes
e destinos importantes. Você também pode usar o Cisco NetFlow, que coleta e mede dados à
medida que eles entram nas interfaces do roteador e do switch, incluindo endereços IP de origem
e destino, números de porta TCP ou UDP de origem e destino, contagens de pacotes e bytes e
assim por diante.
Você pode usar a Tabela 4-3 para documentar informações sobre a direção e o volume dos fluxos
de tráfego. O objetivo é documentar os megabytes por segundo entre pares de sistemas
autônomos, redes, hosts e aplicações. Para obter as informações para preencher os gráficos,
coloque um dispositivo de monitoramento no núcleo da rede e deixe-o coletar dados por um ou
dois dias. Para obter as informações para preencher a coluna Caminho, você pode ativar a opção
de rota de registro em uma rede IP. A opção de rota de registro tem algumas desvantagens,
entretanto. Ele não oferece suporte a grandes redes e geralmente é desativado por motivos de segurança.
Você também pode estimar o caminho observando tabelas de roteamento e analisando o tráfego de
rede em vários segmentos.
Tabela 4-3 Fluxo de tráfego de rede na rede existente
Destino 1 Destino 2 Destino 3 Destino n
Caminho MBps Caminho MBps Caminho MBps Caminho MBps
Fonte 1
Fonte 2
Fonte 3
Fonte n
Caracterizando tipos de fluxo de tráfego para novas aplicações de rede

Conforme mencionado, um fluxo de rede pode ser caracterizado por sua direção e simetria.
A direção especifica se os dados trafegam em ambas as direções ou em apenas uma direção.
A direção também especifica o caminho que um fluxo percorre ao viajar da origem ao destino através de
uma rede interligada. A simetria descreve se o fluxo tende a ter maior desempenho ou requisitos de QoS
em uma direção do que na outra. Muitas aplicações de rede têm requisitos diferentes em cada direção.
Algumas tecnologias de transmissão da camada de enlace de dados, como a linha de assinante digital
assimétrica (ADSL), são fundamentalmente assimétricas. Uma boa técnica para caracterizar o fluxo de
tráfego de rede é classificar as aplicações como suportando um dos poucos tipos de fluxo bem conhecidos:
ÿ Fluxo de tráfego terminal/host
ÿ Fluxo de tráfego cliente/servidor

ÿ Fluxo de tráfego ponto a ponto
ÿ Fluxo de tráfego servidor/servidor
ÿ Fluxo de tráfego de computação distribuída
Em seu livro Network Analysis, Architecture, and Design, Terceira Edição, James D.
McCabe faz um excelente trabalho ao caracterizar e distinguir modelos de fluxo. As descrições dos tipos
de fluxo nas seções a seguir são parcialmente baseadas no trabalho de McCabe.
Fluxo de tráfego terminal/host
O tráfego terminal/host geralmente é assimétrico. O terminal envia alguns caracteres e o host envia muitos
caracteres. Telnet é um exemplo de aplicação que gera tráfego de terminal/host. O comportamento padrão
do Telnet é que o terminal envie cada caractere digitado pelo usuário em um único pacote. O host retorna
vários caracteres, dependendo do que o usuário digitou. Como ilustração, considere o início de uma sessão
Telnet que começa com o usuário digitando um nome de usuário. Quando o host recebe cada pacote para
os caracteres do nome, o host envia de volta uma mensagem (como Senha obrigatória) em um pacote.
Nota O comportamento padrão do Telnet pode ser alterado para que, em vez de enviar um caractere por vez, o
terminal envie caracteres após um tempo limite ou após o usuário digitar um retorno de carro. Esse
comportamento utiliza a largura de banda da rede com mais eficiência, mas pode causar problemas para alguns
aplicativos. Por exemplo, o editor vi em sistemas UNIX deve ver cada caractere imediatamente para
reconhecer se o usuário pressionou um caractere especial para subir uma linha, descer uma linha, até o final de
uma linha e assim por diante.
Os fluxos de tráfego terminal/host são menos prevalentes nas redes do que eram antes, mas não
desapareceram. Na verdade, os chamados thin clients, que se tornaram bastante populares, podem se
comportar como aplicativos terminais/hosts. Os thin clients são abordados na próxima seção sobre fluxo
de tráfego cliente/servidor.
Fluxo de tráfego cliente/servidor
O tráfego cliente/servidor é o tipo de fluxo mais conhecido e mais utilizado. Servidores são geralmente
computadores poderosos dedicados ao gerenciamento de armazenamento em disco, impressoras ou outros
recursos de rede. Clientes são PCs ou estações de trabalho nos quais os usuários executam aplicativos. Os
clientes dependem de servidores para acessar recursos, como armazenamento, periféricos, software aplicativo
e poder de processamento.
Os clientes enviam consultas e solicitações a um servidor. O servidor responde com dados ou permissão para
o cliente enviar dados. O fluxo geralmente é bidirecional e assimétrico. As solicitações do cliente são
normalmente quadros pequenos, exceto quando são gravados dados no servidor, caso em que são
maiores. As respostas do servidor variam de 64 bytes a 1.500 bytes ou mais, dependendo do tamanho máximo
do quadro permitido para a camada de enlace de dados em uso.
Os protocolos cliente/servidor incluem Server Message Block (SMB), Network File System (NFS), Apple Filing Protocol
(AFP) e NetWare Core Protocol (NCP). Em um ambiente TCP/IP, muitas aplicações são implementadas no estilo
cliente/servidor, embora as aplicações tenham sido inventadas antes do modelo cliente/servidor ser inventado. Por
exemplo, o FTP possui um lado cliente e um lado servidor. Os clientes FTP usam aplicativos FTP para se comunicar
com servidores FTP. O X Window System é um exemplo de servidor (o gerenciador de tela) que realmente roda na
máquina do usuário. Isso pode levar a uma grande quantidade de tráfego em ambas as direções, como quando
o usuário ativa um cursor piscante ou um relógio que precisa de atualização contínua na rede, mesmo quando o
usuário não está presente.
Atualmente, o HTTP é o protocolo cliente/servidor mais amplamente utilizado. Os clientes usam um aplicativo
de navegador web, como o Firefox, para se comunicar com servidores web. O fluxo é bidirecional e assimétrico. Cada
sessão geralmente dura apenas alguns segundos porque os usuários tendem a pular de um site para outro.
O fluxo do tráfego HTTP nem sempre ocorre entre o navegador da Web e o servidor da Web devido ao
armazenamento em cache. Quando os usuários acessam dados armazenados em cache em seus próprios sistemas,
não há tráfego de rede. Outra possibilidade é que um administrador de rede tenha configurado um mecanismo de
cache. Um mecanismo de cache é um software ou hardware que disponibiliza localmente páginas da Web acessadas
recentemente, o que pode acelerar a entrega das páginas e reduzir a utilização da largura de banda WAN. Um
mecanismo de cache também pode ser usado para controlar o tipo de conteúdo que os usuários podem visualizar.
Uma rede de distribuição de conteúdo (CDN) também pode afetar o fluxo do tráfego HTTP. Uma CDN é uma rede de
servidores que entrega páginas da web aos usuários com base em sua localização geográfica. Uma CDN copia as
páginas de um site para uma rede de servidores que podem estar dispersos em diferentes locais. Quando um
usuário solicita uma página da Web que faz parte de uma CDN, a CDN redireciona a solicitação para um servidor
mais próximo do usuário e entrega o conteúdo armazenado em cache.
A CDN também pode se comunicar com o servidor de origem para entregar qualquer conteúdo que não tenha sido
armazenado em cache anteriormente. Os CDNs aceleram a entrega de conteúdo e podem proteger um site contra
grandes picos de tráfego.
Fluxo de tráfego de cliente fino
Um caso especial da arquitetura cliente/servidor é um thin client, que é um software ou hardware projetado para ser
particularmente simples e funcionar em um ambiente onde a maior parte do processamento de dados ocorre em um
servidor. Com a tecnologia thin client (também conhecida como computação baseada em servidor), os aplicativos
do usuário são originados em um servidor central. Em alguns casos, o aplicativo é executado no servidor central e,
em outros casos, o software é instalado no servidor e baixado na máquina cliente para execução.
Um dispositivo de informação ou dispositivo de computação é um thin client projetado para executar um conjunto
específico de tarefas dedicadas. Um dispositivo de computação pode ser uma caixa registradora, uma máquina de e-
mail dedicada ou um dispositivo de recuperação de banco de dados. Os dispositivos de computação geralmente
executam o sistema operacional Linux e um navegador de Internet aprimorado com Java.
A principal vantagem da tecnologia thin client são os custos de suporte mais baixos. Os gerentes de rede podem ter
uma base centralizada de aplicativos que são gerenciados, configurados e atualizados apenas uma vez. Não há
necessidade de configurar individualmente a máquina de cada usuário. Além disso,
como os aplicativos são controlados a partir do servidor central, a segurança pode ser melhor gerenciada. Os thin
clients oferecem um custo total de propriedade (TCO) mais baixo e um TCO escalonável para grandes empresas.
Entretanto, a tecnologia thin client não é aplicável a todas as aplicações de computação, porque os usuários podem
precisar de computadores capazes de operar sem conexão constante com um servidor central.
Uma desvantagem da tecnologia thin client é que a quantidade de dados que flui do servidor para o cliente pode ser
substancial, especialmente quando muitos computadores são inicializados ao mesmo tempo todos os dias. As
redes que incluem thin clients devem ser cuidadosamente projetadas com capacidade suficiente e uma topologia
apropriada. Redes comutadas (em vez de mídia compartilhada) são recomendadas e, para evitar problemas
causados por muito tráfego de broadcast, cada rede comutada deve ser limitada a algumas centenas de thin
clients e seus servidores.
As redes comutadas podem ser conectadas através de roteadores para comunicação entre departamentos e
acesso a redes externas, como a Internet.
Fluxo de tráfego ponto a ponto
Com o tráfego ponto a ponto, o fluxo geralmente é bidirecional e simétrico.

As entidades comunicantes transmitem quantidades aproximadamente iguais de informações. Não há hierarquia.
Cada dispositivo é considerado tão importante quanto qualquer outro dispositivo, e nenhum dispositivo armazena
substancialmente mais dados do que qualquer outro dispositivo. Em ambientes LAN pequenos, os administradores
de rede geralmente configuram PCs em uma configuração peer-to-peer para que todos possam acessar os dados
e impressoras uns dos outros. Não há arquivo central ou servidor de impressão. Outro exemplo de ambiente ponto a
ponto é um conjunto de hosts UNIX multiusuário onde os usuários configuram sessões FTP, Telnet, HTTP e NFS
entre hosts. Cada host atua como cliente e servidor. Existem muitos fluxos em ambas as direções.
Recentemente, aplicativos peer-to-peer para download de músicas, vídeos e software ganharam popularidade.
Cada usuário publica música ou outro material e permite que outros usuários da Internet baixem os dados. Isso é
considerado tráfego ponto a ponto porque cada usuário atua como distribuidor e consumidor de dados. O fluxo de
tráfego é bidirecional e simétrico. A maioria das empresas e muitas redes universitárias não permitem esse tipo
de tráfego ponto a ponto por dois motivos:
ÿ Pode causar uma quantidade excessiva de tráfego.
ÿ O material publicado geralmente é protegido por direitos autorais por outra pessoa que não a pessoa que publicou
adorando.
Um outro exemplo de aplicação ponto a ponto é uma reunião entre empresários em locais remotos usando equipamento
de videoconferência. Em uma reunião, cada participante pode comunicar quantos dados forem necessários a
qualquer momento. Todos os sites têm os mesmos requisitos de QoS.
Uma reunião é diferente de uma situação em que a videoconferência é utilizada para divulgar informações. Com a
disseminação de informações, como uma aula de treinamento ou um discurso de um presidente corporativo aos
funcionários, a maior parte dos dados flui do site central. Algumas perguntas são permitidas nos locais remotos.
A disseminação de informações geralmente é implementada usando um modelo cliente/servidor.
Fluxo de tráfego servidor/servidor

O tráfego servidor/servidor inclui transmissões entre servidores e transmissões entre servidores e aplicativos
de gerenciamento. Os servidores conversam com outros servidores para implementar serviços de diretório, para
armazenar em cache dados muito usados, para espelhar dados para balanceamento de carga e redundância,
para fazer backup de dados e para transmitir a disponibilidade do serviço. Os servidores conversam com
aplicativos de gerenciamento pelos mesmos motivos, mas também para impor políticas de segurança e
atualizar dados de gerenciamento de rede.
Com o tráfego de rede servidor/servidor, o fluxo geralmente é bidirecional. A simetria do fluxo depende da
aplicação. Na maioria dos aplicativos servidor/servidor, o fluxo é simétrico, mas em alguns casos há uma
hierarquia de servidores, com alguns servidores enviando e armazenando mais dados do que outros.
Fluxo de tráfego de computação distribuída

A computação distribuída refere-se a aplicativos que requerem vários nós de computação trabalhando
juntos para concluir um trabalho. Algumas tarefas complexas de modelagem e renderização não podem ser
realizadas em um prazo razoável, a menos que vários computadores processem dados e executem algoritmos
simultaneamente. Os efeitos visuais para filmes são frequentemente desenvolvidos em um ambiente de
computação distribuído. A computação distribuída também é usada na indústria de semicondutores para
atender às necessidades computacionais extremas de projeto e verificação de microchips, e na indústria de
defesa para fornecer simulações militares e de engenharia.
Com a computação distribuída, os dados trafegam entre um gerenciador de tarefas e nós de computação e
entre nós de computação. Em seu livro Network Analysis, Architecture, and Design, Third Edition,
McCabe distingue entre nós de computação fortemente acoplados e fracamente acoplados. Nós fortemente
acoplados transferem informações entre si com frequência. Os nós fracamente acoplados transferem pouca ou
nenhuma informação.
Com alguns aplicativos de computação distribuída, o gerenciador de tarefas informa aos nós de computação
o que fazer com pouca frequência, resultando em pouco fluxo de tráfego. Com outras aplicações, há
comunicação frequente entre o gerenciador de tarefas e os nós de computação. Em alguns casos, o
gerenciador de tarefas aloca tarefas com base na disponibilidade de recursos, o que torna a previsão do
fluxo um tanto difícil.
A caracterização do fluxo de tráfego para aplicativos de computação distribuída pode exigir que você estude o
tráfego com um analisador de protocolo ou modele o tráfego potencial com um simulador de rede.
Fluxo de tráfego em redes de voz sobre IP
O conceito mais importante a ser entendido ao considerar o fluxo de tráfego em redes VoIP é que existem
dois fluxos. O fluxo associado à transmissão da voz de áudio é separado do fluxo associado à configuração e
encerramento da chamada. O fluxo para transmissão da voz digital é peer-to-peer, entre dois telefones ou entre
dois PCs executando software como Skype ou Cisco IP Communicator (CIPC). A configuração e desmontagem
de chamadas, por outro lado, pode ser caracterizada como um fluxo cliente/servidor porque um telefone
precisa falar
para um dispositivo mais complicado, como um servidor ou switch telefônico tradicional, que compreende
números de telefone, endereços, recursos de negociação e assim por diante.
O fluxo de voz de áudio entre dois terminais IP é transportado pelo Real-Time Transport Protocol (RTP),
que é um protocolo sem conexão executado sobre UDP. Os principais protocolos de configuração,
desmontagem e controle de chamadas em uma rede IP são H.323, Cisco Skinny Client Control Protocol
(SCCP), Simple Gateway Control Protocol (SGCP), Media Gateway Control Protocol (MGCP) e
Session Initiation Protocol ( TRAGO). Esses protocolos de sinalização são executados entre um terminal IP
e um servidor habilitado para voz e seguem o paradigma cliente/servidor.
Tanto as redes de voz tradicionais, que são baseadas em centrais privadas (PBX) e comutação de circuitos,
quanto as redes VoIP modernas, que utilizam comutação de pacotes, devem lidar com duas funções
fundamentais: controle de chamadas e comutação de chamadas. O controle de chamadas trata a
chamada <$Icharacterizing;fluxo de tráfego;redes VoIP>Erro! Marcador não definido. configuração e
desmontagem, endereçamento e roteamento e serviços informativos e complementares. Uma tarefa
fundamental do controle de chamadas é comparar os dígitos discados pelo usuário que faz uma chamada
com padrões numéricos configurados para determinar como rotear uma chamada. Em uma rede VoIP, o
controle de chamadas mapeia um número de telefone ou nome de usuário para um endereço de destino
IP, que é compreendido pela camada de infraestrutura de pacotes. Em um ambiente Cisco, um telefone IP
se comunica com o software Cisco Unified Communications Manager para obter um endereço de destino IP a ser usado.
A troca de chamadas trata da troca real de chamadas. Nas redes de voz tradicionais, quando uma chamada
é feita, um PBX conecta o telefone chamador por meio de uma chamada interface de linha à interface
de linha de outro telefone. Se a chamada for destinada à rede telefônica pública comutada (PSTN), a
função de comutação de chamadas conecta a interface do lado da linha à interface do lado do tronco. Em
uma rede VoIP, a comutação de pacotes de voz é feita pela camada de infraestrutura de pacotes, que
fornece switches Ethernet e roteadores IP. Os dispositivos do lado da linha são telefones IP e PCs que
executam software VoIP, como o Cisco IP Communicator (CIPC). A interface do lado do
tronco é controlada por um gateway PSTN, como um roteador habilitado para voz.
Os pacotes de voz de áudio, que são encapsulados em RTP, UDP e IP e um cabeçalho da camada de
enlace de dados, podem ser comutados através da rede usando um caminho diferente daquele usado pelos
pacotes de controle de chamadas. Os pacotes de áudio representam um fluxo de tráfego distinto que deve
ser analisado de forma diferente do fluxo de controle de chamadas quando se considera os requisitos de
largura de banda e QoS.
Documentando o fluxo de tráfego para aplicativos de rede novos e existentes

Para documentar o fluxo de tráfego para aplicativos de rede novos (e existentes), caracterize o tipo de
fluxo de cada aplicativo e liste as comunidades de usuários e armazenamentos de dados associados aos
aplicativos. Você pode usar a Tabela 4-4 para aprimorar os gráficos de Aplicativos de Rede já discutidos
nos Capítulos 1 e 2. Ao preencher a Tabela 4-4, use os mesmos nomes de aplicativos usados nos outros
gráficos. (As colunas Protocolos usados por aplicativo, Requisito aproximado de largura de banda para
o aplicativo e Requisitos de QoS são descritas posteriormente neste capítulo.)
Tabela 4-4 Características de tráfego de aplicativos de rede
Nome de Tipo Protocolos Do utilizador Armazenamentos de dados Aproximado QoS

Aplicação de Usado por Comunidades (servidores, Largura de banda Requisitos
Tráfego Aplicativo Que Use o Anfitriões, e Requerimento
Fluxo Aplicativo Assim por diante) para o
Aplicativo
Ao identificar o tipo de fluxo de tráfego de uma aplicação, selecione um dos tipos bem conhecidos:
ÿ Terminal/host
ÿ Cliente/servidor
ÿ Ponto a ponto
ÿ Servidor/servidor
ÿ Computação distribuída
Se necessário, adicione um comentário para qualificar o tipo de fluxo. Por exemplo, se o tipo for terminal/
host e tela cheia, certifique-se de dizer isso, porque em uma aplicação de tela cheia, o host envia mais
dados do que em uma chamada aplicação de terminal burro. Se o tipo de fluxo for computação
distribuída, adicione algum texto para especificar se os nós de computação estão fortemente ou fracamente
acoplados. Se o fluxo for ponto a ponto e for usado para voz, inclua um comentário nesse sentido, pois
o tráfego de voz precisa de características de QoS diferentes das que a maioria dos aplicativos ponto
a ponto precisa.
Caracterizando a carga de tráfego

Para selecionar topologias e tecnologias apropriadas para atender aos objetivos do cliente, é importante
caracterizar a carga de tráfego com o fluxo de tráfego. A caracterização da carga de tráfego pode ajudá-
lo a projetar redes com capacidade suficiente para uso local e fluxos de interligação de redes.
Devido aos muitos fatores envolvidos na caracterização do tráfego de rede, é improvável que as
estimativas de carga de tráfego sejam precisas. O objetivo é simplesmente evitar um projeto que tenha
gargalos críticos. Para evitar gargalos, você pode pesquisar padrões de uso de aplicativos, tempos ociosos
entre pacotes e sessões, tamanhos de quadros e outros padrões comportamentais de tráfego para
protocolos de aplicativos e sistemas. No entanto, para clientes com inúmeras aplicações, este nível
de análise pode não ser prático. Para esses clientes, você poderia limitar a análise às cinco ou dez
aplicações principais.
Outra abordagem para evitar gargalos é simplesmente lançar grandes quantidades de largura de banda
no problema (também conhecido como superprovisionamento). Uma interpretação estrita dos sistemas
princípios de análise não aprovariam tal abordagem, mas a largura de banda é barata nesses
dias. A largura de banda da LAN é extremamente barata. Não há desculpa para não usar Fast Ethernet
(ou melhor) em todas as novas estações de trabalho e switches, e a maioria das organizações também pode pagar
para usar Gigabit Ethernet em links switch-to-switch e switch-servidor. Largura de banda WAN
ainda é caro em algumas partes do mundo, incluindo áreas rurais dos Estados Unidos.
Mas em muitas partes dos Estados Unidos e do resto do mundo, a largura de banda tem sido
superprovisionado e não é superutilizado. Se você sabe que a largura de banda não será uma restrição nos projetos
de sua rede, você pode pular as próximas seções e ir para
“Caracterizando o comportamento do tráfego.”
Cálculo da carga de tráfego teórica

Conforme descrito no Capítulo 2, a carga de tráfego (às vezes chamada de carga oferecida) é a soma de todos
os dados que todos os nós da rede estão prontos para enviar em um determinado momento. Um objetivo geral para
maioria dos projetos de rede é que a capacidade da rede deve ser mais que adequada para lidar com a carga de tráfego.
O desafio é determinar se a capacidade proposta para um novo projeto de rede é suficiente para lidar com a carga
potencial.
Em seu livro Local and Metropolitan Area Networks, Sexta Edição, William Stallings
fornece alguns cálculos básicos para calcular a carga de tráfego. Paradas
ressalta que você pode fazer um cálculo elementar baseado simplesmente no número de
estações transmitindo, a rapidez com que cada estação gera mensagens e o tamanho das mensagens. Por exemplo,
para uma rede com capacidade proposta de 1 Mbps, se 1.000 estações
enviar quadros de 1000 bits a cada segundo, a carga oferecida é igual à capacidade. Embora
Stallings estava se referindo à capacidade de uma LAN, capacidade poderia se referir à capacidade de um
link WAN, uma rede inteira ou partes de uma rede, ou o backplane de um
switch ou roteador.
Em geral, para calcular se a capacidade é suficiente, são necessários apenas alguns parâmetros:
ÿ O número de estações
ÿ O tempo médio que uma estação fica ociosa entre o envio de quadros
ÿ O tempo necessário para transmitir uma mensagem depois que o acesso ao meio é obtido
Estudando os tempos de inatividade e os tamanhos dos quadros com um analisador de protocolo e estimando o número
de estações, você pode determinar se a capacidade proposta é suficiente.
Se você pesquisar os tipos de fluxo de tráfego, conforme discutido anteriormente neste capítulo, poderá desenvolver
estimativas mais precisas de carga. Em vez de assumir que todas as estações têm qualidades de geração de carga
semelhantes, você pode assumir que as estações que utilizam uma aplicação específica têm qualidades de geração de
carga semelhantes. Podem ser feitas suposições sobre o tamanho do quadro e o tempo ocioso para
uma aplicação depois de você ter classificado o tipo de fluxo e identificado os protocolos (discutidos posteriormente neste
capítulo) usados pela aplicação.
Para uma aplicação cliente/servidor, o tempo ocioso do servidor depende do número de clientes que usam o
servidor e da arquitetura e das características de desempenho do servidor (velocidade de acesso ao disco,
velocidade de acesso à RAM, mecanismos de cache e assim por diante). Ao estudar o tráfego de rede dos
servidores com um analisador de protocolo, você pode estimar o tempo médio de inatividade. Em geral, os
servidores devem ter pouco tempo ocioso. Se um servidor estiver subutilizado, considere movê-lo para uma
plataforma de servidor compartilhado usando tecnologia de virtualização de servidores.
O tempo ocioso do lado do cliente depende parcialmente da ação do usuário, o que significa que é impossível
prever com precisão o tempo ocioso. Entretanto, você pode fazer estimativas do tempo ocioso estudando o
tráfego com um analisador de protocolo e usando scripts para simular as piores ações do usuário ou usando
uma ferramenta de modelagem de rede. Uma boa ferramenta de modelagem de rede sabe quais suposições
devem ser feitas sobre o tempo ocioso, os atrasos da camada MAC, a distribuição da chegada de pacotes
em servidores e dispositivos de interligação de redes e o comportamento de enfileiramento e buffer em dispositivos
de interligação de redes.
Depois de identificar a carga de tráfego aproximada para um fluxo de aplicativo, você poderá estimar a carga
total de um aplicativo multiplicando a carga do fluxo pelo número de dispositivos que usam o aplicativo. A pesquisa
que você faz sobre o tamanho das comunidades de usuários e o número de armazenamentos de dados
(servidores) pode ajudá-lo a calcular um requisito aproximado de largura de banda agregada para cada aplicativo.
Documentar a localização das comunidades de usuários e dos armazenamentos de dados, como você fez nas
Tabelas 4-1 e 4-2, pode ajudá-lo a compreender a quantidade de tráfego que fluirá de um segmento para outro.
Isto pode ajudar na seleção de tecnologias de backbone e dispositivos de interligação de redes.
Ao estimar a carga de tráfego, além de investigar tempos ociosos entre pacotes, tamanhos de quadros e
comportamento de fluxo, você também deve investigar padrões de uso de aplicativos e requisitos de QoS.
Alguns aplicativos são usados com pouca frequência, mas exigem uma grande quantidade de largura de
banda quando são usados. Por exemplo, talvez os trabalhadores normalmente acessem uma LAN Ethernet para
ler e-mails, armazenar pequenos arquivos em servidores e imprimir pequenos documentos em impressoras de
rede. Mas, uma vez a cada três meses, eles usam software multimídia em tempo real em seus PCs para assistir
ao discurso do presidente corporativo sobre os números de vendas trimestrais. Isto significa que uma vez por
trimestre as características do tráfego e os requisitos de QoS são diferentes do normal.
Em geral, para caracterizar com precisão a carga de tráfego, é necessário entender os padrões de uso do
aplicativo e os requisitos de QoS, além dos tempos ociosos e dos tamanhos dos quadros. Algumas
aplicações esperam que a rede simplesmente faça o melhor esforço para atender aos requisitos de carga
(largura de banda). Outras aplicações, como aplicações de vídeo, possuem requisitos inflexíveis para uma
quantidade constante de largura de banda.
A próxima seção aborda a caracterização dos padrões de uso com mais detalhes. A seção
“Caracterizando os requisitos de qualidade de serviço”, mais adiante neste capítulo, discute a caracterização
dos requisitos de QoS.
Documentando padrões de uso de aplicativos

O primeiro passo na documentação dos padrões de utilização de aplicações é identificar as comunidades de
utilizadores, o número de utilizadores nas comunidades e as aplicações que os utilizadores utilizam. Esta
etapa, que já foi abordada na seção “Identificando as principais fontes e armazenamentos de tráfego” deste
capítulo, pode ajudá-lo a identificar o número total de usuários de cada aplicativo.
Além de identificar o número total de usuários de cada aplicativo, você também deve documentar as seguintes
informações:
ÿ A frequência das sessões de aplicação (número de sessões por dia, semana, mês ou qualquer período de
tempo apropriado)
ÿ A duração média de uma sessão de aplicativo
ÿ O número de usuários simultâneos de um aplicativo
Armado com informações sobre a frequência e duração das sessões e o número de sessões simultâneas,
você pode prever com mais precisão a necessidade agregada de largura de banda para todos os usuários
de um aplicativo. Se não for prático pesquisar esses detalhes, você pode fazer algumas suposições:
ÿ O número de usuários de um aplicativo é igual ao número de usuários simultâneos.
ÿ Todos os aplicativos são usados o tempo todo, de modo que o cálculo da largura de banda é pior
estimativa de caso (pico).
ÿ Cada usuário abre apenas uma sessão, e essa sessão dura o dia todo até que o usuário feche
feche o aplicativo no final do dia.
Refinando estimativas de carga de tráfego causada por aplicativos

Para refinar sua estimativa dos requisitos de largura de banda do aplicativo, você precisa pesquisar o
tamanho dos objetos de dados enviados pelos aplicativos, a sobrecarga causada pelas camadas do protocolo
e qualquer carga adicional causada pela inicialização do aplicativo. (Alguns aplicativos enviam muito mais
tráfego durante a inicialização do que durante a operação em estado estacionário.)
Como o comportamento dos aplicativos e dos usuários varia muito, é difícil estimar com precisão o tamanho
médio dos objetos de dados que os usuários transferem entre si e para os servidores. (A verdadeira resposta
de engenharia para a maioria das questões relacionadas ao tráfego de rede é “depende”.) No passado,
alguns livros sobre redes especificavam o tamanho médio de uma mensagem de e-mail, página da Web,
objeto multimídia, registro de banco de dados e assim por diante. Hoje em dia, com mensagens de e-mail
que incluem anexos de vídeo, páginas da Web que oferecem vídeo sob demanda e bancos de dados que
podem ser usados para correio de voz, é difícil fazer generalizações sobre o tamanho médio dos objetos
enviados em uma rede. Uma análise completa do comportamento real do aplicativo é necessária se você
deseja obter uma resposta precisa ao provisionar suas redes para lidar com a carga oferecida.
Para caracterizar completamente o comportamento do aplicativo, você deve investigar quais protocolos um
aplicativo usa. Ao conhecer os protocolos, você pode calcular a carga de tráfego com mais precisão
adicionando o tamanho dos cabeçalhos do protocolo ao tamanho dos objetos de dados. A Tabela 4-5
mostra alguns tamanhos típicos de cabeçalho de protocolo.
Tabela 4-5 Sobrecarga de Tráfego para Vários Protocolos
Protocolo Detalhes indiretos Total

Bytes
Ethernet Preâmbulo = 8 bytes, cabeçalho = 14 bytes, CRC = 4 bytes, intervalo 38

Versão II entre quadros (IFG) = 12 bytes
IEEE 802.3 Preâmbulo = 8 bytes, cabeçalho = 14 bytes, LLC = 3 ou 4 bytes, 46

com 802.2 SNAP (se presente) = 5 bytes, CRC = 4 bytes, IFG = 12 bytes
HDLC Flags = 2 bytes, endereços = 2 bytes, controle = 1 ou 2 bytes, 10
CRC = 4 bytes
PI Tamanho do cabeçalho sem opções 20
TCP Tamanho do cabeçalho sem opções 20
UDP Tamanho do cabeçalho 8
Dependendo das aplicações e protocolos que uma estação de trabalho utiliza, a inicialização da estação de
trabalho pode causar uma carga nas redes devido ao número de pacotes e, em alguns casos,
o número de pacotes de transmissão. Embora isso esteja se tornando um problema menor à medida que a rede
a largura de banda tornou-se tão barata, e CPUs extremamente rápidas em estações de trabalho estão prontamente
disponíveis para que o processamento de transmissão não seja uma preocupação, ainda é digno de nota para
redes que estão limitadas por preocupações de largura de banda e processamento, especialmente redes em
escolas e organizações sem fins lucrativos. Além dos aplicativos configurados para iniciar
inicialização, os seguintes protocolos de nível de sistema enviam pacotes quando uma estação de trabalho é inicializada:
ÿ Protocolo de resolução de endereço (ARP)
ÿ Protocolo de configuração dinâmica de host (DHCP)
ÿ Protocolo de mensagens de controle da Internet (ICMP), versões 4 e 6
ÿ Protocolo de gerenciamento de grupo da Internet (IGMP), versões 4 e 6
ÿ Sistema de Nomes de Domínio (DNS)
ÿ DNS multicast (mDNS)
ÿ Consultas de nome NetBIOS
ÿ Protocolo de tempo de rede (NTP)
ÿ Protocolo Simples de Descoberta de Serviço (SSDP)
ÿ Protocolo de localização de serviço (SLP)
ÿ Protocolo Simples de Gerenciamento de Rede (SNMP)

Estimando a carga de tráfego causada por protocolos de roteamento
Neste ponto do processo de projeto de rede, você pode não ter selecionado protocolos de roteamento para
o novo projeto de rede, mas deverá ter identificado protocolos de roteamento em execução na rede existente.
Estimar a carga de tráfego causada por protocolos de roteamento legados é importante em uma topologia que
inclui muitas redes em um lado de um link WAN lento. Um roteador que envia uma grande tabela de
roteamento de vetor de distância a cada meio minuto pode usar uma porcentagem significativa de WAN.
largura de banda. Como os protocolos de roteamento limitam o número de rotas por pacote, em grandes
redes, um roteador envia vários pacotes para enviar a tabela inteira. Informações de roteamento
O Protocolo (RIP), por exemplo, envia um pacote de roteamento a cada 30 segundos. Cada rota no
o pacote usa 20 bytes e há 25 rotas por pacote. Quando cabeçalhos são adicionados, isso
significa que um roteador executando RIP envia um ou mais pacotes de 532 bytes a cada 30 segundos,
dependendo do tamanho da tabela de roteamento.
Protocolos de roteamento mais recentes, como Open Shortest Path First (OSPF) e Enhanced Interior
Gateway Routing Protocol (EIGRP), usa pouca largura de banda. No caso do OSPF, seu principal
A preocupação deve ser a quantidade de largura de banda consumida pela sincronização do banco de dados
pacotes que os roteadores enviam a cada 30 minutos. Ao subdividir uma rede OSPF em áreas
e utilizando a sumarização de rotas, esse tráfego pode ser minimizado. Além do tráfego de sincronização do
banco de dados, o único tráfego que o OSPF envia após a inicialização é pequeno Olá
pacotes a cada 10 segundos.
O EIGRP também envia pacotes Hello, mas com mais frequência que o OSPF (a cada 5 segundos). Sobre
por outro lado, o EIGRP não envia atualizações periódicas de rota ou pacotes de sincronização de banco de
dados. Ele envia atualizações de rota somente quando há alterações.
Caracterizando o comportamento do tráfego

Para selecionar soluções apropriadas de projeto de rede, você precisa entender o protocolo e
comportamento do aplicativo, além de fluxos de tráfego e carga. Por exemplo, para selecionar topologias de
LAN apropriadas, você precisa investigar o nível de tráfego de broadcast nas LANs.
Para provisionar capacidade adequada para LANs e WANs, você precisa verificar a utilização extra de largura
de banda causada por ineficiências de protocolo e tamanhos de quadros ou temporizadores de retransmissão
abaixo do ideal.
Comportamento de transmissão/multicast
Um quadro de transmissão é um quadro que vai para todas as estações da rede em uma LAN. No link de dados
camada, o endereço de destino de um quadro de transmissão é FF:FF:FF:FF:FF:FF (todos 1s em binário).
Um quadro multicast é um quadro que vai para um subconjunto de estações. Por exemplo, um quadro
destinado a 01:00:0C:CC:CC:CC vai para roteadores e switches Cisco que executam o
Cisco Discovery Protocol (CDP) em uma LAN.
Dispositivos de interligação de redes da camada 2, como switches e pontes, transmissão direta e

quadros multicast em todas as portas. O encaminhamento de quadros broadcast e multicast pode ser uma
problema de escalabilidade para grandes redes planas (comutadas ou em ponte). Um roteador não faz
transmissões ou multicasts. Todos os dispositivos de um lado de um roteador são considerados parte de um
único domínio de broadcast.
Além de incluir roteadores em um projeto de rede para diminuir o encaminhamento de transmissão, você
também pode limitar o tamanho de um domínio de transmissão implementando LANs virtuais (VLAN).
A tecnologia VLAN, discutida com mais detalhes no Capítulo 5, “Projetando uma topologia de rede”, permite que
um administrador de rede subdivida os usuários em sub-redes associando portas de switch a uma ou
mais VLANs. Embora uma VLAN possa abranger vários switches, o tráfego de broadcast dentro de uma
VLAN não é transmitido para fora da VLAN.
Muitos quadros de transmissão podem sobrecarregar estações finais, switches e roteadores. É

importante que você pesquise o nível de tráfego de transmissão no projeto proposto e limite o número de
estações em um único domínio de transmissão. O termo radiação de transmissão é frequentemente usado
para descrever o efeito das transmissões que se espalham do remetente para todos os outros dispositivos
em um domínio de transmissão. A radiação de transmissão pode degradar o desempenho nos terminais da
rede.
A placa de interface de rede (NIC) em uma estação de rede passa transmissões e multicasts relevantes para a
CPU da estação. Algumas NICs passam todos os multicasts para a CPU, mesmo quando os multicasts não
são relevantes, porque as NICs não possuem software de driver mais seletivo. O software de driver inteligente
pode informar a uma NIC quais multicasts passar para a CPU.
Infelizmente, nem todos os motoristas possuem essa inteligência. As CPUs nas estações de rede
ficam sobrecarregadas ao processar altos níveis de transmissões e multicasts. Se mais de 20% do tráfego da
rede for de broadcast ou multicast, a rede precisará ser segmentada usando roteadores ou VLANs.
Outra possível causa do tráfego pesado de transmissão são tempestades de transmissão intermitentes causadas
por estações de rede mal configuradas ou com mau comportamento. Por exemplo, uma máscara de sub-rede
mal configurada pode fazer com que uma estação envie quadros ARP desnecessariamente porque a estação
não distingue corretamente entre endereços de estação e de transmissão, fazendo com que ela envie ARPs
para endereços de transmissão.
Em geral, porém, o tráfego de transmissão é necessário e inevitável. Os protocolos de roteamento e comutação

usam transmissões e multicasts para compartilhar informações sobre a topologia da rede. Os servidores enviam
transmissões e multicasts para anunciar seus serviços. Os clientes enviam transmissões e multicasts para
localizar serviços e verificar a exclusividade de endereços e nomes.
Eficiência da rede
Caracterizar o comportamento do tráfego de rede requer a compreensão da eficiência de novas aplicações de
rede. Eficiência refere-se a se os aplicativos e protocolos usam a largura de banda de maneira eficaz. A
eficiência é afetada pelo tamanho do quadro, pela interação dos protocolos usados por um aplicativo, pelo
janelamento e pelo controle de fluxo e pelos mecanismos de recuperação de erros.
Tamanho do quadro
Usar um tamanho de quadro que seja o máximo suportado pelo meio em uso tem um impacto positivo
no desempenho da rede para aplicativos em massa. Para aplicativos de transferência de arquivos, em
particular, você deve usar a maior unidade máxima de transmissão (MTU) possível.
Dependendo das pilhas de protocolos que seu cliente usará no novo projeto de rede, o MTU poderá ser
configurado para algumas aplicações.
Em um ambiente IP, deve-se evitar aumentar o MTU para um valor maior que o máximo suportado para
a mídia atravessada pelos frames, para evitar fragmentação e remontagem de frames. Quando dispositivos
como nós finais ou roteadores precisam fragmentar e remontar quadros, o desempenho diminui.
Os sistemas operacionais modernos suportam a descoberta de MTU. Com a descoberta de MTU, o

software pode descobrir e usar dinamicamente o maior tamanho de quadro que atravessará a rede
sem exigir fragmentação. A descoberta de MTU geralmente funciona, mas há alguns problemas com
ela, conforme mencionado na seção “Analisando a eficiência da rede” no Capítulo 3.
Janelas e controle de fluxo Para
realmente entender o tráfego de rede, você precisa entender o janelamento e o controle de fluxo. Um
dispositivo TCP/IP, por exemplo, envia segmentos (pacotes) de dados em sequência rápida, sem
esperar por uma confirmação, até que sua janela de envio se esgote. A janela de envio de uma estação
é baseada na janela de recebimento do destinatário. O destinatário informa em cada pacote TCP quantos
dados está pronto para receber. Esse total pode variar de alguns bytes até 65.535 bytes. A janela de
recebimento do destinatário é baseada na quantidade de memória que o receptor possui e na rapidez com
que ele pode processar os dados recebidos. Você pode otimizar a eficiência da rede aumentando a
memória e a potência da CPU nas estações finais, o que pode resultar em uma janela de recebimento
maior.
Observação Teoricamente, o tamanho ideal da janela é a largura de banda de um link multiplicada pelo
atraso no link. Para maximizar o rendimento e usar a largura de banda de forma eficiente, a janela de envio
deve ser grande o suficiente para que o remetente preencha completamente o canal de largura de
banda com dados antes de interromper a transmissão e aguardar uma confirmação.
A RFC 1323 ilustra a necessidade de uma janela maior do que o tamanho máximo padrão da janela TCP
de 65.535 bytes. O produto do atraso da largura de banda é maior que 65.535 bytes em links de alta
velocidade, mas com longo atraso, como canais de satélite de alta capacidade e links terrestres de fibra
óptica que percorrem longas distâncias (por exemplo, através dos Estados Unidos).
A RFC 1323 refere-se a um caminho que opera nesta região como um tubo longo e grosso e a uma rede
que contém esse caminho como uma rede longa e gorda ou LFN (pronuncia-se “elefante”). Se a rede do seu
cliente incluir LFNs, você deverá recomendar implementações de TCP baseadas na RFC 1323. O
campo Janela no cabeçalho TCP tem 16 bits. A RFC 1323 define uma extensão de escala de janela que
expande a definição da janela TCP para 32 bits e usa um fator de escala para transportar esse valor de 32
bits no campo Janela de 16 bits. Durante o handshake triplo do TCP, os hosts podem incluir uma opção
TCP que indica seu suporte à extensão de escala de janela.
Alguns aplicativos baseados em IP são executados em UDP, não em TCP. Nesse caso, não há controle de
fluxo ou o controle de fluxo é tratado na sessão ou na camada de aplicação. A lista a seguir mostra quais
protocolos são baseados em TCP e quais protocolos são baseados em UDP:
ÿ Protocolo de transferência de arquivos (FTP): porta TCP 20 (dados) e porta TCP 21 (controle)
ÿ Telnet: porta TCP 23
ÿ Protocolo simples de transferência de correio (SMTP): porta TCP 25
ÿ Protocolo de transferência de hipertexto (HTTP): porta TCP 80
ÿ Protocolo simples de gerenciamento de rede (SNMP): portas UDP 161 e 162
ÿ Sistema de Nomes de Domínio (DNS): porta UDP 53
ÿ Protocolo de transferência de arquivos trivial (TFTP): porta UDP 69
ÿ Servidor DHCP: porta UDP 67
ÿ Cliente DHCP: porta UDP 68
ÿ Chamada de procedimento remoto (RPC): porta UDP 111
Os protocolos executados em sistemas UNIX, como NFS e Network Information Services (NIS), geralmente
usam RPC, embora versões mais recentes suportem TCP.
Os protocolos que enviam uma resposta a cada solicitação são frequentemente chamados de protocolos
Ping-Pong. Os protocolos Ping Pong não usam largura de banda de forma eficiente. Como exemplo, considere
o SMB, o protocolo de compartilhamento de arquivos usado nas plataformas Windows. Embora o SMB use
protocolos não Ping-Pong nas camadas inferiores, ele se comporta como um protocolo Ping-Pong na camada
de aplicação. O cliente envia uma solicitação de leitura para receber dados. Um servidor SMB típico pode
enviar 32 KB de dados por vez, divididos em segmentos TCP. O cliente espera até que esses dados sejam
recebidos antes de solicitar mais dados. Isso limita bastante o rendimento.
Faça o cálculo para uma VPN IPsec, por exemplo, que conecta um usuário na cidade de Nova York a um
servidor em Washington, DC. O atraso unidirecional é de cerca de 50 ms. Ignorando os atrasos do cliente e
do servidor para E/S de disco e atraso de serialização, o cliente recebe no máximo 32 KB a cada 100 ms ou
320 KBps. Isso significa que a taxa de transferência máxima é de 2,56 Mbps. Com perdas de pacotes e
conseqüentes retransmissões, o rendimento real pode ser ainda menor. Esse problema sugere que você
deve aconselhar seus clientes de projeto de rede a não planejarem iniciar programas ou copiar diretórios
grandes de um servidor de arquivos SMB remoto.
Mecanismos de recuperação de erros

Mecanismos de recuperação de erros mal projetados podem desperdiçar largura de banda. Por exemplo, se
um protocolo retransmite dados rapidamente sem esperar tempo suficiente para receber uma confirmação,
isso pode causar degradação do desempenho do restante da rede devido à largura de banda utilizada. As
confirmações em múltiplas camadas também podem desperdiçar largura de banda.
Os protocolos sem conexão geralmente não implementam a recuperação de erros. A maior parte da camada de enlace de dados
e os protocolos da camada de rede não têm conexão. Alguns protocolos da camada de transporte, como
UDP, não têm conexão.
Os mecanismos de recuperação de erros para protocolos orientados a conexão variam. TCP implementa um
algoritmo de retransmissão adaptativo, o que significa que a taxa de retransmissões diminui
quando a rede está congestionada, o que otimiza o uso da largura de banda.
Implementações TCP mais recentes também implementam ACK seletivo (SACK), conforme descrito em RFC
2018. Sem SACK, caminhos propensos a erros e com alto atraso podem apresentar baixo rendimento devido
à maneira como o TCP reconhece os dados. Os reconhecimentos TCP (ACK) são cumulativos
até o ponto em que ocorre um problema. Se os segmentos forem perdidos, o número ACK será mais um
que o número do último byte recebido antes da perda, mesmo que mais segmentos
chegou depois da perda. Não há como o receptor relatar uma falha nos dados recebidos.
Isso faz com que o remetente espere um tempo de ida e volta para descobrir cada segmento perdido ou
retransmita desnecessariamente segmentos que o destinatário possa ter recebido corretamente.
recebido.
Com o mecanismo SACK, o destinatário TCP preenche o campo de opção SACK no TCP
cabeçalho para informar ao remetente os blocos não contíguos de dados que foram recebidos.
O remetente pode então retransmitir apenas os segmentos ausentes. RFC 2018 define um TCP
opção para preenchimento dos números de sequência dos blocos recebidos e outra opção TCP para
informando ao destinatário durante o handshake triplo que o host suporta SACK.
Usando um analisador de protocolo, você pode determinar se os protocolos do seu cliente implementam
uma recuperação de erros eficaz. Em alguns casos, você pode configurar temporizadores de retransmissão
e tempo limite ou atualizar para uma implementação de protocolo melhor.
Caracterizando Requisitos de Qualidade de Serviço

Analisar os requisitos de tráfego de rede não é tão simples quanto identificar fluxos, medir a carga dos fluxos
e caracterizar o comportamento do tráfego, como comportamento de transmissão e recuperação de erros.
Você também precisa caracterizar os requisitos de QoS dos aplicativos.
Apenas saber o requisito de carga (largura de banda) de um aplicativo não é suficiente. Você
também precisa saber se o requisito é flexível ou inflexível. Algumas aplicações continuam
funcionar (embora lentamente) quando a largura de banda não é suficiente. Outras aplicações, como
aplicações de voz e vídeo, tornam-se inúteis se um certo nível de largura de banda não for
disponível. Além disso, se você tiver uma combinação de aplicativos flexíveis e inflexíveis em uma rede,
precisará determinar se é prático emprestar largura de banda do flexível.
aplicativo para manter o aplicativo inflexível funcionando.
Conforme discutido no Capítulo 2, a voz também é inflexível no que diz respeito ao atraso. A voz também é
sensível à perda de pacotes, o que resulta em cortes e saltos de voz. Sem a configuração adequada de
QoS em toda a rede, podem ocorrer perdas devido a links congestionados e buffer de pacotes e
gerenciamento de filas inadequados nos roteadores.
As seções a seguir abordam a análise dos requisitos de QoS usando ATM e Internet
Técnicas da Força-Tarefa de Engenharia (IETF). O objetivo destas seções é apresentar a você
à terminologia que os engenheiros ATM e IETF usam para classificar o tráfego e especificar os requisitos
de QoS para classes de tráfego. Embora o material seja altamente técnico e detalhado, ele deverá lhe
dar algumas idéias fundamentais sobre a classificação dos tipos de aplicações que desempenharão um
papel no projeto de sua rede e deverá prepará-lo para capítulos futuros que abrangem estratégias para
projetar e otimizar redes que pode atender às necessidades de diversas aplicações.
Especificações de QoS ATM

Em seu documento “Traffic Management Specification Version 4.1”, o ATM Forum faz um excelente trabalho
ao categorizar os tipos de serviços que uma rede pode oferecer para suportar diferentes tipos de aplicações.
Em 2004, o Fórum ATM uniu forças com a MPLS e a Frame Relay Alliance para formar o Fórum MFA. O
Fórum MFA fundiu-se posteriormente com o Fórum IP/MPLS e em 2008 com o Fórum de Banda Larga.
No entanto, os engenheiros de rede ainda se referem ao trabalho do Fórum ATM.
Mesmo que seu cliente não tenha planos de usar a tecnologia de modo de transferência assíncrona (ATM),
a terminologia ATM Forum ainda é útil porque identifica os parâmetros que diferentes tipos de aplicativos
devem especificar para solicitar um determinado tipo de serviço de rede.
Esses parâmetros incluem atraso e variação de atraso, tamanhos de rajadas de dados, perda de dados e
taxas de tráfego de pico, sustentáveis e mínimas. Embora possa ser necessário substituir a palavra célula
por pacote em alguns casos, as definições do Fórum ATM podem ajudá-lo a classificar aplicativos em qualquer
rede, mesmo em redes não ATM.
O Fórum ATM define seis categorias de serviços, cada uma das quais é descrita com mais detalhes
posteriormente nesta seção:
ÿ Taxa de bits constante (CBR)
ÿ Taxa de bits variável em tempo real (rt-VBR)
ÿ Taxa de bits variável não em tempo real (nrt-VBR)
ÿ Taxa de bits não especificada (UBR)
ÿ Taxa de bits disponível (ABR)
ÿ Taxa de quadros garantida (GFR)
Para cada categoria de serviço, o Fórum ATM especifica um conjunto de parâmetros para descrever tanto o
tráfego apresentado à rede quanto a QoS exigida da rede. O Fórum ATM também define mecanismos
de controle de tráfego que a rede pode utilizar para atender aos objetivos de QoS. A rede pode
implementar mecanismos como controle de admissão de conexão e alocação de recursos de forma
diferente para cada categoria de serviço.
As categorias de serviço são diferenciadas como sendo em tempo real ou não em tempo real. CBR e rtVBR
são categorias de serviços em tempo real. Aplicações em tempo real, como aplicações de voz e vídeo,
exigem atraso e variação de atraso fortemente restritos. Aplicações que não são de tempo real, como
aplicações de dados cliente/servidor e de terminal/host, não exigem
atraso restrito e variação de atraso. Nrt-VBR, UBR, ABR e GFR são categorias de serviço que não são
em tempo real.
É importante trabalhar com seu cliente para mapear corretamente aplicações e protocolos para a categoria
de serviço correta para atender aos objetivos de desempenho da rede. Uma breve visão geral das categorias
de serviços ATM é fornecida aqui. Você pode aprender mais sobre categorias de serviços ATM e
gerenciamento de tráfego lendo o documento “Especificação de gerenciamento de tráfego
versão 4.1”. Este documento está disponível no Fórum ATM em http://broadband-forum.org/ftp/
pub/approved-specs/af-tm-0121.000.pdf.
Categoria de serviço de taxa de bits constante

Quando o CBR é usado, um sistema de origem reserva recursos de rede antecipadamente e pede uma
garantia de que a QoS negociada seja assegurada a todas as células, desde que as células estejam em
conformidade com as especificações de conformidade relevantes. A fonte pode emitir células na taxa de
pico de células (PCR) a qualquer momento e por qualquer duração e os compromissos de QoS devem ser
aplicáveis. O CBR é usado por aplicativos que precisam da capacidade de solicitar uma quantidade estática
de largura de banda para estar continuamente disponível durante a vida útil da conexão. A quantidade de
largura de banda que uma conexão requer é especificada pelo valor PCR.
O serviço CBR destina-se a suportar aplicações em tempo real que exigem variação de atraso fortemente
restrita (por exemplo, voz, vídeo e emulação de circuito), mas não está restrito a essas aplicações. A fonte
pode emitir células no PCR negociado ou abaixo dele ou ficar em silêncio por períodos de tempo. As células
que são atrasadas além do valor especificado pelo parâmetro atraso máximo de transferência de células
(maxCTD) são consideradas de valor significativamente reduzido para o aplicativo.
As conexões rt-VBR da categoria de serviço de taxa de bits
variável em tempo real são caracterizadas em termos de PCR, taxa de célula sustentável (SCR) e tamanho
máximo de burst (MBS). Espera-se que as fontes transmitam em rajadas a uma taxa que varia com o tempo.
As células que são atrasadas além do valor especificado por maxCTD são consideradas de valor
significativamente reduzido para o aplicativo. O serviço rt-VBR pode suportar multiplexação estatística de
fontes de dados em tempo real.
Categoria de serviço de taxa de bits variável em tempo não real

A categoria de serviço nrt-VBR destina-se a aplicações que não sejam de tempo real e que possuam
características de tráfego em rajadas. Nenhum limite de atraso está associado a esta categoria de
serviço. O serviço é caracterizado em termos de PCR, SCR e MBS. Para células transferidas dentro do
contrato de tráfego, o aplicativo espera uma baixa taxa de perda de células (CLR). O serviço nrt-VBR
pode suportar multiplexação estatística de conexões.
Categoria de serviço de taxa de bits não especificada
O serviço UBR não especifica nenhuma garantia de serviço relacionada ao tráfego. Nenhum compromisso numérico
é feito em relação à taxa de perda de células ou ao atraso de transferência de células (CTD) experimentado por um
Conexão UBR. Uma rede pode ou não aplicar PCR à admissão de conexão
funções de controle e controle de parâmetros de uso (UPC). (UPC é definido como o conjunto de ações
tomada pela rede para monitorar e controlar o tráfego no ponto de acesso do sistema final.)
Onde a rede não impõe PCR, o valor do PCR é apenas informativo. (Isso é
ainda é útil negociar PCR para permitir que a fonte descubra a menor limitação de largura de banda ao longo do
caminho da conexão.)
A categoria de serviço UBR destina-se a aplicações que não sejam de tempo real, incluindo aplicações tradicionais.
aplicativos de comunicação de computador, como transferência de arquivos e e-mail. Com o UBR, o controle de
congestionamento pode ser realizado em uma camada superior, de ponta a ponta.
Categoria de serviço de taxa de bits disponível
Com o ABR, as características de transferência fornecidas pela rede podem mudar

para o estabelecimento da conexão. Um mecanismo de controle de fluxo oferece vários tipos de feedback
para controlar a taxa de origem em resposta às mudanças nas condições da camada ATM. Este feedback é
transportado para a fonte através de células de controle chamadas células de gerenciamento de recursos (RM).
Um sistema final que adapta seu tráfego de acordo com o feedback deve experimentar um
CLR baixo e obter uma parcela justa da largura de banda disponível de acordo com uma política de alocação
específica da rede. O serviço ABR não requer limite de atraso ou atraso
variação experimentada por uma determinada conexão. O serviço ABR não se destina a oferecer suporte a aplicativos
em tempo real.
Ao estabelecer uma conexão ABR, um sistema final especifica para a rede ambos
uma largura de banda máxima necessária e uma largura de banda mínima utilizável. Estes são designados
como a taxa de pico de células (PCR) e a taxa de células mínima (MCR), respectivamente. O MCR pode
ser especificado como zero. A largura de banda disponível na rede pode variar, mas não se torna
menor que o MCR.
Categoria de serviço de taxa de quadros garantida
A categoria de serviço GFR foi adicionada à Especificação de Gerenciamento de Tráfego em 1999,

depois das demais categorias, definidas em 1996. A TFG é projetada para aplicações
que exigem uma garantia de taxa mínima e podem se beneficiar do acesso dinâmico à largura de banda adicional
disponível na rede. Dispositivos conectando LANs a uma rede ATM
pode usar GFR para transportar múltiplas conexões TCP/IP em um único circuito virtual GFR
(VC). A TFG não exige adesão a um protocolo de controle de fluxo. Sob condições de congestionamento, a rede
tenta descartar quadros completos em vez de descartar células sem referência aos limites do quadro.
Ao estabelecer uma conexão GFR, um sistema final especifica um PCR, MCR, MBS e
tamanho máximo do quadro (MFS). O MCR pode ser zero. O sistema final pode enviar células até
o PCR, mas a rede apenas se compromete a enviar células (em quadros completos não marcados) no
MCR. O tráfego além do MCR e MBS é entregue dentro dos limites disponíveis
recursos.
Especificações de QoS do Grupo de Trabalho de Serviços Integrados IETF

Em um ambiente IP, você pode usar o trabalho que o grupo de trabalho de Serviços Integrados da IETF
está realizando nos requisitos de QoS. Na RFC 2205, o grupo de trabalho descreve o Protocolo de
Reserva de Recursos (RSVP). Na RFC 2208, o grupo de trabalho fornece informações sobre a aplicabilidade
do RSVP e algumas diretrizes para sua implantação. As RFCs 2209 a 2216 também estão relacionadas
ao suporte de QoS na Internet e intranets.
RSVP é um protocolo de configuração usado por um host para solicitar qualidades específicas de serviço
da rede para fluxos de aplicativos específicos. O RSVP também é usado por roteadores para entregar
solicitações de QoS a outros roteadores (ou outros tipos de nós) ao longo dos caminhos de um fluxo.
As solicitações RSVP geralmente resultam na reserva de recursos em cada nó ao longo do caminho.
O RSVP implementa QoS para um fluxo de dados específico usando mecanismos chamados coletivamente
de controle de tráfego. Esses mecanismos incluem o seguinte:
ÿ Um classificador de pacotes que determina a classe de QoS (e talvez a rota) para cada pacote
ÿ Uma função de controle de admissão que determina se o nó tem disponibilidade suficiente

recursos capazes de fornecer a QoS solicitada
ÿ Um agendador de pacotes que determina quando pacotes específicos são encaminhados para atender
Requisitos de QoS de um fluxo
O RSVP trabalha com mecanismos nos sistemas finais para solicitar serviços. Para garantir que as
condições de QoS sejam atendidas, os clientes RSVP fornecem aos nós intermediários da rede uma
estimativa do tráfego de dados que irão gerar. Isto é feito com uma especificação de tráfego (TSpec)
e uma especificação de solicitação de serviço (RSpec), conforme descrito na RFC 2216.
Nota Um TSpec é uma descrição do padrão de tráfego para o qual o serviço está sendo solicitado.
O TSpec forma um lado de um “contrato” entre o fluxo de dados e o “provedor” de serviços.
Depois que uma solicitação de serviço é aceita, o provedor de serviços concorda em fornecer uma QoS
específica, desde que o tráfego do fluxo continue em conformidade com o TSpec.
Um RSpec é uma especificação de QoS que um fluxo deseja solicitar de um elemento de rede.
O conteúdo de um RSpec é específico para um serviço específico. O RSpec pode conter informações sobre a
largura de banda necessária para o fluxo, atraso máximo ou taxas de perda de pacotes.
RSVP fornece um recurso geral para reserva de recursos. O RSVP não define os diferentes tipos de serviços
que as aplicações podem solicitar. O grupo de trabalho de Serviços Integrados descreve os serviços
nas RFCs 2210 a 2216. Para uma compreensão completa da visão do grupo de trabalho sobre como os
serviços integrados devem ser tratados na Internet ou
uma intranet, você deve ler as RFCs. As seções a seguir fornecem uma visão geral dos dois principais tipos
de serviço: serviço de carga controlada e serviço garantido.
Serviço de carga controlada
O serviço de carga controlada é definido na RFC 2211 e fornece ao fluxo de dados do cliente uma QoS que
se aproxima muito da QoS que o mesmo fluxo receberia em uma rede descarregada. O controle de
admissão é aplicado às solicitações para garantir que o serviço solicitado seja recebido mesmo quando
a rede estiver sobrecarregada.
O serviço de carga controlada destina-se a aplicações altamente sensíveis a condições de sobrecarga,

como aplicações em tempo real. Esses aplicativos funcionam bem em redes descarregadas, mas
degradam rapidamente em redes sobrecarregadas. Um serviço, como o serviço de carga controlada, que
imita redes descarregadas, atende bem a esses tipos de aplicações.
Supondo que a rede esteja funcionando corretamente, um aplicativo que solicita serviço de carga controlada
pode assumir o seguinte:
ÿ Uma alta porcentagem de pacotes transmitidos será entregue com sucesso pela rede
trabalho para os nós finais receptores. (A porcentagem de pacotes não entregues com êxito deve se
aproximar da taxa básica de erro de pacote do meio de transmissão.)
ÿ O atraso de trânsito experimentado por uma alta porcentagem dos pacotes entregues não excederá muito
o atraso mínimo de transmissão experimentado por qualquer pacote entregue com sucesso. (Esse
atraso mínimo de trânsito inclui o atraso na velocidade da luz mais o tempo de processamento fixo em
roteadores e outros dispositivos de comunicação ao longo do caminho.)
O serviço de carga controlada não aceita nem utiliza valores-alvo específicos para parâmetros como
atraso ou perda. Em vez disso, a aceitação de uma solicitação de serviço de carga controlada implica
um compromisso por parte do nó da rede de fornecer ao solicitante um serviço aproximadamente equivalente
àquele fornecido ao tráfego não controlado (de melhor esforço) sob condições de carga leve.
Um nó da rede que aceita uma solicitação de serviço de carga controlada deve usar funções de controle de
admissão para garantir que recursos adequados estejam disponíveis para lidar com o nível de tráfego
solicitado, conforme definido pelo TSpec do solicitante. Os recursos incluem largura de banda do link, espaço
de buffer de porta do roteador ou switch e capacidade computacional do mecanismo de encaminhamento de pacotes.
Serviço Garantido
A RFC 2212 descreve o comportamento do nó da rede necessário para entregar um serviço

denominado serviço garantido , que garante características de largura de banda e atraso.
O serviço garantido fornece um limite firme para atrasos de enfileiramento de pacotes de ponta a ponta. (Por
empresa, a RFC significa que o limite pode ser provado matematicamente.) Ela não tenta minimizar o jitter e
não se preocupa com atrasos fixos, como atrasos de transmissão. (O atraso fixo é uma propriedade do
caminho escolhido, que é determinado pelo mecanismo de configuração, como RSVP.)
O serviço garantido garante que os pacotes chegarão dentro do prazo de entrega garantido e não
serão descartados devido a estouros de fila, desde que o tráfego do fluxo esteja de acordo com seu
TSpec. Uma série de nós de rede que implementam o RFC 2212 garante um nível de largura de
banda que, quando usado por um fluxo regulado, produz um serviço limitado por atraso sem perda
de fila (assumindo que não há falha nos componentes da rede ou alterações no roteamento durante a
vida do fluxo). ).
O serviço garantido destina-se a aplicações que necessitam de garantia de que um pacote chegará
no máximo um determinado tempo após ter sido transmitido pela sua origem. Por exemplo, alguns
aplicativos de reprodução de áudio e vídeo são intolerantes com a chegada de um pacote após o
tempo de reprodução esperado. Aplicações que possuem requisitos em tempo real também podem
usar serviço garantido.
Na RFC 2212, um fluxo é descrito usando um token bucket. Um token bucket tem uma taxa e um
tamanho de bucket. A taxa especifica a taxa de dados continuamente sustentável e o tamanho
especifica até que ponto a taxa de dados pode exceder o nível sustentável por curtos períodos de
tempo.
A taxa é medida em bytes de datagramas IP por segundo e pode variar de 1 byte por segundo até 40
TB por segundo (a largura de banda teórica máxima de um único fio de fibra). O tamanho do bucket
pode variar de 1 byte a 250 GB. A faixa de valores é intencionalmente grande para permitir larguras de
banda futuras. O intervalo não pretende implicar que um nó de rede deva suportar todo o intervalo.
A expectativa do grupo de trabalho de Serviços Integrados é que um desenvolvedor de software

possa usar as RFCs relevantes para desenvolver aplicativos inteligentes que possam definir com
precisão a taxa e o tamanho do bucket. Um aplicativo geralmente pode estimar com precisão o atraso
esperado na fila que o serviço garantido fornecerá. Se o atraso for maior que o esperado, o aplicativo
poderá modificar seu token bucket para obter um atraso menor.
Como projetista de rede, geralmente você não será solicitado a estimar taxas e tamanhos de token
bucket. Por outro lado, você deve reconhecer quais aplicativos precisam de serviço garantido e deve
ter alguma ideia de seu comportamento padrão e se uma reconfiguração do comportamento padrão é
possível. Se um aplicativo pode solicitar largura de banda de terabytes por segundo, você precisa
saber disso devido ao efeito negativo que isso pode ter em outros aplicativos.
Especificações de QoS do Grupo de Trabalho de Serviços Diferenciados da IETF

A IETF também possui um grupo de trabalho de Serviços Diferenciados que trabalha em
especificações relacionadas a QoS. RFC 2475, “Uma Arquitetura para Serviços Diferenciados”, define
uma arquitetura para implementar diferenciação de serviços escaláveis em uma rede ou na
Internet. Como o Capítulo 13, “Otimizando seu projeto de rede”, aborda com mais detalhes, os
pacotes IP podem ser marcados com um ponto de código de serviços diferenciados (DSCP) para
influenciar decisões de enfileiramento e descarte de pacotes para datagramas IP em uma
interface de saída de um roteador. A RFC 2475 refere-se a essas decisões como comportamentos
por salto (PHB). O DSCP pode ter 1 de 64 valores possíveis, cada um dos quais descreve um PHB,
embora em uma rede real você usaria no máximo 6 a 8 valores DSCP.
Embora o modelo de serviços integrados (RSVP), descrito na seção anterior, ofereça

granularidade mais fina, é menos escalável que o modelo de serviço diferenciado. O integrado
modelo de serviços permite que fontes e receptores troquem mensagens de sinalização que estabelecem
classificação de pacotes e estado de encaminhamento em cada roteador ao longo do caminho entre eles.
As informações de estado em cada roteador podem ser potencialmente grandes. A quantidade de informação
cresce proporcionalmente ao número de reservas simultâneas, que pode ser um número elevado em links de backbone de alta
capacidade. Serviços diferenciados não exigem RSVP e
pode ser utilizado para agregar serviços integrados/estado RSVP no núcleo de uma rede.
A RFC 2475 compara sua abordagem ao modelo de marcação de prioridade relativa usado por tais
Soluções de QoS como marcação de precedência IPv4 definida em RFC 791, IEEE 802.5 Token
Prioridade de anel e classes de tráfego IEEE 802.1p. Em comparação com essas soluções, a arquitectura de serviços
diferenciados especifica mais claramente o papel e a importância das fronteiras.
nós e condicionadores de tráfego, e usa um modelo de comportamento por salto que permite mais
comportamentos gerais de encaminhamento do que uma prioridade relativa. Um exemplo de prioridade relativa é
Precedência IPv4, que pode variar de rotina (os bits são definidos como 000) a alta (os bits
estão definidos como 111).
A RFC 2475 também compara sua abordagem ao modelo de marcação de serviço no tipo de IPv4.
Bits de serviço (ToS). Conforme definido na RFC 1349, os aplicativos podem usar os bits ToS para marcar cada
pacote com uma solicitação de um tipo de serviço (por exemplo, uma solicitação para minimizar atraso,
maximizar o rendimento, maximizar a confiabilidade ou minimizar custos). A intenção desses bits,
que nunca foram usados, era permitir que um roteador selecionasse caminhos de roteamento ou comportamentos de
encaminhamento que fossem adequadamente projetados para satisfazer a solicitação de serviço. O modelo de serviços
diferenciados, por outro lado, não descreve o uso do campo DSCP como entrada para
seleção de rota.
As marcações ToS definidas na RFC 1349 são genéricas e não correspondem aos serviços reais
que roteadores e provedores de serviços oferecem. Além disso, a solicitação de serviço está associada
com cada pacote individual, enquanto algumas semânticas de serviço podem depender do comportamento de
encaminhamento agregado de uma sequência de pacotes. O modelo de marcação ToS não acomoda facilmente o crescimento
no número e na variedade de serviços futuros (porque o espaço de pontos de código é pequeno) e envolve a configuração
do comportamento de encaminhamento para cada ToS em
cada nó da rede principal. O modelo de serviços diferenciados não apresenta esses problemas.
Requisitos de grau de serviço para aplicativos de voz

Em uma rede de voz, além da necessidade de QoS garantir atraso baixo e invariável
e baixa perda de pacotes, há também a necessidade do que os especialistas em voz chamam de serviço de alto nível (GoS).
GoS refere-se à fração de chamadas que são concluídas com sucesso em tempo hábil
moda. Taxa de conclusão de chamadas (CCR) é outro nome para o requisito.
Uma rede deve ter alta disponibilidade para suportar um alto GoS. Em uma rede não confiável,
O GoS é afetado negativamente quando as mensagens de configuração e desmontagem da chamada são perdidas. Um sinal perdido
para configuração de chamada pode resultar em uma tentativa de chamada malsucedida. Um sinal perdido para interrupção da chamada
pode fazer com que os recursos de voz fiquem indisponíveis para outras chamadas. As mensagens de configuração e
encerramento da chamada não são tão sensíveis ao atraso quanto o áudio enviado durante a chamada real, portanto, a retransmissão de
essas mensagens são permitidas, mas geralmente devem ser evitadas para não impactar os usuários.
(Os pacotes de voz em si não são retransmitidos porque não faz sentido. A voz não soaria bem se os
pacotes chegassem mais tarde do que deveriam.)
Para obter um GoS alto, você deve seguir as recomendações que serão apresentadas nos capítulos
subsequentes para usar componentes confiáveis (cabos, painéis de conexão, switches, roteadores e
assim por diante) e para criar redundância e failover na rede usando técnicas como roteamento
dinâmico. , o Spanning Tree Protocol (STP) para redes comutadas, o Hot Standby Router Protocol
(HSRP) e assim por diante. Conforme discutido no Capítulo 9, “Desenvolvendo estratégias de
gerenciamento de rede”, alcançar um GoS alto também requer a implementação de uma estratégia
de gerenciamento de rede que irá alertá-lo rapidamente sobre interrupções na rede e degradação do
serviço.
Documentando requisitos de QoS

Você deve trabalhar com seu cliente para classificar cada aplicativo de rede em uma categoria de
serviço. Depois de classificar o aplicativo, você deverá preencher a coluna Requisitos de
QoS na Tabela 4-4.
Se o seu cliente tiver aplicações que possam ser caracterizadas como necessitando de carga controlada
ou serviço garantido, você poderá usar esses termos ao preencher a coluna Requisitos de QoS. Se o
seu cliente planeja usar ATM, você pode usar a terminologia do Fórum ATM para categorias de serviço.
Mesmo que seu cliente não planeje usar QoS ATM ou IETF, você ainda poderá usar a terminologia do
Fórum ATM ou do grupo de trabalho de Serviços Integrados. Outra alternativa é simplesmente usar os
seguintes termos:
ÿ Inflexível: um termo genérico para descrever qualquer aplicação que tenha requisitos específicos de
largura de banda constante, atraso, variação de atraso, precisão e rendimento.
ÿ Flexível: Um termo genérico para descrever qualquer aplicação que simplesmente espera que a rede
faça o melhor esforço para atender aos requisitos. Muitas aplicações não multimídia possuem
requisitos de QoS flexíveis.
Para aplicações de voz, você deve fazer mais de uma entrada na Tabela 4-4 devido aos diferentes
requisitos para o fluxo de controle de chamadas e o fluxo de áudio. O fluxo de controle de chamadas,
usado para configurar e encerrar chamadas, não possui restrições de atraso estritas, mas exige alta
disponibilidade de rede e pode haver um requisito de GoS que deve ser especificado. Para o fluxo de voz,
a classificação de QoS deve ser listada usando o termo ATM CBR ou o termo IETF de serviço
garantido.
Ao documentar os requisitos de QoS para aplicativos, também é uma boa ideia informar aos seus
clientes que a QoS é uma proposta de ponta a ponta. Questões como o mapeamento de QoS baseado
em LAN (por exemplo, os bits 802.1p) para IP DSCP e bits experimentais (EXP) de Multiprotocol
Label Switching (MPLS) devem fazer parte da discussão de análise de requisitos de QoS. A discussão
detalhada das soluções de QoS acontecerá posteriormente no ciclo de design, conforme abordado no
Capítulo 13.
Lista de verificação de tráfego de rede

Você pode usar a seguinte lista de verificação de tráfego de rede para determinar se concluiu todas as
etapas para caracterizar o tráfego de rede:
ÿ Identifiquei as principais fontes e lojas de tráfego e documentei o fluxo de tráfego

entre eles.
ÿ Categorizei o fluxo de tráfego para cada aplicação como sendo terminal/host, cliente/servidor,
peer-to-peer, servidor/servidor ou computação distribuída.
ÿ Estimei os requisitos de largura de banda para cada aplicativo.
ÿ Estimei os requisitos de largura de banda para protocolos de roteamento.
ÿ Caracterizei o tráfego de rede em termos de taxas de broadcast/multicast, eficiência, tamanhos de

quadros, janelas e controle de fluxo e mecanismos de recuperação de erros.
ÿ Categorizei os requisitos de QoS de cada aplicativo.
ÿ Discuti os desafios associados à implementação de QoS de ponta a ponta e a necessidade de os

dispositivos em toda a rede fazerem a sua parte na implementação de estratégias de QoS.
Resumo
Este capítulo forneceu técnicas para analisar o tráfego de rede causado por aplicativos e protocolos.
O capítulo discutiu métodos para identificar fontes de tráfego e armazenamentos de dados, medir o
fluxo e a carga do tráfego, documentar o uso de aplicativos e protocolos e avaliar os requisitos de QoS.
1. Por que é importante explorar o comportamento do tráfego ao projetar uma rede? O que
podem surgir problemas se você não entender o comportamento do tráfego ao construir uma
nova rede ou atualizar uma rede?
2. Faça alguma pesquisa sobre ACK seletivo de TCP (SACK). Descubra se o sistema operacional
(SO) do seu computador o utiliza por padrão e, caso contrário, se existe um mecanismo para
configurar o SO para usá-lo.
3. Faça alguma pesquisa sobre o dimensionamento da janela TCP. Descubra se o sistema operacional do seu
computador o utiliza por padrão e, caso contrário, se existe um mecanismo para configurar o sistema operacional
para usá-lo.
4. Faça pesquisas sobre computação distribuída. Encontre um aplicativo que use computação
distribuída e escreva um parágrafo sobre o aplicativo.
5. Faça pesquisas sobre computação em nuvem. A computação em nuvem se enquadra nos tipos
de fluxo de tráfego discutidos neste livro (terminal/host, cliente/servidor, peer-to-peer, servidor/
servidor e computação distribuída) ou é um novo tipo de fluxo de tráfego?
Defenda sua resposta.
Cenário de projeto
Genome4U é um projeto de pesquisa científica em uma grande universidade dos Estados Unidos.
Genome4U iniciou recentemente um projeto em grande escala para sequenciar os genomas de 100.000 voluntários
com o objetivo de criar um conjunto de bancos de dados acessíveis ao público com dados genômicos, de
características e médicos humanos.
O fundador do projeto, um homem brilhante com muitos talentos e interesses, diz que as bases de dados
públicas fornecerão informações para a comunidade científica mundial em geral, não apenas para os interessados
em pesquisa médica. A Genome4U está tentando não pré-julgar como os dados serão usados porque pode
haver oportunidades para interconexões e correlações que os computadores podem descobrir e que as pessoas
podem ter perdido. O fundador prevê clusters de servidores que serão acessíveis a pesquisadores de todo o
mundo. As bases de dados serão utilizadas pelos utilizadores finais para estudar o seu próprio património genético,
com a ajuda dos seus médicos e conselheiros genéticos. Além disso, os dados serão utilizados por cientistas da
computação, matemáticos, físicos, cientistas sociais e outros pesquisadores.
O genoma de um único ser humano consiste em fitas complementares de DNA enroladas em uma dupla hélice.
As fitas contêm 6 bilhões de pares de bases de nucleotídeos conectados por ligações de hidrogênio. Para
armazenar os dados da pesquisa, é utilizado 1 byte de capacidade para cada par de bases.
Como resultado, são necessários 6 GB de capacidade de dados para armazenar a informação genética de
apenas uma pessoa. O projeto planeja usar clusters de armazenamento conectado à rede (NAS).
Além das informações genéticas, o projeto pedirá aos voluntários que forneçam informações detalhadas
sobre suas características para que os pesquisadores possam encontrar correlações entre características e
genes. Os voluntários também fornecerão seus registros médicos. O armazenamento será necessário para
esses conjuntos de dados e para os dados brutos de nucleotídeos.
Você foi contratado como consultor de design de rede para ajudar no projeto Genome4U.
1. Liste as principais comunidades de usuários.
2. Liste os principais armazenamentos de dados e as comunidades de usuários de cada armazenamento de dados.
3. Caracterizar o tráfego da rede em termos de fluxo, carga, comportamento e requisitos de QoS

comentários. Você não será capaz de caracterizar precisamente o tráfego, mas fornecer algumas teorias
sobre ele e documentar os tipos de testes que você realizaria para provar que suas teorias estão certas ou
erradas.
4. Que perguntas adicionais você faria ao fundador do Genome4U sobre este projeto?
Com quem além do fundador você conversaria e que perguntas você faria a eles?
Resumo da Parte I
Neste ponto do processo de projeto de rede, você identificou os aplicativos de rede de um cliente e os
requisitos técnicos para um projeto de rede que possa suportar os aplicativos. Você deve dar uma nova
olhada na Tabela 4-4, “Características de tráfego de aplicativos de rede” e na Tabela 2-2, “Requisitos técnicos
de aplicativos de rede”, para ter certeza.
certifique-se de entender os requisitos de aplicação do seu cliente. Se você quiser você pode
mescle essas duas tabelas para que haja uma linha para cada aplicativo.
Uma metodologia top-down para projeto de rede concentra-se em aplicações. Capítulo 1 coberto
identificando aplicativos e objetivos de negócios. O Capítulo 2 analisou metas técnicas para aplicativos e para a
rede como um todo, como disponibilidade, desempenho e capacidade de gerenciamento.
O Capítulo 3 concentrou-se em técnicas para caracterizar a rede existente, e
O Capítulo 4 concentrou-se novamente nos requisitos técnicos em termos das características do tráfego de rede
de aplicações e protocolos.
Este resumo encerra a Parte I, “Identificando as necessidades e metas do seu cliente”, que
apresentou a fase de análise de requisitos do projeto de rede. A análise de requisitos
fase é a fase mais importante no projeto de rede de cima para baixo. Obter uma compreensão sólida dos
requisitos do cliente ajuda a selecionar tecnologias que atendam aos critérios de sucesso do cliente.
Agora você deve ser capaz de analisar as metas comerciais e técnicas de um cliente e estar
pronto para começar a desenvolver um projeto de rede lógica e física. Parte II, “Rede Lógica
Design”, abrange o projeto de uma topologia de rede lógica, o desenvolvimento de uma camada de rede
modelo de endereçamento e nomenclatura, seleção de protocolos de comutação e roteamento e planejamento
estratégias de segurança e gerenciamento de rede.

Parte-1-Cisco Top-Down (PT)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Parte-1-Cisco Top-Down (PT)

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Design de rede de cima para baixo

ii Projeto de rede de cima para baixo

Design de rede de cima para baixo, terceira edição

Direitos autorais© 2011 Cisco Systems, Inc.

Indianápolis, IN 46240 EUA

Impresso nos Estados Unidos da América

Primeira impressão, agosto de 2010

Os dados de catalogação na publicação da Biblioteca do Congresso estão arquivados.

Aviso e isenção de responsabilidade

Reconhecimentos de marcas registradas

Vendas Corporativas e Governamentais

Agradecemos sua assistência.

Editor: Paul Boger Gerente, Certificação Global: Erik Ullanderson

Editora-chefe: Sandra Schroeder Editor de texto: Bill McManus

Editor sênior de desenvolvimento: Christopher Cleveland Designer do livro: Louisa Adair

Editora Sênior do Projeto: Tonya Simpson Revisor: Serviços de edição de apóstrofo

Assistente Editorial: Vanessa Evans

Composição: Mark Shirar

Indexador: Tim Wright

iv Design de rede de cima para baixo

Sobre os revisores técnicos

Gostaria de agradecer a outros profissionais de networking que me inspiraram ao longo dos

vi Design de rede de cima para baixo

Parte I Identificando as necessidades e objetivos do seu cliente 1

Capítulo 1 Analisando Metas e Restrições de Negócios 3

Capítulo 2 Analisando Metas Técnicas e Compensações 25

Capítulo 3 Caracterizando a Rede Existente 59

Capítulo 4 Caracterizando o Tráfego de Rede 87

parte II Projeto de Rede Lógica 117

Capítulo 5 Projetando uma Topologia de Rede 119

Capítulo 6 Projetando Modelos para Endereçamento e Numeração 167

Capítulo 7 Selecionando protocolos de comutação e roteamento 199

Capítulo 8 Desenvolvendo estratégias de segurança de rede 233

Capítulo 9 Desenvolvendo estratégias de gerenciamento de rede 263

Parte III Projeto de Rede Física 281

Capítulo 10 Selecionando Tecnologias e Dispositivos para Redes de Campus 283

Capítulo 11 Selecionando Tecnologias e Dispositivos para Redes Empresariais 319

Parte IV Testando, otimizando e documentando sua rede

Capítulo 12 Testando seu projeto de rede 353

Capítulo 13 Otimizando seu projeto de rede 367

Capítulo 14 Documentando seu projeto de rede 393

Parte I Identificando as necessidades e objetivos do seu cliente 1

Capítulo 1 Analisando Metas e Restrições de Negócios 3

Usando uma metodologia de design de rede de cima para baixo 3

Usando um processo de design de rede estruturada 5

Ciclos de Vida de Desenvolvimento de Sistemas 6

Planejar Projeto Implementar Operar Otimizar (PDIOO) Ciclo de Vida da Rede 7

Analisando Metas de Negócios 8

Trabalhando com seu cliente 8

Mudanças nas Redes Empresariais 10

Redes oferecem um serviço 11

A necessidade de apoiar usuários móveis 12

A importância da segurança e resiliência da rede 12

Metas de negócios típicas de design de rede 13

Identificando o Escopo de um Projeto de Design de Rede 14

Identificando os Aplicativos de Rede de um Cliente 16

Analisando Restrições de Negócios 19

Restrições Orçamentárias e de Pessoal 20

Capítulo 2 Analisando Metas Técnicas e Compensações 25

Expandindo o Acesso aos Dados 26

Especificando Requisitos de Disponibilidade 29