Ospf and Is Is em Portugues

Machine Translated by Google
Canal do Telegram: @IRFaraExam

OSPF e IS-IS
Do roteamento de estado de link
Princípios para Tecnologias


OSPF e IS-IS
Do roteamento de estado de link
Princípios para Tecnologias
Rui Valadas

Aviso de marca comercial: nomes de produtos ou empresas podem ser marcas comerciais ou marcas
registradas e são usados apenas para identificação e explicação sem a intenção de infringir.
Imprensa CRC
Grupo Taylor & Francis

6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
© 2019 por Taylor & Francis Group, LLC

CRC Press é uma marca do Taylor & Francis Group, uma empresa da Informa
Nenhuma reivindicação de obras originais do governo dos EUA
Impresso em papel sem ácido

Data da versão: 20181122
Livro padrão internacional número 13: 978-1-138-50455-4 (capa dura)
Este livro contém informações obtidas de fontes autênticas e altamente conceituadas. Esforços razoáveis foram
feitos para publicar dados e informações confiáveis, mas o autor e o editor não podem assumir a responsabilidade
pela validade de todos os materiais ou pelas consequências de seu uso. Os autores e editores tentaram rastrear
os detentores dos direitos autorais de todo o material reproduzido nesta publicação e pedem desculpas aos
detentores dos direitos autorais se a permissão para publicar neste formulário não foi obtida. Se algum material
protegido por direitos autorais não tiver sido reconhecido, por favor, escreva-nos e informe-nos para que
possamos corrigi-lo em qualquer reimpressão futura.
Exceto conforme permitido pela Lei de Direitos Autorais dos EUA, nenhuma parte deste livro pode ser reimpressa,
reproduzida, transmitida ou utilizada de qualquer forma por qualquer meio eletrônico, mecânico ou outro, agora
conhecido ou inventado no futuro, incluindo fotocópia, microfilmagem e gravação, ou em qualquer sistema de
armazenamento ou recuperação de informações, sem permissão por escrito dos editores.
Para obter permissão para fotocopiar ou usar material eletronicamente deste trabalho, acesse www. copyright.com
(http://www.copyright.com/) ou contate o Copyright Clearance Center, Inc.
(CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. A CCC é uma organização sem fins lucrativos
que fornece licenças e registros para uma variedade de usuários. Para as organizações que obtiveram uma
licença de fotocópia do CCC, um sistema de pagamento separado foi providenciado.
Visite o site da Taylor & Francis em http://

www.taylorandfrancis.com
e o site da CRC Press em

http://www.crcpress.com

à Matilde e à Teresa


viii Conteúdo
2.2.1.4 Identificadores dinâmicos de links compartilhados e designados

roteadores ....................................... ........ 56
2.2.1.5 Tipos de mudanças de rede e suas
consequências ................................................ 57
2.2.1.6 Reação ao particionamento de link compartilhado. . . . .
2.2.1.7 Reação a falhas do roteador. . . . . . . . . 58 . 60 .
2.2.1.8 O link-NR-compartilhado. . . . . . . . . . . . . 64 . 68
2.2.2 As informações de endereçamento interno da área. . . . . .
2.2.2.1 Separando informações topológicas e de
endereçamento 68 2.2.2.2 O prefixo interno da área NR .
70 2.2.2.3 Misturando informações topológicas. e.de. endereçamento
. . . . . .
75 2.2.3 As informações do link . 76 2.2.4 Interconexão com outros
domínios de roteamento. . . . . . . . . . . . . . . . . . .
. . . . . 78
2.2.4.1 Exportando e importando informações de endereçamento
80
2.2.4.2 O domínio-externo-prefixo-NR . . . . . . . . 82
2.2.5 Identificadores NR
2.2.6 Resumo da estrutura LSDB . . . . . . . . . . . . . 82 . 84
2.3 Do LSDB para a tabela de encaminhamento. . . . . . . . . . . . 85
2.3.1 Construindo o grafo da rede e associando os prefixos de destino
aos nós 85
2.3.2 Determinando caminhos mais curtos em um grafo - algoritmo
de Dijkstra 87
2.3.3 Determinando caminhos mais curtos para prefixos de destino e
reunindo informações de roteamento local . . . . . . . . . . 91
2.3.4 Rotas padrão 94
2.4 Divulgação e atualização de informações de roteamento. . . . . 95
2.4.1 Atualização de NR 96
2.4.2 Identificação de instâncias de NR . . . . . . . . . . . . . . 96 . 97
2.4.3 Cheias controladas . . . . . . . . . . . . . . . . . . .
2.4.4 Inundação confiável 98 2.4.5 A
disseminação de NRs . . . . . . . . . . . . . . . . 98
2.4.6 Exclusão de NRs 100 2.4.7 Mensagens
de controle . . . . . . . . . . . . .
. . . . . . . . 101
2.4.8 Problema envolvente . . . . . . . . . .
. . . . . . . . 102
2.4.9 Remoção de NRs desatualizadas . . . . . . . .
. . . . . . . . 103
2.5 Sincronização LSDB inicial. . . . . . . . . .
. . . . . . . . 104 .
2.5.1 Com quais vizinhos sincronizar? . . . . . . . . 104 .
2.5.2 Protocolo para troca de LSDBs. . . . . . . . . . . . 107 .
2.5.3 Lidando com NRs desatualizadas de autoria . . . . . . 108 .
2.6 Resumo das mensagens de controle . . . . . . . . . . . . . . . . . 112

Conteúdo ix
3 princípios de roteamento de estado de link multiárea 115 .

3.1 Estrutura de rede multiárea e roteamento entre áreas . . . . 116
3.1.1 Passos na comunicação de informações externas através de ar
fácil
3.1.2 Determinando caminhos mais curtos fim-a-fim. . . . . . . . 118 . 120

3.1.3 Área LSDB 3.1.4 121
Gráfico da sobreposição ABR . . . . . . . . . . . . . . . . 125 .
3.1.5 Mecanismos de sincronização. . . . . . . . . . . . . 126 .
3.2 Abordagens de roteamento entre áreas. . . . . . . . . . . . . . . . . 127 .
3.2.1 Abordagem de roteamento de estado de link. . . . . . . . . . . . . . 127 .
3.2.2 Atualizador de roteamento do vetor de distância . . . . . . . . . . . 129 . 131
3.2.3 Abordagem de roteamento por vetor de distância . . . . . . . . . . .
3.3 Ainda é possível ter um roteamento ótimo globalmente? . . . . . 134
3.4 Informações de endereçamento externo do domínio de publicidade . . . . . 135
III Tecnologias 139

4 Visão geral do OSPF e IS-IS 141
4.1 Um pouco de história ....................................... ....................... 141 4.2 Roteamento Link
State de hoje . . 141 4.3 A estrutura dos domínios . . . de . roteamento
. . . . . .OSPF . . . e .IS-IS
. . .. . 142
4.3.1 OSPF 144 4.3.2 IS-IS 144 4.3.3 Instâncias OSPFv3 . . . . .
. . . . . . . . . . . . . . . . . . . 145 .
4.4 Constantes arquitetônicas e parâmetros configuráveis. . . . 145 .
4.5 Objetivos e estrutura desta parte do livro. . . . . . . . 146
5 Estrutura LSDB de redes de área única OSPF e IS-IS 147 5.1 Elementos LSDB 148 5.2
Identificadores de roteador e link . . 149 5.2.1 Identificadores de roteador . . 149 5.2.2
Identificadores de links 5.3 Tipos de links 5.4.Estrutura
. . . . geral
. . .dos
. .elementos
. . . . .LSDB
. . .
. . . . . . . . . . . . . . . . . . .
151
. . . . . . . . . . 153 .
5.4.1 Cabeçalho LSA 155 155
5.4.2 Cabeçalho LSP 156
5.4.3 Registros IS-IS TLV 156
5.5 Informações topológicas e de endereçamento interno de domínio em
OSPFv2 157 5.5.1 Roteador-LSA 157 5.5.2 Rede-LSA 160 5.5.3 Fornecendo
informações topológicas e de endereçamento . . 160 5.6 Informações topológicas e
de endereçamento interno de domínio em SI
.
É ................................................. ......................................... 162 5.6.1 IS Vizinhos

TLV e Estendido Acessibilidade IS TLV 163

x Conteúdo
5.6.2 TLVs de acessibilidade de IP. . . . . . . . . . . . . . . . . . 165 .

5.6.3 Fornecimento de informações topológicas e de endereçamento. . 166 .
5.6.4 IS-IS TLVs adicionais. . . . . . . . . . . . . . . . . 168
5.7 Informações de endereçamento topológicas e de domínio interno em
OSPFv3 169
5.7.1 Roteador-LSA 170
5.7.2 Rede-LSA 5.7.3
Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . . 171 .
5.7.4 Fornecimento de informações topológicas e de endereçamento. . 171 .
5.8 Informações de endereçamento externo ao domínio. . . . . . . . . . . 173 .
5.8.1 OSPF 174 175
5.8.2 IS-IS 175
5.8.3 Métricas OSPF tipo E . . . . . . . . . . . . . . . . . . 176
5.9 Informações do link ....................................... ...................... 177
6 Mecanismos de Sincronização OSPF e IS-IS 179

6.1 Pacotes de controle ....................................... ...................... 179 6.1.1 Tipos de
pacotes ...................... ...................................... 179 6.1.2
Encapsulamento ..... ................................................ ....... 184 6.1.3 Endereços
multicast usados em links compartilhados . . 184 6.1.4 Regras . de
. . aceitação
. . . da
interface . . 184 6.2 Protocolo Hello 6.2.1 Formato . . . .do. pacote
. . . .6.2.2
. . Vivência
. . . dos
relacionamentos . 185
186
. . . . . . . . . . . . . . . . 187
6.2.3 Adjacências
6.2.3.1 Bidirecionalidade dos relacionamentos . . . . . . . 188 .
6.2.3.2 Adjacências OSPF . . . . . . . . . . . . . . 189 .
6.2.3.3 Adjacências IS-IS . . . . . . . . . . . . . . . 189 .
6.2.4 Máquina de estado do protocolo OSPF Hello. . . . . . . . . . 189 .
6.2.5 Máquina de estado do protocolo IS-IS Hello . . . . . . . . . . 190 . 192
6.2.6 Bidirecionalidade de relacionamentos em links ponto a ponto IS-
IS 6.2.7
Respostas HELLO imediatas . . . . . . . . . . . . . . . 192 .
6.3 Eleição do roteador designado. . . . . . . . . . . . . . . . . . 194 . 195
6.3.1 Suporte a pacotes 195
6.3.2 Processo de eleição OSPF . . . . . . . . . . . . . . . . . . 196
6.3.2.1 A máquina de estado da interface. . . . . . . . . . 196
. . . . . . . . . . . . .. 198
6.3.2.2 Algoritmo de eleição. . 197 6.3.2.3 Casos especiais . 6.3.2.4
. . . . . . . . . . . . . .
Procedimento para definição do DR e BDR. . 200 6.3.2.5 Eventos . .
desencadeados pela eleição do DR . . 200 6.3.3 Processo eleitoral
IS-IS . . 200 6.3.3.1 Algoritmo de eleição . . 201 6.3.3.2 Eventos . . .
. . . .
desencadeados pela eleição DIS . . 201 6.4 Procedimento de. . . . . . . . . . . . .
. . . . . .
inundação ....................................... ................ 202. . . . . . .
. . .

Conteúdo XI
6.4.1 Inundação em OSPF ....................................... .......... 203 6.4.2 Inundações

em IS-IS . . 206 6.4.3 Tempo de .guarda
. . . entre
. . . as . .transmissões
. . . . . . LSA . . .e LSP
. ..
207 .
6.5 Procedimento de 208
. . . .. . . . . . . . . . . . . . . 208 .
atualização 6.5.1 Atributos de atualização
6.5.2 Determinando qual LSA e LSP é mais recente. . . . . 210 .
6.5.3 Exclusão de LSAs e LSPs. . . . . . . . . . . . . . 212 .
6.5.4 Ações na recepção de LSAs e LSPs. . . . . 213
6.5.4.1 O LSA/LSP de entrada não é auto-originado. . 214
6.5.4.2 O LSA/LSP de entrada é auto-criado. . . . 214
6.5.5 Geração não solicitada de LSAs e LSPs. . . . . . . 215
6.5.6 Wrap around de SNs 6.5.7 216
Expiração de idade de LSAs e LSPs . . . . . . . . . . . 216
6.5.8 Proteção contra corrupção de LSAs e LSPs. . . 217 .
6.6 Sincronização LSDB inicial. . . . . . . . . . . . . . . . . 217
6.6.1 OSPF 218
6.6.1.1 Processo de descrição do banco de dados. . .. 219
. . 6.6.1.2
. . .
Processo de carregamento . . 220 .6.6.1.3 . . . Lidando
. . . . com . . .LSAs
. . .auto-
originados desatualizados . 221 6.6.1.4 Exemplo 222 6.6.2 IS-IS 225
. . . .Links
6.6.2.1 Enlaces ponto a ponto . . 225 6.6.2.2 . . .compartilhados
. . . . . ..
226 6.6.2.3 Lidando com LSPs. auto-criados
. . . . . . desatualizados
. . . . . . . . . .227
6.6.2.4 Exemplos . . 227 6.7 Origem e exclusão de informações de
roteamento. . 230 231 233. . . . . . . . . . . . . . . . . .
. . . . .
6.7.1 OSPF
6.7.2 IS-IS
7 Redes Hierárquicas OSPF e IS-IS

7.1 Comparação das estruturas hierárquicas OSPF e IS-IS . . . 235 .
7.2 DVR em redes hierárquicas . . . . . . . . . . . . . . . . . 236 .
7.3 Estrutura LSDB e vetores de distância. . . . . . . . . . . . 238 . 239
7.3.1 OSPF 240
7.3.2 IS-IS 242
7.4 Restrições na seleção do caminho mais curto . . . . . . . . . . . . . 245
IV Estudos de caso 247
8 Ferramentas e Configurações 249

8.1 Acostumando-se com o GNS3 ....................................... .............. 250 8.2
. . . . . . . . .ao. Cisco
Acostumando-se ao Wireshark . . 252 8.3 Acostumando-se . . . IOS. . ... 253
. . 253 .
254 . . . . . . . . . . . . . . . . .
8.3.1 Alguns antecedentes do IOS. . . . . . . . . . . . . . . . .
8.3.2 Configuração de interfaces e endereços IP. . . . .

xii Conteúdo
8.3.3 Recursos adicionais do IOS . . . . . . . . . . . . . . . . . 257 .

8.4 Configuração básica de roteamento. . . . . . . . . . . . . . . . . . 259
8.4.1 OSPFv2 260
8.4.2 OSPFv3 260
8.4.3 IPv4 IS-IS 260
8.4.4 IPv6 IS-IS 8.5 262
Lista de comandos IOS 262
9 Experimentos em tabelas de encaminhamento e LSDB 9.1

Rotas e tabelas de encaminhamento . . . . . . . . . . . . . . . . . 267 .
9.1.1 Tabelas de encaminhamento IPv4 obtidas com IPv4 IS-IS . . 267 .
9.1.2 Tabelas de encaminhamento IPv4 obtidas com OSPFv2 . . . 268 . 270
9.1.3 Tabelas de encaminhamento IPv6 . . . . . . . . . . . . . . . . . . 271
9.1.4 Mudando os caminhos . . . . . . . . . . . . . . . . . . . 273 .
9.1.5 Prevalência de rotas conectadas diretamente . . . . . . . 273 .
9.2 Estrutura LSDB de redes de área única. . . . . . . . . . . 274
9.2.1 Estrutura LSDB sem endereçamento externo ao domínio
informações 274
9.2.1.1 OSPFv2 275
9.2.1.2 OSPFv3
9.2.1.3 Recursos específicos do OSPFv3 . . . . . . . . . . 278 .
9.2.1.4 IS-IS para IPv4 . . . . . . . . . . . . . . . . 284 .
9.2.1.5 IS-IS para IPv6 . . . . . . . . . . . . . . . . 288 .
9.2.1.6 Adjacências ponto a ponto em links compartilhados . 291 .
9.2.1.7 Uso de tags locais para identificar links . . . . . . 292 .
9.2.2 Estrutura LSDB quando conectado a outro AS . . . 292 .
9.2.2.1 OSPFv2 295
9.2.2.2 IPv4 IS-IS 296
297 9.2.3 Estrutura LSDB com rotas padrão . . 300 9.2.3.1. . . OSPFv2
. . . . 301
.
9.2.3.2 IPv4 IS-IS 301 9.2.4 Métricas OSPF E-type . . 302 9.2.5
Estrutura OSPF LSDB quando conectado ao domínio RIP 309
. . . . . . . . . . . . . . . .
10 Experimentos sobre Mecanismos de Sincronização 10.1 313

Protocolo Hello ....................................... ............................ 313 10.1.1 Transmissão
periódica de pacotes HELLO . . 314 10.1.2 Detecção de falhas . . . do
. .roteador
. ..
317 10.1.3 Verificando relacionamentos bidirecionais . . . . . no . . OSPF
. . . .. . 319
. . 10.1.4
Verificando relacionamentos bidirecionais em links ponto a ponto. IS-IS . . 10.1.5
Adjacências OSPF .
. . . . . . . . . . . . . . . . . . 322 .
10.1.6 Adjacências IS-IS . . . . . . . . . . . . . . . . . . . . 323 .
10.2 Eleição do roteador designado . . . . . . . . . . . . . . . . . . 324 .
327 10.2.1 OSPF ....................................... ......................... 327

Conteúdo xiii
10.2.1.1 Partida a frio .............................. ......... 327 10.2.1.2 Partida a

frio com prioridades do roteador . . 332 10.2.1.3 Roteador . .
. . . juntando link
quando DR e BDR já eleitos
10.2.1.4 Apenas um roteador iniciado no link. . . . . . . 334 . 335

10.2.1.5 Falha DR 336
10.2.2 IS-IS 339
10.2.2.1 Partida a frio 340
10.2.2.2 Mudança de DIS . . . . . . . . . . . . . . . . . 343
10.2.2.3 Falha DIS 10.3 346
Procedimento de inundação 348
10.3.1 Links compartilhados OSPF .. . . . . . . . . . . . . . . . . . . 348
10.3.2 Enlaces ponto a ponto OSPF. . . . . . . . . . . . . . . . 351
10.3.3 Links compartilhados IS-IS . . . . . . . . . . . . . . . . . . . . . 351
10.3.4 Enlaces ponto a ponto IS-IS. . . . . . . . . . . . . . . . 354
10.4 Procedimento de 356
exclusão 10.4.1 356
OSPF 10.4.2 IS-IS 357
10.5 Sincronização LSDB inicial. . . . . . . . . . . . . . . . . . 358
10.5.1 OSPF 359
10.5.2 IS-IS 364
10.5.2.1 Links compartilhados.. . .364
. . 10.5.2.2
. . . . Enlaces
. . . . ponto
. . . a. ponto . .
. . . . desatualizados
366 10.5.2.3 Lidando com LSPs auto-criados . . . . . . . .. 368
11 Experimentos em Redes Hierárquicas 373

11.1 Estrutura LSDB ........................................ ......................... 373 11.1.1
Configurações do roteador . . 373 11.1.2 . .Estrutura
. . . . OSPF . . . .LSDB . . . . .. 376
. . 11.1.3
Estrutura IS-IS LSDB . . 380 . 383 . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
11.2 Restrições na seleção do caminho mais curto. . . . . . . . . . . .
Glossário 387
Referências 397
Índice 401


Prefácio
Link State Routing (LSR) é um tópico de rede que tem merecido muita atenção em artigos
científicos, padrões e livros didáticos. Existem livros volumosos dedicados a tecnologias LSR
específicas, como OSPF (Open Shortest Path First) e IS-IS (Intermediate System to Intermediate
System).
[11, 15, 31, 35, 37, 50]. Aprendemos muito com esses livros, mas eles são principalmente
direcionados à explicação de muitos detalhes tecnológicos de OSPF e IS-IS - certamente algo
que os gerentes de rede precisam estar cientes.
O assunto de LSR é frequentemente considerado complexo. No entanto, acreditamos que
é muito mais simples do que parece e que a chave para sua compreensão é a correta
segregação dos mecanismos fundamentais e estruturas de dados dos protocolos LSR, ou seja,
os princípios que norteiam o seu funcionamento. Uma vez que esses princípios são dominados,
é muito mais fácil compreender as tecnologias específicas e navegar em suas especificações
densas, bem como ser crítico sobre algumas das opções tomadas.
O livro visa ser uma referência completa sobre OSPF e IS-IS, do ponto de vista
metodológico. Fundamentamos a aprendizagem nos princípios do LSR, explicando os
mecanismos e estruturas de dados fundamentais ao seu funcionamento e comuns às várias
tecnologias. Em seguida, descrevemos OSPF e IS-IS em detalhes, abrangendo suas versões
IPv4 e IPv6.
O nível de detalhamento é suficiente para especialistas que precisam configurar, gerenciar e
planejar redes suportadas nessas tecnologias. Por fim, complementamos o livro com a
discussão de um grande conjunto de experimentos, ilustrando os vários recursos do OSPF e
do IS-IS. Nossos experimentos abrangem não apenas a visão estática das redes—enquanto
elas permanecem estáveis—, mas também sua dinâmica—enquanto convergem após alguma
perturbação (por exemplo, uma configuração de rede ou uma falha). No entanto, não somos
exaustivos em cobrir as muitas extensões de OSPF e IS-IS, uma vez que novas continuam
aparecendo rapidamente e não estão mudando a natureza fundamental das tecnologias.
Compreender os princípios por trás das tecnologias torna o processo de aprendizagem

mais fácil e sólido. Além disso, ajuda a descobrir as diferenças e semelhanças de OSPF e IS-
IS e expor seus recursos mais fortes e mais fracos. As experiências abordadas no livro ajudam
a adquirir a capacidade de solucionar problemas de redes, uma habilidade importante exigida
dos profissionais de redes de computadores. Essa habilidade também é alcançada de forma
mais eficaz quando o entendimento do assunto LSR vai além das especificidades de
tecnologias particulares.
Curiosamente, a Área de Roteamento da Força-Tarefa de Engenharia da Internet
xv

XVI Prefácio
(IETF), que define os padrões da Internet para protocolos de roteamento, decidiu fundir os
grupos de trabalho OSPF e IS-IS em um único grupo chamado Roteamento de estado de link.
Isso está muito de acordo com o espírito deste livro.
Visão geral do roteamento de estado de link Nos
protocolos LSR, os roteadores trocam informações de roteamento para que cada roteador
construa e mantenha individualmente uma visão global da rede. Esta visão global inclui dois
aspectos: (i) a informação topológica (ou mapa da rede), ou seja, uma descrição dos
roteadores e links entre roteadores, e (ii) a informação de endereçamento, ou seja, os prefixos
de endereço (IPv4 ou IPv6) atribuídos ao roteadores e links. A visão global é obtida de forma
distribuída: cada roteador divulga para todos os outros informações sobre sua visão local da
rede, descrevendo a si mesmo e seus links (a informação topológica local), e os prefixos de
endereço atribuídos a ele e seus links (o informações de endereçamento local). Em seguida,
cada roteador reúne autonomamente as informações de roteamento recebidas de todos os
outros roteadores, bem como as suas próprias, para construir a visão global da rede, que
armazena em um banco de dados local chamado Link State Database (LSDB). As tabelas
de encaminhamento são obtidas dessa visão global executando, em cada roteador, um
algoritmo de caminho mais curto centralizado, geralmente o algoritmo de Dijkstra. Grande
parte do esforço nos protocolos LSR é garantir que a visão global permaneça a mesma em
todos os roteadores, para evitar inconsistências nas tabelas de proteção. Esta é a razão pela
qual esses protocolos são às vezes chamados de protocolos de banco de dados distribuídos
replicados [35], uma designação que certamente é perspicaz. Os mecanismos necessários
para manter a visão global consistente da rede são geralmente chamados de mecanismos de
sincronização.
A necessidade de armazenar a visualização completa da rede aumenta as preocupações

de escalabilidade, pois os roteadores podem não ter recursos de memória quando as redes
se tornam grandes. Para resolver esse problema, os protocolos LSR incluem a possibilidade
de estruturar uma rede em várias sub-redes menores chamadas áreas, de modo que um
roteador precise apenas manter a visão completa da rede de sua própria área. No entanto,
essa possibilidade requer várias melhorias no protocolo LSR básico, por exemplo, a
necessidade de introduzir um protocolo de roteamento entre áreas.
OSPF e IS-IS são atualmente as principais tecnologias implementando LSR.
Eles são suportados por praticamente todos os fornecedores de equipamentos de rede e
amplamente implantados por operadoras de rede em todo o mundo. Eles formam uma parte
importante do esqueleto da Internet atual e vieram para ficar. Suas especificações continuam
sendo constantemente atualizadas e aprimoradas pelo IETF.
Tanto o OSPF quanto o IS-IS incluem uma restrição na forma como as redes multiárea
podem ser estruturadas. Especificamente, a topologia da rede é restrita a uma hierarquia de
dois níveis, com apenas uma área no nível superior, e onde a comunicação entre áreas de
nível inferior só pode ser feita através da superior. Devido à sua estrutura hierárquica, as
redes multiárea OSPF e IS-IS são geralmente chamadas de redes hierárquicas.

Prefácio xvii
Estrutura do livro
O livro está estruturado em quatro partes: Introdução (Parte I), Princípios (Parte II),
Tecnologias (Parte III) e Estudos de Caso (Parte IV).
• Introdução - A Introdução inclui o Capítulo 1, que revisa as noções básicas de

roteamento e endereçamento. Esta parte pode ser ignorada por leitores
familiarizados com redes TCP/IP. No entanto, você pode encontrar aqui
abordagens menos tradicionais para alguns assuntos. Dê uma olhada!
• Princípios - A parte Princípios inclui dois capítulos abordando os princípios da

LSR. O Capítulo 2 concentra-se em redes de área única e o Capítulo 3 em redes
multiárea. Esses capítulos são, provavelmente, o principal valor agregado do livro.
• Technologies - A parte Technologies descreve as versões IPv4 e IPv6 de OSPF

e IS-IS. O Capítulo 4 fornece uma breve visão geral das tecnologias. Os próximos
capítulos discutem a estrutura LSDB de redes de área única (Capítulo 5), os
mecanismos de sincronização de bancos de dados distribuídos (Capítulo 6) e as
extensões necessárias para o suporte de redes hierárquicas (Capítulo 7).
• Estudos de caso - A parte de Estudos de caso apresenta e discute vários

experimentos projetados para ilustrar os vários recursos de OSPF e IS-IS.
O Capítulo 8 apresenta as ferramentas utilizadas nos experimentos e explica
suas configurações básicas. Os próximos capítulos discutem experimentos
relacionados às tabelas de encaminhamento e à estrutura LSDB (Capítulo 9),
aos mecanismos de sincronização (Capítulo 10) e às redes hierárquicas (Capítulo 11).
Incluímos no final do livro um glossário explicando os principais conceitos e as

abreviaturas.
Como ler o livro

Este livro pode ser lido de várias maneiras diferentes. Conforme mencionado acima,
você pode pular o Capítulo 1 se estiver familiarizado com os fundamentos de
roteamento e endereçamento. Você também pode ler primeiro os capítulos
relacionados a redes de área única e só posteriormente os relacionados a redes
multiárea. Isso significa ler primeiro o Capítulo 2, sobre princípios, e os Capítulos 4,
5 e 6, sobre a estrutura do LSDB e os mecanismos de sincronização. Por fim, se
você já tem experiência com OSPF e IS-IS, pode ir direto para a parte de Estudos de
Caso, onde poderá encontrar alguns experimentos interessantes. Em particular, os
experimentos relacionados aos mecanismos de sincronização não são comumente
encontrados na literatura.

xviii Prefácio
Uma palavra sobre nomenclatura
Uma palavra é devida sobre nomenclatura. Uma das barreiras mais difíceis ao tentar
comparar OSPF e IS-IS são os nomes dados aos vários elementos do protocolo, que
raramente coincidem. Poderíamos ter adotado uma das terminologias ao discutir os
princípios do LSR. No entanto, decidimos criar uma terminologia própria, para evitar
o favorecimento de uma tecnologia em detrimento da outra e tornar a nomenclatura
o mais expressiva possível. Fornecemos as correspondências entre as várias
nomenclaturas ao longo do livro. Quando necessário, nossa nomenclatura será
chamada de genérica.
Público
O livro deve ser útil para professores, alunos e profissionais de redes de computadores.
Ele fornece um caminho para aprender e ensinar com eficiência o assunto de LSR, o
que chama a atenção para seus aspectos principais. Além disso, fornecemos uma
descrição abrangente de OSPF e IS-IS, principais tecnologias LSR, com detalhes
suficientes para apoiar os profissionais que precisam configurar, gerenciar e planejar
esse tipo de rede. O livro também inclui um grande conjunto de experimentos que (i)
podem ser facilmente reproduzidos usando um computador pessoal padrão e (ii)
podem apoiar o processo de aprendizado em sala de aula ou por alunos individuais
tentando dominar OSPF e IS-IS.
suplementos
Os arquivos contendo as configurações dos experimentos e as capturas do Wire

shark estão disponíveis no site do livro CRC. Visite https://www.crcpress.com/
9781138504554.
Nós gostaríamos de ouvir de você

Seus comentários, sugestões e correções são muito bem-vindos. Por favor, envie
as que tiver para [email protected].
Agradecimentos
Primeiramente, gostaria de agradecer ao meu amigo e colega José Brázio, do

Instituto de Telecomunicações. Sua contribuição para este livro foi inestimável.
Obrigado pelo cuidado na revisão das várias versões do manuscrito, pela precisão
de seus comentários e sugestões e por nunca me deixar congelar em uma má ideia.
Este livro é certamente muito melhor devido à sua ajuda! Também gostaria de
agradecer a João Sobrinho, do Instituto de Telecomunicações, por revisar as primeiras
versões do manuscrito.
Agradeço também o apoio do Instituto Superior Técnico da

Prefácio xix
Universidade de Lisboa (minha Universidade) e Instituto de Telecomunicações (meu

Instituto de Pesquisa).
Por fim, gostaria de agradecer a minha esposa Rosário pelo amor e apoio: sem
você eu não poderia ter realizado este sonho.


Parte I
Introdução


1
Roteamento e Endereçamento
1.1 Os elementos físicos das redes de computadores

As redes de computadores incluem hoje uma miríade de diferentes elementos físicos, desempenhando
diferentes funções. A Figura 1.1 mostra um exemplo relativamente simples, mas rico. Do ponto de vista
do roteamento, precisamos considerar três tipos de elementos físicos: dispositivos finais, equipamentos
de comutação e meios de comunicação.
Os dispositivos finais e equipamentos de comutação se conectam ao meio de comunicação por

meio de interfaces. As interfaces possuem hardware distinto para transmitir e receber tráfego; a interface
de entrada é a parte da interface que recebe o tráfego e a interface de saída é aquela que transmite o
tráfego.
Os dispositivos finais, geralmente chamados de hosts, são as fontes e os coletores de informações.
Na Internet de hoje, eles variam de grandes servidores a minúsculos sensores e atuadores.
A figura mostra quatro tipos de hosts: servidores, computadores desktop, laptops e tablets.
As informações trocadas entre os hosts são transportadas em pedaços de bits chamados pacotes.
Os pacotes são encaminhados da origem ao destino através da infraestrutura de rede, que é formada
por uma malha de equipamentos de comutação e meios físicos de comunicação. O equipamento de
comutação transfere pacotes das interfaces de entrada para as de saída de acordo com as tabelas de
encaminhamento e usando o modo de operação armazenar e encaminhar. A operação store-and-forward
significa que um pacote só começa a ser transmitido pela interface de saída, após ter sido totalmente
recebido pela interface de entrada. Os equipamentos de comutação geralmente são diferenciados com
base no tipo de informação de endereçamento usada para tomar decisões de encaminhamento. A
figura mostra dois tipos de equipamentos de comutação: roteadores IP e switches Ethernet.
Os meios físicos de comunicação fornecem as conexões físicas entre os equipamentos (hosts ou

equipamentos de comutação) e incluem fibras ópticas, cabos coaxiais e de par trançado, bem como
vários tipos de meios sem fio.
As tecnologias abordadas neste livro abordam o problema de “roteamento entre roteadores IP”.
Como será discutido mais adiante, neste caso, as conexões entre roteadores vizinhos podem ser
ocultadas de seus detalhes, ou seja, a estrutura específica dessas conexões, sejam links físicos
individuais ou redes de switches Ethernet, é de pouca preocupação.

4 1 Roteamento e Endereçamento
link E1
servidor
interruptor
Ethernet
Área de Trabalho
tábua
roteador IP
computador portátil
FIGURA 1.1: Os elementos físicos das redes de computadores.
Do ponto de vista do roteamento, as redes de computadores compreendem três tipos

de elementos físicos: dispositivos finais (hosts), equipamentos de comutação e meios
de comunicação.
1.2 Nomes, endereços e caminhos

Suponha que você deseja obter um serviço da rede, por exemplo, uma busca por alguma
página da Web. Quais entidades da rede precisam ser nomeadas para esse fim e que tipos de
associações precisam ser estabelecidas entre esses nomes é uma questão importante e, de
forma alguma, simples. Apresentaremos aqui a visão de Saltzer sobre este problema [47], que
se baseia no trabalho anterior de Shoch [49]; O trabalho de Day também é uma contribuição
significativa para a compreensão desse problema [10]. Ressaltamos que este é um modelo
conceitual, não vinculado à arquitetura atual da Internet.
Nomes, espaços de nome e escopos de nome Uma entidade de rede é referenciada por meio
de um nome. Os nomes podem ser caracterizados por seu espaço e escopo. O espaço é o
conjunto de nomes de onde são retirados todos os nomes de uma determinada coleção de
entidades. O escopo é o conjunto de entidades às quais o nome se aplica.
Obtenção de um serviço de rede As entidades envolvidas na obtenção de um serviço

1.2 Nomes, endereços e caminhos 5
FIGURA 1.2: Visão de Saltzer sobre como obter um serviço de rede.
da rede são (i) serviços (ou aplicativos), (ii) nós (hosts ou equipamentos de comutação), (iii)
interfaces de rede (chamadas de pontos de conexão em [47]) e caminhos. Os nomes dados
às interfaces de rede são geralmente chamados de endereços, e manteremos essa
nomenclatura. Este processo será explicado com a ajuda da Figura 1.2.
• Um serviço pode ser executado em um ou mais nós e pode precisar se mover entre os
nós sem perder sua identidade como serviço. Deve haver alguma maneira de encontrar
o nó que executa o serviço. Isso pode ser fornecido por meio de um serviço de resolução
de nomes, vinculando o nome do serviço ao nome do nó.
• Um nó pode se conectar a uma ou mais interfaces de rede (ou pontos de conexão) e

pode precisar passar de uma interface para outra sem perder sua identidade como nó.
Por exemplo, um usuário com um laptop pode percorrer uma rede e conectar-se a
diferentes pontos da rede. Deve haver alguma maneira de encontrar a interface de rede
onde o nó está conectado e, novamente, isso pode ser fornecido por meio de um serviço
de resolução de nomes, agora vinculando o nome do nó ao endereço da interface.
• Finalmente, um par de interfaces de rede pode ser conectado por um ou mais caminhos,
e esses caminhos podem precisar mudar ao longo do tempo. Encontrar caminhos dentro
da rede é o papel da função de roteamento.
Day observou mais tarde que o nó deve ser pensado como uma entidade lógica, na
verdade o ponto final de todos os caminhos de todos os processos de aplicação, e que os
endereços de interface têm apenas significado local [10].
Função de roteamento O objetivo da função de roteamento é encontrar caminhos dentro da
rede. Um caminho é uma sequência de interfaces de nós (interfaces de hosts ou equipamentos
de comutação) que levam a algum nó. Observe que, devido à possibilidade de links paralelos
entre os nós, um caminho não é totalmente descrito pelos nomes dos nós; os endereços de
interface também são necessários. No entanto, os endereços de interface têm apenas
significado local, ou seja, eles precisam ser únicos dentro de um nó. O roteamento é
implementado localmente em cada nó usando tabelas de encaminhamento, que indicam a
próxima interface no caminho para cada destino (a interface do próximo salto).
Exemplo A Figura 1.3 fornece um exemplo. A rede inclui quatro roteadores

R2
i1 i3 i1
i3 i2
i2
i1 i1 i3 i1
i4 i3
i2 R4
R1
H1 i1 H2
i2
R3
FIGURA 1.3: Caminhos e tabelas de encaminhamento.
e dois hospedeiros. Os nomes de hosts, roteadores e interfaces são obtidos de espaços de nome
separados, prefixados pelas letras “H”, “R” e “i”, respectivamente.
Existem dois enlaces paralelos entre R3 e R4. Suponha que H1 precise entrar em contato com um
serviço em execução em H2. Dado o nome do serviço, o nome do host (H2) e o nome da interface
(i1-H2) são encontrados usando um processo de resolução de nomes e o caminho é determinado
por meio da função de roteamento. O caminho de H1 a H2 indicado na figura é descrito como a
sequência i1-R1 ÿ i1-R2 ÿ i4-R3 ÿ i3-R4 ÿ i1-H2. As tabelas de encaminhamento indicam a próxima
interface no caminho para H2. Por exemplo, a tabela de encaminhamento de R3 indica que a
próxima interface no caminho para H2 é i3-R4.
Por mais simples que seja, esse modelo tem sido objeto de controvérsia e não está totalmente
implementado na atual arquitetura da Internet [10, 16, 47]. De fato, a Internet não possui nomes
de nós, e alguns autores até argumentam que ela possui apenas endereços de interface e
caminhos. Na verdade, as interfaces são nomeadas usando os endereços IP conhecidos (e às
vezes usando também endereços MAC).
Quais entidades de rede precisam ser nomeadas para fins de roteamento e quais tipos
de associações precisam ser estabelecidas entre esses nomes é uma questão importante
sujeita a controvérsia. Em princípio, os serviços, os nós (hosts ou equipamentos de
comutação) e as interfaces de rede devem ser nomeados; além disso, os caminhos são
sequências de interfaces que levam a algum nó. A função de roteamento determina os
caminhos dentro da rede e é implementada localmente em cada nó por meio de tabelas
de encaminhamento, que indicam a próxima interface no caminho para cada destino.
Nas arquiteturas de endereçamento da Internet não há nomes de nós e as interfaces

são nomeadas usando endereços IP.
Distinção entre encaminhamento e roteamento É importante fazer uma distinção clara entre os
termos encaminhamento e roteamento: encaminhamento refere-se

1.3 Arquitetura de endereçamento da Internet 7
para a decisão local em um nó de determinar a próxima interface no caminho para um destino,

enquanto o roteamento se refere ao processo global de encontrar um caminho fim-a-fim de uma
origem para um destino.
Protocolos de roteamento Os caminhos podem ser calculados de forma centralizada, ou seja, com
conhecimento a priori sobre a topologia da rede, ou de forma distribuída, ou seja, por meio de
protocolos de roteamento. Protocolos de roteamento são algoritmos distribuídos que rodam em
equipamentos de comutação e cooperam por meio da troca de mensagens de controle, chamadas
neste contexto de mensagens de roteamento. Os hosts geralmente não participam de protocolos
de roteamento. Quando os protocolos de roteamento são usados, é seu papel construir e manter
as tabelas de encaminhamento do roteador.
Os protocolos de roteamento são algoritmos distribuídos executados em equipamentos

de comutação para determinar caminhos dentro da rede.
1.3 Arquitetura de endereçamento da Internet

A Internet usa endereços IP para identificar, em nível mundial, as interfaces de rede alcançáveis.
Além disso, os processos de aplicação em execução nos hosts são identificados por meio do tipo
de protocolo de transporte utilizado na comunicação entre eles e seus números de porta. Os
números de porta têm apenas significado local, exceto os números de porta bem conhecidos, que
identificam tipos de aplicativos específicos em execução nos servidores.
A arquitetura de endereçamento da Internet também inclui o serviço DNS para mapear nomes
de host e URLs para endereços IP. O DNS define um banco de dados distribuído que armazena
esses mapeamentos em todo o mundo. Uma discussão abrangente sobre DNS pode ser
encontrada em [3].
Famílias de endereçamento IP Existem atualmente dois tipos de endereços IP: endereços IPv4 e
endereços IPv6. O comprimento dos endereços IPv4 é de 32 bits e o comprimento dos endereços
IPv6 é de 128 bits. Os endereços IPv6 foram introduzidos para substituir os endereços IPv4,
devido à escassez destes últimos. No entanto, a transição foi um processo lento e as duas famílias
de endereços coexistirão por muitos anos.
Representação de endereço A Figura 1.4 ilustra a representação de endereço usada em IPv4 e
IPv6. Os endereços IPv4 são representados em notação decimal com pontos, ou seja, usando
quatro números decimais separados por um ponto, onde cada número corresponde ao valor
decimal de um octeto, por exemplo, 128.10.2.30. Devido ao seu comprimento, os endereços IPv6
são representados em notação hexadecimal, com blocos de 16 bits separados por dois pontos,
por exemplo, 2001:0db8:000d:000a:0000:0000:0000:0003. Várias simplificações podem ser
adotadas para encurtar a representação do endereço, por exemplo, pular os zeros à esquerda em
um bloco de 16 bits e substituir um grupo de zeros consecutivos por dois pontos duplos. Com
essas duas simplificações, o endereço IPv6 anterior seria representado como 2001:db8:d:a::3
(consulte o Capítulo 3 de [14] para discussões adicionais).

FIGURA 1.4: Representação do endereço em (a) IPv4 e (b) IPv6.
Representando blocos de endereço Freqüentemente, é preciso se referir a blocos de endereços

contíguos que compartilham um prefixo comum, em vez de endereços individuais. O prefixo
corresponde aos bits de ordem superior do endereço. O tamanho do bloco, ou seja, o número
de endereços que ele contém, é determinado pelo tamanho do prefixo, com prefixos menores
definindo blocos maiores. Uma forma de caracterizar um bloco de forma compacta é indicar (i)
seu endereço mais baixo (também chamado de endereço base) e (ii) o comprimento do prefixo.
A notação usual é seguir o endereço por /n, onde n é o número de bits no prefixo; isso às vezes
é chamado de notação de barra. O bloco começa no endereço mais baixo, que tem o prefixo
comum e um sufixo totalmente zero, e termina no endereço mais alto possível com o mesmo
prefixo e um sufixo totalmente zero. Por exemplo, o bloco 123.4.8.0/24 tem um prefixo de 24
bits que começa em 123.4.8.0, termina em 123.4.8.255 e inclui um total de 28 = 256 endereços.
Com o mesmo endereço mais baixo, o bloco 123.4.8.0/21 começa em 123.4.8.0, termina em
123.4.15.255 e inclui 211 = 2.048 endereços. Para facilitar a notação, os zeros decimais à
direita do endereço podem ser omitidos. Por exemplo, o bloco 123.4.8.0/21 também pode ser
representado como 123.4.8/21. Observe que um bloco de endereços também pode ser definido
por (i) qualquer um dos endereços pertencentes ao bloco e (ii) o comprimento do prefixo.
A Figura 1.5 ilustra como os endereços mais baixo e mais alto do bloco 123.4.8/21 podem
ser determinados. Esse processo é facilitado pelo uso de uma representação de endereço
misto, onde os octetos iniciais caracterizados por terem todos os bits no prefixo são
representados em notação decimal com pontos e os restantes em notação binária. Nesse
caso, os dois primeiros octetos (os dois octetos mais à esquerda), ou seja, 123,4, são
representados em notação decimal e os dois octetos restantes em notação binária. Por exemplo,
o valor mais alto do terceiro octeto pode ser determinado observando que, devido ao prefixo /
21, os cinco primeiros bits devem ser 00001, pois pertencem ao prefixo, e os três últimos devem
ser

1.3 Arquitetura de endereçamento da Internet 9
123.4.8.0/21
123 . 4 . 00001 111 . 11111111 = 123.4.15.255
123 . 4 . 00001 000 . 00000000 = 123.4.8.0
PREFIXO SUFIXO
FIGURA 1.5: Determinando os endereços mais baixo e mais alto de um bloco de endereços.
111, pois pertencem ao sufixo do endereço mais alto de um bloco. Isso leva ao octeto 00001111,
que corresponde ao decimal 15.
No IPv4, o comprimento do prefixo às vezes é representado por uma palavra de 32 bits
expressa em notação decimal com ponto (como um endereço IPv4), onde para um prefixo com n
bits, os n bits de ordem mais alta da palavra são iguais a 1 e o os restantes são iguais a 0. Por
exemplo, no IPv4 os comprimentos de prefixo /24 e /21 também são representados como
255.255.255.0 e 255.255.248.0, respectivamente. Por motivos que ficarão claros em breve, essas
palavras binárias são chamadas de máscaras de sub-rede. Este tipo de representação não é
usado no IPv6.
Blocos de endereços reservados Tanto os espaços de endereços do IPv4 quanto os do IPv6
possuem blocos de endereços reservados para fins específicos. Esses blocos estão listados na
Figura 1.6 e serão descritos a seguir.
Comunicações multicast e broadcast Uma classificação importante de endereços IP é de acordo

com o número de interfaces que eles identificam quando usados como endereços de destino:
endereços unicast identificam uma única interface, endereços multicast identificam um grupo de
interfaces e endereços broadcast identificam todas as interfaces. Endereços multicast e broadcast
são usados sempre que um pacote
FIGURA 1.6: Tipos de endereço em IPv4 e IPv6.

precisa ser enviado para várias interfaces ao mesmo tempo. Isso é necessário em muitas
situações, por exemplo, em aplicativos que realizam comunicações em grupo (por exemplo,
videoconferência) e em várias funções de rede. O OSPF usa endereços IP multicast para a
comunicação entre roteadores vizinhos em links compartilhados.
Quando um pacote chega a uma interface, a interface primeiro analisa o endereço IP de

destino do pacote. Se não for igual a um endereço unicast ou multicast atribuído à interface ou
ao endereço de broadcast, o pacote será descartado. Este procedimento evita que a interface
tenha que analisar o conteúdo completo de todos os pacotes que chegam.
Os endereços de broadcast têm escopo restrito: um endereço de broadcast pode ter como
alvo apenas interfaces dentro de um domínio de roteamento específico, caso contrário, toda a
Internet seria inundada com esse tipo de pacote. No IPv6 não há endereços de broadcast,
apenas multicast. A maioria dos endereços multicast também tem escopo restrito.
Independentemente do escopo, os pacotes multicast e broadcast podem ser proibidos de cruzar
os limites da rede por meio de configuração administrativa.
Os blocos de endereços reservados para multicast são 224/4 (os primeiros 4 bits são iguais
a 1110) em IPv4 e ff00::/8 em IPv6.
Endereços públicos versus privados Os endereços IP também podem ser classificados como
endereços públicos ou privados. Os endereços públicos são usados para comunicações em
toda a Internet; eles são globalmente visíveis, globalmente exclusivos e podem aparecer como
endereços de destino em qualquer pacote IP. Endereços privados são usados para
comunicações dentro de domínios específicos e só precisam ser únicos dentro deles. Os
endereços privados desempenham um papel importante no endereçamento IPv4 devido à
escassez de endereços públicos nesta família de endereçamento. Os blocos de endereço
reservados para endereçamento privado no IPv4 são 10/8, 172.16/12, 192.168/16 e 169.254/16.
O IPv6 chama esses endereços de endereços locais exclusivos e os reserva o bloco fc00::/7.
No entanto, ao contrário do IPv4, os endereços privados do IPv6 foram projetados para ter uma
alta probabilidade de serem globalmente exclusivos (consulte o Capítulo 3 de [14] para obter
detalhes adicionais).
Endereços globais e de link local IPv6 O IPv6 introduziu uma importante distinção entre dois
tipos de endereços unicast: endereços globais e de link local. Os endereços globais são
definidos pelo prefixo 2000::/3 e são usados para comunicações em toda a Internet, da mesma
forma que os endereços IPv4 públicos.
Endereços de link local são definidos pelo prefixo fe80::/10 e são usados para comunicações
dentro de um link. Os endereços link-local trouxeram um benefício importante em relação ao
IPv4: as interfaces podem criar esses endereços por conta própria e usá-los para se comunicar
em um link sem qualquer configuração prévia. A estrutura desses dois tipos de endereço será
discutida na Seção 1.4.2.
A Internet tem atualmente duas famílias de endereços IP: endereços IPv4 com 32 bits
e IPv6 com 128 bits. Cada uma dessas famílias contém blocos de endereços
reservados para fins especiais, por exemplo, para comunicações multicast e broadcast
e para comunicações privadas. IPv6 inclui endereços link-local, para serem usados
para comunicações dentro de links.

mensagem
aplicativo mensagem APLICATIVO
mensagem APP TP
transporte
rede mensagem APP TP NET
link mensagem APP TP NET LK
físico mensagem APP TP NET LK PHY
rede
Hospedar
FIGURA 1.7: Adição de informações de controle por sucessivas camadas TCP/IP.
As três camadas inferiores da pilha TCP/IP lidam com a comunicação entre os hosts e as duas
superiores com a comunicação entre os processos de aplicativos em execução nos hosts. Exemplos de
protocolos da camada de aplicação são HTTP, para navegação na Web, FTP e TFTP, para transferência
de arquivos e Skype para conferência multimídia. Com relação aos protocolos da camada de transporte, os
principais protocolos utilizados na Internet são o TCP e o UDP. Eles estabelecem canais virtuais entre os
processos de aplicação. O TCP fornece funções de endereçamento, detecção de erros, controle e controle
de congestionamento; O UDP fornece apenas cobertura de anúncios e detecção de erros. Na outra ponta da
pilha, a camada física trata dos problemas relacionados à transmissão de bits no meio físico de comunicação,
como conversão analógico-digital e digital-analógico, modulação e codificação, resiliência a ruídos e distorção,
e recuperação de clock.
A camada de rede (camada-3) e a camada de enlace (camada-2) são as mais relevantes para os problemas
de roteamento abordados neste livro e serão discutidas com mais detalhes a seguir.
Uma hierarquia de roteamento de dois níveis A Internet é formada hoje por muitas tecnologias de
comunicação diferentes, como cabos submarinos, links de satélite, redes celulares e redes locais fixas e
sem fio, variando em velocidade, tipo de meio de comunicação, abrangência geográfica, confiabilidade e
número de dispositivos suportados, entre outras propriedades. Para lidar com essa heterogeneidade, a
arquitetura em camadas do TCP/IP inclui duas camadas, a saber, a camada de rede e a camada de enlace,
que formam uma hierarquia de roteamento de dois níveis (consulte a Figura 1.8).
A camada de rede A camada de rede fornece comunicações de ponta a ponta entre hosts e abstrai as
especificidades das tecnologias de comunicação. Os equipamentos de comutação que operam nesta
camada são os roteadores.
Os roteadores encaminham pacotes com base nos endereços da camada 3, ou seja, os endereços IP. Como

1.4 Lidando com tamanho e heterogeneidade 13
aplicativo aplicativo
transporte transporte
rede rede rede rede
link link link link link
físico físico físico físico físico
Endpoint da Trocar Roteador

endpoints de camada 3
camada 2 ponto final endpoints de camada 3
e camada 2
do roteador da camada 2 e camada 2
Hospedar Hospedar
endereços endereços
da camada 2 da camada 2
FIGURA 1.8: Relação entre camadas, endereços e dispositivos.
Como mostrado na Figura 1.8, os roteadores processam as três primeiras camadas da pilha TCP/IP.
Nesta camada, a rede é vista como uma rede de hosts e roteadores conectados por meio de links
lógicos, onde os links são representações abstratas de conexões reais. Os elementos de rede são
identificados nesta camada pelos endereços IP.
O protocolo IP O protocolo da camada de rede da Internet é o protocolo IP; é o protocolo que cola
a Internet, reunindo suas diversas tecnologias de comunicação! O protocolo IP define os endereços
usados nas comunicações ponta a ponta (os endereços IP) e fornece os mecanismos de adaptação
à heterogeneidade das tecnologias de comunicação. Um desses mecanismos é o processo de
fragmentação, por meio do qual a transmissão ponta a ponta dos pacotes se ajusta às tecnologias
de comunicação com diferentes restrições quanto ao comprimento máximo de pacotes que podem
suportar.
Atualmente existem duas versões do protocolo IP, uma para endereços IPv4 e outra para
endereços IPv6. O IPv6 foi introduzido para resolver a escassez de endereços IPv4: os endereços
IPv4 têm 32 bits e os endereços IPv6 têm 128. A implantação do IPv6 começou nos anos 2000,
mas, devido à sua complexidade, foi um processo lento. Espera-se que IPv4 e IPv6 coexistam por
muitos anos.
A camada de enlace Os enlaces lógicos entre hosts e roteadores são tratados pela camada de
enlace; às vezes, eles são chamados de links de camada 2. A camada de enlace fornece as
comunicações básicas em nível de pacote entre os dispositivos e delimita os pacotes dentro do fluxo
de bits que chegam a um dispositivo. Conforme destacado acima, esses links podem ter
características muito diferentes e, portanto, existem muitos protocolos de camada 2, cada um
adaptado às especificidades do link. Exemplos de

protocolos de camada 2 são IEEE 802.3 (Ethernet), IEEE 802.5 (Token Ring) e IEEE 802.11 (WiFi).
Os enlaces da camada 2 podem ser enlaces ponto a ponto simples, por exemplo, enlaces E1
ou V.35, ou redes relativamente complexas, como uma rede de área local Ethernet comutada. Os
equipamentos de comutação que operam nesta camada são chamados de switches de camada 2,
ou simplesmente switches. Comuta os pacotes de encaminhamento de acordo com os endereços
da camada 2. Conforme mostrado na Figura 1.8, ao contrário dos roteadores, os switches processam
apenas as duas primeiras camadas da pilha TCP/IP. Na verdade, isso significa que um pacote
sendo transmitido por uma rede de camada 2, por exemplo, entre dois roteadores ou entre um
roteador e um host, não terá seu endereço IP analisado pelos switches de camada 2 que ele cruza.
As redes da camada 2 podem ser integradas na Internet global ou operadas isoladamente.
Endereços da camada 2 Os endereços predominantes da camada 2 são os endereços MAC usados

nas LANs IEEE 802. Esses endereços são planos (não hierárquicos), têm um comprimento de 48
bits e, como os endereços IP, são atribuídos a interfaces. Assim, a arquitetura de endereçamento da
Internet possui dois tipos de endereços que nomeiam o mesmo elemento de rede. Os endereços
MAC são representados em notação hexadecimal, por exemplo, 48:dd:a9:56:b3:47. Assim como os
endereços IP, os endereços MAC podem ser classificados como unicast, multicast e broadcast, com
o mesmo significado. O endereço de broadcast é o endereço de todos (ff:ff:ff:ff:ff:ff). Os endereços
MAC são assinados globalmente pelo IEEE, mas só precisam ter escopo de link de camada 2.
Switches de camada 2 e tabelas de encaminhamento Uma rede de camada 2 é uma rede de

switches de camada 2. Comuta os pacotes de encaminhamento de acordo com os endereços da camada 2.
Nas tabelas de encaminhamento dos switches, os destinos são endereços da camada 2 e cada
entrada indica a interface de saída do switch que leva ao destino. Ao contrário das tabelas de
encaminhamento dos roteadores, as informações do próximo salto não fazem sentido na camada 2,
pois é a camada mais baixa para encapsular os pacotes.
Pontos finais da camada 2 e da camada 3 Dentro da hierarquia de roteamento de dois níveis, os
roteadores atuam como pontos finais da camada 2, pois estabelecem uma fronteira entre as redes
da camada 2 e os hosts são pontos finais da camada 3 e da camada 2. Os endereços da camada 3
têm escopo global e os endereços da camada 2 têm apenas escopo de link.
Conseqüentemente, quando um pacote é roteado na Internet, seus endereços de camada 3
permanecem inalterados, mas os endereços de camada 2 mudam toda vez que ele passa por um
roteador; voltaremos a esta questão na Seção 1.6.
O IP é um protocolo de roteamento? O protocolo IP não resolve o problema de roteamento em sua

totalidade. Além do IP, os protocolos de roteamento são necessários para determinar os caminhos
de ponta a ponta e para construir e manter as tabelas de encaminhamento dos roteadores. Exemplos
de protocolos de roteamento usados atualmente na Internet são RIP, OSPF, IS-IS e BGP. Além do
roteamento, existem outras questões que o protocolo IP não resolve sozinho e para as quais precisa
do auxílio de protocolos complementares; entre essas questões estão o fornecimento de segurança
de ponta a ponta e qualidade de serviço.
A função de roteamento está vinculada à camada de rede? Os protocolos de roteamento não estão
vinculados a uma camada específica da arquitetura TCP/IP, pois o roteamento é

necessário em várias camadas. É lamentável que vários livros didáticos ainda liguem a
função de roteamento à camada de rede, uma fonte comum de confusão entre os alunos. De
fato, o roteamento é necessário na camada 2 para encontrar caminhos dentro das redes de
switches da camada 2, e na camada 3 para encontrar caminhos dentro das redes de
roteadores e até mesmo na camada 5 para encontrar caminhos entre os servidores de
aplicativos. Exemplos de protocolos de roteamento operando em cada uma dessas camadas
são o spanning tree protocol na camada 2 (veja o Capítulo 3 de [41]), RIP, OSPF, IS-IS e
BGP na camada 3, e o roteamento entre o proxy SIP servidores na camada 5 (ver Capítulo 7 de [27] ou [22])
Curiosamente, o IS-IS foi modificado recentemente para se tornar o protocolo de roteamento
de camada 2 das redes de ponte de caminho mais curto 802.1aq [5]; assim, mesmo a mesma
tecnologia de roteamento é usada em diferentes camadas com modificações.
Os protocolos da Internet são organizados em uma pilha de camadas conhecida

como arquitetura TCP/IP. A camada de enlace (camada 2) e a rede (camada 3)
formam uma hierarquia de roteamento de dois níveis que abstrai a heterogeneidade
das tecnologias de comunicação usadas na Internet. A camada de rede fornece as
comunicações de ponta a ponta entre os hosts; nesse nível, a Internet pode ser
vista como uma rede de roteadores usando endereços IP. A camada de enlace
fornece comunicações entre roteadores e hosts. As conexões da camada de enlace
podem ser simples enlaces ponto a ponto ou redes relativamente complexas usando
endereços da camada 2 para comunicações internas. Os endereços predominantes
da camada 2 são os endereços MAC, que têm um comprimento de 48 bits.
1.4.2 Sub-redes, estrutura de endereços e tabelas de encaminhamento
Como pode ser facilmente entendido, seria impossível na Internet de hoje ter destinos
individuais listados nas tabelas de encaminhamento dos roteadores. O tamanho das tabelas
de encaminhamento seria muito grande. Assim, os endereços IP devem ser agregados de
alguma forma.
Sub-redes Para responder a este problema, as redes IP são organizadas em sub-redes. Sub-
redes são redes lógicas que reúnem um bloco de endereços IP contíguos que compartilham
um prefixo comum, atribuídos a interfaces que podem se comunicar entre si sem a
intervenção de um roteador. Assim, a mesma sub-rede não pode abranger diferentes
interfaces de roteador, e todas as interfaces associadas à mesma sub-rede devem ter
endereços IP com o mesmo prefixo. Além disso, uma sub-rede pode ser totalmente
caracterizada por um prefixo de endereço.
Estrutura de endereço Para suportar a organização em sub-redes, os endereços IP são
estruturados hierarquicamente em dois níveis, onde o prefixo, às vezes chamado netid,
identifica a sub-rede e o sufixo, às vezes chamado hostid, identifica a interface do host nessa
sub-rede. As sub-redes são geralmente definidas por (i) o endereço IP mais baixo do bloco
de endereço, chamado endereço de sub-rede ou endereço de prefixo, e (ii) o comprimento
do prefixo ou máscara de sub-rede.
No IPv4, os endereços mais baixos e mais altos do bloco de endereços de sub-rede

FIGURA 1.9: Estrutura de endereços IPv6 (a) link-local e (b) global unicast.
não pode ser atribuído a interfaces. O endereço mais baixo (juntamente com a máscara de sub-
rede) é reservado para identificar a sub-rede e o endereço mais alto é usado como endereço de
broadcast dentro da sub-rede. Este tipo de restrição não se aplica ao IPv6.
Endereços classful Nos primórdios da Internet, havia uma demarcação rígida entre o netid e o
hostid. Naquela época, havia três tipos de endereços unicast IPv4, identificados por seus bits
mais à esquerda: anúncios de classe A com hostid de 24 bits, endereços de classe B com
hostid de 16 bits e endereços de classe C com hostid de 8 bits. . Como o tipo de endereço era
determinado pelos bits mais à esquerda (“0” para classe A, “10” para classe B e “110” para
classe C), não havia necessidade de uma máscara de sub-rede. Mais tarde, a introdução de
máscaras de sub-rede permitiu sub-redes de comprimento variável, trazendo mais flexibilidade
para a estrutura da rede.
Estrutura de endereço IPv6 global e link-local A Figura 1.9 mostra a estrutura dos endereços
link-local e global. Ambos os tipos de endereços incluem o campo Interface ID, que identifica a
interface e corresponde à parte hostid do endereço. Endereços de link local devem ser usados
apenas dentro de um link de camada 2 e, portanto, não possuem netid. Em endereços globais,
a parte netid do endereço é dividida em duas partes: Global Routing Prefix e Subnet ID.
O prefixo de roteamento global é a parte do endereço atribuído pelo ISP e o ID da sub-rede

identifica a sub-rede dentro da rede do ISP. A figura indica valores típicos para o comprimento
desses campos; no entanto, outros valores são possíveis. Como no IPv4, o comprimento da
parte netid é variável e é definido pelo valor do comprimento do prefixo que acompanha o
endereço. Independentemente das subdivisões netid, a partição netid/hostid conforme definida
pelo comprimento do prefixo é o que é relevante para fins de roteamento em uma determinada
tabela de encaminhamento.
Configuração de endereços Os endereços IP podem ser configurados nas interfaces usando
diferentes métodos. O IPv6 é muito mais rico que o IPv4 a esse respeito.
Os endereços IPv4 podem ser configurados manualmente ou por DHCP. Ao usar o DHCP,
a interface contata um servidor DHCP, que normalmente fornece o endereço IP atribuído à
interface, a máscara de sub-rede e os endereços IP do gateway padrão e de um servidor DNS
(consulte o capítulo 23 de [9] para detalhes adicionais ).

Os endereços IPv6 também podem ser configurados manualmente ou por DHCP

(chamado DHCPv6, neste caso). No entanto, os endereços IPv6 também podem ser
configurados (i) tendo o Interface ID atribuído aleatoriamente ou pelo processo EUI-64
ou, no caso de endereços globais unicast, (ii) tendo o prefixo do endereço obtido de um
roteador por meio do roteador ICMPv6 Mensagens publicitárias. O último método é
chamado Stateless Address Autoconfiguration (SLAAC). O primeiro método é usado em
endereços globais e de link local. Quando o ID da interface é atribuído aleatoriamente,
deve ser envolvido um método para determinar se o endereço IPv6 resultante é uma
duplicata; este método é chamado Detecção de Endereço Duplicado (DAD) em IPv6. O
processo EUI-64 constrói um ID de interface a partir do endereço MAC da interface. Os
capítulos 4 e 5 de [14] fornecem detalhes adicionais sobre como configurar endereços
IPv6.
Tabelas de encaminhamento Quando a rede é organizada em sub-redes, as tabelas de
encaminhamento podem se referir a prefixos de sub-rede (e não apenas a endereços IP
individuais), e apenas o roteador conectado a uma sub-rede de destino precisa se
preocupar em entregar pacotes a destinos individuais. As tabelas de encaminhamento
dos roteadores têm uma entrada por prefixo de sub-rede de destino e cada entrada inclui,
em geral, informações sobre (i) a interface de saída, (ii) o endereço da camada 3 da
próxima interface do roteador no caminho para o destino e (iii) o custo do caminho. O
custo do caminho será abordado na Seção 1.5. Nas entradas referentes a destinos
diretamente conectados ao roteador, o custo do caminho é omitido e o endereço do
próximo salto é substituído pela indicação “está conectado diretamente”; também
usaremos a palavra-chave dc para essa finalidade. Observe que o endereço IP do
próximo salto determina totalmente em um roteador o caminho a ser seguido para cada
sub-rede de destino; as demais informações são complementares.
Comparando roteadores e switches Roteadores e switches são equipamentos de
comutação que encaminham pacotes das interfaces de entrada para as de saída. Quando
um pacote chega a um equipamento de comutação, o equipamento lê o endereço de
destino contido no cabeçalho do pacote e procura esse endereço em sua tabela de
encaminhamento, para determinar como deve encaminhar o pacote. Essa forma de
operação é comum a roteadores e switches. A distinção fundamental entre eles está
relacionada às informações de endereçamento usadas para tomar decisões de
encaminhamento: os roteadores encaminham os pacotes de acordo com os endereços
IP, enquanto os switches o fazem de acordo com os endereços da camada 2.
Exemplo As sub-redes, como outras abstrações de rede, geralmente são representadas
por nuvens. A Figura 1.10 mostra a visualização da sub-rede da rede da Figura 1.1 e a
tabela de encaminhamento do roteador R1. A figura inclui o identificador e o custo de
cada interface do roteador, colocados próximos à interface. O custo da interface é
utilizado no processo de seleção do caminho, que será explicado na Seção 1.5. Algumas
interfaces também incluem os endereços IP atribuídos a elas. Nessa rede, há cinco sub-
redes, cada uma atribuída a um dos links da camada 2 e caracterizada por um prefixo
diferente. Por exemplo, a rede sem fio recebe uma sub-rede com o prefixo 9.0.0.0/8 e o
link ponto a ponto entre R1 e R2 recebe uma sub-rede com o prefixo 192.168.0.0/30. As
interfaces que pertencem ao mesmo

192.168.0.2
R1 R2
192.168.0.0/30
222.0.0.1
192.168.0 222.0.0.2
H1
125.6.0.0/16
222.0.0.3
222.0.0.0/24
R4
9.0.0.254
H2
222.0.0.4 9.0.0.1 9.0.0.2

9.0.0.0/8
R3
H3 H4
FIGURA 1.10: Visão de sub-rede da rede da Figura 1.1.
sub-rede recebem endereços IP que compartilham um prefixo comum. Por exemplo, todas as
interfaces da sub-rede 222.0.0.0/24 recebem endereços IP começando com 222.0.0.
A tabela de encaminhamento do roteador R1 inclui cinco entradas, uma para cada sub-
rede. Cada entrada inclui o endereço IP da interface do próximo salto, o identificador da interface
de saída e o custo do caminho. Por exemplo, a entrada relativa à sub-rede 9.0.0.0/8 diz que um
pacote destinado a esta sub-rede deve ser transmitido através da interface i3 para a interface
com endereço IP 222.0.0.4, ou seja, interface i2-R3. A tabela de encaminhamento não lista os
endereços IP individuais das interfaces do host de destino, por exemplo, do laptop ou do tablet.
Um pacote sendo transmitido do roteador R1 para o tablet, ou seja, para o endereço IP 9.0.0.1,
é encaminhado de roteador para roteador com base no prefixo de sub-rede 9.0.0.0/8, que
abrange 9.0.0.1, até chegar ao roteador R4. É então responsabilidade de

roteador R4 para encontrar a interface do tablet na sub-rede 9.0.0.0/8 e encaminhar o pacote

para ela. Voltaremos a esse assunto na Seção 1.6.
As sub-redes podem ser sobrepostas em links de camada 2? Como uma sub-rede é uma
entidade lógica reunindo um bloco de endereços IP atribuídos a interfaces anexadas ao
mesmo link de camada 2, é possível sobrepor várias sub-redes no topo do mesmo link de
camada 2. Dentro de um link de camada 2, pode haver diferentes interfaces pertencentes a
diferentes sub-redes; além disso, uma interface pode pertencer a mais de uma sub-rede,
uma vez que podem ser atribuídos vários endereços IP. A comunicação entre interfaces de
diferentes sub-redes deve ser sempre através de um roteador, mesmo que as interfaces
estejam conectadas ao mesmo link.
As redes IP são organizadas em sub-redes menores chamadas sub-redes. Sub-

redes são redes lógicas que reúnem um bloco de endereços IP contíguos que
compartilham um prefixo comum, atribuídos a interfaces que podem se comunicar
entre si sem a intervenção de um roteador. Para suportar a organização em sub-
redes, os endereços IP são estruturados hierarquicamente em dois níveis, com o
prefixo identificando a sub-rede e o sufixo identificando a interface do host dentro
da sub-rede. Dessa forma, as tabelas de encaminhamento do roteador só precisam
se referir a prefixos de sub-rede e não a endereços IP de destino individuais.
1.4.3 Domínios de Roteamento e Sistemas Autônomos

Domínios de roteamento e roteamento entre domínios Os caminhos de ponta a ponta
geralmente não são calculados usando um único protocolo de roteamento, especialmente
se os caminhos forem longos. Para facilitar essa tarefa, a rede é organizada em domínios
de roteamento, de forma que cada domínio resolva seu próprio problema de roteamento,
ou seja, determine os caminhos entre seus terminais. O roteamento dentro de um domínio
de roteamento é realizado por meio de protocolos de roteamento intradomínio, e o
roteamento entre domínios de roteamento é realizado por meio de protocolos de roteamento
interdomínio. OSPF e IS-IS são dois exemplos de protocolos intra-domínio. Os roteadores
localizados na fronteira entre os domínios de roteamento e executando o protocolo de
roteamento interdomínio são chamados genericamente de Domain Border Routers (DBRs).
Sistemas Autônomos e BGP A nível mundial, a Internet está organizada em Sistemas
Autônomos (ASes) (ver Figura 1.11). ASes são domínios sob responsabilidade de uma única
administração, geralmente um provedor de serviços de Internet (ISP). As sub-redes e os
domínios de roteamento estão contidos nos ASes. Cada AS tem sua própria política de
roteamento e pode ter um ou mais domínios de roteamento, cada um executando seu próprio
protocolo de roteamento intradomínio. Os roteadores localizados na fronteira entre ASes
são chamados Autonomous System Border Routers (ASBRs). Os ASBRs executam um
protocolo de roteamento inter-AS entre eles, que anuncia as sub-redes (ou seja, os prefixos
de endereço) atribuídos a cada AS e determina os caminhos entre os ASes. BGP é o padrão
atual de fato para roteamento inter-AS [46]. Estudar o BGP está fora do escopo deste livro; o

Protocolo de roteamento
entre domínios (BGP)
ASBR
ASBR
Autônomo
ASBR
Sistema
roteador
interno
Autônomo ASBR
Sistema
FIGURA 1.11: A Internet como uma rede de Sistemas Autônomos.
O leitor interessado deve consultar [52] e [18], dois excelentes livros-texto sobre o assunto.
É importante destacar que o roteamento inter-AS é intrinsecamente diferente do roteamento

intradomínio. No primeiro, a seleção de caminhos precisa considerar questões políticas,
econômicas e de segurança, além de questões de desempenho.
Para este último, apenas as questões de desempenho são relevantes, pois se aplica apenas a
roteamentos sob responsabilidade de uma única administração.
Domínios de roteamento multiárea Os domínios de roteamento podem ser ainda estruturados
em várias áreas, com o objetivo de simplificar o processo de roteamento interno (consulte a
Figura 1.12). Nesse caso, os roteadores localizados na fronteira entre as áreas, denominados
Area Border Routers (ABRs), executam um protocolo de roteamento entre áreas entre si para a
troca de informações de roteamento entre as áreas. Tanto o OSPF quanto o IS-IS suportam
essa possibilidade, e vamos abordá-la nos Capítulos 3 e 7. Como veremos, os protocolos de
roteamento entre áreas compartilham muitos aspectos comuns com os protocolos de roteamento
entre domínios.

roteador
interno
Área
ABR
Protocolo de roteamento
Área ABR
entre áreas
roteador
interno
roteador
interno
ABR Área
FIGURA 1.12: Um domínio de roteamento estruturado em múltiplas áreas.
A nível mundial, a Internet está organizada em domínios administrativos,

denominados Sistemas Autônomos (ASes), cada um com sua própria política de
roteamento. Os ASes se comunicam através do protocolo BGP que roda em
roteadores especiais localizados na fronteira entre eles, chamados Autonomous
System Border Routers (ASBRs). O BGP anuncia os prefixos de endereço
alcançáveis em cada AS e determina os caminhos entre os ASes. Um AS pode
incluir um ou mais domínios de roteamento, cada um executando seu próprio
protocolo de roteamento intradomínio, dos quais OSPF e IS-IS são dois exemplos.
Os domínios de roteamento podem ser ainda estruturados em múltiplas áreas,
que se comunicam por meio de um protocolo de roteamento entre áreas
executado em roteadores especiais localizados na fronteira entre eles,
denominados Area Border Routers (ABRs).
Abordagens de roteamento intradomínio As duas abordagens de roteamento intradomínio

mais importantes são o vetor de distância e o estado do link. O roteamento do vetor de
distância depende da versão distribuída e assíncrona do algoritmo de Bellman-Ford (ver
Seção 5.2 de [6]). Nesse algoritmo, os roteadores enviam para seus vizinhos as estimativas
dos custos do caminho mais curto deles mesmos para cada destino da rede. O custo do
caminho mais curto para um destino e a interface do próximo salto que o fornece são
calculados com base (i) nas estimativas de custo do caminho recebidas dos vizinhos e (ii)
nos custos das interfaces de saída que levam a esses vizinhos.
Roteamento de estado de link (LSR) é um processo de duas etapas: primeiro, cada

roteador obtém informações sobre a topologia de rede completa e os prefixos de endereço
assinados para elementos de rede, usando um procedimento de inundação; segundo, um
algoritmo de caminho mais curto centralizado, como os algoritmos Dijkstra ou Bellman-Ford, é

executado em cada roteador para obter a tabela de encaminhamento. Como será visto no
Capítulo 7, os protocolos LSR, apesar de fundamentados na abordagem LSR, podem ser
combinados com um protocolo de vetor de distância para fornecer roteamento entre áreas; este
é precisamente o caso do OSPF e do IS-IS.
O roteamento dentro de domínios de roteamento é tratado por protocolos de roteamento

intradomínio, que podem assumir um estado de link ou uma abordagem de vetor de
distância. OSPF e IS-IS combinam as duas abordagens: eles são protocolos de
roteamento de estado de enlace intrínseco, mas usam uma abordagem de vetor de
distância em seu protocolo de roteamento entre áreas.
Fluxo de informações de roteamento As informações de roteamento fluem na direção oposta das

informações de dados. Em um ambiente distribuído, as informações de roteamento são
originadas nos destinos (onde mais?) quando eles anunciam os prefixos de endereço nos quais
desejam ser alcançados. Essas informações são então propagadas em direção às fontes,
formando uma árvore de caminhos direcionados ao destino, conforme ilustrado na Figura 1.13.
Durante esse processo, o prefixo de endereço original pode ser agregado em espaços de
endereço sucessivamente maiores, para economizar no tamanho das tabelas de encaminhamento.
Por exemplo, a sub-rede de destino anuncia um prefixo de endereço, sua área anuncia um
prefixo maior representando todos os prefixos da área e seu domínio anuncia um prefixo de
endereço ainda maior representando todos os prefixos do domínio. É por meio desse prefixo de
endereço maior que o destino será conhecido nas fontes mais remotas. Às vezes, esse processo
é chamado de super-rede porque os agregados são descritos com prefixos sucessivamente mais
curtos, representando redes sucessivamente maiores. Na Figura 1.13, o destino D recebe o
prefixo 123.4.5.0/24, sua área anuncia 123.4.0.0/16 e seu domínio 123.0.0.0/8.
A informação de roteamento flui do destino para a fonte, direção oposta ao fluxo de

dados, e durante este processo os prefixos anunciados podem ser agregados em
espaços de endereçamento sucessivamente maiores; às vezes, esse processo é
chamado de supernetting.
Coexistência e integração IPv4 e IPv6 As famílias de endereços IPv4 e IPv6 e os protocolos de

roteamento deverão coexistir por muitos anos. De uma perspectiva de roteamento, IPv4 e IPv6
são executados em domínios de roteamento separados e seus protocolos de roteamento
constroem tabelas de encaminhamento separadas. Esses domínios de roteamento podem ser
sobrepostos ou executados em redes físicas separadas. Existem três técnicas para a coexistência
e integração de IPv4 e IPv6: dual-stack, tunelamento e tradução. Na técnica de pilha dupla, os
dispositivos de rede (hosts e roteadores) implementam os protocolos IPv4 e IPv6. Assim, os
domínios de roteamento IPv4 e IPv6 são sobrepostos e os hosts podem se comunicar usando
um ou outro. A técnica de tunelamento é um método para transportar pacotes IPv6 em redes
somente IPv4. Isso é feito encapsulando pacotes IPv6 dentro de pacotes IPv4. Finalmente, a
técnica de tradução é usada para interconectar redes somente IPv4 e somente IPv6 convertendo
o cabeçalho IP de

1.5 O processo de seleção do caminho 23
123.0.0.0/8
S1
123.4.0.0/16
123.4.5.0/24
S2
S3
FIGURA 1.13: Fluxo de informações de roteamento e endereçamento versus fluxo de dados.
uma família na outra. Os capítulos 10 e 11 de [14] fornecem uma discussão abrangente dessas
técnicas.
1.5 O processo de seleção do caminho

Em redes de computadores, vários caminhos geralmente estão disponíveis para enviar tráfego de
uma origem a um destino. Dentre estes, pelo menos um caminho deve ser selecionado.
Para tanto, cada caminho candidato é caracterizado por uma métrica, chamada path cost,
expressando a preferência de transmissão de tráfego por aquele caminho.
O custo do caminho é uma função dos atributos dos roteadores e links. Porém, em redes fixas,
os atributos do roteador são geralmente ignorados, pois os recursos disponíveis nos roteadores não
restringem o processo de comunicação. O link em tributo expressa o custo de transmissão de
pacotes através de um link; exemplos de atributos são o atraso do link, taxa de transferência, taxa
de erro ou confiabilidade. Em muitos protocolos de roteamento, os custos de transmissão do link
são expressos por inteiros positivos atribuídos estaticamente às interfaces de saída dos roteadores.
Esses custos podem ser configurados manualmente nos roteadores, fornecendo aos gerentes de
rede uma ferramenta flexível para configurar soluções de roteamento específicas. No entanto, os
custos estáticos não refletem o estado do link em tempo real. Ressaltamos que os custos de
interface representam o custo de transmitir a informação, e não de recebê-la; portanto,

os custos estão associados às interfaces de saída e as interfaces de entrada são consideradas

como tendo um custo zero.
Os protocolos LSR, como outros protocolos de roteamento intradomínio, selecionam
caminhos usando o critério de menor custo de caminho. Nesse caso, o custo do caminho de
cada caminho candidato é obtido somando-se os custos das interfaces de saída que fazem parte
do caminho, sendo que o caminho selecionado para roteamento é o de menor custo. Observe
que pode haver mais de um caminho de menor custo, caso em que o caminho selecionado pode
ser escolhido aleatoriamente entre o conjunto de caminhos candidatos de menor custo.
Ilustraremos o processo de seleção de caminho usando a rede da Figura 1.10. Considere a

seleção de caminho do roteador R1 para a sub-rede 9.0.0.0/8. Existem seis caminhos candidatos
diferentes. Os caminhos e seus custos são os seguintes (expressos em termos de interfaces de
transmissão para facilitar o entendimento):
• i1-R1 ÿ i1-R2 ÿ i2-R4 com custo 50;
• i2-R1 ÿ i2-R4 ÿ com custo 70;
• i3-R1 ÿ i1-R3 ÿ i1-R2 ÿ i2-R4 com custo 60;
Para dar um exemplo de cálculo de custo de caminho, considere o segundo caminho acima.
O custo do caminho é obtido somando os custos das interfaces i1-R1, i2-R2 e i2-R4, que são 10,
40 e 20, respectivamente, resultando em um custo de caminho de 70.
Essas são as interfaces que transmitiriam pacotes se o caminho fosse selecionado para
roteamento; o custo das interfaces receptoras não é contabilizado no cálculo do custo do caminho.
O caminho de menor custo, ou seja, o escolhido para roteamento, é o último da lista acima,
com custo 40. Isso pode ser confirmado na tabela de encaminhamento da Figura 1.10 . A primeira
entrada da tabela indica que o caminho para 9.0.0.0/8 é através da interface i3, tendo 222.0.0.4
tem o endereço IP da interface do próximo salto (ou seja, o endereço atribuído à interface i2-R3)
e um custo de 40.
Os protocolos LSR selecionam caminhos de acordo com o princípio de roteamento de

caminho mais curto, ou seja, o caminho selecionado para roteamento é o de menor
custo, e o custo de um caminho é calculado adicionando os custos das interfaces de
saída que pertencem ao caminho.
Links conectados diretamente Há uma exceção ao uso de caminhos mais curtos no roteamento
da Internet, e isso ocorre quando o destino está em um link conectado diretamente ao roteador.
Nesse caso, a rota conectada diretamente prevalece sobre qualquer outro caminho, mesmo
que este apresente um custo menor. Considerar

1.6 Roteamento de ponta a ponta 25
novamente o exemplo da Figura 1.10 e o problema de determinar o caminho do roteador R1 para a sub-rede
125.6.0.0/16. O caminho mais curto é i3-R1 ÿ i1-R3 com um custo de 20. A rota conectada diretamente tem um
custo de 50 (o custo da interface i2-R1) mas, apesar de seu custo mais alto, ela é selecionada para roteamento.
A precedência de rotas conectadas diretamente é implementada localmente nos roteadores por meio de um
parâmetro chamado distância administrativa, que discutiremos a seguir.
Distâncias administrativas A distância administrativa fornece uma forma genérica de seleção entre caminhos
para o mesmo destino obtidos através de diferentes processos de roteamento. Além das rotas conectadas
diretamente, um roteador pode executar mais de um protocolo de roteamento ao mesmo tempo, por exemplo,
OSPF e IS-IS, cada um fornecendo um caminho diferente para o mesmo destino. A distância administrativa é
um valor atribuído a cada processo de roteamento que define sua precedência. Atualmente, a distância
administrativa é 0 para rotas conectadas diretamente, 110 para OSPF e 115 para IS-IS, e a convenção é que
valores menores têm precedência maior. Assim, as rotas conectadas diretamente são preferidas a quaisquer
outros caminhos e, se um roteador estiver executando OSPF e IS-IS, os caminhos OSPF serão preferidos aos
IS-IS.
No roteamento da Internet, as rotas conectadas diretamente têm precedência sobre os caminhos

mais curtos. Essa precedência é implementada localmente nos roteadores por meio de um
parâmetro, denominado distância administrativa, que também classifica entre caminhos para o
mesmo destino obtidos por meio de diferentes protocolos de roteamento que podem estar rodando
simultaneamente.
1.6 Roteamento de ponta a ponta

Como um pacote pode ser roteado entre hosts quando precisa atravessar a rede global de camada 3 e várias
redes de camada 2? Conforme ilustrado na Figura 1.14, esse processo pode ser decomposto em três etapas:
roteamento do host de origem para o roteador do primeiro salto (etapa 1), do roteador do primeiro salto para o
último salto (etapa 2) e do roteador de último salto para o host de destino (etapa 3). O protocolo de roteamento
está envolvido apenas na segunda etapa. Todas as etapas podem exigir a resolução da camada 3 em
endereços da camada 2.
Resolução de endereço Quando um pacote IP precisa ser transmitido por uma rede de camada 2, o endereço
de camada 2 associado ao endereço IP do próximo salto (ou seja, o ponto final da camada 3 da rede de
camada 2) pode ser desconhecido. No caso de pacotes unicast, esse problema é resolvido por meio de um
protocolo de resolução de endereço.
O IPv4 usa o Address Resolution Protocol (ARP) [43] e o IPv6 o Neighbor Discovery Protocol (NDP) [39].
Apesar de nomes diferentes, esses protocolos operam de maneira semelhante no que diz respeito à resolução
de endereços.
Tomando como exemplo o ARP, quando um dispositivo precisa determinar o endereço MAC associado a
um endereço IPv4 de sua sub-rede, ele questiona todas as

1 2 3
roteador de roteador de
fonte primeiro salto último salto host de

hospedar destino
FIGURA 1.14: As três etapas do roteamento de ponta a ponta.
faces anexadas à sub-rede por meio de uma mensagem ARP REQUEST transmitida ao
endereço de broadcast MAC; o destinatário que possui o endereço IPv4 fornece as informações
solicitadas por meio de uma mensagem ARP REPLY (ver Seção 3.2.6 de [42]). O NDP usa o
mesmo processo, onde o equivalente de ARP REQUEST é a mensagem NEIGHBOR
SOLICITATION, e o equivalente de ARP REPLY é a mensagem NEIGHBOR ADVERTISEMENT
(ver Capítulo 5 de [14]). Para evitar a troca dessas mensagens sempre que um novo pacote
precisa ser transmitido em uma rede de camada 2, os dispositivos (hosts ou roteadores) que
descobrem uma associação entre os endereços IP e MAC o armazenam na memória por algum
tempo.
A resolução de endereços IP multicast em endereços MAC é realizada por meio de um

processo de mapeamento e não por meio de um protocolo de resolução de endereço.
Por exemplo, um endereço IPv4 multicast é convertido em um endereço MAC multicast usando
as seguintes regras: (i) os bits 48 a 25 do endereço MAC são 0×01005e; (ii) o bit 24 é 0; (iii) os
bits 23 a 1 são os últimos 23 bits do endereço multicast IPv4.
Do host de origem ao roteador de primeiro salto Na primeira etapa, pode haver vários roteadores
de primeiro salto possíveis para escolher, porque o host de origem é multi-homed e/ou está
conectado a um link compartilhado com vários roteadores conectados (ver Figura 1.15). O host
de origem poderia, em princípio, selecionar seu roteador de primeiro salto ouvindo passivamente
as mensagens de roteamento transmitidas pelos vários roteadores de primeiro salto; isso
permitiria determinar o melhor roteador de primeiro salto para cada destino individual. No
entanto, esta solução tem dois problemas: primeiro, porque os hosts podem fazer roaming em
redes que executam diferentes protocolos de roteamento, eles precisariam entender todos eles,
e há muitas possibilidades; em segundo lugar, as informações de roteamento fornecidas pelos
roteadores de primeiro salto executando diferentes protocolos de roteamento podem ser
incompatíveis, por exemplo, podem fornecer métricas de custo de caminho não comparáveis
para o mesmo destino. Assim, em vez de ter um roteador de primeiro salto adaptado para cada
destino individual, a solução usual é ter um único roteador de primeiro salto para cada interface
de link compartilhado,

roteador de
i1 primeiro salto
i2 roteador de
primeiro salto
host de
origem
gateway padrão
roteador de
primeiro salto
FIGURA 1.15: Host multi-homed com vários gateways padrão possíveis.
que é usado como primeiro salto para todo o tráfego transmitido pela interface; esse
roteador é chamado de gateway padrão. Observe que um endereço de gateway padrão
não é necessário para interfaces de link ponto a ponto.
O endereço do gateway padrão é o endereço IP do gateway padrão na interface
anexado ao link compartilhado. No caso do IPv6, o endereço de gateway padrão deve
ser um endereço de link local.
Os hosts multihomed têm um gateway padrão por interface de link compartilhado e
enfrentam o problema adicional de determinar qual interface usar para transmitir seu
tráfego. O tráfego pode ser distribuído entre as várias interfaces de acordo com algum
critério, mas a solução comum é enviar todo o tráfego pela interface de maior largura de
banda. Assim, nessa configuração, o host de origem seleciona primeiro a interface de
saída e depois envia todo o tráfego para o roteador de primeiro salto dessa interface,
que no caso de interfaces de link compartilhado é o gateway padrão.
O endereço de gateway padrão pode ser substituído para destinos específicos,

manualmente ou por meio de mensagens de redirecionamento ICMP. Este último caso
funciona da seguinte forma: quando um pacote chega ao gateway padrão e, com base
no protocolo de roteamento, o gateway padrão verifica se existe um roteador de primeiro
salto melhor para o destino do pacote, ele envia uma mensagem de redirecionamento
ICMP para o host de origem contendo o endereço desse roteador de primeiro salto e o
endereço de destino correspondente. O host de origem então instala essas informações
em sua tabela de encaminhamento. Este recurso é opcional.
No IPv4, o endereço do gateway padrão é configurado manualmente no host ou
obtido de um servidor através do protocolo DHCP (Ver Seção 3.2.7 de [42]); em IPv6,
pode ser configurado manualmente no host, obtido de um servidor

através do protocolo DHCPv6, ou obtido de um roteador de primeiro salto através do protocolo

NDP (ver Capítulo 5 de [14]).
Quando um pacote fica pronto para transmissão no host de origem, o host primeiro verifica
se o host de destino pertence ou não à sua sub-rede. Ele faz isso comparando (i) seu prefixo de
sub-rede com (ii) o prefixo obtido aplicando sua máscara de sub-rede ao endereço de destino.
Se os prefixos coincidirem, conclui que o host de destino pertence à sua sub-rede e, caso
contrário, conclui o contrário.
No primeiro caso, o pacote deve ser enviado diretamente ao host de destino e, no segundo
caso, deve ser enviado ao gateway padrão. Se necessário, o host de origem usa o protocolo de
resolução de endereço para determinar o endereço MAC associado ao endereço IP do host de
destino ou do padrão
Porta de entrada.
Do roteador de primeiro salto ao roteador de último salto O problema de roteamento entre

roteadores e, portanto, do roteador de primeiro salto para o roteador de último salto é resolvido
por protocolos de roteamento de camada 3, que é o tópico principal deste livro . Conforme
discutido acima, esses protocolos constroem e mantêm tabelas de encaminhamento de camada
3 em cada roteador, que indicam como o roteamento prossegue para o próximo roteador.
Quando um pacote chega a um roteador, o roteador executa uma pesquisa na tabela de
encaminhamento e tenta corresponder o endereço IP de destino contido no cabeçalho do pacote
com uma de suas entradas na tabela de encaminhamento. A verificação de correspondência
para um endereço IP de entrada é realizada em cada entrada da tabela de encaminhamento
comparando (i) o prefixo de entrada com (ii) o prefixo obtido aplicando a máscara de sub-rede
de entrada ao endereço IP de entrada. Pode haver mais de uma entrada na tabela de
encaminhamento correspondente a um determinado endereço IP. Quando isso acontece, a
entrada com o prefixo mais longo é selecionada para roteamento; isso é conhecido como a
regra de correspondência de prefixo mais longo.
A entrada correspondente indica a interface de saída e, exceto para o roteador do último
salto, o endereço IP do roteador do próximo salto. Se necessário, o roteador usa o protocolo de
resolução de endereço para determinar o endereço MAC associado ao endereço IP do próximo
salto.
Do roteador de último salto para o host de destino Na última etapa, o roteador de último salto
entrega o pacote ao host de destino. Um roteador sabe que é o último para um pacote quando
a entrada correspondente na tabela de encaminhamento informa que a sub-rede de destino
está conectada diretamente ao roteador. Nesse caso, se a sub-rede de destino for um link
compartilhado, o roteador usará o protocolo de resolução de endereço para obter o endereço
da camada 2 associado ao endereço IP de destino, para que o pacote possa ser transportado
para o host de destino.
Um exemplo Damos um exemplo de roteamento ponta a ponta na Figura 1.16. O exemplo
considera o endereçamento IPv4, mas o comportamento com o endereçamento IPv6 é
semelhante. A rede inclui três sub-redes IPv4 interconectadas por dois roteadores. As sub-redes
recebem os prefixos 223.2.3.0/24, 125.6.0.0/16 e 9.0.0.0/8; a sub-rede do meio inclui um switch
de camada 2. Mostramos, junto às interfaces, os identificadores das interfaces e seus endereços
IP e MAC. A figura também mostra as tabelas de encaminhamento de todos os equipamentos
de comutação. nós il

ilustrar como um pacote é enviado do servidor localizado na sub-rede 223.2.3.0/24 (o

host de origem) para um laptop localizado na sub-rede 9.0.0.0/8 (o host de destino). A
representação do pacote inclui apenas os campos de cabeçalho necessários para fins
de encaminhamento, ou seja, os endereços IP e MAC de destino. Neste exemplo,
assumimos que todos os caches de resolução de endereço estão inicialmente vazios.
Quando o pacote fica pronto para transmissão no servidor, o servidor aplica sua
máscara de sub-rede /24 ao endereço IP de destino e conclui que o laptop não está
em sua sub-rede, pois o prefixo resultante, 9.0.0.0/24, é diferente de próprio,
223.2.3.0/24. Assim, o pacote deve ser enviado para o gateway padrão, ou seja, para
o endereço IP 223.2.3.254. Antes de transmiti-lo, o servidor invoca o protocolo ARP
para obter o endereço MAC associado a 223.2.3.254, que é 00:1d:70:d7:c4:c1. Após
obter essas informações, o pacote IP é encapsulado em um pacote Ethernet e
transmitido ao roteador R1.
Quando o pacote chega em R1, o cabeçalho MAC é retirado do pacote; foi usado
apenas para transporte na primeira sub-rede e não é mais útil. Em seguida, R1 realiza
uma pesquisa em sua tabela de encaminhamento, tentando casar o endereço IP de
destino contido no cabeçalho do pacote com uma de suas entradas na tabela e
determina que o pacote deve ser transmitido pela interface i2 para o próximo salto
125.6.2.2, que é um endereço do roteador R2. Novamente, o roteador usa o protocolo
ARP para determinar o endereço MAC associado ao endereço IP do próximo salto,
que é 10:d3:51:23:d5:38. Depois que R1 obtém essas informações, o pacote IP é
encapsulado em um pacote Ethernet e transmitido para o switch.
Quando o pacote chega ao switch, o switch procura em sua tabela de

encaminhamento uma entrada correspondente ao endereço MAC de destino contido
no cabeçalho do pacote e conclui que o pacote deve ser transmitido pela interface i2.
Observe que o switch analisa apenas as informações da camada 2 para executar suas
decisões de encaminhamento; os endereços IP contidos no cabeçalho do pacote são
irrelevantes para sua operação. Além disso, o endereço MAC de destino não é
modificado pelo switch, da mesma forma que os endereços IP de destino não são
modificados pelos roteadores.
Quando o pacote chega em R2, o cabeçalho MAC é novamente retirado do pacote.
Ao executar a consulta à tabela de encaminhamento, o roteador conclui que o host de
destino está localizado em uma sub-rede conectada diretamente e que o pacote deve
ser transmitido por meio da interface i2. Em seguida, invoca o protocolo ARP para
determinar o endereço MAC associado ao endereço IP do laptop, 9.0.0.1, que é
d0:15:a7:5b:11:20. Finalmente, o pacote é transmitido ao laptop, pelo ar, mas desta
vez o pacote IP é encapsulado em um pacote IEEE 802.11.
Observe que o endereço IP de destino não mudou durante esta jornada. Ao

contrário, o endereço MAC de destino mudava toda vez que o pacote cruzava um
roteador e mudava de sub-rede.

223.2.3.18/24
DG=223.2.3.254 00:1d:70:d7:c4:c1
9.0.0.1
outros campos
223.2.3.254/24
pacote Ethernet
00:1d:70:d7:c4:c1
tabela de encaminhamento de camada 3
i1
destino próximo int
9.0.0.0/8 salto 125.6.2.2 i2
125.6.0.0/16 CC i2 R1
223.2.3.0/24 CC i1
i2
125.6.1.1/16
48:dd:a9:56:b3:47
tabela de encaminhamento de camada 2 i1

destino int 10:d3:51:23:d5:38
48:dd:a9:56:b3:47 i1 9.0.0.1
Sw
10:d3:51:23:d5:38 i2 outros campos
i2 pacote Ethernet
125.6.2.2/16
10:d3:51:23:d5:38
tabela de encaminhamento de camada 3
i1
destino próximo int
9.0.0.0/8 i2
125.6.0.0/16 salto dc dc i1
R2
223.2.3.0/24 125.6.1.1 i1 i2
endereço MAC de destino d0:15:a7:5b:11:20

endereço IP de destino 9.0.0.1
outros campos
pacote IEEE
802.11
9.0.0.1/8
d0:15:a7:5b:11:20
FIGURA 1.16: Exemplo de roteamento ponta a ponta.

1.7 Representando a topologia de rede 31
O roteamento de ponta a ponta envolve três etapas, e cada etapa pode exigir a
intervenção de um protocolo de resolução de endereço para mapear endereços
IP em endereços MAC. Na primeira etapa, do host de origem ao roteador do
primeiro salto, o host de origem entrega o pacote a um roteador do primeiro
salto predefinido, chamado de gateway padrão. O endereço do gateway padrão
pode ser configurado manualmente no host ou obtido de um servidor DHCP ou
do próprio gateway padrão. A segunda etapa, entre o primeiro salto e o
roteador do último salto, é realizada por meio do protocolo de roteamento.
Nesta etapa, o pacote é roteado de acordo com as tabelas de encaminhamento
dos roteadores. Na última etapa, o roteador de último salto entrega o pacote ao
host de destino.
1.7 Representando a topologia de rede

Em muitas situações, é conveniente representar as redes de forma simplificada,
enfatizando os elementos-chave e ocultando os detalhes irrelevantes. Por exemplo, ao
estudar protocolos de roteamento, as redes de camada 2 usadas para conectar
roteadores não precisam ser representadas com todos os seus detalhes internos, por
exemplo, incluindo os switches de camada 2 e as conexões entre eles. Ter as redes
representadas por meio de gráficos geralmente é conveniente para entender melhor a
estrutura da rede e a operação dos protocolos. Esta seção discute primeiro a tipificação
das conexões da camada 2 e, em seguida, a representação gráfica das redes.
1.7.1 Tipos de conexões da camada 2

Enlaces ponto a ponto e compartilhados Do ponto de vista do roteamento da camada 3,
os enlaces da camada 2 entre roteadores são apenas conexões entre roteadores,
independentemente de sua complexidade interna. Essas conexões podem ser
classificadas em dois tipos: links ponto a ponto e links compartilhados. Um link ponto a
ponto conecta dois, e apenas dois, dispositivos de camada 3; exemplos são links E1 ou
V.35. Normalmente, os enlaces ponto a ponto são bidirecionais, ou seja, fornecem
comunicações em ambas as direções, mas também existem exemplos de enlaces ponto
a ponto unidirecionais. Um link compartilhado é uma abstração de uma rede de camada
2 e pode potencialmente conectar muitos dispositivos de camada 3. Exemplos são
Ethernet (comutada e não comutada), Token Ring, Wi-Fi, X.25, Frame Relay e ATM.
Grau de conectividade e capacidade de transmissão Os links compartilhados podem ser
classificados de acordo com duas propriedades: grau de conectividade e capacidade de
transmissão. Com relação ao grau de conectividade, os links compartilhados podem
fornecer conexões diretas entre todos os dispositivos conectados ao link (uma malha
completa) ou apenas entre alguns dispositivos (uma malha parcial). Por exemplo, uma
rede Ethernet fornece conectividade total entre seus dispositivos conectados e

uma rede ATM pode ser configurada para fornecer conectividade total ou parcial, usando uma malha
total ou parcial de PVC (Circuitos Virtuais Permanentes).
Um link compartilhado tem capacidade de broadcast se um pacote transmitido no link por um
dispositivo usando o endereço de destino de broadcast for recebido e lido por todos os outros
dispositivos conectados ao link. Assim, esta capacidade diz respeito à possibilidade de entregar
informações simultaneamente para todos os dispositivos conectados a um link usando apenas um
pacote. Está presente em redes Ethernet (comutadas e não comutadas), Token Ring e Wi-Fi, mas
não em redes X.25, Frame Relay e ATM. Observe que um link pode ser totalmente em malha, mas
não capaz de transmitir.
Links compartilhados de trânsito e stub Finalmente, pode-se distinguir entre links compartilhados de
trânsito e stub. Um link compartilhado stub tem apenas um roteador conectado e um link compartilhado
de trânsito tem dois ou mais roteadores conectados. Por exemplo, na rede da Figura 1.1, o link
wireless é um link compartilhado stub, e a Ethernet comutada conectando todos os quatro roteadores
é um link compartilhado de trânsito.
Observe que não precisa haver uma correspondência direta entre as tecnologias da camada 2
e os tipos de links abstratos usados para representá-los. Por exemplo, um link Ethernet é uma
tecnologia que pode conectar muitos roteadores e, portanto, é naturalmente representado como um
link compartilhado. No entanto, também pode ser representado como um link ponto a ponto se estiver
conectando apenas dois roteadores. Esta possibilidade é ilustrada na Seção 9.2.1.6.
Os links da camada 2 podem ser classificados como links ponto a ponto ou compartilhados.
Os links ponto a ponto conectam dois, e apenas dois, dispositivos de camada 3. Os links
compartilhados abstraem as redes da camada 2 e podem potencialmente conectar muitos
dispositivos da camada 3. Além disso, links compartilhados podem ser classificados como
full-meshed ou parcialmente mesh, como broadcast ou non-broadcast, e como trânsito ou
links stub.
1.7.2 Representando redes através de grafos

Os gráficos fornecem uma maneira simplificada de representar redes, o que é útil em muitas
situações. Um grafo é composto de nós e arcos. Os arcos representam conexões entre nós e podem
ser direcionados ou não. Arcos direcionados descrevem uma relação direcional entre nós (por
exemplo, a comunicação em uma direção específica). Grafos com arcos direcionados são chamados
de grafos direcionados, e aqueles com arcos não direcionados são chamados de grafos não
direcionados. Ambos os tipos de gráficos são úteis ao estudar protocolos de roteamento.
Mapeando grafos para redes Ao estudar protocolos de roteamento de camada 3, a associação natural
entre elementos de rede e gráfico é ter nós representando roteadores e arcos representando as
conexões de camada 2 entre roteadores. Porém, em alguns casos, pode ser vantajoso adotar outros
mapeamentos entre os elementos da rede e do grafo. Os hosts não são incluídos no gráfico se não
participarem do protocolo de roteamento, que geralmente é o
caso.

1.7 Representando a topologia de rede 33
R1 R2 R1 pseudonó
R2
R3 R4 R3 nó R4
(a) (b)
FIGURA 1.17: Conectividade fornecida por um link compartilhado com quatro roteadores
representados por (a) arcos conectando cada par de nós ou (b) um pseudonó.
Identificando os elementos da rede Além do mapeamento entre os elementos da rede e

do grafo, a representação da rede também requer que os elementos da rede sejam
identificados por nomes únicos. Assumiremos que os nomes dos roteadores, links ponto
a ponto e links compartilhados são obtidos de espaços de nomes separados. Os nomes
dos roteadores serão prefixados por R, os nomes dos links ponto a ponto por lp e os
nomes dos links compartilhados por ls.
Representando as conexões Conforme discutido na Seção 1.7.1, pode-se abstrair as
conexões da camada 2 entre roteadores em dois tipos: enlaces ponto a ponto e enlaces
compartilhados. A conectividade fornecida por um link ponto a ponto pode ser
representada por um arco. Nesse caso, o arco representa tanto o meio de comunicação
que conecta os dois roteadores quanto as interfaces que ligam esses roteadores ao
meio.
O pseudonó Da mesma forma, a conectividade fornecida por um link compartilhado
pode ser representada por um conjunto de arcos, um arco para cada par de roteadores
conectados ao link (Figura 1.17.a). No entanto, quando o link conecta muitos roteadores,
esse tipo de representação envolve muitos arcos e pode se tornar incômoda. Se o link
estiver totalmente em malha, uma solução para esse problema é representar a
conectividade dentro do link por meio de um único nó (Figura 1.17.b). De fato, esse tipo
de link compartilhado pode ser visto como um elemento de comutação que encaminha
os pacotes recebidos em uma interface para todas as outras interfaces. Para distinguir
nós que representam roteadores e nós que representam links compartilhados, vamos
nos referir aos primeiros como nós e aos segundos como pseudonós, seguindo a nomenclatura IS-IS.
Além disso, desenharemos nós usando círculos e pseudonós usando elipses.
Os arcos entre nós e pseudonós têm uma interpretação diferente dos arcos entre nós:
eles apenas representam as interfaces que conectam roteadores a links compartilhados.
Observe que arcos entre pseudonós não são permitidos nesta representação, pois não
possuem significado físico.
Um exemplo da Figura 1.18 mostra o grafo não direcionado que representa a rede da
Figura 1.1 para estudar seu roteamento no nível IP. Os nós R1 a R4 representam os
roteadores IP. Os arcos entre os nós R1 e R2, denominados lp1, e entre os nós R2 e
R4, denominados lp2, representam os links E1. O pseudonó

link ponto a ponto
lp1
R1 R2
ls1 ls2
lp2
pseudonó (link
compartilhado de trânsito)
R3 R4
ls3
nó pseudonó (link
compartilhado stub)
FIGURA 1.18: Gráfico representando a rede da Figura 1.1.
ls1 representa a LAN Ethernet baseada em hub simples. O pseudonó ls2 representa a Ethernet
comutada composta por três switches arranjados em uma topologia triangular. Esses pseudonós
são links compartilhados de trânsito. O pseudonó ls3 representa a LAN sem fio e é um link
compartilhado de stub. Claro, há um problema de roteamento dentro da rede Ethernet comutada
representada pelo link compartilhado ls2. Este problema geralmente é tratado através do
protocolo spanning tree, e poderia ser estudado usando outro grafo, agora representando os
detalhes internos da Ethernet comutada. Entretanto, para o estudo do roteamento IP, a Ethernet
comutada pode ser convenientemente abstraída por meio de uma única entidade (no caso, o
link compartilhado), pois, nessa perspectiva, a Ethernet comutada é apenas uma provedora de
conectividade entre os roteadores IP.
As redes podem ser representadas por grafos, e essa representação abstrata facilita
o entendimento dos protocolos de roteamento. Um grafo é composto de nós e arcos.
Para estudar o roteamento da camada 3, um mapeamento natural entre os elementos
da rede e do grafo é ter nós representando roteadores e arcos as conexões da camada
2 entre os roteadores, que podem ser ponto a ponto ou links compartilhados. Para
simplificar a representação, a conectividade dentro de um link compartilhado totalmente
em malha pode ser resumida por meio de um único nó, chamado de pseudonó.

1.8 Correção e desempenho dos protocolos de roteamento 35
1.8 Correção e desempenho dos protocolos de roteamento

O projeto de um protocolo de roteamento deve observar vários critérios de correção e desempenho.
Em particular, um protocolo de roteamento deve:
• Convergir dentro de um tempo razoável para um estado correto quando o seguinte

eventos ocorrem:
– os atributos dos roteadores ou links mudam; –
roteadores são adicionados ou removidos, possivelmente devido a uma falha.
• Lidar adequadamente com a possibilidade de corrupção das mensagens de roteamento e das

informações de roteamento armazenadas nos roteadores, bem como a falta de recursos (por
exemplo, memória ou capacidade de processamento) para lidar com as informações de roteamento
nos roteadores.
• Ser eficiente, ou seja, manter ao mínimo a carga introduzida pelas mensagens de controle, pois os
recursos disponíveis para transportar informações de controle são subtraídos dos de informações
de dados.
A correção de um protocolo é geralmente avaliada em termos de propriedades de segurança e

vivacidade, onde a observação da primeira garante que o protocolo nunca produza um resultado
incorreto e a observação da segunda garante que o protocolo nunca entre em um estado de impasse
(consulte a Seção 2.4 .1 de [6]). Um protocolo de roteamento distribuído deve garantir que todos os
roteadores criem tabelas de encaminhamento consistentes, cada uma tendo localmente a noção
correta dos caminhos fim a fim (globais).
Um cenário particularmente desafiador para correção e desempenho é quando todos os roteadores
são ligados ao mesmo tempo; isso é conhecido como partida a frio.
O projeto de um protocolo de roteamento deve atender a vários critérios de exatidão e

desempenho, para garantir que o protocolo converja dentro de um tempo razoável para um
estado correto e não imponha carga excessiva na rede.
1.8.1 Transmissão confiável de mensagens de controle

Nenhum meio de comunicação é totalmente confiável. No entanto, as mensagens de controle devem
ser transmitidas de forma confiável, ou seja, devem chegar ao destino pretendido sem erros e no devido
tempo. Para alcançar a confiabilidade, deve haver mecanismos (i) para detectar se as mensagens
contêm erros de bit e (ii) para garantir que mensagens sem erros sejam eventualmente recebidas.
Detecção de erros A técnica usual de detecção de erros consiste em anexar à mensagem transmitida
um campo calculado sobre seu conteúdo e compará-lo, no destino, com o mesmo cálculo realizado
sobre o conteúdo da mensagem.

mensagem recebida. Existem essencialmente três tipos de métodos de detecção de erros:

verificações de paridade, somas de verificação e verificações de redundância cíclica (ver, por
exemplo, Seção 5.2 de [27]).
Repetição periódica de mensagens Para se recuperar de mensagens corrompidas, existem
basicamente duas técnicas. Uma técnica freqüentemente usada em protocolos de roteamento,
mas nem sempre apreciada como tal, é a repetição periódica de mensagens.
Nesse caso, mesmo que algumas mensagens sejam perdidas ou corrompidas, outras
eventualmente terão sucesso (se o meio de comunicação não falhar completamente).
Proteção ACK Outra técnica é baseada no reconhecimento pelo receptor de que a mensagem
foi recebida corretamente. O procedimento é o seguinte:
• O remetente armazena uma cópia da mensagem, define um timer (para aguardar a

confirmação) e transmite a mensagem; o timer, chamado ACK timer, é configurado para
um valor predefinido chamado timeout.
• O receptor responde com uma confirmação quando recebe a mensagem

sem erros.
• Se o remetente não receber a confirmação antes que o timer ACK expire, ele retransmite a
mensagem e ajusta novamente o timer para o valor de timeout; isso é repetido até que uma
confirmação seja finalmente recebida.
• Quando o remetente recebe a confirmação, ele exclui a cópia da mensagem confirmada

armazenada inicialmente e limpa o temporizador ACK.
Observe que nessa interação tanto a mensagem inicial quanto o reconhecimento podem
ser corrompidos, mas as retransmissões só param quando ambas as mensagens são recebidas
corretamente.
A confirmação pode ser realizada por meio de uma mensagem de controle explícita,
geralmente chamada de ACK, ou pode estar implícita na resposta. Por exemplo, se o remetente
solicitar alguma informação, receber essa informação confirma que a solicitação foi recebida
corretamente. Iremos nos referir a transmissões protegidas desta forma como sendo protegidas
por ACK.
Um remetente pode ter que transmitir ao mesmo tempo várias mensagens que requerem
proteção ACK. Além disso, um receptor pode receber a mesma mensagem várias vezes, o que
pode acontecer quando os ACKs são perdidos. Assim, deve haver uma forma de distinguir entre
uma nova mensagem e uma cópia de uma anteriormente transmitida, e deve haver uma forma
de correlacionar cada mensagem transmitida com o reconhecimento correspondente. Isso
geralmente é obtido numerando as mensagens com números sequenciais exclusivos, geralmente
chamados apenas de Números de Sequência (SNs), e numerando os ACKs com os SNs das
mensagens que eles reconhecem.
Protocolo Stop-and-Wait Existem várias estratégias para a retransmissão de mensagens em

caso de erro, geralmente referidas como estratégias Automatic Repeat-reQuest (ARQ) (Ver
Secção 2.4 de [6]). A estratégia ARQ mais simples, muitas vezes

5 5 5 5
WLPHRXW
WLPH WLPH
D E
FIGURA 1.19: Protocolo Stop-and-Wait.
usado no LSR, é o protocolo Stop-and-Wait (SW). Nesse caso, apenas uma mensagem pode
ser transmitida por vez, e o remetente só pode passar para a transmissão da próxima mensagem
após receber a confirmação de que a anterior foi recebida corretamente.
A Figura 1.19 ilustra a operação do protocolo SW. Na Figura 1.19.a, o roteador R1 envia
três mensagens DATA para o roteador R2. As mensagens DATA são numeradas
sequencialmente e cada ACK repete o SN do DATA que ele reconhece.
Não há erros de transmissão, mas uma mensagem DATA só pode ser transmitida após o
reconhecimento da anterior. Na Figura 1.19.b , o ACK enviado pelo roteador R2 em resposta à
primeira mensagem DATA é perdido. Assim, o timer definido pelo roteador (quando a mensagem
foi transmitida inicialmente) expira e, quando isso acontece, o roteador R1 retransmite a
mensagem DATA usando o mesmo SN. O roteador R2 descarta a segunda mensagem DATA,
pois reconhece, com base no SN, que já foi recebida. No entanto, ainda reconhece sua recepção.
Um procedimento semelhante é seguido no caso de perda de uma mensagem de DADOS.
Confiabilidade em links compartilhados Alcançar a confiabilidade em um link compartilhado traz

um desafio adicional: quando um roteador transmite uma mensagem em um link compartilhado,
ele deve obter a confirmação de que todos os outros roteadores conectados ao link a receberam.
Assim, o roteador de origem deve saber antecipadamente quantos roteadores estão conectados
ao link e quem são eles. Uma maneira de conseguir isso é por meio do protocolo Hello, que
descrevemos na Seção 2.1.

As mensagens de roteamento precisam ser transmitidas de forma confiável para

garantir a exatidão do protocolo. A confiabilidade geralmente é obtida através da
repetição periódica de mensagens de controle ou usando proteção ACK e uma
estratégia de retransmissão Stop-and-Wait (SW).
1.8.2 Detectando falhas de roteador e link

A capacidade de detectar falhas de roteador e link é um recurso importante dos protocolos de
roteamento. Em caso de falha, os protocolos de roteamento precisam encontrar alternativas
para as rotas danificadas, o mais rápido possível. Em alguns casos, as falhas podem ser
detectadas por meio de mecanismos de hardware, por exemplo, por circuitos eletrônicos que
detectam perda de sinal. No entanto, isso nem sempre é possível. Para ver isso, considere a
rede da Figura 1.20, que reproduz parte da rede da Figura 1.1. Suponha que o roteador R3
falhe ou que os switches Sw1 e Sw3 falhem simultaneamente (Figura 1.20.a). O primeiro caso
é uma falha de roteador e o segundo uma falha de link compartilhado.
Essas falhas não podem ser detectadas pelo roteador R2 usando mecanismos de hardware,
pois R2 está conectado ao link compartilhado por meio do switch Sw2 e esse switch permanece
operacional.
As falhas do roteador são as mais difíceis de lidar. Uma falha de roteador só pode ser
detectada por seus vizinhos, pois um roteador com falha não tem oportunidade de informar a
todos os outros que vai falhar. Isso implica a existência de um mecanismo de manutenção de
atividade, por meio do qual os roteadores anunciam periodicamente que ainda estão operacionais.
Esse mecanismo está incluído, implícita ou explicitamente, nos protocolos de roteamento.
As falhas de links compartilhados podem ser apenas parciais. Suponha que os enlaces que
conectam os switches Sw3 e Sw1 e os switches Sw3 e Sw2 falhem simultaneamente (Figura
1.20.b). Nesse caso, o link compartilhado ainda pode ser usado para conectar os roteadores R3
e R4 de um lado e os roteadores R1 e R2 do outro. Dizemos que o link foi particionado. Um link
particionado não é um link com falha completa e, se possível, a rede deve continuar usando
suas partes sobreviventes para propósitos de roteamento. Como no caso de falhas do roteador,
um mecanismo de manutenção de atividade pode ser usado para detectar os subgrupos de
roteadores que ainda podem se comunicar uns com os outros no caso de um particionamento
de link compartilhado.
Os protocolos de roteamento devem ser capazes de lidar com falhas de roteador e

link e a partição de links compartilhados. Para lidar com esses eventos, os roteadores
devem anunciar periodicamente a seus vizinhos que ainda estão ativos; isso é
chamado de mecanismo de manutenção de atividade.

R1 R2
Sw1 Sw2
R3 R4
Sw3
R1 R2
Sw1 Sw2
R3 R4
Sw3
FIGURA 1.20: (a) Falhas de roteadores e enlaces e (b) particionamento de enlaces

compartilhados.


parte II
Princípios


2
Princípios do estado de link de área única
Roteamento
Link State Routing (LSR) é uma abordagem de roteamento em que cada roteador mantém uma visão
completa da rede, ou seja, onde cada roteador conhece a topologia de rede completa e a correspondência
entre prefixos disponíveis e elementos de rede (roteadores ou links). É com base nessa visão, que
chamaremos de informação de roteamento, que os roteadores constroem suas tabelas de encaminhamento.
Para garantir que os roteadores mantenham tabelas de encaminhamento globalmente consistentes, as
informações de roteamento devem ser as mesmas em todos os roteadores.
Este capítulo aborda os princípios do LSR, ou seja, os mecanismos fundamentais e as estruturas de

dados que sempre devem estar presentes nos protocolos LSR, independentemente da tecnologia que os
implemente. Os princípios da LSR podem ser organizados em torno de três questões principais:
• Como as informações de roteamento são representadas?
• Quais são os mecanismos utilizados para manter essas informações atualizadas e

sincronizado em todos os roteadores?
• Como a representação da rede e os mecanismos de sincronização escalam

para grandes redes?
Neste capítulo, nos concentramos nas duas primeiras questões; a terceira questão é
relacionadas a redes multiárea e serão abordadas no capítulo 3.
Nos protocolos LSR, cada roteador constrói e mantém um Link State Database (LSDB) contendo as
informações de roteamento necessárias para construir sua tabela de encaminhamento. Existem três
tipos de informações de roteamento (consulte a Figura 2.1):
• Informações topológicas - Também conhecidas como mapa de rede, descrevem os roteadores, os

links entre os roteadores e os custos atribuídos às interfaces dos roteadores.
• Informações de endereçamento - Descreve os prefixos de endereços roteáveis (IPv4 ou IPv6) e sua

associação com roteadores e links. Pode-se distinguir entre informações de endereçamento internas
e externas ao domínio, ou seja, informações relacionadas a prefixos internos e externos ao domínio
de roteamento.
• Informações do link - Descreve os endereços usados para transportar pacotes no link entre roteadores
vizinhos. Essas informações têm natureza local e não precisam ser as mesmas nos LSDBs de todos
os roteadores.
43

44 2 Princípios de Roteamento de Estado de Link de Área Única
FIGURA 2.1: Estrutura LSDB e mecanismos de sincronização.
O LSDB deve ser mantido atualizado e sincronizado em todos os roteadores, e para isso são
necessários três mecanismos (ver Figura 2.1):
• Protocolo Hello - Detecta os vizinhos ativos de um roteador.
• Procedimento de inundação confiável - Divulga em toda a rede

as informações de roteamento originadas por cada roteador.
• Processo de sincronização inicial do LSDB - Sincroniza os LSDBs dos roteadores que se tornam
vizinhos.
Vamos nos referir a esses mecanismos como mecanismos de sincronização.

Nas seções seguintes, discutimos os vários aspectos relativos à representação das informações
de roteamento e aos mecanismos de sincronização.
A Seção 2.1 apresenta o protocolo Hello. A Seção 2.2 discute a estrutura do LSDB e a Seção 2.3
explica como as tabelas de encaminhamento são construídas a partir do LSDB. A Seção 2.4 aborda
os mecanismos usados para disseminar as informações de roteamento pela rede, incluindo o
procedimento de flooding confiável. A seção 2.5 descreve o processo inicial de sincronização do
LSDB.
Finalmente, a Seção 2.6 apresenta um resumo das mensagens de controle que suportam os vários
mecanismos de sincronização apresentados ao longo do capítulo.
Neste capítulo, adotamos uma nomenclatura própria, muitas vezes não aderindo à de OSPF ou
IS-IS. O objetivo é tornar a nomenclatura o mais expressiva possível e evitar o favorecimento de
uma tecnologia em detrimento da outra. Mais adiante no livro, fornecemos a correspondência entre
as várias terminologias.

2.1 Protocolo de saudação 45
Os protocolos LSR constroem e mantêm um banco de dados, chamado Link State Database
(LSDB), contendo informações topológicas (o mapa da rede, representando a topologia da
rede), informações de endereçamento (os prefixos de endereço atribuídos a roteadores e
links) e informações de link (os endereços necessários para transportar pacotes entre
roteadores vizinhos). A consistência do LSDB é obtida por meio de três mecanismos de
sincronização distintos: protocolo Hello, procedimento de flooding confiável e processo de
sincronização inicial do LSDB.
2.1 Protocolo de saudação

O protocolo Hello visa a manutenção de relacionamentos de vizinhança entre roteadores. O protocolo
permite que os roteadores acompanhem os vizinhos atualmente ativos em cada um de seus links.
Assim, ele desempenha um papel central em manter o mapa da rede atualizado.
O protocolo Hello é executado por link e, portanto, um roteador deve executar uma instância do
protocolo em cada uma de suas interfaces. O protocolo mantém uma lista com os identificadores dos
vizinhos atualmente ativos no enlace, chamada lista de vizinhos ativos.
O protocolo deve se comportar corretamente mesmo se a rede não for confiável, ou seja, em caso
de falha de roteador e link e perda de mensagens de controle. Nas próximas seções, discutimos primeiro
o protocolo Hello para redes confiáveis e, em seguida, introduzimos as modificações necessárias para
garantir a correção do protocolo no caso de redes não confiáveis. Também discutimos como o protocolo
é usado para verificar se as comunicações entre vizinhos são bidirecionais, quais requisitos ele impõe
na identificação de vizinhos, bem como alguns usos adicionais do protocolo.
2.1.1 Protocolo Hello para redes confiáveis

Começamos considerando um cenário ideal onde ambos os roteadores e links são confiáveis, ou seja,
onde (i) roteadores e links não falham e (ii) mensagens de controle não são perdidas. Isso permite uma
introdução mais suave às questões envolvidas. Neste cenário, o protocolo requer três mensagens de
controle que chamamos de HELLO, HELLO REPLY e BYE, e opera da seguinte maneira:
• Quando um roteador entra no link, ele transmite uma mensagem HELLO contendo
seu identificador;
• Todo roteador que recebe uma mensagem HELLO responde com uma mensagem HELLO REPLY
contendo seu identificador;
• Quando um roteador deixa o link, ele transmite uma mensagem BYE contendo seu
identificador;

3 3 5 5
1 R1 1 R1 R1 7 R1
R1 R2 R1 R2 R2 R1 R2
R2 R3 R2 R3 R3 R3 R3
R1 R2 R1 R2
4 4 6
+(//2 +(//2
5(3/<5 +(//25 5(3/<5 %<(5
2
5 1 5 7
R1 R3 R3 R1 R1 R3
R2 (a) R2 R3 (b)
R3 R3
FIGURA 2.2: Protocolo Hello para redes confiáveis; (a) roteador R3 entrando no link, (b) roteador R2
saindo do link.
• Quando um roteador recebe uma mensagem HELLO ou HELLO REPLY, ele adiciona o
identificador contido na mensagem à sua lista de vizinhos ativos; inversamente, ao receber uma
mensagem BYE, remove o identificador contido na mensagem dessa lista.
Ilustramos a operação desse protocolo na Figura 2.2. Os números dentro de círculos indicam
as etapas do algoritmo, e abaixo de cada etapa mostramos a lista de vizinhos ativos de cada
roteador. Neste exemplo, o roteador R3 se junta ao link quando os roteadores R1 e R2 já estão lá
(Figura 2.2.a) e posteriormente o roteador R2 sai do link (Figura 2.2.b). Inicialmente, (passo 1) as
listas de vizinhos ativos dos roteadores R1 e R2 contêm R1 e R2, e a do roteador R3 contém apenas
R3. Quando o roteador R3 entra no link, ele transmite uma mensagem HELLO com seu identificador
(etapa 2). Ao receber esta mensagem, os roteadores R1 e R2 adicionam R3 às suas listas de
vizinhos ativos (etapa 3) e cada roteador responde transmitindo uma mensagem HELLO REPLY
contendo seu identificador (etapa 4). Quando essas mensagens são recebidas, o roteador R3
adiciona R1 e R2 à sua lista e o algoritmo termina (etapa 5). Posteriormente, quando o roteador R2
decide sair do enlace, ele transmite uma mensagem BYE contendo seu identificador e deleta sua
lista de vizinhos ativos (etapa 6). Ao receber esta mensagem, os roteadores R1 e R3 removem R2
de sua lista de vizinhos ativos e o algoritmo termina novamente (etapa 7).
2.1.2 Lidando com redes não confiáveis

Agora suponha que as mensagens de controle possam ser perdidas. Isso coloca vários problemas:
• Se uma mensagem BYE for perdida, os vizinhos restantes continuarão acreditando que o roteador
de saída ainda está ativo;

• Se uma mensagem HELLO for perdida, os vizinhos já ativos no link não

reconhecerão a presença do roteador que está entrando.
O último problema não pode ser resolvido através da proteção ACK (ver Seção
1.8.1): quando um roteador entra em um link e envia uma mensagem HELLO, ele
não sabe quantos ACKs deve receber, pois, para começar, não saber quantos
roteadores estão ativos no link. Na verdade, a única maneira de resolver esse
problema de confiabilidade é por meio da repetição periódica de mensagens HELLO.
Nesse caso, mesmo que a primeira mensagem seja perdida, uma das subseqüentes
acabará tendo sucesso e o roteador se tornará conhecido por todos os seus vizinhos.
Além disso, se a periodicidade das mensagens HELLO for relativamente curta, as
mensagens HELLO REPLY podem ser eliminadas do protocolo.
A repetição periódica de mensagens HELLO também pode lidar com falhas de
roteador e link, se combinada com um mecanismo de tempo de vida útil.
Especificamente, cada entrada na lista de vizinhos ativos recebe uma idade e um
tempo de vida. Quando uma nova entrada é instalada na lista, significando que um
novo vizinho foi descoberto, é atribuída uma idade de zero. A idade continua
aumentando enquanto a entrada permanece na lista, e é atualizada (redefinida para
zero) sempre que uma mensagem HELLO enviada pelo vizinho correspondente é
recebida. Quando a entrada atinge o tempo de vida, significando que as comunicações
com o vizinho falharam, ela é removida da lista. O valor do tempo de vida deve ser
várias vezes a periodicidade das mensagens HELLO. A periodicidade das mensagens
HELLO é de 10 segundos em OSPF e IS-IS, e o tempo de vida é de 40 segundos em
OSPF e 30 segundos em IS-IS (esses são valores padrão).
Observe que o protocolo Hello não detecta em seu próprio roteador falhas. Ele
apenas detecta a perda de conectividade através de links específicos. A repetição
periódica de mensagens HELLO sinaliza a vivacidade das comunicações com um
roteador através de um link específico, e o procedimento age-lifetime fornece um
critério para decidir quando as comunicações não são mais possíveis (devido à falta
de mensagens HELLO recebidas). Uma falha de roteador só é detectada quando o
roteador com falha fica isolado no mapa de rede (consulte a Seção 2.4.9).
2.1.3 Monitoramento de comunicações bidirecionais

Receber mensagens HELLO de um vizinho significa que o vizinho está vivo e pode
se comunicar conosco, mas não garante que possamos nos comunicar com ele.
Para ver isso, considere um link ponto a ponto que consiste em dois cabos para
transmissão em qualquer direção e suponha que um cabo falhe, mas o outro não.
Isso é ilustrado na Figura 2.3.a. O roteador R1 recebe mensagens HELLO do
roteador R2, mas a comunicação do roteador R1 para o roteador R2 não é possível
devido à falha do link. Assim, a recepção de mensagens HELLO per se não é uma
indicação de que a comunicação na direção de saída é possível. Como será visto
mais adiante, ter essas informações é necessário para manter o mapa da rede
atualizado (consulte a discussão da Seção 2.2.1.7).
Um roteador pode monitorar as comunicações de saída com um vizinho, se o

OLÁ (R1,R2) 3
OLÁ (R1)
1
(a) R1 R2 R1 R2 (b)
2
OLÁ (R2) OLÁ (R1, R2)
FIGURA 2.3: Monitorando comunicações bidirecionais por meio do protocolo Hello.
vizinho reconhece a recepção das mensagens HELLO transmitidas pelo roteador. Isso pode ser
alcançado se as mensagens HELLO listarem não apenas o identificador do roteador de envio, mas
também os identificadores dos vizinhos ativos no link. O procedimento se aplica a links ponto a ponto
e compartilhados e é ilustrado na Figura 2.3.b. O roteador R1 envia uma mensagem OLÁ listando a
si mesmo (etapa 1). Na próxima mensagem HELLO enviada por R2, o roteador lista a si mesmo e
R1 (etapa 2), e quando R1 recebe esta mensagem, conclui que as comunicações para R2 estão
operacionais. Da mesma forma, na próxima mensagem HELLO enviada por R1, o roteador lista a si
mesmo e R2 (etapa 3), e quando R2 recebe esta mensagem, conclui que as comunicações para R1
estão operacionais. Nos protocolos LSR, dois roteadores só são considerados vizinhos se a
comunicação bidirecional entre eles for verificada.
2.1.4 O protocolo Hello completo

Agora podemos dar uma descrição completa do protocolo Hello:
• Os roteadores mantêm uma lista dos vizinhos ativos em um link, onde cada entrada
corresponde a um vizinho e tem uma idade e um tempo de vida;
• Os roteadores transmitem periodicamente em um link mensagens HELLO contendo sua lista de

vizinhos ativos;
• Quando um roteador recebe uma mensagem HELLO de um novo vizinho, ele instala uma nova
entrada na lista com o identificador daquele vizinho e idade zero; caso contrário, se o vizinho já
existir, ele simplesmente zera a idade da entrada correspondente;
• A idade de uma entrada continua aumentando e, se atingir o tempo de vida, é

removido da lista de vizinhos ativos.
O timer que regula a transmissão de pacotes HELLO é chamado de Hello timer, e aquele que é
usado para detectar se um vizinho ainda está ativo (ou seja, se o

R1 R1 R1
R2 R2 R2
R3 R3 R3
R1 R2 R1 R2
+(//2 +(//2 +(//2
+(//2 +(//2
R1 R1
R2 R3 R2 R3
R3 R3
R1
R3 R1 R2
+(//2
+(//2
R1
R3
R3
FIGURA 2.4: Protocolo Hello para redes gerais.
a idade da entrada correspondente ainda é menor do que o tempo de vida) é chamado

Hello liveness timer.
O protocolo é ilustrado na Figura 2.4. Os roteadores R1, R2 e R3 enviam periodicamente
no link mensagens HELLO e, com base no conteúdo das mensagens recebidas, constroem
suas listas de vizinhos ativos (Figura 2.4.a). Se o roteador R2 falhar, ele para de enviar
mensagens HELLO no link, e a entrada relativa a este roteador nas listas de R1 e R3
continua envelhecendo (Figura 2.4.b). Quando as entradas atingem o tempo de vida, elas
são removidas das listas, significando que R1 e R3 não consideram mais R2 como vizinho
(Figura 2.4.c).
2.1.5 Identificando vizinhos

A operação correta do protocolo Hello requer que os roteadores tenham identificadores
exclusivos dentro de um link. No entanto, como um roteador pode ter mais de uma
interface anexada ao mesmo link (no caso de links compartilhados), o protocolo exige que
as interfaces tenham identificadores exclusivos dentro de um link. Existem várias maneiras de

conseguir isso, dependendo da tecnologia. OSPFv2 identifica cada interface usando endereços IPv4
e IS-IS usando endereços MAC; esses endereços são globalmente exclusivos. No OSPFv3, os
roteadores identificam suas interfaces concatenando o identificador do roteador (que é único em
um domínio de rede) com um número de interface atribuído localmente pelo roteador.
2.1.6 Usos adicionais do protocolo Hello

O protocolo Hello auxilia outros mecanismos dos protocolos LSR. Um desses mecanismos é a
eleição de um roteador designado em enlaces compartilhados, que será discutido na Seção 2.2.1.4.
O protocolo também é usado para determinar se dois roteadores podem realmente se tornar vizinhos.
Por exemplo, no OSPF, duas interfaces conectadas ao mesmo link só podem se tornar vizinhas se
pertencerem à mesma área.
Para manter o mapa da rede atualizado, os roteadores precisam manter uma lista dos
vizinhos ativos em cada um de seus links. Isso é obtido pelo protocolo Hello. Nesse
protocolo, cada roteador transmite periodicamente em cada enlace mensagens HELLO
contendo sua lista de vizinhos ativos. Se um roteador deixa de enviar mensagens HELLO
por algum tempo, seus vizinhos assumem que ele foi removido do link. O protocolo Hello
também é usado para determinar se a comunicação entre dois roteadores é bidirecional.
2.2 estrutura LSDB

O LSDB contém as informações de roteamento necessárias para construir as tabelas de
encaminhamento. Conforme discutido acima, existem três tipos de informações de roteamento:
informações topológicas, de endereçamento e de link. Com exceção das informações de link, as
informações de roteamento devem ser as mesmas em todos os roteadores, para que os roteadores
possam calcular tabelas de encaminhamento consistentes. Dizemos que os roteadores devem
manter o LSDB sincronizado. Uma boa maneira de atingir esse objetivo é usar uma estratégia
distribuída, onde cada roteador dissemina para todos os outros informações sobre sua visão local da
rede. Chamamos essa informação de Registro de Rede (NR) e o roteador que a cria de roteador de
origem . A disseminação de NRs é realizada por meio de um procedimento de inundação controlado
e confiável, que será explicado na Seção 2.4. As seções a seguir descrevem em detalhes a estrutura
do LSDB.
2.2.1 O mapa da rede

Nos protocolos LSR, cada roteador deve construir e manter um mapa da rede, ou seja, uma
representação da topologia completa da rede, contendo todos os seus roteadores

2.2 estrutura LSDB 51
e links. Esta seção discute os vários aspectos relacionados à estrutura do mapa de rede.
2.2.1.1 A representação da rede
A representação da rede depende de uma abstração da rede física, que oculta seus detalhes
irrelevantes. Para obter essa representação, é preciso considerar três aspectos:
• Quais tipos de elementos topológicos são considerados na representação da rede

sentação?
• Como são identificados os elementos topológicos?
• Como é descrita a topologia da rede (ou seja, a conexão entre os elementos topológicos)?
Seguindo a Seção 1.7.2, reconhecemos três tipos de elementos topológicos: (i) roteadores,
(ii) links compartilhados e (iii) links ponto-a-ponto e assumimos que esses elementos são
identificados usando espaços de nomes separados. Para facilitar a leitura, vamos nos referir aos
nomes dos elementos topológicos como identificadores.
Além disso, para distinguir entre os tipos de elementos, prefixamos os identificadores do roteador
com R, os identificadores de link compartilhado com ls e os identificadores de link ponto a ponto
com lp.
Para construir o mapa da rede, cada roteador descreve sua visão local da topologia da rede
usando um NR. A NR inclui (i) o identificador do roteador, (ii) os identificadores dos links aos
quais o roteador está conectado e (iii) os custos atribuídos às interfaces do roteador
correspondentes. O NR montado por um roteador é disseminado para todos os outros e, para
construir o mapa completo da rede (para resolver o quebra-cabeça...), cada roteador junta os
NRs recebidos, assim como os seus próprios.
A Figura 2.5 mostra, para a rede da Figura 1.1, a visão local de cada roteador e as NRs
correspondentes. Para facilitar a análise, repetimos o gráfico da rede na parte superior da figura.
Por exemplo, o NR do roteador R2 informa que o roteador está conectado aos links lp1, lp2 e ls2,
com custos de 10, 20 e 30, respectivamente; e o NR do roteador R3 informa que o roteador está
conectado aos enlaces ls1 e ls2, com custos de 25 e 15, respectivamente. Em um cenário onde
todos os roteadores são ligados ao mesmo tempo (cold start), inicialmente cada roteador conhece
apenas seu próprio NR. Neste momento, a rede ainda é vista como quatro ilhas isoladas!
A Figura 2.6 mostra a construção passo a passo do mapa de rede no roteador R3; todos os
outros roteadores se comportam de maneira semelhante. Inicialmente (Figura 2.6.a), o roteador
R3 conhece apenas a si mesmo e os links aos quais está conectado, ou seja, ls1 e ls2; ele tem
apenas um NR - o seu próprio - em seu mapa de rede. Quando o roteador R2 dissemina seu NR
(Figura 2.6.b), R3 aprende sobre a existência de R2 e seus links, lp1, lp2 e ls2; R3 também
aprende que pode se comunicar diretamente com R2 por meio do link ls2.
No entanto, neste ponto, R3 ainda tem uma visão parcial da rede: não

40 lp1 10
R1 R2
30
5 50 20
ls1 ls2
lp2
25 15 5
5
R3 R4
10
ls3
R1
lp1: 40
ls1: 5
ls2: 50
lp1 Registro de Rede (NR)

R1 40
5 50
R2
ls1 ls2
lp1: 10
lp2: 20
ls2: 30
lp1 10
R2
30
20
ls2
lp2
ls1 ls2
25
15
R3 ls2
lp2
5
R3 R4 5
ls1: 25
ls2: 15
lp2: 5 R4
ls2: 5
ls3: 10 10 ls3
FIGURA 2.5: Visualização da rede local de cada roteador e os correspondentes Net work Records
(NRs), na rede da Figura 1.1.

ls1 ls2
R3
ls1: 25
25 15
ls2: 15
R3
(a)
lp1 10 R2
R2
30
lp1: 10
20 lp2: 20
ls1 ls2 ls2: 30
lp2
R3
25
ls1: 25
15
ls2: 15
R3
(b)
R2
lp1 10 lp1: 10
R2 lp2: 20
30
20 ls2: 30
ls1 ls2 R3
lp2 ls1: 25
ls2: 15
25 15 5
5 R4
R3 R4 lp2: 5
ls2: 5
10
ls3 ls3: 10
(c)
R1
lp1: 40
40 lp1 10
R1 R2 ls1: 5
30 ls2: 50
5 50 20
ls1 ls2 R2
lp2 lp1: 10
lp2: 20
25 15 5 ls2: 30
5
R3 R4 R3
ls1: 25
10 ls2: 15
ls3
R4
(d)
lp2: 5
ls2: 5
ls3: 10
FIGURA 2.6: Construção passo a passo do mapa da rede no roteador R3.

conheça os roteadores R1 e R4 e seus links. O mapa completo da rede só é obtido quando esses
dois roteadores transmitem seus NRs (Figura 2.6.ce Figura 2.6.d).
Observe que considera-se que dois roteadores estão conectados por meio de um link se seus
NRs compartilham o mesmo identificador de link. Por exemplo, sabemos que os roteadores R2 e R4
estão conectados através do link lp2 porque ambos os seus NRs incluem uma entrada referente a
esse link.
O mapa da rede é construído a partir das contribuições individuais de todos os roteadores:

cada roteador dissemina para todos os outros um Network Record (NR) contendo sua
visão local da rede, ou seja, seu identificador, e os identificadores e custos de interface
dos links aos quais está vinculado .
2.2.1.2 Configuração de identificadores de roteador e link
Os identificadores de roteadores e links devem ser configurados nos roteadores, pois apenas os
roteadores são equipamentos de camada 3 configuráveis. Os identificadores de roteador devem ser
configurados explicitamente pelo gerente de rede; dizemos que são identificadores estáticos.
Os identificadores de link também podem ser configurados estaticamente. No entanto, esta solução
é repetitiva e propensa a erros. Por exemplo, na rede da Figura 2.5, o gerente de rede teria que
configurar o mesmo identificador em todos os quatro roteadores conectados ao enlace ls2, sem
erros, para garantir a exatidão. Uma solução melhor é derivar os identificadores do link dos
identificadores do roteador, de forma que apenas o último precise ser configurado estaticamente.
Uma maneira de conseguir isso é construir o identificador do link com base nos identificadores
dos roteadores conectados ao link e contar com o protocolo Hello para disseminar os identificadores
do roteador dentro do link. Essa solução é mais flexível e evita a identificação de links por meio de
namespaces dedicados. Também traz um benefício adicional: devido ao envolvimento do protocolo
Hello, a presença ou ausência do identificador do link reflete diretamente no estado do link, como
operacional ou não operacional. Os identificadores configurados dessa forma são chamados de
identificadores dinâmicos.
Os identificadores do roteador devem ser configurados pelo gerente de rede nos

roteadores. Para reduzir a quantidade de configuração manual, os identificadores do link
podem ser obtidos dinamicamente a partir dos identificadores dos roteadores conectados
ao link, que se tornam conhecidos através do protocolo Hello.
2.2.1.3 Identificadores dinâmicos de enlace ponto a ponto
Um enlace ponto a ponto pode ser identificado em um roteador através do identificador de seu
vizinho no enlace (ou seja, o roteador do outro lado), que se torna conhecido através do protocolo
Hello. No entanto, como pode haver vários links paralelos ponto a ponto entre dois roteadores, é
necessário um elemento adicional para garantir a exclusividade dos identificadores. Este elemento
pode ser uma tag atribuída localmente pelo

identificador
tipo de vizinho identificador
de link de interface
lp1=p|2|1
i1
lp1=p|1|3
R1 i5
i3
R2
lp2=p|2|5
i7
lp2=p|1|7
FIGURA 2.7: Identificadores de enlace ponto a ponto.
roteador, único entre os enlaces ponto a ponto que levam ao mesmo vizinho; a tag geralmente
é o identificador da interface do link. Assim, um link ponto-a-ponto pode ser identificado
exclusivamente em um roteador usando três elementos: (i) o tipo de link, (ii) o identificador do
roteador vizinho e (iii) o identificador da interface que conecta o roteador ao a ligação. Observe
que um link ponto a ponto é considerado um único link que fornece comunicações em ambas
as direções. Assim, de acordo com o critério de identificação de link acima, um link ponto-a-
ponto é nomeado de forma diferente por cada um de seus roteadores finais (sabemos que
isso parece estranho...).
As interfaces de enlace ponto a ponto também são consideradas bidirecionais, ou seja,
capazes de transmitir e receber tráfego. Além disso, usaremos o alias lpi para nos referirmos
ao link ponto-a-ponto i sempre que for conveniente, tendo em vista que o identificador possui
uma estrutura interna mais complexa. Isso é ilustrado na Figura 2.7.
Os roteadores R1 e R2 são conectados por meio de dois links ponto a ponto paralelos.
Os identificadores de interface são i1 e i5 em R1 e i3 e i7 em R2. O link ponto a ponto superior
é identificado no roteador R1 por p|2|1 e no roteador R2 por p|1|3; o link ponto a ponto inferior
é identificado no roteador R1 por p|2|5 e no roteador R2 por p|1|7.
Observe que pode não ser necessário anunciar todos os links paralelos entre roteadores.
Por exemplo, se o mapa de rede está sendo construído apenas para calcular os caminhos
mais curtos, apenas o link de menor custo precisa ser anunciado.
Os links ponto a ponto são identificados usando identificadores de vizinhos em OSPF e
IS-IS. IS-IS não tem como distinguir entre links paralelos, e apenas o link de menor custo é
anunciado. O OSPF distingue entre esses links usando o endereço IPv4 atribuído à interface,
em OSPFv2, e o identificador de interface, em OSPFv3.
Um link ponto-a-ponto é identificado dinamicamente em um roteador usando três

elementos: o tipo de link, o identificador do roteador vizinho e uma tag local que
distingue entre links paralelos.

identificador DR
RD tipo
identificador de
ls1=s|5|2 de link interface DR
i2 ls3=s|5|1
i1
R5
i3
ls2=s|5|3
FIGURA 2.8: Identificadores de links compartilhados.
2.2.1.4 Identificadores dinâmicos de links compartilhados e roteadores designados
Os links compartilhados podem ser identificados dinamicamente através do identificador de um roteador

selecionado entre todos os roteadores conectados ao link. Este roteador é chamado de Roteador Designado
(DR). Em links compartilhados stub, o DR é o único roteador conectado ao link. No entanto, em links
compartilhados de trânsito, uma eleição deve ser realizada para selecionar o DR.
Eleição de DR A eleição de DR pode ser baseada no protocolo Hello, pois ele divulga periodicamente (através
de mensagens HELLO) os identificadores de todos os roteadores conectados a um link compartilhado. Os
roteadores devem concordar com algum critério para decidir qual roteador é o DR. Um critério possível é
selecionar o primeiro roteador a se tornar ativo no link; outro critério é selecionar o roteador com o identificador
mais alto (ou mais baixo). OSPF usa o primeiro critério e IS-IS o segundo. Por exemplo, na rede da Figura 2.5,
o DR seria o roteador R1 em ambos os enlaces ls1 e ls2, se o critério for o identificador mais baixo primeiro,
ou o roteador R3 no enlace ls1 e o roteador R4 no enlace ls2, se o critério for o identificador mais alto primeiro.
Exclusividade da identificação do link O primeiro exemplo acima mostra que um roteador pode ser o DR em
mais de um link compartilhado. Assim, para garantir a unicidade na identificação de links compartilhados, é
necessário um elemento adicional. Este elemento pode ser um tag atribuído localmente pelo DR, único entre
os enlaces onde o roteador é o DR; a tag geralmente é o identificador da interface que conecta o DR ao link.
Assim, um link compartilhado é identificado dinamicamente por meio de três elementos: (i) o tipo de link, (ii) o
identificador do DR e (iii) o identificador da interface que conecta o DR ao link. Da mesma forma que os links
ponto-a-ponto, usaremos o alias lsi para nos referirmos ao link compartilhado i sempre que conveniente,
lembrando que o identificador possui uma estrutura interna mais complexa. A Figura 2.8 apresenta uma
ilustração. No exemplo, o roteador R5 é o DR em três links compartilhados; o identificador do link conectado
via interface i1 é s|5|1, o link conectado via interface i2 é s|5|2 e o link conectado via interface i3 é s|5|3.
Links compartilhados são identificados desta forma em IS-IS e OSPFv3. No OSPFv2, o identificador DR
não é usado e os links compartilhados são identificados por meio do endereço IPv4 atribuído à interface DR
anexada ao link.

Anunciando o identificador de link compartilhado Uma vez que o identificador de link compartilhado
é determinado pelo DR, ele deve ser anunciado a todos os roteadores conectados ao link. Sem
essa informação, os roteadores não conseguem finalizar a montagem de suas NRs. Por exemplo,
na rede da Figura 2.5, os roteadores R1 a R4 não podem concluir a construção de seus NRs sem
saber que ls2 é o identificador do link compartilhado ao qual estão conectados. Mesmo que os
roteadores possam determinar por conta própria qual roteador é o DR (porque todos eles
conhecem a regra de eleição), a tag identificadora é atribuída localmente pelo DR e apenas o DR
a conhece inicialmente. Uma solução simples para anunciar o identificador de link compartilhado
é usar o protocolo Hello. Como antes, os roteadores conectados a um link compartilhado primeiro
se tornam vizinhos (isto é, eles estabelecem comunicação bidirecional) e elegem o DR. Depois
que a eleição é concluída, o DR compõe o identificador do link compartilhado e o anuncia nas
mensagens HELLO subsequentes que ele transmite no link. Assim, um campo para anunciar o
identificador de link compartilhado deve ser adicionado às mensagens HELLO transmitidas em
links compartilhados.
Um link compartilhado é identificado dinamicamente através do identificador de um

roteador eleito entre todos os roteadores conectados ao link, denominado Roteador
Designado (DR). O identificador do link é composto por três elementos: o tipo de link,
o identificador do DR e uma tag local atribuída pelo DR para distinguir entre os vários
links compartilhados onde está o DR.
2.2.1.5 Tipos de mudanças de rede e suas consequências
As redes são altamente dinâmicas. Quando o estado de uma rede muda, o mapa da rede deve
ser atualizado o mais rápido possível para refletir a nova realidade. Isso significa que as NRs,
uma vez criadas e divulgadas, podem precisar ser substituídas por versões mais atualizadas
contendo informações mais recentes. Especificamente, se um roteador detecta uma alteração em
si mesmo ou nos links aos quais está conectado, ele deve disseminar um novo NR para informar
todos os outros e atualizar o mapa da rede. Assim, os NRs devem ter um atributo de atualização
para expressar o quão recentes eles são, de modo que os NRs mais recentes possam substituir
os mais antigos no mapa de rede. Iremos nos referir aos sucessivos NRs originados por um
roteador como instâncias NR. Na Seção 2.4.1, discutiremos como os atributos de frescor podem
ser compostos.
Três tipos de mudanças de rede precisam ser considerados:
• Alterações nos custos de interface;
• Adições de roteadores e links;
• Remoções de roteadores e links (por exemplo, falhas).
Alterações nos custos da interface Quando o custo de uma interface é alterado em um roteador,
o roteador dissemina uma nova instância de NR com o novo custo, que substituirá a antiga.
Adições de roteadores e links Da mesma forma, quando um novo link é anexado a um roteador,
o roteador dissemina uma nova instância NR com uma nova entrada

contendo o identificador do link e o custo da interface correspondente. Além disso, quando um

roteador entra na rede, ele dissemina uma nova NR se identificando e descrevendo seus enlaces.
Remoções de roteadores e links A remoção de roteadores e links é mais difícil de lidar. Dois tipos
de remoções podem ser identificados: remoções suaves, ou seja, remoções por meio de ações de
configuração, e remoções definitivas, ou seja, falhas. Uma remoção de link (soft ou hard) é detectada
pelos roteadores conectados ao link, por exemplo, por meio de mecanismos de hardware ou do
protocolo Hello. Quando um roteador detecta esse evento, ele dissemina uma nova instância de NR
sem a entrada associada ao link removido. Os links compartilhados podem falhar apenas
parcialmente, mantendo duas ou mais ilhas de conectividade separadas; discutiremos esse problema
na Seção 2.2.1.6.
O impacto das remoções do roteador no mapa de rede depende se a remoção é uma remoção
suave ou uma falha. Quando um roteador é removido temporariamente, ele tem a oportunidade de
excluir seu NR dos LSDBs dos roteadores restantes antes de ser removido (por exemplo, desligado).
Isso pode ser feito disseminando uma mensagem de exclusão por toda a rede; abordaremos essa
questão na Seção 2.4.6. No entanto, quando um roteador falha, ele não tem oportunidade de excluir
seu NR.
Isso mostra que o mapa da rede pode conter NRs desatualizados e, como será mostrado adiante,
esses NRs podem levar a conclusões errôneas sobre a conectividade da rede; este problema será
discutido na Seção 2.2.1.7.
O grafo de conectividade Para estudar o problema das NRs desatualizadas, recorremos a um grafo
que expressa a conectividade que deriva do mapa da rede; nós o chamamos de gráfico de
conectividade. Neste grafo, os roteadores são representados como nós e a conectividade entre os
roteadores como arcos. Haverá um arco entre dois nós somente se a comunicação entre os
roteadores correspondentes for bidirrecional, pois somente neste caso os dois roteadores podem
ser considerados vizinhos (ver Seção 2.1).
Nas próximas seções, analisaremos em detalhes como o particionamento do link compartilhado

e as falhas do roteador afetam o mapa da rede. A discussão será realizada usando a rede da Figura
2.9, que inclui um enlace compartilhado conectando quatro roteadores e três enlaces ponto a ponto.
A Figura 2.9.a mostra o mapa da rede e a Figura 2.9.b o gráfico de conectividade. No gráfico, há um
arco conectando cada par de roteadores conectados ao link compartilhado. O gráfico também mostra
que R1 e R2 estão diretamente conectados por meio de dois links diferentes.
2.2.1.6 Reação ao particionamento de link compartilhado
Conforme discutido na Seção 1.8.2, links compartilhados podem ser particionados em duas ou mais
ilhas de conectividade; neste caso, a rede deve continuar utilizando as partes resultantes para fins
de roteamento, se possível. Felizmente, o mecanismo para atribuir identificadores dinâmicos de links
compartilhados lida corretamente com esse problema. Quando um link particiona, o protocolo Hello
identifica os subgrupos de roteadores que ainda podem se comunicar entre si e elege um DR para
cada subgrupo, exceto o subgrupo do DR anterior. Então, novo link

40
lp1 10
R1 R2 5
30 lp2
50
10
ls1 R5
15
5 lp3
15
R3 R4 25
R1 R2 R3 R4 R5
lp1: 40 lp1: 10 ls1: 15 lp3: 25 lp2: 10 (a)
ls1: 50 lp2: 5 ls1: 5 lp3: 15
ls1: 30
R1 R2
R5 (b)
R3 R4
FIGURA 2.9: Exemplo de rede para estudar o impacto no mapa de rede de

particionamento de link e falhas de roteador; (a) mapa de rede e (b) grafo de
conectividade correspondente.
são obtidos identificadores (com base nos novos DRs), e os roteadores conectados
aos links onde o identificador do link foi alterado divulgam novas instâncias de NR com
as informações atualizadas.
Isso é ilustrado na Figura 2.10. O roteador R2 é inicialmente o DR do link
compartilhado e o identificador do link compartilhado é ls1=s|2; não incluímos o número
da interface nos identificadores de links compartilhados, pois, nesta rede de exemplo,
não é necessário identificar exclusivamente os links. Quando o link é particionado, os
roteadores R1 e R3 param de receber mensagens HELLO dos roteadores R2 e R4 e
vice-versa. Assim, dois subgrupos são formados, cada um contendo apenas os
roteadores que se reconhecem como vizinhos através do protocolo Hello. O subgrupo
de roteadores R1 e R3 elege um novo DR, que neste exemplo é o roteador R3, e o
DR define o identificador do novo link como ls2=s|3. Este identificador é comunicado
ao roteador R1 através do protocolo Hello, e tanto R1 quanto R3 disseminam uma
nova instância NR contendo o novo identificador de enlace. No subgrupo de roteadores
R2 e R4 não há eleição de DR (o roteador R2 continua sendo o DR) e o identificador
do link permanece o mesmo. A Figura 2.10.a mostra

40 lp1 10
R1 R2 5
30 lp2
50
10
DR (ls1)
ls2=s|3 R5
ls1=s|2
15
5 lp3
15
R3 R4 25
DR (ls2)
R1 R2 R3 R4 R5
lp1: 40 lp1: 10 ls2: 15 lp3: 25 lp2: 10 (a)
ls2: 50 lp2: 5 ls1: 5 lp3: 15
ls1: 30
R1 R2
R5 (b)
R3 R4
FIGURA 2.10: Particionamento de link compartilhado; (a) mapa da rede após o particionamento e (b)
grafo de conectividade correspondente.
o mapa da rede após o particionamento, onde os NRs dos roteadores R1 e R3 já se referem ao

enlace ls2 (em vez de ls1), e a Figura 2.10.b mostra o grafo de conectividade correspondente. Pode-
se ver que, apesar do particionamento, todos os roteadores ainda podem se comunicar entre si. Por
exemplo, os roteadores R3 e R4 não podem se comunicar diretamente por meio do link compartilhado,
como antes, mas podem se comunicar por meio dos roteadores R1 e R2.
2.2.1.7 Reação a falhas do roteador
Um roteador que falha não pode excluir seu NR do mapa de rede. Porém, em geral, a falha de um
roteador pode ser inferida a partir das informações veiculadas por seus vizinhos, o que permite
atualizar corretamente as tabelas de encaminhamento. Especificamente, quando um roteador falha,
seus vizinhos detectam o evento através do protocolo Hello e disseminam novas instâncias de NR
onde o link com o roteador que falhou não está mais listado. Então, na maioria dos cenários de falha,
o roteador com falha fica isolado no mapa de rede e, quando outros roteadores reconstroem suas
tabelas de encaminhamento, as novas rotas não cruzarão mais o roteador com falha.

40 lp1 10
R1 R2 5
30 lp2
50
10
ls1 R5
15
5 lp3
15
R3 R4 25
5 lp1: 5 lp1: 5 ls1: 15 5 ls1: 5 5 lp2: (a)

40 ls1: 50 10 ls1: 30 10 lp3: 15
R1 R2
R5 (b)
R3 R4
FIGURA 2.11: Falha de roteador conectado com vizinhos através de enlaces ponto a ponto
(caso 1); (a) mapa da rede após a falha e (b) grafo de conectividade correspondente.
Infelizmente, existem alguns cenários de falha em que o roteador com falha não fica isolado
no mapa de redes.
Três casos devem ser considerados em relação ao vizinho que detecta uma falha:
1. O vizinho está conectado ao roteador com falha por meio de um ponto a

ponto de ligação;
2. O vizinho está conectado ao roteador com falha por meio de um link compartilhado
e o roteador que falhou foi o link DR;
3. O vizinho está conectado ao roteador com falha por meio de um link compartilhado
e o roteador com falha não era o link DR.
Caso 1 O primeiro caso é ilustrado na Figura 2.11. O roteador R5 está conectado aos
roteadores R2 e R4 por meio de links ponto a ponto. Quando o roteador R5 falha, os
roteadores R2 e R4 detectam a falha através do protocolo Hello e ambos divulgam novas
instâncias de NR onde seu link com o roteador R5 não está mais listado. A Figura 2.11.a
mostra que o NR do roteador R5 permanece no mapa da rede após o

40
lp1 10
R1 R2 5
30 lp2
50
10
ls1=s|2
ls2=s|3
antigo DR
R5
15
5 lp3
15
R3 R4 25
novo DR
(a)
5 ls2: 50 5 lp1: 5 ls2: 15 5 lp3: 5 lp3: 15
10 25 ls2: 5
lp2: 5 ls1: 30
R1 R2
R5 (b)
R3 R4
FIGURA 2.12: Falha de roteador conectado com vizinhos através de um link compartilhado onde é o
DR (caso 2); (a) mapa da rede após a falha e (b) grafo de conectividade correspondente.
falha. Porém, conforme visto no gráfico de conectividade da Figura 2.11.b, o roteador R5 fica isolado
e, portanto, não será mais utilizado para fins de roteamento.
Caso 2 O segundo caso é ilustrado na Figura 2.12. Nesse caso, o roteador R2 é o DR no link
compartilhado e falha. A falha é detectada por seus vizinhos no link compartilhado (e em seus links
ponto-a-ponto), através do protocolo Hello. Uma vez detectada a falha, os demais roteadores
conectados ao link compartilhado elegem um novo DR e definem um novo identificador para o link;
isso é novamente realizado por meio do protocolo Hello. Assumimos que o identificador do enlace
era inicialmente ls1=s|2 e, após a falha, mudou para ls2=s|3. Como o identificador do link foi
alterado, os roteadores conectados ao link compartilhado disseminam uma nova instância de NR,
onde o identificador do link antigo é substituído pelo novo. Além disso, os links ponto a ponto que
levam ao roteador R2 são suprimidos dos NRs dos roteadores R1 e R5. A Figura 2.12.a mostra o
mapa da rede após a falha do roteador R2, e a Figura 2.12.b mostra o gráfico de conectividade
correspondente. Como no exemplo anterior, o NR do roteador que falhou fica no

40 lp1 10
R1 R2 5
50 30 lp2
10
RD
ls1=s|2 R5
15
5 lp3
15
R3 R4 25
5 lp1: 5 lp2: 5 ls1: 15 5 lp3: 5 lp2: (a)

40 ls1: 50 5 ls1: 30 25 ls1: 5 10 lp3: 15
R1 R2
R5 (b)
R3 R4
FIGURA 2.13: Falha de roteador conectado com vizinhos através de um link

compartilhado onde não é o DR (caso 3); (a) mapa da rede após a falha e (b) grafo
de conectividade correspondente.
mapa da rede. No entanto, conforme visto no gráfico de conectividade, o roteador R2

fica isolado e não será mais usado para fins de roteamento.
Caso 3 O terceiro caso é ilustrado na Figura 2.13. Nesse caso, o roteador R1 falha,
mas o roteador não é o link DR. A falha é detectada por seus vizinhos no link
compartilhado e em seu link ponto a ponto. Porém, como o roteador que falhou não é
o DR, não há necessidade de eleger um novo DR, e o identificador do link permanece
o mesmo. Observe que, ao contrário dos roteadores R2, R3 e R4, o roteador R5 não
é vizinho do roteador R1 e, portanto, não pode detectar a falha pelo protocolo Hello:
nada mudou, sob a perspectiva deste roteador! (Na verdade, esta foi a motivação
para selecionar esta topologia de rede para estudar o problema de NRs
desatualizados). O mapa da rede após a falha é mostrado na Figura 2.13.a, e o grafo
de conectividade correspondente na Figura 2.13.b. Ao contrário dos casos anteriores,
o roteador com falha (roteador R1, neste caso) permanece acessível por todos os
outros roteadores, o que é incorreto.
O problema raiz destacado por este exemplo é que o identificador de link
compartilhado abstrai (muito...) a conectividade pairwise entre roteadores conectados
a um link compartilhado, e essa simplificação é incapaz de lidar com algumas falhas

cenários. O problema não existiria se um identificador de link diferente fosse assinado para cada
par de roteadores se comunicando por um link compartilhado. No entanto, essa solução não
escalaria, conforme discutido na Seção 1.7.1.
Soluções alternativas para o problema do caso 3 Uma solução para este problema é impor uma
mudança no identificador do enlace sempre que for detectada a falha de um roteador não DR. Isso
pode ser implementado facilmente: o DR apenas modifica a tag que, juntamente com o identificador
do DR, compõe o identificador do link compartilhado. A desvantagem dessa solução é que, em caso
de falha, todos os roteadores devem disseminar uma nova instância de NR, contendo o novo
identificador do enlace.
Outra solução para este problema é criar um novo tipo de NR, descrevendo links compartilhados
e seus roteadores conectados. Esta é a solução adotada em OSPF e IS-IS, e a discutiremos na
próxima seção.
2.2.1.8 O link compartilhado-NR
A falha de um roteador não DR conectado a um link compartilhado não é refletida no mapa da rede,
pois o identificador do link não muda em reação à falha. Uma maneira de lidar com esse problema é
introduzir um novo tipo de NR para representar enlaces compartilhados de trânsito e seus roteadores
conectados. Esta NR inclui (i) o identificador do link e (ii) os identificadores de todos os roteadores
conectados ao link. Dessa forma, falhas de roteadores conectados a links compartilhados, DR ou
não-DR, tornam-se imediatamente visíveis no mapa da rede. Este NR será chamado de NR de link
compartilhado (slink-NR para abreviar) e, para evitar confusão, chamaremos de NR de roteador o
NR introduzido anteriormente para representar um roteador e seus links. Os links compartilhados
stub não precisam ser representados por slink-NRs, pois esses links possuem apenas um roteador
conectado.
Uma questão imediata é qual roteador deve ser responsável por originar slink-NRs. A escolha
natural é o DR do enlace compartilhado, pois este roteador já é eleito dentre os roteadores atrelados
ao enlace para efeito de definição do identificador do enlace.
Exemplo com router-NRs e slink-NRs A Figura 2.14 mostra o mapa da rede da Figura 1.1, estruturada
com router-NRs e slink-NRs.
Os roteadores-NRs descrevem os roteadores e seus links, e são exatamente como antes.
Mas o mapa de rede agora inclui dois slink-NRs, cada um representando um dos enlaces
compartilhados de trânsito, ou seja, enlaces ls1 e ls2. Por exemplo, o slink-NR do link ls2 lista todos
os quatro roteadores conectados ao link. Observe que as informações topológicas coletadas dos
slink-NRs podem ser completamente inferidas dos roteadores-NRs. Assim, deste ponto de vista,
slink-NRs não adicionam nenhuma informação.
No entanto, conforme discutido acima, eles fornecem uma maneira de lidar com falhas do roteador.
Como os slink-NRs resolvem o problema de falhas não DR em links compartilhados? O uso de slink-
NRs permite verificar duplamente a conectividade da rede.
Em particular, dois roteadores só são considerados conectados entre si por meio de um link
compartilhado de trânsito se (i) seus roteadores NRs se referirem ao link (através do identificador do
link) e (ii) o slink-NR que descreve o link se referir ao dois roteadores

40 lp1 10
R1 R2
30
5 50 20
ls1 ls2
lp2
25 15 5
5
R3 R4
10
ls3
R2 ls1
R1 lp1: lp1: 10 R1
40 lp2: 20 R3
ls1: 5 ls2: 50 ls2: 30
ls2
R3 R4 R1
ls1: 25 lp2: 5 R2
ls2: 15 ls2: 5 R3
ls3: 10 R4
router-NRs NRs de links compartilhados
FIGURA 2.14: Mapa da rede da Figura 1.1 estruturada com router-NRs e slink-NRs.
(através de seus identificadores de roteador). Essas condições devem ser levadas em

consideração ao construir o grafo de conectividade.
A Figura 2.15 ilustra como o uso de slink-NRs resolve o problema de falhas não DR
em enlaces compartilhados, ilustrado na Figura 2.13 (caso 3). A Figura 2.15.a mostra o
mapa da rede antes da falha. O mapa de rede agora inclui um slink-NR, listando todos
os roteadores conectados ao link compartilhado de trânsito ls1. Quando o roteador R1
falha, o roteador R2, o DR do enlace ls1, detecta a falha através do protocolo Hello e
divulga um novo slink-NR sem R1 listado, que substitui o anterior. O novo mapa de rede
é mostrado na Figura 2.15.b. Novamente, o roteador-NR do roteador R1 fica no mapa
da rede, indicando que o roteador pode estar conectado ao link ls1. No entanto, o
roteador não pode mais ser considerado conectado a este link, pois não está listado no
slink-NR correspondente. Assim, como mostra o gráfico de conectividade da Figura
2.15.c, o roteador fica isolado no mapa da rede.
Revisitando o caso de falhas de DR em enlaces compartilhados Para completar o

conjunto de casos interessantes, mostramos na Figura 2.16 como o mapa de rede
estruturado com router-NRs e slink-NRs é formado no caso de falha de DR (caso 2).
Isso já foi abordado na Figura 2.12, para o caso de um mapa de rede estruturado apenas
com router-NRs. O DR inicial é novamente o roteador R2 e o identificador do link é ls1=s|
2. Quando o DR falha, R3 é novamente eleito DR, e

40 lp1 10
R1 R2 5
50 30 lp2
10
ls1=s|2 RD R5
15
5 lp3
15
R3 R4 25
R1 R2 R3 ls1
lp1: 40 lp1: 10 ls1: 15 R1
ls1: 50 lp2: 5 R2 (a)
R5
ls1: 30 R3
R4 lp2: 10 R4
lp3: 25 lp3: 15
ls1: 5
router-NRs link-compartilhado-NR
R1 R2 R3 ls1
lp1: 40 lp2: 5 ls1: 15 R2
ls1: 50 ls1: 30 R3 (b)
R5
R4
R4 lp2: 10
ls1: 5 lp3: 15
lp3: 25
R1 R2
R5 (c)
R3 R4
FIGURA 2.15: Falha de roteador conectado com vizinhos através de um link compartilhado onde não
é o DR. Mapa de rede com roteador-NRs e slink-NRs (a) antes da falha, (b) após a falha e (c) grafo
de conectividade correspondente.

40 lp1 10
R1 R2 5
30 lp2
50
10
ls1=s|2
ls2=s|3
antigo DR R5
15
5 lp3
15
R3 R4 25
novo DR
R1 R2 R3 ls1
lp1: 40 lp1: 10 ls1: 15 R1
ls1: 50 lp2: 5 R2 (a)
R5
ls1: 30 R3
R4 lp2: 10 R4
lp3: 25 lp3: 15
ls1: 5
R1 R2 R3 ls1 ls2
ls2: 50 lp1: 10 ls2: 15 R1 R1
R2 R3 (b)
R4 lp2: 5 R5
ls1: 30 R3 R4
lp3: 25 lp3: 15 R4
ls2: 5
R1 R2
R5 (c)
R3 R4
FIGURA 2.16: Falha de roteador conectado com vizinhos através de link

compartilhado onde está o DR. Mapa de rede com roteador-NRs e slink-NRs (a)
antes da falha, (b) após a falha e (c) grafo de conectividade correspondente.

define ls2=s|3 como o novo identificador de link. Ele então dissemina um novo slink-NR que não
inclui mais o roteador R2. O slink-NR anterior, listando os roteadores R1 a R4 como sendo anexados
ao link ls1, permanece no LSDB, pois R2 não pôde excluí-lo (devido à falha). Assim, como visto na
Figura 2.16.b, existem agora dois slink-NRs, um novo (referente ao link ls2) e um desatualizado
(referente ao link ls1). O roteador-NR do roteador R2 também permanece no mapa de rede. Os dois
NRs desatualizados indicam que o roteador R2 pode estar conectado ao link ls1.
No entanto, nenhum outro roteador está conectado a este link, pois os roteadores-NRs de R1, R3 e
R4 foram atualizados para listar ls2 (em vez de ls1). Assim, como mostra o gráfico de conectividade
da Figura 2.16.c, o roteador R2 fica isolado no mapa da rede.
O mapa de rede deve ser mantido atualizado quando os custos de interface mudam,
quando roteadores ou links são adicionados ou removidos e quando links compartilhados
são particionados. Para lidar com o problema de falhas de roteadores, é necessária uma
nova NR descrevendo os links compartilhados e seus roteadores conectados. É chamado
de NR de link compartilhado (slink-NR) e, para evitar confusão, o NR que descreve os
roteadores e seus links agora é chamado de NR de roteador. O slink-NR é originado pelo
DR do link compartilhado que ele representa.
2.2.2 As informações de endereçamento interno da área

Até agora, nos preocupamos apenas com a representação da topologia da rede - o mapa da rede.
No entanto, para construir tabelas de encaminhamento - o objetivo final de um protocolo de
roteamento - os roteadores precisam saber quais prefixos de endereços roteáveis estão disponíveis
na rede e a quais elementos topológicos (roteadores ou links) foram atribuídos. Existem várias
possibilidades de combinar as informações topológicas e de endereçamento no LSDB. Nas próximas
seções, discutimos as alternativas para representar o endereçamento em formação interna a um
domínio de roteamento de área única. A representação de informações de address externas a um
domínio de roteamento será discutida na Seção 2.2.4.
2.2.2.1 Separando informações topológicas e de endereçamento
Do ponto de vista do roteamento, é possível e desejável separar as informações relacionadas à

topologia da rede, ou seja, as informações topológicas, daquelas relacionadas aos prefixos roteáveis,
ou seja, as informações de endereçamento.
Há dois aspectos nessa separação: o primeiro diz respeito aos namespaces utilizados por esses
dois tipos de informação, e o segundo diz respeito à forma como a informação é disseminada.
Discutiremos esses dois aspectos a seguir.
Espaços de nomes Os identificadores de elementos topológicos podem, em princípio, compartilhar

o espaço de nomes de prefixos roteáveis. No entanto, isso não é desejável, pois esses dois tipos de
identificadores possuem funções intrinsecamente diferentes. Os identificadores de roteadores e links
visam a representação da rede intradomínio:

FIGURA 2.17: Separação das informações topológicas e de endereçamento em OSPFv2, OSPFv3

e IS-IS.
eles só precisam ser únicos dentro de um domínio de roteamento e não precisam estar presentes
nas tabelas de encaminhamento. Por outro lado, os prefixos roteáveis representam os destinos
finais da informação: eles devem estar presentes nas tabelas de encaminhamento e, para
comunicações em toda a Internet, devem estar preparados para identificar inequivocamente o
conjunto das interfaces da Internet. Assim, o espaço de nomes dos prefixos roteáveis precisa ser
muito maior em tamanho e escopo do que os identificadores topológicos. Uma sobrecarga
significativa é incorrida se alguém usar endereços roteáveis para identificar roteadores e links,
especialmente em uma época em que o número de hosts está aumentando muito rapidamente,
pressionando pela implantação rápida do endereçamento IPv6.
Assim como os identificadores de roteadores, links ponto a ponto e links compartilhados são
precedidos pelas palavras-chave R, lp, ls, respectivamente, os prefixos de endereços roteáveis
serão precedidos pela palavra-chave ap.
Divulgação O segundo aspecto mencionado acima diz respeito à divulgação de informações
topológicas e de endereçamento. Esses dois tipos de informação podem ser divulgados em
conjunto ou separadamente, mas há boas razões para divulgá-los separadamente. Primeiro, os
prefixos atribuídos a roteadores ou links específicos podem mudar com o tempo e podem mudar
com mais frequência do que a topologia da rede. Em segundo lugar, novos esquemas de
endereçamento podem ser introduzidos ao longo do tempo, e foi exatamente isso que aconteceu
com a evolução do IPv4 para o IPv6.
A importância de separar informações topológicas e de endereçamento não foi reconhecida,

pelo menos inicialmente, por algumas tecnologias LSR: OSPFv2 usa o mesmo espaço de nomes
para informações topológicas e de endereçamento (pelo menos em parte), mas esses dois tipos
de informações podem ser disseminados independentemente (embora em alguns casos não o
sejam); IS-IS separa os espaços de nomes, mas obriga a que as informações topológicas e de
endereçamento sejam disseminadas juntas; por fim, o OSPFv3 separa os namespaces e permite
que esses tipos de informação sejam disseminados de forma independente. A Figura 2.17 resume
essa comparação.

Um bom princípio de projeto em relação aos protocolos LSR é a separação de informações

topológicas e de endereçamento, ou seja, descrever esses dois tipos de informações
separadamente (usando espaços de nomes independentes) e divulgá-los separadamente.
2.2.2.2 A área-prefixo-interno-NR
O router-NR e o slink-NR são os elementos necessários para representar a topologia da rede, e

vamos nos referir a eles como os NRs topológicos; eles formam o que temos chamado de mapa de
rede. Se a formação topológica e de endereçamento devem ser separadas de acordo com o
princípio introduzido na seção anterior, então uma nova NR é necessária para anunciar prefixos de
endereço e sua associação com elementos topológicos. Ele será chamado de area-internal-prefix-
NR (aip-NR para abreviar). Usamos o termo área interna porque, neste capítulo, estamos lidando
com domínios de roteamento de área única; como será discutido no capítulo 3, em domínios
multiárea há a necessidade de descrever informações de endereçamento externas a uma área
(prefixos de área externa). Observe que apenas OSPFv3 e IS-IS (IPv4 e IPv6) incluem o equivalente
a um aip-NR; O OSPFv2 mistura informações topológicas e de endereçamento, uma questão que
será discutida na Seção 2.2.2.3.
Existem três questões importantes que precisam ser abordadas em relação aos NRs de aip: (i)
como os prefixos estão relacionados aos elementos topológicos aos quais foram atribuídos, (ii) qual
roteador origina um NR de aip e (iii) quantos prefixos anunciar em cada aip-NR.
Como os prefixos estão relacionados aos elementos topológicos? Prefixos de endereço (ou mesmo
endereços individuais) podem ser atribuídos aos três tipos de elementos topológicos — roteadores,
links ponto a ponto e links compartilhados — para fornecer pontos de conexão para hosts ou para
fins de gerenciamento. Uma forma simples de relacionar prefixos a elementos topológicos é através
dos identificadores topológicos, ou seja, estabelecer uma correspondência entre os prefixos e os
identificadores dos roteadores ou enlaces aos quais estavam associados. Assim, um aip-NR deve
incluir (i) o prefixo que está sendo anunciado e (ii) o identificador do elemento topológico ao qual o
prefixo foi associado (ou seja, o ponteiro para o elemento topológico).
Roteadores anunciando prefixos em nome de links Um prefixo atribuído a um roteador é naturalmente

associado ao roteador ao qual ele pertence; assim, um aip-NR anunciando um prefixo atribuído a um
roteador aponta para o roteador usando o identificador do roteador. No entanto, um prefixo atribuído
a um link pode não estar diretamente associado ao link ao qual foi atribuído, mas a um roteador
conectado ao link. Nesse caso, o aip-NR aponta para o roteador, através do identificador do roteador,
e não para o link. Podemos dizer que o roteador anuncia o prefixo em nome do link.
Quando os prefixos atribuídos a enlaces estiverem associados a roteadores, o aip-NR publicitário

deve incluir, além do prefixo e do identificador do roteador, o custo da interface que liga o roteador
ao enlace. Esta informação é necessária para que os custos dos caminhos que levam ao prefixo
possam ser calculados. Na verdade, isso

pode ser visto como um afastamento do princípio de separação, porque os custos de

interface são misturados com prefixos de endereço. O cálculo do custo do caminho
realizado por um roteador tem duas etapas: (i) primeiro, calcular o custo do caminho
do roteador onde o cálculo está sendo feito até o roteador associado ao prefixo; (ii)
segundo, adicionar ao custo do caminho anterior o custo da interface declarado no
aip-NR que anuncia o prefixo.
Além disso, na solução acima, todos os roteadores conectados ao link devem
anunciar o prefixo, pois cada um deles fornece um caminho para o link que pode ter
um custo de caminho diferente. Assim, neste caso, um prefixo atribuído a um link
ponto-a-ponto é anunciado pelos dois roteadores finais do link, um prefixo atribuído a
links compartilhados de trânsito é anunciado por todos os roteadores conectados ao
link e um prefixo atribuído a um stub link compartilhado é anunciado pelo roteador de link (único).
No primeiro e segundo casos, haverá informações de endereçamento repetidas no
LSDB.
Removendo identificadores de link do mapa de rede Indo um passo adiante, quando
prefixos atribuídos a links são associados a roteadores, os identificadores de link
correspondentes podem ser removidos do mapa de rede. Esta é a prática usual na
representação de links compartilhados stub. Nesse caso, um prefixo atribuído a um
link compartilhado stub é associado ao (único) roteador conectado ao link e anunciado
por meio de um aip-NR que inclui (i) o prefixo, (ii) o identificador do roteador e (iii) o
custo da interface conectando o roteador ao link. Além disso, o roteador-NR
anunciando o roteador e seus links não inclui mais uma entrada relativa ao link
compartilhado do stub.
Qual roteador origina um aip-NR? Seja anunciando prefixos como assinados para
roteadores ou links, os aip-NRs só podem ser originados por roteadores, pois apenas
os roteadores são equipamentos ativos da camada 3. Naturalmente, um aip-NR
anunciando um prefixo associado a um roteador é originado por esse roteador.
Conforme discutido acima, no caso de um prefixo atribuído a um link, mas associado
a um roteador, todos os roteadores conectados ao link devem anunciar o prefixo e,
portanto, todos eles devem originar aip-NRs relativos ao prefixo.
Para prefixos atribuídos e associados a links existem essencialmente duas
alternativas: ter o prefixo anunciado por (i) todos os roteadores conectados ao link ou
(ii) um roteador selecionado entre todos os roteadores conectados ao link. Na primeira
solução haverá informações de endereçamento repetidas no LSDB, exceto no caso
de links compartilhados stub. Esta última solução implica eleger um roteador, o que
já é feito no caso de enlaces compartilhados de trânsito, para fins de definição do
identificador do enlace e origem dos slink-NRs (ver Seções 2.2.1.4 e 2.2.1.8 ) .
Quantos prefixos anunciar em cada aip-NR? Outra questão que precisa ser enfrentada
é quantos prefixos de endereços anunciar em cada aip-NR. De fato, um roteador pode
ser responsável por anunciar diversos prefixos, por exemplo, atribuídos a ele mesmo,
aos seus enlaces ponto a ponto, ou aos enlaces compartilhados onde ele é o DR.
Esses prefixos podem ser todos anunciados no mesmo aip-NR ou em diferentes. No
entanto, se um dos prefixos originados por um roteador for alterado, ele deve

FIGURA 2.18: Os originadores e ponteiros para elementos topológicos de aip-NRs em OSPF e IS-IS.
possível atualizar o LSDB sem ter que disseminar novamente todas as informações de endereçamento
originadas por aquele roteador. Assim, é preferível anunciar apenas um prefixo de endereço em
cada aip-NR, e assumiremos essa opção a seguir.
Como os prefixos são anunciados em OSPFv3 e IS-IS? No OSPFv3 e IS-IS, os prefixos atribuídos a
roteadores, links ponto a ponto e links compartilhados stub são anunciados da mesma maneira, mas
os prefixos atribuídos a links compartilhados de trânsito são anunciados de maneira diferente
(consulte a Figura 2.18) .
• Roteadores - Um prefixo atribuído a um roteador é associado ao roteador (através do identificador

do roteador) e é anunciado por um aip-NR originado pelo roteador.
• Enlaces ponto a ponto - Um prefixo atribuído a um enlace ponto a ponto é associado ao enlace
(através do identificador do enlace) e é anunciado por dois aip-NRs, cada um originado por um
dos roteadores finais do enlace.
• Links compartilhados stub - Um prefixo atribuído a um link compartilhado stub é associado ao

roteador de link (único) (através do identificador do roteador) e é anunciado por um aip-NR
originado por esse roteador. O aip-NR inclui o custo da interface que conecta o roteador ao link, e
o link é removido do mapa de rede.
• Links compartilhados de trânsito - Um prefixo atribuído a um link compartilhado de trânsito é

associado ao link (através do identificador de link) tanto no OSPFv3 quanto no IS-IS.
Porém, no OSPFv3, ele é anunciado por um único aip-NR originado pelo link DR e, no IS-IS, é
anunciado por todos os roteadores conectados ao link, cada um originando um aip-NR relativo ao
prefixo (e produzindo informações de endereçamento repetidas).

40 lp1ÿap2 10
R1 R2
30
5 50 20
ls1
lp2
ls2ÿap1
25 15 5
5
R3 R4
10
R3ÿap4 ls3ÿap3
OV DS5 ls2 DS5 lp1

5 lp1: 5 lp1: R1
40 10 lp2: R3
DS5 lp1 DS5
ls1: 5 ls2: 50 20 ls2: 30
OV R4: 10
R1
DS5
5 ls1: 5 lp2: R2
R3
25 ls2: 15 5 ls2: 5 R3
URXWHU15V
R4 DUHDLQWHUQDOSUHIL[15V
VKDUHGOLQN15V
FIGURA 2.19: LSDB da rede da Figura 1.1, com informações topológicas e de

endereçamento separadas: o caso OSPFv3.
Exemplo OSPFv3 Na Figura 2.19, ilustramos a estrutura LSDB do OSPFv3 com

informações topológicas e de endereçamento de área interna, usando a rede da Figura
1.1. Atribuímos apenas quatro prefixos de endereço: ap1 para o link compartilhado de
trânsito ls2, ap2 para o link ponto a ponto lp1, ap3 para o link compartilhado stub ls3 e
ap4 para o roteador R3. A figura mostra as diversas NRs que compõem a LSDB. A
informação topológica é dada pelos router-NRs e slink-NRs, como antes. Eles coincidem
com os da Figura 2.14, exceto pelo stub do link compartilhado que não está mais
representado.
A informação de endereçamento é fornecida pelos aip-NRs. Na figura, incluímos,
entre parênteses, os originadores de aip-NR. O prefixo ap1 é anunciado através de um
aip-NR originado pelo DR do link ls2, que supomos ser R1. O prefixo ap2 é anunciado
através de dois aip-NRs, um originado pelo roteador R1 e outro pelo roteador R2. O
prefixo ap3 é anunciado através de um aip-NR originado pelo roteador R4, e inclui o
custo da interface anexada ao link, ou seja, um custo de 10. Finalmente, o prefixo ap4
é anunciado através de um aip-NR originado pelo roteador R3.
Exemplo de IS-IS A Figura 2.20 repete o caso da Figura 2.19, mas para IS-IS.
A única diferença é que o prefixo ap1, atribuído ao link compartilhado de trânsito,

40 lp1ÿap2 10
R1 R2
30
5 50 20
ls1
lp2
ls2ÿap1
25 15 5
5
R3 R4
10
R3ÿap4 ls3ÿap3
R1 R2 ls1 ap1 (R1) ap1 (R2)

lp1: 40 lp1: 10 R1 ls2 ls2
ls1: 5 lp2: 20 R3
ls2: 50 ls2: 30 ap1 (R3) ap1 (R4)
ls2 ls2 ls2
R3 R4 R1
ls1: 25 R2 ap2 (R1) ap2 (R2)
lp2: 5
R3 lp1 lp1
ls2: 15 ls2: 5
R4 ap3 (R4) ap4 (R3)
router-NRs
R4: 10 R3
NRs de links compartilhados
área-interna-prefixo-NRs
FIGURA 2.20: LSDB da rede da Figura 1.1, com informações topológicas e de endereçamento
separadas: o caso IS-IS.
é anunciado por quatro aip-NRs, cada um originado por um dos roteadores conectados ao link. Tem
muita informação repetida!
Destacamos aqui que nem todos os elementos topológicos precisam receber endereços
roteáveis. Este é um equívoco comum, provavelmente estimulado pelas tecnologias que misturam
informações topológicas e de endereçamento. Somente os elementos topológicos que devem ser
acessíveis (por exemplo, para fins de gerenciamento ou porque possuem hosts anexados) precisam
receber endereços. Por exemplo, um link compartilhado que é usado apenas como um link de
trânsito entre roteadores e não possui hosts conectados, não precisa! Ilustraremos esta possibilidade
através de um experimento descrito na Seção 9.2.1.3.

Quando as informações topológicas e de endereçamento são separadas, os

prefixos de endereço internos a uma área são anunciados por meio de NRs de
prefixo interno de área (aip-NRs), contendo o identificador do elemento
topológico ao qual o prefixo está associado. Existem várias alternativas para
associar prefixos a elementos de rede e para originar aip-NRs. A prática usual é
ter (i) prefixos atribuídos a roteadores anunciados por meio de um aip-NR
originado pelo roteador proprietário, (ii) pré-fixos atribuídos a links ponto-a-ponto
anunciados por meio de dois aip-NRs cada um originado por um roteador de
link , (iii) prefixos atribuídos a links compartilhados de trânsito anunciados por
meio de um aip-NR originado pelo link DR ou aip-NRs originados por todos os
roteadores conectados ao link e (iv) prefixos atribuídos a links compartilhados
stub anunciados por meio de um aip -NR originado pelo roteador de link (único).
Neste último caso, o aip-NR inclui o custo da interface anexada ao link, o que
permite remover links compartilhados stub da representação topológica da rede.
2.2.2.3 Combinando informações topológicas e de endereçamento
Se o mesmo namespace for usado para informações topológicas e de endereçamento,

não há necessidade de ter um NR separado para transmitir as informações de
endereçamento: essas informações podem ser incluídas nos roteadores NRs e slink-NRs.
Além disso, exceto para prefixos atribuídos a roteadores e links compartilhados de stub,
apenas o comprimento do prefixo precisa ser adicionado, pois o identificador topológico
combinado com o comprimento do prefixo define completamente o prefixo. No contexto
do endereçamento IP, misturar informações topológicas e de endereçamento significa
que os elementos topológicos (roteadores e links) são identificados por meio de endereços IP.
A Figura 2.21 ilustra esta solução. Na figura, a palavra-chave pl refere-se ao
comprimento do prefixo e pli denota o comprimento do prefixo api. O prefixo assinado
para o roteador R3 (ap4) é anunciado por meio de uma nova entrada no roteador-NR
originado por R3; a definição do prefixo requer dois elementos: o endereço base do
prefixo e o comprimento do prefixo. Da mesma forma, o prefixo atribuído ao link
compartilhado do stub (ap3) é anunciado por meio de uma nova entrada no roteador-NR
originada por R4; esta entrada precisa incluir o custo da interface que conecta o roteador
ao link. O prefixo atribuído ao enlace ponto a ponto (ap2) é anunciado adicionando o
comprimento do prefixo pl2 às entradas dos roteadores-NRs de R1 e R2 que anunciam o
enlace. Finalmente, o prefixo atribuído ao link compartilhado de trânsito (ap1) é anunciado
associando o comprimento do prefixo pl1 ao identificador do link compartilhado do slink-
NR que anuncia o link. Em vez disso, o comprimento do prefixo poderia ter sido adicionado
aos roteadores NRs dos roteadores conectados ao link (como nos links ponto a ponto),
mas isso repetiria desnecessariamente essas informações e desperdiçaria recursos de
memória.
A solução que acabamos de descrever para anunciar os problemas topológicos e de endereçamento
informação é muito próxima da adotada pelo OSPFv2.

40 lp1ÿap2 10
R1 R2
30
5 50 20
ls1
lp2
ls2ÿap1
25 15 5
5
R3 R4
10
R3ÿap4 ls3ÿap3
R1 R2 ls1
lp1/pl2: 40 lp1/pl2: 10 R1
ls1: 5 lp2: 20 R3
ls2: 50 ls2: 30
ls2/pl1
R3 R4 R1
ls1: 25 lp2: 5 R2
ls2: 15 ls2: 5 R3
ap4 ap3: 10 R4
router-NRs NRs de links compartilhados
FIGURA 2.21: LSDB da rede da Figura 1.1 com informações topológicas e de endereçamento
mistas: o caso OSPFv2.
Quando as informações topológicas e de endereçamento são misturadas, os roteadores-

NRs e slink-NRs descrevem ambos os tipos de informações.
2.2.3 As informações do link
Já introduzimos três tipos de NR: o router-NR, o slink-NR e o aip-NR. As duas primeiras descrevem
a topologia da rede e a terceira divulga os prefixos de endereços disponíveis na rede e sua
associação com elementos topológicos. A partir dessas informações, um roteador pode calcular os
caminhos mais curtos de si mesmo para cada prefixo na rede. O caminho determina, localmente em
um roteador, a interface de saída e, exceto para o roteador do último salto, o roteador do próximo
salto que leva ao prefixo. No entanto, quando um roteador precisa encaminhar um pacote através
de uma rede de camada 2 para um roteador de próximo salto, ele ainda precisa encontrar o endereço
de camada 2 da interface do roteador de próximo salto que deve receber o pacote. Por exemplo, se
um roteador precisa enviar um pacote por uma LAN Ethernet para outro roteador, o pacote deve ser
encapsulado em um quadro Ethernet contendo o endereço MAC da interface do roteador de destino.
Camada

2 endereços não são necessários no caso de links ponto a ponto, mas são necessários para
links compartilhados, pois mais de um roteador de próximo salto pode estar disponível.
Chamaremos o endereço do link de endereço da camada 2 ou um endereço que pode
ser resolvido em um endereço da camada 2 no qual o roteador do próximo salto pode ser
alcançado no link. Os endereços de link não precisam ser endereços de camada 2, se houver
algum mecanismo de resolução de endereço para resolver o endereço de link no endereço
de camada 2 correspondente. Por exemplo, o roteador do próximo salto pode fornecer um
endereço IPv4, a ser resolvido em um endereço MAC usando ARP.
As tabelas de encaminhamento devem incluir, em cada entrada, o endereço do link da
interface do próximo salto que leva ao destino correspondente. Nas tabelas de
encaminhamento de roteadores comerciais, os endereços de link do próximo salto são
endereços de camada 3 (IPv4 ou IPv6) e estão incluídos em todas as entradas relativas a
links não conectados diretamente, mesmo em entradas relativas a links ponto a ponto , onde
não são necessários; também adotaremos essa abordagem. Para distinguir os endereços de
link de outros tipos de identificadores, vamos prefixá-los por la.
Para fornecer informações sobre endereços de link, introduzimos o link-address-NR (la-
NR para abreviar). Um la-NR inclui (i) o endereço do link, (ii) o identificador topológico do
roteador de origem e (iii) o identificador topológico do link onde o endereço será usado. Um
roteador origina um la-NR por link conectado e cada la-NR anuncia o endereço do link no
qual o roteador pode ser alcançado em um link. Os la-NRs precisam ser enviados apenas
para roteadores vizinhos em um determinado link, ou seja, os la-NRs precisam apenas ter
escopo de inundação de link.
Notamos que as informações do enlace são de natureza local, pois precisam ser
conhecidas apenas dentro de um enlace: um roteador só precisa conhecer os endereços da
camada 2 de seus vizinhos em cada um de seus enlaces. Assim, ao contrário das informações
topológicas e de endereçamento, as informações de enlace não são disseminadas por toda
a rede e, portanto, não são as mesmas nos LSDBs de todos os roteadores.
OSPFv3 é a única tecnologia que fornece informações de endereçamento de link por
meio de la-NRs. No OSPFv2, essas informações são fornecidas por meio do equivalente a
router-NRs, e no IS-IS são fornecidas por meio do protocolo Hello.
A Figura 2.22 mostra a rede da Figura 1.1, incluindo os endereços de enlace de todas as
interfaces e os la-NRs dos enlaces ls1 e ls2. Assim, este é o LSDB completo do roteador R3.
Por exemplo, o roteador R3 aprende com os la-NRs presentes em seu LSDB que pode usar
o endereço de link la6 para se comunicar com o roteador R1 por meio do link ls2 e o endereço
de link la8 para se comunicar com o mesmo roteador por meio do link ls1. A figura também
ilustra que os endereços de link podem ser os mesmos em links diferentes. Por exemplo, o
roteador R3 fornece o endereço de link la2 para seus vizinhos nos links ls1 e ls2.
Quando um roteador deseja transmitir um pacote em um link de camada 2 para

um roteador de próximo salto, ele precisa primeiro determinar o endereço de
camada 2 da interface que deve receber o pacote ou um endereço que possa ser
resolvido nele. . Esse endereço é chamado de endereço de link. Os endereços de
link são fornecidos por meio de NRs de endereço de link (la-NRs), que são
divulgados apenas dentro do link.

40 lp1ÿap2 10
R1 la1 la2 R2
50
5 la8 30 20 la2 la1
la6
ls1 lp2
ls2ÿap1
la2 25 5 la1
15 5
la3
la2
R3 R4
10
r3ÿap4 ls3ÿap3
R1 R2 ls1 ap1 ap2

lp1: 40 lp1: 10 R1 ls2 lp1
ls1: 5 lp2: 20 R3
ap2 ap3
ls2: 50 ls2: 30
ls2 lp1 R4: 10
R3 R4 R1
ap4
ls1: 25 lp2: 5 R2
R3
ls2: 15 ls2: 5 R3
R4 área-interna-prefixo-NRs
router-NRs
NRs de links compartilhados
la6
R1, ls2 la8
R1, ls1
la1
R2, ls2 la2
R3, ls1
la2
link-endereço-
R3, ls2 NRs (link ls1)
la3
R4, ls2
link-endereço-NRs
(link ls2)
FIGURA 2.22: LSDB do roteador R3 na rede da Figura 1.1, com informações topológicas, de
endereçamento e de link separadas.
2.2.4 Interconexão com outros domínios de roteamento

Os protocolos LSR fornecem roteamento dentro de domínios de roteamento. No entanto, os usuários
dentro de um domínio de roteamento devem ser capazes de se comunicar com usuários localizados
em outros domínios de roteamento. O problema de comunicação entre redes de roteamento
diferentes pode ser resolvido por meio de um protocolo de roteamento interdomínio que troca os
prefixos de endereços pertencentes a cada domínio e determina os caminhos entre eles. O protocolo
de roteamento entre domínios é executado em roteadores especiais localizados na borda entre os
domínios de roteamento, chamados Domain Border Routers (DBRs).

subcaminho interno subcaminho externo
domínio b
D
roteador
interno DBR
DBR
DBR domínio c
DBR
DBR
domínio a
DBR
protocolo de
roteamento entre domínios

domínio d
FIGURA 2.23: Roteamento entre domínios de roteamento.
atributos. Por exemplo, em BGP [46], um dos atributos externos mais importantes é o AS PATH,
que descreve a sequência de ASes no caminho até o prefixo externo associado. Assim, um roteador
BGP pode executar decisões de roteamento conhecendo a identidade de todos os ASes nos
caminhos candidatos a um destino e, dessa forma, pode evitar ASes indesejados. As informações
que reúnem os prefixos externos com seus atributos são algumas vezes chamadas de informações
de acessibilidade externa.
2.2.4.1 Exportando e importando informações de endereçamento
Exportar informações de endereçamento é uma tarefa simples. Os DBRs fazem parte do domínio
de roteamento e, portanto, conhecem todas as informações de endereçamento de seu domínio,
obtidas por meio do protocolo de roteamento intradomínio. Assim, eles podem facilmente injetar
essas informações no protocolo de roteamento entre domínios e entregá-las aos seus DBRs vizinhos
externos.
A questão da importação pode ser mais complexa e depende se o domínio de roteamento
possui um único ou vários DBRs (consulte a Figura 2.24). Se o domínio tiver

DBR DBR DBR
domínio b domínio b
domínio a domínio a
DBR DBR DBR
FIGURA 2.24: Domínios de roteamento (a) com um DBR ou (b) vários DBRs.
um único DBR, então há apenas um ponto de entrada/saída para domínios externos.

Nesse caso, não há necessidade de injetar informações de endereçamento externo no
domínio. Pode-se simplesmente instalar uma entrada especial nas tabelas de
encaminhamento dos roteadores internos apontando para o (único) DBR, para ser
utilizada sempre que o destino pretendido não corresponder a nenhuma outra entrada.
Essa entrada é chamada de rota padrão ou gateway de último recurso. Para suportar
esta solução de roteamento, um recurso adicional é necessário: os roteadores internos
devem ser capazes de identificar o DBR no mapa da rede. Isso pode ser facilmente
alcançado incluindo um sinalizador nos roteadores NRs, para sinalizar se o roteador de
origem é um DBR. A questão das rotas padrão será discutida mais adiante na Seção 2.3.4.
Se o domínio tiver mais de um DBR, torna-se relevante determinar o melhor DBR
para cada destino externo. Diferentes DBRs podem receber informações no mesmo
prefixo de endereço externo com diferentes atributos externos, que podem então ser
usados para uma decisão. Existem várias alternativas para lidar com esse problema:
• Deixe cada DBR injetar as informações de acessibilidade externa no domínio

e deixe a decisão para os roteadores internos.
• Permitir que os vários DBRs de um domínio troquem informações de acessibilidade

externa entre si para determinar qual DBR é o melhor para cada destino externo, e
permitir que apenas o melhor DBR injete no domínio a informação de acessibilidade
externa correspondente. Essa abordagem é permitida pelo protocolo BGP; pode ser
implementado através de sessões BGP internas estabelecidas entre os roteadores
BGP do mesmo AS.
• Permitir que os roteadores internos decidam qual DBR usar sem considerar as
informações de acessibilidade externa. Nesse caso, um critério de seleção pode ser
usar o DBR mais próximo.
Na primeira e segunda alternativas, deve haver uma forma de anunciar

informações de acessibilidade externa dentro de um domínio de roteamento. Essa questão será

abordada na próxima seção.
2.2.4.2 O domínio-externo-prefixo-NR
Informações de acessibilidade externa podem ser anunciadas dentro de um domínio de roteamento

por meio de um novo NR, chamado domain-external-prefix-NR (dep-NR para abreviar). O dep-NR é
originado por um DBR e inclui (i) o prefixo externo anunciado e (ii) o identificador do DBR de origem.
Assumiremos que também inclui um único atributo de custo, denominado custo externo, que resume
os tributos externos associados ao prefixo anunciado. Este atributo só é relevante na primeira
alternativa descrita acima, onde a decisão de roteamento fica a cargo dos roteadores internos. Em
soluções que misturam informações topológicas e de endereçamento, os prefixos externos ao
domínio também podem ser anunciados através dos roteadores-NRs originados pelos DBRs. No
entanto, não vamos considerar essa possibilidade, uma vez que não é utilizada na prática.
Considere o exemplo da Figura 2.25, onde omitimos as NRs topológicas; o exemplo refere-se à
segunda alternativa descrita acima, onde o domínio de roteamento é um AS conectado à Internet
através de dois ASBRs (roteadores R1 e R2), e os ASBRs se comunicam entre si e com ASBRs
externos usando BGP. Suponha que ambos os ASBRs recebam informações de acessibilidade
referentes aos prefixos externos ap1 e ap2 (etapa 1) e que cada prefixo venha com um atributo AS
PATH indicando o número de saltos (ASes) no caminho que leva a ele. Suponha que os roteadores
R1 e R2 tenham permissão para trocar esse atributo (etapa 2) e sejam programados para selecionar
o ASBR que fornece o menor número de saltos. Neste caso, o roteador R1 verifica se é o melhor
ASBR para alcançar ap2 e o roteador R2 verifica se é o melhor para alcançar ap1.
Assim, o roteador R1 inunda internamente o dep-NR anunciando ap2, e o roteador R2 inunda aquele
anunciando ap1 (etapa 3).
Um domínio de roteamento se comunica com outros domínios de roteamento por meio de

seus DBRs e aprende os prefixos de endereço de outros domínios por meio do protocolo
de roteamento entre domínios. Se o domínio tiver um único DBR, não há necessidade de
injetar esses prefixos no domínio; as rotas padrão que apontam para o DBR devem ser
usadas. Se o domínio tiver mais de um DBR, os DBRs podem injetar informações sobre
os prefixos no domínio, para permitir que os roteadores internos decidam qual o melhor
DBR de saída para alcançar cada prefixo. Essas informações são divulgadas por meio de
NRs de prefixo externo de domínio (dep-NRs), originadas pelos DBRs.
2.2.5 Identificadores NR
Os NRs devem ser identificados exclusivamente dentro do LSDB para evitar confusão na construção
do mapa da rede. Pode-se considerar a possibilidade de identificar NRs através dos identificadores
dos elementos que representam, por exemplo

Internet
ap1, saltos=5 ap1, saltos=3

1 1
ap2, saltos=1 ap2, saltos=8
ap1, saltos=5, via

2 R1 ap2, saltos=1, via R1
R1 R2
ap1, saltos=3, via
R2 ap2, saltos=8, via R2
dep-NR dep-NR
ap2, R1 ap1, R2
3 R3 3
ap1 ap2
R2 R1
domínio-externo-prefixo-NRs
FIGURA 2.25: Injetando informações de acessibilidade externa em um domínio com

vários ASBRs.
usando o identificador do link compartilhado, no caso de slink-NRs, ou o prefixo do

endereço, no caso de aip-NRs. No entanto, isso resultaria em identificadores longos e
não uniformes. Além disso, no caso de prefixos atribuídos a enlaces ponto a ponto, o
mesmo prefixo é anunciado por dois NRs diferentes.
Assim, adotaremos uma forma genérica de identificação de NRs, também utilizada
em OSPF e IS-IS, onde os NRs são identificados por meio de três elementos: (i) o
identificador do roteador de origem, (ii) o indicador de tipo de NR, e (iii) uma tag atribuída
localmente que distingue entre as NRs do mesmo tipo originadas pelo mesmo roteador.
Iremos nos referir a este conjunto de três elementos como o identificador NR.
Os NRs são identificados exclusivamente usando três elementos: o identificador

do roteador de origem, o indicador de tipo de NR e uma etiqueta atribuída
localmente para distinguir entre NRs do mesmo tipo originados pelo mesmo roteador.

FIGURA 2.26: NRs que formam o LSDB de uma rede LSR de área única, seu papel e roteador de
origem.
2.2.6 Resumo da estrutura LSDB

Resumimos agora os tipos de NR introduzidos nas seções anteriores. A estrutura real do LSDB, ou
seja, quais NRs são usados e a maneira como são usados, depende se as informações topológicas,
de endereçamento e de link são descritas separadamente e da maneira como as informações de
endereçamento estão relacionadas aos elementos topológicos. A função e o originador de cada NR
estão resumidos na Figura 2.26.
• roteador-NRs e slink-NRs - O roteador-NR e o slink-NR fornecem as informações topológicas, ou

seja, o mapa da rede. O roteador-NR descreve um roteador e seus links anexados e é originado
pelo roteador que está sendo descrito.
O slink-NR descreve um link compartilhado de trânsito e seus roteadores anexados, e é originado
pelo link DR. Links compartilhados de stub não são representados no mapa de rede. Em soluções
que misturam informações topológicas e de endereçamento, essas NRs também fornecem
informações de endereçamento.
• aip-NR - O aip-NR fornece informações de endereçamento internas ao domínio de roteamento. O

originador aip-NR depende do elemento de rede ao qual o prefixo está associado (consulte a
discussão na Seção 2.2.2.2). Esta NR não é utilizada em soluções que misturam informações
topológicas e de endereçamento.
• dep-NR - O dep-NR fornece informações de endereçamento externas ao domínio de roteamento e

é originado pelo DBR que injeta o prefixo no domínio.
• la-NR - O la-NR fornece informações de link. É originado por um roteador em cada um de seus links
para anunciar o endereço do link no qual o roteador pode ser alcançado no link.

2.3 Do LSDB para a tabela de encaminhamento 85
FIGURA 2.27: Etapas da construção de uma tabela de encaminhamento.
2.3 Do LSDB para a tabela de encaminhamento Conforme discutido na
Seção 1.4.2, a tabela de encaminhamento de um roteador tem uma entrada por prefixo de
destino e cada entrada contém informações sobre o caminho para o prefixo, que inclui a
interface de saída, o endereço do link da interface do próximo salto e o custo do caminho.
A tabela de encaminhamento pode ser obtida em um roteador a partir das informações

topológicas, de endereçamento e de enlace contidas em seu LSDB. Isso envolve três etapas
(consulte a Figura 2.27):
1. Representar a topologia da rede através de um gráfico e associar a

prefixos de destino com nós do grafo.
2. Execute um algoritmo de caminho mais curto centralizado sobre o grafo, para
determinar os caminhos mais curtos entre o nó que representa o roteador onde
a tabela de encaminhamento está sendo construída (o nó de origem) e os outros
nós do grafo. Vários algoritmos de caminho mais curto estão disponíveis, mas o
algoritmo de Dijkstra é o usado em protocolos LSR.
3. Determine o caminho mais curto para os prefixos de destino e reúna as
informações de roteamento local, ou seja, a interface de saída e o endereço do
link da interface do próximo salto que leva a cada prefixo.
Detalhamos cada uma dessas etapas nas próximas seções.
2.3.1 Construindo o grafo da rede e associando os prefixos de destino

aos nós
Como configurar o grafo da rede O grafo no qual o algoritmo de Dijkstra será usado para
encontrar os caminhos mais curtos ponta a ponta é montado com base no mapa da rede
(router-NRs e slink-NRs). No entanto, uma decisão deve ser tomada sobre quais elementos
da rede são representados pelos nós do grafo. Naturalmente, os roteadores são
representados por nós. Em relação aos links, a decisão depende da associação entre
prefixos e links, conforme definido nos aip-NRs. Lembre-se de que um prefixo atribuído a um
link pode estar associado a um roteador conectado ao link (através do identificador do
roteador) e não diretamente ao link. Algumas orientações gerais são:

• Os roteadores são representados por nós.
• Os links compartilhados stub não são representados por nós, pois não fazem parte do mapa de rede.
• Em geral, os links compartilhados de trânsito são representados por nós, pois isso simplifica a
estrutura do grafo e facilita o cálculo dos caminhos mais curtos. Uma possível exceção é quando
o link está conectando apenas alguns roteadores (por exemplo, dois roteadores).
• Enlaces ponto a ponto podem ou não ser representados por nós. Não vale a pena fazer isso se, na
estrutura LSDB, um prefixo atribuído a um link ponto a ponto não estiver diretamente associado
ao link.
Neste grafo, os arcos de saída dos nós que representam os roteadores correspondem às suas
interfaces de saída e são rotulados com os custos de interface correspondentes. Os arcos de saída
dos nós que representam os links são rotulados com custo zero, uma vez que os links não são
equipamentos de comutação da camada 3.
Associação entre prefixos e nodos Uma vez configurado o grafo, os prefixos podem ser associados
aos nodos do grafo, utilizando as informações contidas nos aip-NRs e dep-NRs. No caso de um
prefixo atribuído a um link que não seja representado por um nó do grafo, o prefixo deve ser
associado a cada nó que representa um roteador conectado ao link e deve incluir o custo do roteador
ao prefixo.
Exemplo A Figura 2.28 mostra o grafo da rede da Figura 2.22 onde, além dos roteadores, apenas
os enlaces compartilhados de trânsito são representados pelos nós do grafo. Os nós n1 a n4
representam os roteadores R1 a R4, e os nós n5 e n6 representam os links compartilhados de
trânsito ls1 e ls2. Para simplificar a apresentação gráfica, usamos arcos não direcionados e
colocamos os rótulos próximos aos nós dos arcos de saída correspondentes. No entanto, o cálculo
dos caminhos mais curtos é realizado sobre o grafo direcionado. Por exemplo, o rótulo 40 colocado
próximo ao nó n1 é o rótulo do arco de saída de n1 a n5, e o rótulo 5 colocado próximo ao mesmo
nó é o rótulo do arco de saída de n1 a n7. Observe que os rótulos dos arcos de saída dos nós que
representam links são todos zero.
Em relação à associação entre prefixos e nós, o prefixo ap1 é atribuído ao link compartilhado
de trânsito ls2 representado pelo nó n6. O prefixo ap2 é atribuído ao link ponto a ponto entre R1 e
R2; como este enlace não é representado por um nó do grafo, ele deve ser associado aos nós que
representam os roteadores finais do enlace, ou seja, está associado ao nó n1 com um custo de 40
e ao nó n2 com um custo de 10. Prefixo ap3 é atribuído ao link compartilhado stub; está associado
ao nó n4, representando o roteador do link, com um custo de 10. Finalmente, o prefixo ap4 é
atribuído ao roteador R3 representado pelo nó n3.
Observe que na estrutura LSDB da Figura 2.22, (i) os enlaces ponto a ponto são representados
no mapa da rede e (ii) os prefixos publicitários aip-NRs atribuídos a esses enlaces associam os
prefixos diretamente aos enlaces, por meio da identificadores de links. Nesse caso, o grafo poderia
incluir nodos representando enlaces ponto a ponto e, como será visto na Seção 2.3.3, estes
facilitariam

40 10
n1 n2 ÿ
50 30
ÿ
5 20
ÿ
0 ÿ ÿ
0 0
n5 n6 ÿ
0 0 ÿ
ÿ
0 ÿ
ÿ
ÿ
25 5
15 5
n3 n4 n4 ÿ
FIGURA 2.28: Gráfico da rede da Figura 2.22 e correspondência entre nós,

elementos da rede e prefixos.
a determinação dos caminhos mais curtos para os prefixos. Essa solução não seria
possível na estrutura LSDB da Figura 2.20, pois os aip-NRs associam os prefixos
atribuídos aos enlaces ponto a ponto com os roteadores finais do enlace.
2.3.2 Determinando caminhos mais curtos em um grafo - Algoritmo de

Dijkstra
Os protocolos LSR usam o algoritmo de Dijkstra (Figura 2.29) para determinar os
caminhos mais curtos entre os nós do grafo da rede. Este algoritmo pode determinar
em uma única execução os caminhos mais curtos do nó de origem para todos os
outros nós, ou seja, a árvore de caminho mais curto enraizada no nó de origem. A
iteração de Dijkstra na ordem de aumento do custo do caminho. A cada nó é atribuído
um rótulo, atualizado a cada iteração, correspondente ao custo do caminho do nó de
origem até o próprio nó. Os rótulos tornam-se permanentes quando o valor real do
custo do caminho mais curto é encontrado; caso contrário, eles são considerados temporários.
O algoritmo termina quando todos os rótulos se tornam permanentes. O algoritmo
também registra o pai (predecessor) de cada nó na árvore de caminho mais curto,
para permitir a determinação dos caminhos reais em direção aos nós de destino.
Vamos denotar o nó de origem, S o conjunto de nós rotulados permanentemente,
cij o custo do arco do nó i ao nó j, pi o pai do nó i e Cj a estimativa de custo do
caminho do nó de origem ao nó j (ou seja, o rótulo do nó j). Se não houver arco entre
i e j, então cij = ÿ; nós i e j para os quais cij = ÿ são ditos vizinhos. O rótulo do nó
fonte é sempre Cs = 0 pois corresponde ao custo de um nó para si mesmo.
Inicialmente (passo 0 da Figura 2.29), apenas o nó fonte é colocado em S e, para
cada outro nó j, os rótulos são definidos para os custos dos arcos que levam a j, e os
pais do nó são todos definidos para o nó fonte s. Então, o algoritmo começa a iterar.
O primeiro passo em cada iteração (passo 1 da Figura 2.29) determina o nó ainda
não em S que é

FIGURA 2.29: Algoritmo de Dijkstra.
mais próximo da fonte, ou seja, aquele com rótulo mais baixo. Este nó agora é considerado
permanentemente rotulado e colocado em S; vamos nos referir a ele como nó k. A segunda etapa
(etapa 2 da Figura 2.29) atualiza os rótulos de todos os nós que ainda não estão em S. Nesse ponto,
o algoritmo precisa apenas examinar os caminhos em que o nó k é o penúltimo nó. Sempre que um
rótulo de nó é atualizado, ou seja, a estimativa de custo diminui, seu nó pai é definido como nó k.
Então, o algoritmo retorna ao primeiro passo e procede a partir daí, até que todos os nós tenham
sido incluídos em S.
Quando o algoritmo termina, todos os nós são rotulados com o verdadeiro custo do caminho mais
curto do nó de origem até eles mesmos.
A Figura 2.30 ilustra a transição do passo 1 para o passo 2. O nó k acaba de receber um rótulo
permanente e foi incluído em S. Nesse ponto, o algoritmo atualiza os rótulos dos vizinhos do nó k
que não estão em S, ou seja, os nós a e B. Os nós que não estão em S e que não são vizinhos de
k, ou seja, os nós c e d, não precisam ser considerados neste estágio. Após esta operação de
reetiquetagem, o algoritmo seleciona entre todos os nós que não estão em S, ou seja, os nós de a a
d, aquele com o rótulo mais baixo.
As informações do nó pai permitem determinar o caminho real do nó de origem para todos os

outros nós. Um caminho geralmente é definido em um nó através de seu próximo nó de salto. O nó
do próximo salto pode ser obtido retrocedendo no grafo do nó de destino para o nó de origem,
usando as informações do nó pai.
Ilustramos a operação passo a passo do algoritmo de Dijkstra na Figura 2.31, usando um grafo
de rede mais simples que o da Figura 2.28. Na verdade, o grafo deste exemplo é uma representação
da rede da Figura 1.1 onde apenas roteadores e links compartilhados com mais de duas conexões
são representados como nós. Mostramos como a árvore de caminho mais curto enraizada no nó n2
é determinada.
Em cada gráfico da Figura 2.31, os nós representados com uma linha tracejada são nós ainda não
rotulados permanentemente. A figura também mostra, a cada iteração, a tabela de caminhos mais
curtos do nó n2, que inclui uma entrada para cada destino (dest), indicando o nó do próximo salto
(nh) e o custo do caminho mais curto até o destino (cost). O algoritmo itera da seguinte forma:

Ca
definir S (nós rotulados
permanentemente) a
Cb
b
k
s
Cc
c
Cd
d
FIGURA 2.30: Transição do passo 1 para o passo 2 do algoritmo de Dijkstra.
• Inicialização - Inicialmente (Figura 2.31.a), apenas o nó n2 está em S, ou seja, S = {2}.

Cada nó é rotulado com o custo do arco direcionado do nó de origem para o próprio
nó; observe que o nó n3 recebe um rótulo de ÿ, pois não há arco entre os nós n2 e
n3. Além disso, os nós pais são todos configurados para o nó n2.
• 1º passo - Após a inicialização, o nó n1 passa a ser o nó com menor rótulo, C1 = 10.

Assim, ele recebe um rótulo permanente e é colocado em S, levando a S = {1, 2}
(Figura 2.31.b) . Isso significa que o caminho mais curto de n2 a n1 (e seu custo) foi
encontrado. O custo do caminho mais curto é igual ao rótulo do nó, ou seja, é 10. O
nó do próximo salto é determinado a partir das informações do nó pai: como o pai de
n1 é n2, o nó do próximo salto é definido como n1. Agora, os rótulos dos nós que não
estão em S e são vizinhos do nó n1, o nó k nesta etapa, devem ser atualizados.
Especificamente, C3 diminui para 15 e os rótulos de outros nós permanecem
inalterados. Além disso, como o rótulo de n3 diminuiu, seu pai deve ser alterado para
o nó n1, porque n1 é o nó atual k, ou seja, p3 = 1.
• 2º passo - Em seguida, o algoritmo passa para uma nova iteração onde o nó n3 recebe
um rótulo permanente, levando a S = {1, 2, 3} (Figura 2.31.c). Assim, o caminho mais
curto de n2 a n3 (e seu custo) foi encontrado. O nó do próximo salto é determinado
retrocedendo de n3 para n2. O pai de n3 é n1 e o pai de n1 é n2; assim, o nó do
próximo salto é n1. Neste ponto, nenhuma reetiquetagem ocorre e o algoritmo
prossegue para a próxima iteração.
• 3º passo - Nesta iteração, o nó n4 é incluído em S, levando a S = {1, 2, 3, 4} (Figura

2.31.d), e o nó do próximo salto é definido como n4. o rótulo de

C1=10 p1=2 C2=0 p2=2 C1=10 p1=2 C2=0 p2=2

S={2} S={1,2}
40 10 40 10
n1 i3
i2
n2 n1 i3 n2
50 i1
50 i2
i1
0 0 30 30
5 20 5 0 0 20
C5=30 C5=30
p5=2 n5 p5=2 n5
0 0
25 0 5 25 5
5 0 5
15 15
n3 n4 n3 n4
C3=ÿ p3=2 C4=20 p4=2 C3=15 p3=1 C4=20 p4=2
destino nh custo destino nh custo

n1 - - n1 n1 10
- -
(a) n3 - - (b) n3
n4 - - n4 - -
n5 - - n5 - -
C1=10 p1=2 C2=0 p2=2 C1=10 p1=2 C2=0 p2=2

S={1,2,3} S={1,2,3,4}
40 10 40 10
n1 i3 n2 n1 i3
i2
n2
50 i2
i1 50 i1
30 0 0 30
5 0 0 20 5 20
C5=30 C5=25
p5=2 n5 p5=4 n5
0 0
25 5 25 0 5
0 5 5
15 15
n3 n4 n3 n4
C3=15 p3=1 C4=20 p4=2 C3=15 p3=1 C4=20 p4=2
destino nh custo destino nh custo

n1 n1 10 n1 n1 10
(c) n3 n1 15 (d) n3 n1 15
n4 - - n4 n4 20
n5 - - n5 - -
C1=10 p1=2 C2=0 p2=2

S={1,2,3,4,5}
40 10
n1 i3 n2
50 i2
i1
destino nh custo 30
5 0 0 20
n1 n1 10
C5=25
(e) n3 n1 15
p5=4 n5
n4 n4 20 0
25 0 5
n5 n4 25 5
15
n3 n4
C3=15 p3=1 C4=20 p4=2
FIGURA 2.31: Exemplo do algoritmo de Dijkstra.

o nó n5 diminui para C5 = 25, pois agora pode ser alcançado pelo nó n4 e,

consequentemente, seu pai muda para o nó n4, ou seja, p5 = 4.
• 4º passo - Finalmente, na última iteração (Figura 2.31.e), o nó n5 é incluído em S e o

algoritmo para, pois S agora abrange todos os nós. O custo do caminho mais curto de
n2 a n5 é definido como 25 e o nó do próximo salto é definido como n4. O próximo nó
de salto é novamente determinado retrocedendo do nó de destino: o pai de n5 é n4 e o
pai de n4 é n2, levando a um nó de próximo salto de n4.
2.3.3 Determinando caminhos mais curtos para prefixos de destino e

reunindo informações de roteamento local
Uma vez calculados os caminhos mais curtos entre o nó de origem e todos os outros nós
do grafo da rede, é necessário determinar os caminhos mais curtos reais em direção a
cada prefixo de destino e montar as tabelas de encaminhamento.
A Figura 2.32 mostra as tabelas de encaminhamento da rede da Figura 2.22. As tabelas
incluem, para cada prefixo de destino (dest), o endereço do link da interface do próximo
salto (nh), o identificador da interface de saída (int) e o custo do caminho (cost).
Duas questões precisam ser consideradas, a primeira relacionada à localização do

prefixo em relação ao roteador de origem, e a segunda relacionada à associação entre os
nós do grafo e os prefixos.
Localização do prefixo de destino em relação ao roteador de origem Existem dois casos
em relação à localização do prefixo de destino em relação ao roteador de origem:
1. O prefixo é atribuído a um link conectado diretamente ao roteador; 2. O

prefixo é atribuído a algum link ou roteador além de um link conectado diretamente
e pode ser acessado por meio de um roteador de próximo salto.
Prefixo atribuído ao link de conexão direta No primeiro caso, e conforme discutido na

Seção 1.5, a rota conectada diretamente tem preferência sobre qualquer outro caminho
(por exemplo, caminho mais curto). Assim, a interface de saída instalada na mesa de
encaminhamento deve ser a que está anexada ao link. Nesses tipos de entradas, as
tabelas de encaminhamento incluem informações informando que o prefixo de destino
está em um link conectado diretamente, por exemplo, a frase “está em um link conectado
diretamente” ou a palavra-chave “dc”.
Por exemplo, na rede da Figura 2.32, o caminho de R2 para ap1 é pela interface i2 (a
rota diretamente conectada), mesmo que o caminho R2 ÿ R4 ÿ ap2 tenha custo menor.
Prefixo atribuído ao link ou roteador além do link de conexão direta No segundo caso, é
necessário determinar o caminho mais curto do roteador de origem ao prefixo, usando os
resultados da execução do algoritmo de Dijkstra sobre o

40 lp1ÿap2 10
R1 i3
i2 la1 la2
i1
i2
R2
i1
50
5 la8 i3 30 20 la2 la1
la6
ls1 lp2
ls2ÿap1
la2 25 5 la1
15 i2 5
i1 la3 i1
la2 i2
R3 R4
i3
10
R3ÿap4 ls3ÿap3
nh int custo dest nh int custo

cc i2 - cc i2 -
ap1
CC i3 - CC i1 -
ap2
la2 i1 30 ap3 la1 ap4 i3 30
destino ap1la2 i1
ap2 ap3 ap4 5 la1 i1 15
Roteador R1 Roteador R2
destino nh int custo destino nh int custo

CC i1 - CC i2 -
ap1 ap1
ap2 la1 25 la2 15
ap2
ap3 la3 i1 i1 25 la1 i1 i2 15
- - CC i3 -
ap4 local ap3
ap4 la2 i2 5
Roteador R3
Roteador R4
FIGURA 2.32: Tabelas de encaminhamento da rede da Figura 2.22.
gráfico de rede. O caminho mais curto é definido localmente em um roteador por meio da interface
de saída e do endereço de link da interface do próximo salto.
Dado um caminho no gráfico de rede, o primeiro nó do caminho (o nó de origem) representa um
roteador, mas o segundo nó pode representar um link ou um roteador. O roteador do próximo salto
corresponde ao nó que representa o próximo roteador no caminho e pode ser o segundo ou o
terceiro nó.
A interface de saída é a interface com o segundo nó do caminho. O endereço do link (ou seja, as
informações do link) é fornecido pelo la-NR originado pelo roteador do próximo salto no link
correspondente ou algum meio equivalente (consulte a discussão na Seção 2.2.3).
Calculando caminhos mais curtos para prefixos atribuídos a elementos de rede representados por
nós do grafo O cálculo do caminho mais curto (final) para um prefixo depende da associação entre
prefixos e nós. O algoritmo de Dijkstra determina os caminhos mais curtos entre a fonte

nó e todos os outros nós do grafo da rede. Se o prefixo de destino for atribuído a um

elemento de rede representado por um nó do grafo, o caminho mais curto é
determinado diretamente pelo algoritmo de Dijkstra.
Por exemplo, na rede da Figura 2.32, considere o caminho do roteador R2 ao
prefixo ap4, atribuído ao roteador R3. No grafo de rede correspondente (ver Figura
2.28), o roteador R2 é representado pelo nó n2 e o roteador R3 pelo nó n3. Quando
o algoritmo de Dijkstra é executado no grafo tendo n2 como nó de origem, ele indica
que o caminho mais curto é n2 ÿ n1 ÿ n3, com um custo de 15. Como o nó do próximo
salto no caminho é o nó n1, o endereço do link da interface do próximo salto é aquele
fornecido pelo roteador R1 no link lp1, ou seja, la1.
Calculando caminhos mais curtos para prefixos atribuídos a elementos de rede não
representados por nós do grafo Pode haver prefixos atribuídos a links não
representados por nós do grafo de rede. Este é precisamente o caso do enlace ponto
a ponto e do enlace compartilhado stub no grafo da Figura 2.28. Especificamente, no
caso de prefixos atribuídos a links, (i) um prefixo pode estar associado a um nó que
não representa o link ao qual o prefixo foi atribuído e (ii) um prefixo pode estar
associado a mais de um nó . Nesses casos, o cálculo do caminho final mais curto
requer etapas adicionais.
Um nó representando um roteador associado a um prefixo atribuído a um link

será chamado de nó proxy (relativo ao prefixo). Os nós proxy devem incluir o custo
do roteador representado pelo nó até o prefixo. Por exemplo, no gráfico da Figura
2.28, n4 é um nó proxy para ap3, com custo 10, e n1 e n2 são nós proxy para ap2,
com custos 40 e 10, respectivamente.
Calculando o caminho mais curto para um prefixo associado a um nó proxy O custo
do caminho mais curto de um roteador para um prefixo associado a um nó proxy deve
ser determinado em duas etapas. Primeiro, usando o algoritmo de Dijkstra, determine
o caminho mais curto e o custo do caminho correspondente, do nó de origem ao nó
proxy do prefixo. Em seguida, adicione esse custo de caminho ao custo do prefixo.
Por exemplo, na rede da Figura 2.32, considere o caminho do roteador R1 para o

prefixo ap3, atribuído ao link compartilhado stub. No gráfico de rede da Figura 2.28, o
roteador R1 está associado ao nó n1 e o prefixo ap3 ao nó proxy n4. Quando o
algoritmo de Dijkstra é executado sobre o grafo tendo n1 como nó de origem, ele
indica que o caminho mais curto de n1 a n4 é n1 ÿ n7 ÿ n3 ÿ n8 ÿ n4, com custo 20.
A partir dessas informações, determina-se que a saída A interface do roteador R1 é
aquela que conecta o link ls1 (representado pelo nó n5), e o roteador do próximo salto
é o roteador R3 (representado pelo nó n3). O endereço do link da interface do próximo
salto é aquele fornecido pelo roteador R3 no link ls1, ou seja, la2. Finalmente, como
o nó proxy tem um custo de 10 em relação a ap3, segue-se que o custo do caminho
de R1 a ap3 é 20+10=30.
Calculando o caminho mais curto para um prefixo associado a mais de um nó proxy
Quando um prefixo está associado a mais de um nó proxy,

então é preciso determinar os caminhos mais curtos para o prefixo por meio de cada nó proxy, e o
caminho mais curto real é o de menor custo.
Novamente, na rede da Figura 2.32, considere o caminho do roteador R4 ao prefixo ap2,
atribuído ao link ponto a ponto. No gráfico de rede da Figura 2.28, R4 está associado a n4 e ap2
está associado a dois nós proxy: n1 com custo 40 e n2 com custo 10. É preciso determinar primeiro
os custos do caminho mais curto de n4 para ap2 via n1 e n2. O caminho mais curto de n4 para n1 é
n4 ÿ n1 com custo 5 e, portanto, o custo do caminho mais curto para ap2 via n1 é 5+40=45. Além
disso, existem dois caminhos mais curtos de custo igual de n4 a n2, n4 ÿ n2 e n4 ÿ n6 ÿ n2 ambos
com custo 5; portanto, o custo do caminho mais curto para ap2 via n2 é 5+10=15. Por fim, ao
comparar os custos do caminho via n1 e n2, concluímos que o caminho mais curto é via n2 com
custo de 15.
Isso significa que existem dois caminhos mais curtos de custo igual de R4 a ap2. Nesse caso, a
prática usual é incluir ambos na tabela de encaminhamento. A análise do gráfico de rede mostra que
um caminho é através do link ls2 de trânsito compartilhado e o outro é através do link ponto a ponto
lp2. Assim, os endereços de enlace a serem utilizados em cada caminho são os fornecidos por R2
nesses enlaces, ou seja, la1 para o caminho via enlace compartilhado de trânsito e la2 para o
caminho via enlace ponto a ponto.
2.3.4 Rotas padrão
As tabelas de encaminhamento podem conter uma entrada a ser usada quando o prefixo de destino
de um pacote recebido não corresponde a nenhuma outra entrada. Conforme discutido na Seção
2.2.4.1, essa entrada, denominada rota padrão ou gateway de último recurso, é útil em domínios de
roteamento com apenas um DBR, ou seja, onde há um único ponto de saída para outros domínios
de roteamento. Nesse caso, não há necessidade de disseminar informações de endereçamento
externo dentro do domínio, e todo o tráfego destinado a prefixos externos pode seguir internamente
a rota padrão.
Damos um exemplo na Figura 2.33. Um domínio está conectado à Internet por meio do roteador
R1. Neste exemplo, há apenas um prefixo de endereço interno: ap1 atribuído ao link ls1. Assumimos
que os custos de interface são todos 10. Ao analisar o LSDB, o roteador R2 aprende, através do
roteador-NR de R1, que R1 é um DBR (o roteador-NR inclui um sinalizador para indicar se o roteador
de origem é um DBR) . Em seguida, ele instala uma rota padrão em sua tabela de encaminhamento
correspondente ao caminho mais curto de si mesmo para o DBR, ou seja, tendo i1 como interface
de saída, la1 como o endereço do link da interface do próximo salto no link lp2 e um custo de
caminho de 10 A entrada de rota padrão é a última a ser verificada para qualquer pacote recebido.
Por exemplo, se um pacote chega ao roteador R2 e tem como destino ap1, ele será encaminhado
para R3 via interface i2; no entanto, se for destinado a qualquer outro prefixo de endereço (por
exemplo, um prefixo externo ao domínio), não corresponderá à primeira entrada da tabela de
encaminhamento e será enviado para o DBR via interface i1.

2.4 Divulgação e atualização das informações de roteamento 95
Internet
R1 (DBR)
lp1: 10 R1
lp2: 10 lp2
la1
R2
lp2: 10 i1
lp3: 10
lp1
i2 R2
R3 la2
lp1: 10 lp3
lp3: 10 R3
router-NRs
ap1
R3: 10
área-prefixo ls1 ap1
interno-NR
destino próximo interface custo

ap1 salto la2 i2 20
padrão la1 i1 10
Tabela de encaminhamento do roteador R2
FIGURA 2.33: Rotas padrão.
As tabelas de encaminhamento são construídas a partir das informações de roteamento

contidas no LSDB em três etapas: (i) obter um grafo da rede a partir do mapa da rede
e associar os prefixos de destino aos nós do grafo, (ii) executar o algoritmo de Dijkstra
sobre o grafo da rede determinar os caminhos mais curtos entre os nós do grafo e (iii)
determinar os caminhos mais curtos para os prefixos de destino e montar as informações
de roteamento local, ou seja, a interface de saída e o endereço do link da interface do
próximo salto que leva a cada prefixo.
2.4 Divulgação e atualização das informações de roteamento

Os protocolos LSR requerem um mecanismo para disseminar pela rede as informações de
roteamento originadas por um roteador e permitir a atualização do LSDB

b>a b mais fresco do que um
SN inicial ab SN final
SN
FIGURA 2.34: Números de sequência linear.
substituindo informações antigas por novas. São necessários três tipos de operações: (i) instalar uma
nova NR, (ii) atualizar uma NR existente e (iii) excluir uma NR existente. Essas questões serão discutidas
nas próximas seções.
2.4.1 Frescura NR
Conforme discutido na Seção 2.2.1.5, as instâncias NR devem ter um atributo de atualização

expressando o quão recentes elas são, de modo que as instâncias mais recentes possam substituir as
mais antigas. Esse atributo é chamado de atualização de NR.
Existem várias possibilidades para expressar frescor (ver Seção 2 de [40]). A maneira mais comum
é usar um espaço linear de números de sequência (SNs). Quando o NR é criado pela primeira vez, é
atribuído a ele um valor inicial de SN, e esse valor é incrementado em um toda vez que uma nova
instância do NR é criada (Figura 2.34). Nesse caso, a regra para substituição de uma instância NR
armazenada em um roteador é permitir a substituição apenas quando a instância NR recebida tiver um
SN maior, ou seja, mais recente que a armazenada. Uma vantagem de usar SNs é que eles também
podem ser usados para controlar o processo de inundação, como será discutido na próxima seção.
O uso de números de sequência linear coloca o problema do que fazer quando o

SN final é atingido. Esta questão será abordada na Seção 2.4.8.
Os NRs têm um atributo de atualização para refletir o quão recentes eles são, de modo que
as instâncias NR mais recentes possam substituir as mais antigas. Números de sequência
linear (SNs) são geralmente usados para essa finalidade.
2.4.2 Identificação de instâncias de NR
Um NR pode ter várias instâncias, cada uma com um valor de atualização diferente. Assim, as instâncias
de NR devem ser identificadas exclusivamente por dois elementos: o identificador de NR e a atualização
de NR. Conforme discutido na Seção 2.2.5, o identificador NR inclui (i) o identificador do roteador que
origina o NR, (ii) o indicador de tipo de NR e (iii) uma tag atribuída localmente para distinguir entre NRs
do mesmo tipo originados pelo mesmo roteador. Como veremos adiante, existem circunstâncias em
que apenas o identificador NR é necessário, mas outras em que é necessário o identificador de instância
NR mais completo.

As instâncias de NR são identificadas exclusivamente por dois elementos: o identificador

de NR e a atualização de NR.
2.4.3 Inundação controlada

Começamos discutindo o processo de disseminação em um contexto genérico. Considere uma rede
onde cada roteador origina mensagens sucessivas que devem chegar a todos os outros roteadores.
A disseminação dessas mensagens pode ser realizada através do seguinte procedimento,
denominado flooding:
• O roteador de origem transmite a mensagem a ser inundada por todos os seus

interfaces;
• Qualquer roteador que recebe a mensagem em uma interface a retransmite em todas as outras
interfaces (isto é, a mensagem é retransmitida em todas as interfaces, exceto aquela em que foi
recebida).
Usando esse procedimento simples, a mensagem inicialmente transmitida pelo roteador de

origem é seguramente entregue a todos os outros roteadores da rede. No entanto, se a rede contiver
ciclos, a mensagem continuará circulando indefinidamente, causando até congestionamento e
quebra da rede. Dizemos que esse procedimento de inundação é descontrolado.
A solução para essa falta de controle é fazer com que os roteadores lembrem se já transmitiram
uma mensagem que está sendo inundada. Para atingir esse objetivo, as mensagens precisam ser
rotuladas com identificadores exclusivos e esses identificadores devem ser armazenados nos
roteadores quando as mensagens são recebidas. Os identificadores exclusivos de mensagem podem
ser obtidos usando dois elementos: o identificador do roteador de origem (ID) e um número exclusivo
gerado localmente pelo roteador de origem.
Um exemplo de números únicos são os números de sequência (SNs) introduzidos na Seção 2.4.1.
Com esses ingredientes, o procedimento de inundação controlada funciona da seguinte forma:
• O roteador de origem atribui a cada mensagem a ser inundada um identificador único composto por
dois elementos, ou seja, o par (ID, SN), e transmite a mensagem por todas as suas interfaces.
• Quando uma mensagem é recebida em um roteador, o roteador verifica se o par recebido (ID, SN)
já está armazenado na memória. Se sim, a mensagem é descartada; caso contrário, o par é
armazenado e a mensagem é transmitida por todas as interfaces, exceto aquela onde a mensagem
foi recebida.
Observe que todos os pares (ID, SN) devem ficar armazenados nos roteadores, a menos que,
além de números únicos, os SNs também expressem o frescor da mensagem, de modo que as
mensagens mais antigas fiquem desatualizadas e não precisem mais ser inundadas. Este é
justamente o caso dos protocolos LSR, que serão detalhados na Seção 2.4.5.

2.4.4 Inundação confiável
O procedimento de inundação controlada descrito na seção anterior fornece um mecanismo para

disseminar mensagens por toda a rede. No entanto, para garantir que as mensagens sejam
entregues a todos os roteadores, sem exceção, é necessário um mecanismo adicional. Uma
maneira de obter inundação confiável é proteger com ACK as transmissões entre roteadores vizinhos
(consulte a Seção 1.8.1). Nesse caso, sempre que um roteador envia uma mensagem sendo
inundada para um vizinho, o vizinho responde com uma mensagem ACK. A recepção de uma
mensagem deve ser confirmada mesmo que a mensagem seja descartada devido ao procedimento
de flooding controlado.
A Figura 2.35 mostra um exemplo do mecanismo de inundação confiável. O roteador R5 deseja

disseminar uma mensagem para todos os outros roteadores. Ele atribui SN=1 à mensagem e a
transmite no link compartilhado usando um endereço de broadcast (Figura 2.35.a). A mensagem
enviada pelo roteador R5 é recebida pelos roteadores R3 e R4, que armazenam o par (ID, SN)
correspondente e confirmam a recepção correta com um ACK. Em seguida, o roteador R3 envia a
mensagem para o roteador R1 e o roteador R4 para os roteadores R1 e R2. Novamente, os
roteadores receptores armazenam o par (ID, SN) e respondem aos roteadores transmissores com
mensagens ACK (Figura 2.35.b). A figura assume que as duas mensagens recebidas pelo roteador
R1 chegam exatamente ao mesmo tempo; assim, o roteador R1 só enviará a mensagem recebida
para R2. Por fim, os roteadores R1 e R2 enviam a mensagem um para o outro, mas ambas as
mensagens são descartadas, pois o par (ID, SN) que eles carregam já está armazenado nos
roteadores receptores (Figura 2.35.c). Apesar de descartarem as mensagens, os roteadores R1 e
R2 confirmam sua correta recepção com um ACK. A partir daí, nenhuma outra mensagem circula na
rede (Figura 2.35.d).
2.4.5 A divulgação das NRs
A disseminação de NRs pode ser baseada no processo de inundação controlado e confiável descrito
nas duas seções anteriores. Conforme explicado na Seção 2.4.3, as mensagens a serem divulgadas
devem ser rotuladas com identificadores únicos. Nos protocolos LSR, (i) as mensagens são as
instâncias NR, (ii) as instâncias NR são identificadas exclusivamente usando o identificador NR e a
atualização NR, e (iii) a atualização NR é expressa usando SNs. Além disso, quando uma nova
instância de NR é criada, todas as outras instâncias do mesmo NR (que devem ter um SN inferior)
tornam-se desatualizadas e irrelevantes para o processo de roteamento. Assim, uma instância NR
que chega a um roteador com SN inferior a uma instância existente está desatualizada e não precisa
ser retransmitida, mesmo que esteja chegando ao roteador pela primeira vez.
As regras para o flooding controlado e confiável de uma instância NR chegando

em um roteador são os seguintes:
• Se nenhuma instância do NR de entrada estiver armazenada no roteador, armazene a instância de

entrada e retransmita-a em todas as interfaces, exceto aquela em que foi recebida;

R2 R2
R1 R1
R3 ACK R4 R3 ID=5 ID=5 R4

SN=1 SN=1
mensagem
ID=5 ID=5
(a) R5 SN=1 (b) R5 SN=1
ID=5 ID=5
SN=1 SN=1
ID=5 ID=5
SN=1 SN=1
R2 R2
R1 R1
R3 ID=5 ID=5 R4 R3 ID=5 ID=5 R4

SN=1 SN=1 SN=1 SN=1
ID=5 ID=5
(c) R5 SN=1 (d) R5 SN=1
FIGURA 2.35: Inundação controlada e confiável.
• Se houver uma instância armazenada com um SN menor, substitua-a pela instância de entrada e
retransmita a instância de entrada em todas as interfaces, exceto aquela em que foi recebida;
• Caso contrário, descarte a instância recebida;
• Sempre confirme o recebimento de um NR de entrada para o vizinho

roteador que o transmitiu.
A confirmação de recepção de uma NR não precisa conter o conteúdo completo da NR;

apenas o identificador de instância NR é necessário para identificar completamente o NR que está
sendo reconhecido.
Dependendo do tipo de NR e da estrutura da rede, os NRs podem precisar ser inundados
apenas em algumas zonas da rede; a zona de rede onde um NR deve ser inundado é chamada de
escopo de inundação de NR.

O OSPF e o IS-IS usam o processo de inundação confiável e controlado que acabamos de

descrever em links ponto a ponto, e o OSPF também o usa em links compartilhados, com pequenas
alterações. No IS-IS, a confiabilidade nos enlaces compartilhados é obtida através da transmissão
periódica, pelo DR, dos identificadores de instância dos NRs dos últimos NRs inundados no enlace.
A disseminação de NRs pode ser realizada por meio de um procedimento de inundação

controlado e confiável. O controle do processo de flooding é baseado no identificador de
instância NR, que usa SNs para expressar frescor.
Um NR que chega a um roteador é descartado se houver uma instância armazenada desse
NR com SN igual ou superior; caso contrário, é retransmitido em todas as interfaces,
exceto aquela em que foi recebido. A confiabilidade do processo de inundação é alcançada
pelo ACK protegendo os NRs transmitidos entre roteadores vizinhos.
2.4.6 Exclusão de NRs

Existem várias situações em que NRs devem ser excluídos do LSDB. A exclusão de um NR pode
ser realizada por meio de uma indicação de exclusão, disseminada usando o procedimento de
flooding controlado e confiável descrito acima. As indicações de exclusão não precisam conter todo
o conteúdo e nem mesmo o atributo de atualização do NR que está sendo excluído: apenas o
identificador do NR é necessário.
Ao divulgar indicações de exclusão, o controle do processo de inundação é feito através da
verificação da ação pretendida (ou seja, se a NR já foi excluída). O procedimento seguido quando
uma indicação para excluir um NR chega a um roteador é o seguinte:
• Se o NR referenciado ainda estiver armazenado no LSDB, exclua este NR e transmita a indicação

delete em todas as interfaces exceto aquela onde a indicação foi recebida;
• Caso contrário, descarte a indicação;
• Sempre confirme a recepção de uma indicação de exclusão para o vizinho

roteador que o transmitiu.
A necessidade de um tempo de guarda Um roteador pode deletar um NR e criá-lo novamente logo

em seguida. Assim, uma indicação para excluir um NR pode ser seguida de uma indicação para
criar um novo NR com o mesmo identificador, que passará a ter um SN igual ao valor inicial. Nesse
caso, existe o perigo de que a indicação para criar chegue antes a um roteador do que a indicação
para excluir. Caso isso aconteça, o novo NR não será instalado pois possui um SN menor que o
armazenado. A solução para esse problema é impor um tempo de guarda no roteador de origem
entre as transmissões dessas duas indicações. O guard-time deve ser suficiente para permitir a
propagação da indicação delete para todos os roteadores da rede; é chamado de RESTART-TIME
em [40], onde este problema também é discutido.

identificador NR identificador NR
frescura NR frescura NR
NR corpo NR corpo identificador NR identificador NR

frescura NR frescura NR
ATUALIZAR ACK (ATUALIZAÇÃO)
identificador NR identificador NR identificador NR identificador NR
EXCLUIR ACK (EXCLUIR)
FIGURA 2.36: Mensagens UPDATE, ACK (UPDATE), DELETE e ACK (DELETE) e seus conteúdos.
NRs podem ser excluídos pela divulgação de uma indicação de exclusão usando um
procedimento de flooding controlado e confiável. A indicação precisa conter apenas o
identificador da NR da NR que está sendo deletada. Deve haver um tempo de guarda
entre inundar uma indicação para deletar uma NR e inundar uma nova NR com o mesmo
identificador da deletada anteriormente.
2.4.7 Mensagens de controle

Os NRs, os NRs de confirmação e a indicação para excluir NRs devem ser transmitidos entre
roteadores vizinhos encapsulados em mensagens de controle.
O tipo de mensagem de controle fornece a semântica da ação pretendida. Chamaremos de
UPDATE as mensagens que transmitem instâncias NR completas, DELETE as mensagens que
carregam indicações de exclusão, ACK (UPDATE) as mensagens que confirmam o recebimento
de NRs completos e ACK (DELETE) as mensagens que confirmam o recebimento de indicações
de exclusão.
Conforme destacado anteriormente, uma mensagem DELETE precisa apenas incluir o
identificador do NR que está sendo excluído, e o mesmo vale para mensagens ACK (DELETE).
Da mesma forma, uma mensagem ACK (UPDATE) precisa apenas incluir o identificador de
instância da instância NR que está sendo reconhecida. Isso é ilustrado na Figura 2.36.
Para agregar flexibilidade, consideramos que essas mensagens podem transportar

informações relativas a mais de um NR. Por exemplo, uma mensagem UPDATE pode transportar
mais de uma instância NR e uma mensagem ACK (UPDATE) pode transportar mais de uma
confirmação. Assim, as mensagens de controle são apenas contêineres que transportam
informações relativas a NRs entre vizinhos.
Em links compartilhados, não há necessidade de transmitir uma mensagem UPDATE (ou uma

SN inicial ab SN final
SN
envolver em torno
FIGURA 2.37: Números de sequência linear envolvente.
DELETE) para cada vizinho individual no link: uma única transmissão de mensagem é suficiente se
enviada para um broadcast ou um endereço multicast conhecido por todos os vizinhos. Todos os
roteadores que recebem uma instância NR (ou indicação de exclusão de NR) devem reconhecer
seu recebimento. Ao contrário do caso das mensagens UPDATE e DELETE, não há benefício em
transmitir mensagens ACK usando endereços broadcast ou multicast.
As instâncias NR são transportadas entre roteadores vizinhos usando mensagens UP

DATE, indicações de exclusão NR usando mensagens DELETE, as confirmações de
instâncias NR usando ACK (UPDATE) e as confirmações de indicações de exclusão NR
usando mensagens ACK (DELETE). Essas mensagens podem transportar informações
relativas a mais de um NR.
2.4.8 Problema envolvente

O uso de um espaço linear de SNs para expressar frescor, crescendo de um valor inicial para um
valor final, coloca o problema de decidir o que fazer quando o valor final for alcançado. Normalmente,
o espaço dos SNs é suficientemente grande para tornar esse evento raro; de qualquer forma, os
protocolos LSR devem considerar essa possibilidade. Uma solução para esse problema é contornar
o espaço SN e reiniciar a partir do valor inicial, conforme ilustrado na Figura 2.37. Neste caso, a
instância NR disseminada após aquela com o valor SN final é transmitida com o valor SN inicial. Isso
introduz outro problema: após o wrap around, a instância NR mais recente terá um SN menor que a
mais antiga (a mais recente tem SN=1 e a mais antiga tem o valor final de SN), e as regras de
inundação impedem sua disseminação. Uma solução simples é deletar primeiro a instância NR
antiga, usando o mecanismo de exclusão introduzido na Seção 2.4.6, e só depois inundar a nova
instância NR com o SN inicial. Conforme apontado na Seção 2.4.6, deve haver um tempo de guarda
entre a transmissão da indicação de exclusão e a transmissão da NR subseqüente, para garantir
que a indicação de exclusão chegue primeiro a todos os roteadores.

Quando o SN atinge seu valor final, o espaço SN envolve, ou seja, a próxima

instância NR terá um SN igual ao valor inicial. No entanto, para permitir a
disseminação da instância com o valor SN inicial, a instância com o valor SN
final deve ser excluída primeiro.
2.4.9 Remoção de NRs desatualizadas
Os NRs desatualizados originados por um roteador com falha podem permanecer

indefinidamente no LSDB. Isso não prejudica o processo de roteamento, pois, conforme
discutido na Seção 2.2.1.7, o roteador com falha fica isolado no mapa da rede. No
entanto, desperdiça recursos de memória desnecessariamente. Uma solução para
economizar memória é permitir que os roteadores excluam NRs com base apenas em
considerações topológicas. Por exemplo, se um roteador analisa seu mapa de rede
(por exemplo, ao construir a tabela de encaminhamento) e observa que um roteador
ficou isolado, os NRs originados por esse roteador podem ser removidos com
segurança do LSDB. No exemplo da Figura 2.16, esse processo excluiria do LSDB o
router-NR e o slink-NR originados pelo roteador R2.
Uma alternativa ao processo descrito acima é permitir que NRs desatualizados
sejam removidos usando um mecanismo de tempo de vida. Nesse caso, cada NR
recebe uma idade que vai aumentando enquanto o NR é armazenado na memória e,
quando a idade atinge um tempo de vida predefinido, o NR é deletado do LSDB. Nesse
caso, alguma medida deve ser tomada para evitar a exclusão de NRs legítimas em
operação estável. Em particular, a idade de um NR legítimo deve ser atualizada
(redefinida para zero) antes que seu tempo de vida seja atingido. A atualização pode
ser implementada gerando periodicamente, com um período menor que o tempo de
vida, uma nova NR em instância com idade zero. Esta instância NR é então
disseminada por toda a rede e substitui a instância mais antiga (com maior idade).
Assim, nesta alternativa, novas instâncias de NR devem ser criadas e disseminadas
periodicamente mesmo que a rede permaneça inalterada. Essa é justamente a solução
adotada tanto pelo OSPF quanto pelo IS-IS para deletar NRs desatualizadas. O tempo
de vida é de 1 hora em OSPF e 20 minutos em IS-IS, com um período de atualização
de 30 minutos em OSPF e 15 minutos em IS-IS.
Quando um roteador falha, os NRs que ele originou devem ser excluídos do
LSDB, para evitar o desperdício de recursos de memória. Uma alternativa é
deletar os NRs originados pelos roteadores que ficaram isolados no mapa da
rede. Outra alternativa é usar um mecanismo age-lifetime, em que os NRs
recebem uma idade e são excluídos do LSDB quando sua idade atinge um
tempo de vida predefinido. Nesse caso, para evitar a exclusão de NRs
legítimas em operação estável, novas instâncias de NRs com idade zero
devem ser divulgadas periodicamente.

2.5 Sincronização LSDB inicial Quando dois roteadores se
tornam vizinhos (através do protocolo Hello), eles podem precisar sincronizar seus LSDBs. Os dois
roteadores, mesmo que estejam conectados à rede há muito tempo, podem não prever se o conteúdo
de seus LSDBs é o mesmo. Além disso, quando um roteador se conecta a uma rede, pode fazê-lo
conectando vários vizinhos. Se a rede estiver em condição estável, todos esses vizinhos devem ter
o mesmo LSDB. A questão é então se o roteador que está entrando precisa sincronizar seu LSDB
com todos os vizinhos contatados ou se basta sincronizar com um único.
Em qualquer caso, um protocolo deve ser criado para a sincronização LSDB entre dois vizinhos.
Como o tamanho do LSDB pode ser grande, o protocolo deve tentar minimizar a quantidade de
informações trocadas.
O processo de sincronização do LSDB deve ser acoplado ao procedimento de inundação. Um
roteador que sincroniza seu LSDB com um vizinho pode obter novos NRs ou instâncias mais
recentes de NRs existentes do vizinho. Neste caso, o roteador deve disseminar a nova informação
pela rede, utilizando o procedimento da Seção 2.4.5.
Discutiremos esses aspectos nas próximas seções.
2.5.1 Com quais vizinhos sincronizar?

Para discutir com quais vizinhos um roteador deve sincronizar ao ingressar em uma rede,
consideramos vários cenários com complexidade crescente. Nesses cenários, o roteador de entrada
conecta-se à rede por meio de:
• um único vizinho;
• vários vizinhos localizados na mesma rede;
• vários vizinhos localizados em diferentes partes da rede (ou seja, com diferentes LSDBs), por meio
de links ponto a ponto;
• vários vizinhos localizados em diferentes partes da rede, por meio de um link compartilhado.
Esses cenários são ilustrados na Figura 2.38.
Conectando a rede por meio de um único vizinho No primeiro (e mais simples) cenário, o roteador
de entrada conecta-se à rede por meio de um único vizinho (Figura 2.38.a). Nesse caso, os dois
roteadores devem trocar seus LSDBs. Observe que mesmo um roteador que acabou de ser ligado
já terá um LSDB, consistindo pelo menos em seu roteador-NR auto-originado. Na Figura 2.38.a, o
roteador R1 envia LSDB1 para o roteador R2 e o roteador R2 envia LSDB2 para o roteador R1.
Então, cada roteador mescla o LSDB recebido do vizinho com o seu próprio LSDB, e ambos chegam
ao mesmo LSDB, ou seja, ficam sincronizados. Este exemplo mostra que a sincronização LSDB
inicial entre

2.5 Sincronização LSDB inicial 105
/6'% /6'%
R2 R2 R3
/6'% /6'% /6'% /6'%
R1 R1
/6'% /6'%
(a) (b)
/6'% /6'% /6'% /6'%
R2 R3 R2 R3
/6'% /6'%
/6'%
/6'% /6'% / /6'% /
6'% 6'%
R1 R1
/6'% /6'%
(c) (d)
/6'% /6'%
R1 R2
/6'% /
/6'% 6'% /
6'% /
/6'% /6'% 6'%
R3 R4
/6'% /6'%
(e)
FIGURA 2.38: Cenários iniciais de sincronização do LSDB.

dois roteadores devem ser sempre bidirecionais, ou seja, um roteador deve enviar para o outro uma
cópia de seu LSDB, por mais simples que seja.
Conectando a rede por meio de vários vizinhos localizados na mesma rede No segundo cenário, o
roteador de entrada conecta-se à rede por meio de vários vizinhos localizados na mesma rede
(Figura 2.38.b).
Nesse caso, pode-se perguntar se basta sincronizar o LSDB com apenas um vizinho. Os vizinhos
contatados podem ter exatamente o mesmo LSDB se a rede estiver em um estado estável, mas
também podem ter diferentes LSDBs, nenhum deles totalmente atualizado, se a rede estiver em um
estado variável. O LSDB de um roteador não é totalmente atualizado no período entre a origem das
informações de roteamento que irão alterar o LSDB (por exemplo, inserção de um novo NR ou
exclusão de um existente) e a chegada dessas informações ao roteador. Porém, se o LSDB de um
vizinho contatado não estiver totalmente atualizado, esse vizinho certamente receberá posteriormente
as informações que faltam, e então terá a oportunidade de entregá-las ao roteador de entrada
através do procedimento de flooding. Assim, de acordo com este cenário, um roteador de entrada
só precisa entrar em contato com um vizinho.
Conectando a rede por meio de vários vizinhos localizados em diferentes partes da rede, por meio
de links ponto-a-ponto links de ponto. Dizemos que o roteador associado está resolvendo um
problema de partição de rede. Nesse cenário, se o roteador sincronizar apenas com um vizinho, ele
obterá apenas o LSDB de uma parte da rede e não poderá se comunicar com as outras partes ou
fornecer conectividade entre as várias partes desconectadas. Na Figura 2.38.c, o roteador R1 entra
na rede, torna-se vizinho de R2 e R3, mas sincroniza apenas com R2. Nesse caso, o roteador não
conseguirá se comunicar com a parte de rede do roteador R3 e a rede permanecerá particionada.
Observe que o procedimento de inundação não ajuda neste caso. Como o roteador R1 obtém
LSDB2 do roteador R2, que é uma nova informação, ele deve disseminá-la para o roteador R3.
Assim, R3 obtém LSDB2; no entanto, nem R1 nem R2 obtêm LSDB3. Conforme mostrado na Figura
2.38.d, a solução para esse problema é ter R1 sincronizando com R2 e R3. Neste caso, R1 pode
injetar em cada lado o LSDB recebido do outro, de forma que os LSDBs se unam.
Uma vez que um roteador que se junta inicialmente não tem informações sobre se dois vizinhos
pertencem à mesma parte da rede, este cenário mostra que um roteador que se junta deve
sincronizar o LSDB com todos os seus vizinhos.
Conectando a rede através de vários vizinhos localizados em diferentes partes da rede, através de
links compartilhados O procedimento definido acima pode ser relaxado no caso de vizinhos
conectados ao mesmo link compartilhado. Esses vizinhos estão diretamente conectados entre si e,
em condições estáveis, pertencem necessariamente à mesma parte da rede e possuem o mesmo
LSDB. Portanto, basta sincronizar com um único vizinho em um link compartilhado. Esse vizinho
geralmente é o link DR. Quando os roteadores conectados a um link compartilhado são todos ligados
ao mesmo tempo (inicialização a frio), alcançando a sincronização LSDB completa

RD
R3
link ponto a ponto R4 R5 R6
SINCRONIZAR
R2 SINCRONIZAR
link compartilhado
SINCRONIZAR
R1
juntando-se ao roteador
FIGURA 2.39: Vizinhos que devem sincronizar com um roteador de entrada durante o
processo inicial de sincronização do LSDB.
A cronização envolve a sincronização LSDB emparelhada entre vizinhos e o

procedimento de inundação. Considere o exemplo da Figura 2.38.e , onde quatro
roteadores, pertencentes a quatro partes de rede separadas e com quatro LS DBs
distintos, conectam-se a um link compartilhado ao mesmo tempo. Suponha que o DR
tenha o papel de disseminar novas informações de roteamento no link. Primeiro, os
roteadores estabelecem relacionamentos de vizinhança entre si (em pares) e elegem
R2 como o link DR. Em seguida, eles começam a sincronizar seus LSDBs com o DR.
Suponha que R2 sincronize primeiro com R1. Nesse caso, R1 e R2 trocam LSDB1 e
LSDB2 e, como LSDB1 é uma nova informação de roteamento para R2, R2 a divulga
no link. Este processo é repetido para R3 e R4 e quando termina, todos os roteadores
compartilham um LSDB comum, mesclando os quatro anteriores. Esta é justamente a
solução adotada pelo OSPF e IS-IS. No IS-IS, o DR transmite periodicamente o LSDB
em links compartilhados, para garantir que ele seja mantido totalmente sincronizado.
Concluímos da discussão acima que um roteador de entrada deve sincronizar

seu LSDB com todos os seus vizinhos em links ponto a ponto e com o DR de cada
link compartilhado ao qual ele se conecta. Isso é ilustrado na Figura 2.39. Isso significa
que, em links compartilhados, a sincronização LSDB só pode ser iniciada após a
eleição do DR.
Dois roteadores que se tornam vizinhos podem precisar sincronizar seus LS

DBs. A sincronização LSDB é necessária quando os roteadores se tornam
vizinhos em um link ponto a ponto. Em links compartilhados, um roteador
precisa apenas sincronizar o LSDB com o link DR.
2.5.2 Protocolo para troca de LSDBs

O protocolo de troca de LSDBs entre dois vizinhos pode, a princípio, ser uma simples
interação requisição-resposta, onde cada roteador solicita o LSDB ao seu vizinho e o
vizinho responde enviando-o. No entanto, os LSDBs dos dois vizinhos podem não ser
completamente diferentes, ou seja, podem conter

várias instâncias NR iguais. Nesse caso, a troca dos LSDBs completos torna-se ineficiente, pois
informações duplicadas são recuperadas desnecessariamente. Uma maneira de lidar com esse
problema é introduzir uma fase preliminar no processo de sincronização em que os roteadores
recuperam não o conteúdo completo do LSDB, mas um resumo do LSDB. O resumo LSDB deve
conter a quantidade mínima de informações necessárias para determinar se as instâncias NR
armazenadas em um vizinho são mais recentes do que aquelas armazenadas localmente. Esta
informação é apenas o identificador da instância do NR, ou seja, o identificador do NR e os atributos
de atualização do NR; por exemplo, o identificador de instância NR de um roteador-NR não inclui a
lista de links aos quais o roteador está conectado e os custos de interface correspondentes. Assim,
a introdução da fase preliminar pode levar a uma economia significativa na quantidade de
informações trocadas.
Com base nas observações acima, um possível protocolo para sincronização inicial do LSDB
é o seguinte (consulte a Figura 2.40):
• Quando dois roteadores estabelecem um relacionamento de vizinhança, cada um deles envia ao

outro uma mensagem, chamada LSDB SUMMARY REQUEST, solicitando o resumo LSDB.
• Um roteador que recebe uma LSDB SUMMARY REQUEST responde com uma mensagem LSDB
SUMMARY, incluindo os identificadores de instância NR de todos os NRs contidos em seu LSDB.
• Ao receber um LSDB SUMMARY, um roteador compara o conteúdo de seu próprio LSDB com os
identificadores de instância NR recebidos do vizinho.
Ele pode então enviar ao vizinho uma mensagem PARTIAL LSDB REQUEST solicitando o
conteúdo completo de todos os NRs que estão faltando ou para os quais o vizinho possui uma
instância mais recente. Essa solicitação é feita usando os identificadores de instância NR.
• Finalmente, um roteador que recebe um PARTIAL LSDB REQUEST responde com o conteúdo
completo dos NRs solicitados, transportados em uma mensagem UPDATE.
O protocolo descrito acima inclui duas interações solicitação-resposta: a primeira interação é a

troca de mensagens LSDB SUMMARY REQUEST e LSDB SUMMARY, e a segunda é a troca de
mensagens PARTIAL LSDB REQUEST e UPDATE. Cada uma dessas interações pode ser protegida
usando a proteção ACK controlada pelo solicitante, onde a resposta reconhece implicitamente o
recebimento da solicitação. Observe que a Figura 2.40 inclui apenas as interações solicitação-
resposta iniciadas pelo roteador R1.
2.5.3 Lidando com NRs autogeridas desatualizadas

Um cenário importante relacionado ao processo de sincronização inicial do LSDB é quando um
roteador é desligado e posteriormente ligado, antes da exclusão de seus NRs auto-originados no
LSDB de seu vizinho. Nesse caso, o vizinho poderia ter em seu LSDB instâncias mais antigas das
NRs auto-originadas com igual

R1 R2
Olá protocolo
FIGURA 2.40: Mensagens de controle trocadas durante o processo inicial de

sincronização do LSDB (são mostradas apenas as requisições iniciadas pelo roteador R1).
ou SNs superiores, já que os NRs criados pelo roteador renascido teriam SN=1. Se
nenhuma medida for tomada, a inundação será evitada até que os SNs das novas
instâncias NR excedam os que estão sendo usados imediatamente antes do desligamento
do roteador.
A Figura 2.41 ilustra esse problema, usando uma rede com três roteadores.
Neste exemplo, assumimos que (i) todos os custos de interface são inicialmente 10, (ii)
o roteador-NR de R1 tem inicialmente um grande SN, digamos 50, e (iii) o link lp3 é
muito mais lento que os outros dois ( Figura 2.41.a). Quando o roteador R1 é desligado,
os roteadores R2 e R3 detectam a falha através do protocolo Hello e disseminam novos
roteadores-NRs onde os links lp1 e lp2 não estão mais listados (Figura 2.41.b). Neste
ponto, e antes de cada roteador receber o roteador-NR enviado pelo outro, R2 e R3
ainda acreditam que o roteador R1 está ativo e acessível. Por exemplo, o gráfico de
conectividade do roteador R2 (Figura 2.41.c) mostra que o roteador R1 pode ser
alcançado por meio de R3. A chegada dos dois roteadores NRs forneceria informações
para R2 e R3 de que o roteador R1 ficou isolado na rede, o que poderia desencadear a
exclusão de seu roteador NR do LSDB.
Porém, suponha que antes que isso aconteça, (i) o roteador R1 seja ligado
novamente, (ii) divulgue um novo roteador-NR (que deve ter SN=1) com custos de
interface diferentes e, como o link lp3 é muito mais lento que o outros dois enlaces, (iii)
esse roteador-NR chega aos roteadores R2 e R3 antes daqueles enviados anteriormente
por esses roteadores entre si (Figura 2.41.d). Neste caso, o antigo roteador-NR de R1
(com SN=50) ainda está no LSDB dos roteadores R2 e R3 quando o novo roteador-NR
(com SN=1) chega, e o novo roteador-NR será descartado , pois tem um SN menor.
Assim, informações desatualizadas sobre

R1 (SN=50)
lp1: 10
R3 lp2: 10
R2 (SN=6)
(a) lp2 lp3 lp1: 10
lp3: 10
R3 (SN=2)
R1 R2 lp2: 10
lp1 lp3: 10
LSDB (todos os roteadores)
R1 (SN=50)
R3 R3 (SN=3)
lp1: 10
lp2: 10
lp3: 10
(b) R2 (SN=7)
lp2
lp3: 10
R2 (SN=7)
lp3: 10 lp3 R3 (SN=2)
R1 R2 lp2: 10
lp1 lp3: 10
LSDB de R2
R1 (SN=50)
R3 lp1: 10
lp2: 10
(c) R2 (SN=7)
lp3: 10
R1 R2 R3 (SN=2)
lp2: 10
lp3: 10
LSDB de r2
R1 (SN=50)
R1 (SN=1) lp1: 10
lp1: 5 R3 lp2: 10
lp2: 5
(d)
lp3
lp2
R1 (SN=50)
lp1
R1 R2 lp1: 10
lp2: 10
R1 (SN=1)
lp1: 5
lp2: 5
FIGURA 2.41: Desligando e ligando novamente um roteador, antes que seus NRs originados sejam
deletados do LSDB dos vizinhos.

R1 R2
Olá protocolo
FIGURA 2.42: Lidando com NRs auto-originados durante o processo inicial de

sincronização do LSDB.
o roteador R1 permanece no LSDB dos roteadores R2 e R3, e esta situação será

mantida até que o SN do roteador-NR enviado pelo roteador R1 seja maior que 50.
O problema descrito acima é fácil de resolver. Durante o processo inicial de

sincronização do LSDB, se um roteador obtiver uma instância de NR auto-originada
de um vizinho, ele inunda uma nova instância desse NR com o SN incrementado
em um (em relação ao SN recebido do vizinho). Isso é ilustrado na Figura 2.42.
Quando o roteador R1 é ligado e sincroniza com o roteador R2, ele recebe um
resumo LSDB do roteador R2, indicando que R2 ainda possui uma instância NR
de R1 com SN=50. Então, o roteador R1 inunda uma nova instância desse NR
com SN=51, que substitui a anterior no LSDB de todos os outros roteadores.
Para evitar a recuperação do mesmo LSDB de vários vizinhos, o processo

inicial de sincronização do LSDB entre dois roteadores pode ser dividido
em duas fases: na primeira fase, ambos os roteadores anunciam um
resumo de seus LSDBs; no segundo, cada roteador solicita ao outro os
NRs que faltam ou para os quais o vizinho possui instâncias mais recentes,
mas somente esses. Quando um roteador descobre que o vizinho tem
NRs originados por ele mesmo, ele dissemina novas instâncias desses
NRs com o SN incrementado em um.

FIGURA 2.43: Mensagens de controle dos protocolos LSR, seu papel e conteúdo.
2.6 Resumo das mensagens de controle

Nesta seção, resumimos as várias mensagens de controle exigidas pelos protocolos LSR que foram
apresentadas neste capítulo. A lista de mensagens, juntamente com sua função e conteúdo, é
mostrada na Figura 2.43.
As mensagens HELLO fazem parte do protocolo Hello. Cada roteador transmite essas
mensagens periodicamente, em todos os seus enlaces, para determinar quais vizinhos estão ativos
em cada enlace. Assim, ele desempenha um papel central na detecção de falhas de roteadores e
links. A mensagem também é usada para eleger o DR e determinar se dois roteadores podem
realmente se tornar vizinhos.
As mensagens UPDATE carregam as instâncias NR que estão sendo disseminadas pela rede
para atualizar o LSDB. Essas mensagens são transmitidas entre roteadores vizinhos, e uma
mensagem pode transportar mais de uma instância NR. As confirmações de que as instâncias NR
foram recebidas corretamente são transportadas em mensagens ACK (UPDATE) e, como no caso
das mensagens UPDATE, uma mensagem pode conter mais de uma confirmação. As confirmações
precisam incluir apenas o identificador de instância das instâncias NR sendo reconhecidas (ou seja,
o identificador NR e os atributos de atualização de NR).
As mensagens DELETE carregam as indicações de exclusão de NR que estão sendo

disseminadas por toda a rede para atualizar o LSDB. Assim como as mensagens UPDATE, as
mensagens DELETE são transmitidas entre roteadores vizinhos,

2.6 Resumo das mensagens de controle 113
e uma mensagem pode transportar mais de uma indicação de exclusão. As indicações de

exclusão precisam apenas incluir o identificador NR do NR que está sendo excluído (o
atributo de atualização do NR não é necessário). As confirmações das recepções corretas
das indicações de exclusão de NR são transportadas em mensagens ACK (DELETE), que
podem novamente transportar mais de uma confirmação. Os reconhecimentos precisam
incluir apenas o identificador NR.
As mensagens LSDB SUMMARY REQUEST, LSDB SUMMARY, PARTIAL LSDB
REQUEST são utilizadas no processo inicial de sincronização do LSDB, que ocorre entre
pares de vizinhos (ver Seção 2.5). O LSDB SUM MARY REQUEST solicita ao vizinho que
envie o resumo de seu LSDB, e o LSDB SUMMARY carrega esse resumo. O resumo LSDB
contém os identificadores de instância NR de todos os NRs presentes no LSDB. A
mensagem LSDB SUM MARY reconhece implicitamente a recepção do LSDB SUM MARY
REQUEST. Finalmente, o PARTIAL LSDB REQUEST solicita ao vizinho que envie o
conteúdo completo dos NRs selecionados, especificamente os NRs que faltam no roteador
ou para os quais o vizinho possui instâncias mais recentes. Essas mensagens carregam
apenas os identificadores de instância NR dos NRs completos que estão sendo solicitados.
As instâncias NR completas são enviadas em mensagens UPDATE. Assim, receber um
NR completo (encapsulado em uma mensagem UPDATE) reconhece implicitamente o
recebimento da solicitação (encapsulado em uma mensagem PARTIAL LSDB REQUEST);
um roteador continuará solicitando uma instância NR até recebê-la do vizinho, sob o controle
de um timer ACK.
OSPF e IS-IS dão nomes diferentes para suas mensagens de controle (com exceção
de HELLO), e os nomes também são diferentes dos apresentados neste capítulo. No
entanto, os papéis desempenhados pelas mensagens são os mesmos nos três casos. Na
Figura 6.1, fornecemos uma correspondência detalhada entre as mensagens de controle do
OSPF, IS-IS e do nosso próprio protocolo (chamado de genérico na figura).


3
Princípios do estado de link multiárea
Roteamento
Os protocolos LSR requerem o armazenamento de uma instância completa do LSDB em cada roteador.
No entanto, quando a rede é grande, contendo muitos roteadores e links, o LSDB também se torna
grande e alguns roteadores podem não ter recursos de memória para armazená-lo completamente.
Uma forma de contornar esse problema é estruturar a rede em áreas menores, de forma que os
roteadores só precisem manter o mapa da rede da área a que pertencem. Economias significativas de
memória podem ser alcançadas dessa maneira.
As áreas são delimitadas por roteadores especiais chamados Area Border Routers (ABRs).
Cada área constrói e mantém seu próprio LSDB, chamado de área LSDB. O LSDB contém o mapa de
rede da área, que precisa ser conhecido apenas dentro da área, e os prefixos internos à área. No
entanto, para se comunicar com outras áreas, uma área ainda precisa conhecer os prefixos disponíveis
fora de seus limites e os caminhos que devem ser usados para alcançá-los. Essas informações são
trocadas entre as áreas por meio de um protocolo de roteamento entre áreas executado entre os ABRs.
Existem várias abordagens possíveis disponíveis para o roteamento entre áreas.
Como no caso do Capítulo 2, queremos manter a discussão neste capítulo mais centrada em
conceitos do que em tecnologias. Como será visto no Capítulo 7, OSPF e IS-IS restringem a topologia
de rede entre áreas a uma estrutura hierárquica de dois níveis e usam uma abordagem de vetor de
distância em seu protocolo de roteamento entre áreas. Nesta seção, consideraremos topologias
arbitrárias entre áreas e as abordagens de vetor de distância e estado de enlace para roteamento
entre áreas.
Estrutura do capítulo A Seção 3.1 apresenta os principais aspectos relacionados à estrutura de rede
multiárea e ao protocolo de roteamento interárea. A Seção 3.2 apresenta as abordagens de vetor de
distância e estado de enlace para roteamento entre áreas.
A Seção 3.3 discute as consequências de restringir as informações de roteamento disponíveis nas
áreas. Finalmente, a Seção 3.4 apresenta alternativas para anunciar informações de endereçamento
externo de domínio em todas as áreas.
115

116 3 princípios de roteamento de estado de link multiárea
$UHD $UHD
/6'% /6'%
$%5
LQWHUQDO F
URXWHU
$%5 $%5
$%5
D G
E
$UHD $UHD
/6'% /6'%
$%5
$%5
H
EU
LQWHUQDO
URXWHU
$UHD /
6'%
FIGURA 3.1: Estrutura da rede multiárea.
3.1 Estrutura de rede multiárea e roteamento entre áreas

Em uma rede multiárea, a rede é particionada em várias áreas que se comunicam por meio
de ABRs. A Figura 3.1 representa uma rede estruturada em cinco áreas (1 a 5) conectadas
por seis ABRs (a a f ). Também inclui alguns roteadores internos para áreas.
A informação de roteamento interno a uma área, ou seja, o mapa de rede da área e os

prefixos internos, é obtida através do protocolo de roteamento que roda dentro de cada área,
ou seja, o protocolo de roteamento intra-área. Este é um protocolo LSR e, como tal, as
informações são obtidas usando os procedimentos de redes de área única discutidos no
Capítulo 2.
A sobreposição ABR O conjunto de ABRs e suas interconexões formam uma sobreposição
de roteamento, ou seja, uma rede lógica sobre a rede física utilizada para a troca de
informações de roteamento entre áreas. O protocolo de roteamento entre áreas é executado
nessa sobreposição e é por meio desse protocolo que os ABRs aprendem sobre os destinos
externos e calculam os custos do caminho mais curto até eles.
Na Figura 3.1, a sobreposição ABR é representada por linhas mais grossas.
Assume-se que (i) cada interface ABR está associada a uma área e

3.1 Estrutura de rede multiárea e roteamento entre áreas 117
S
endereços domínio externo
endereços externos de área endereços
internos de área
área A
domínio X todos os outros domínios
FIGURA 3.2: Tipos de endereços da perspectiva de um roteador interno de área

(roteador S).
que (ii) conexões (diretas) entre ABRs só podem existir entre duas interfaces da mesma
área. Cada conexão torna-se então associada a uma área.
As conexões entre os ABRs são realizadas através do mecanismo de inundação
fornecido pelo protocolo LSR intra-área. Os ABRs conectados à mesma área são
chamados de ABRs vizinhos. As conexões entre os ABRs vizinhos formam uma malha
completa dentro de cada área. Por exemplo, na rede da Figura 3.1, os ABRs a, b e e
são vizinhos na área 3, e estão interligados nesta área através de uma malha completa;
o mesmo vale para os ABRs b, d e f na área 4. Observe que dois ABRs vizinhos podem
não estar conectados diretamente por meio de um link de camada 2, pois pode haver
vários roteadores internos interpostos no caminho entre eles.
A área LSDB Em uma rede multi-área, cada área constrói e mantém seu próprio LSDB.
Os roteadores internos a uma área mantêm apenas um LSDB, enquanto os ABRs
mantêm tantos LSDBs quanto as áreas às quais se conectam diretamente. Por exemplo,
a rede da Figura 3.1 tem cinco LSDBs diferentes e o ABR b mantém os LSDBs das
áreas 1, 3 e 4.
Um roteador não tem conhecimento da topologia de rede além de sua área. Assim,
as informações topológicas contidas na área LSDB são restritas à área.
Relativamente à informação de endereçamento, dentro de uma área já se podem
distinguir três tipos de prefixos: area-internal (prefixos internos à área), area-external
(prefixos externos à área mas internos ao domínio de encaminhamento) e domain-
externo (prefixos externos ao domínio). Iremos nos referir às informações que são
externas à área ou externas ao domínio simplesmente como informações de
endereçamento externo. A Figura 3.2 mostra os vários tipos de endereços do ponto de
vista do roteador S.
Os destinos externos à área que precisam ser conhecidos dentro de uma área
geralmente são prefixos de endereço, mas, em algumas circunstâncias especiais,
também podem ser roteadores. Isso não é necessário, mas algumas tecnologias o
fazem. Por exemplo, no OSPF, os identificadores dos DBRs são anunciados nas áreas
por meio do protocolo de roteamento entre áreas. Discutiremos esse recurso na Seção 3.4.
O protocolo de roteamento entre áreas Os prefixos de endereços externos e os
caminhos para alcançá-los são aprendidos por meio do protocolo de roteamento entre
áreas executado na sobreposição ABR. O papel do protocolo de roteamento entre áreas é então

determinar caminhos que suportam as comunicações com destinos externos a uma área. O
protocolo de roteamento entre áreas deve ser projetado para atingir o roteamento ótimo
globalmente, ou seja, de modo que os caminhos selecionados entre dois roteadores sejam
sempre os mais curtos. No entanto, tanto o OSPF quanto o IS-IS incluem restrições na forma
como as informações de roteamento são disseminadas, o que impede essa possibilidade em
alguns casos.
Abordagens de roteamento entre áreas As principais abordagens de roteamento entre áreas são
o estado do enlace e o vetor de distância; discutiremos essas alternativas na Seção 3.2. Também
poderíamos ter considerado a abordagem do vetor caminho (ver Capítulo 3 de [33]). No entanto,
esta abordagem parece mais adaptada ao roteamento entre domínios e compartilha muitos
aspectos comuns com a abordagem do vetor de distância. Observe que, em nosso caso, o
protocolo de roteamento intra-área é considerado do tipo LSR, independentemente da abordagem
de roteamento inter-área.
Comparação com o roteamento entre domínios O roteamento entre áreas é, em muitos aspectos,
semelhante ao roteamento entre domínios (que discutimos na Seção 2.2.4).
Do ponto de vista de uma área ou de um domínio, o problema em ambos os casos é aprender
os prefixos externos e determinar qual ABR ou DBR deve ser usado para alcançar esses prefixos.
Em ambos os casos, o protocolo de roteamento que obtém essas informações é executado em
alguma sobreposição de roteamento. No roteamento entre áreas é a sobreposição de ABRs e
no roteamento entre domínios é a sobreposição de DBRs. A principal diferença entre esses dois
tipos de roteamento são as métricas de caminho. No roteamento entre áreas, as métricas de
caminho de diferentes áreas são comparáveis, o que permite calcular os caminhos mais curtos
ponta a ponta entre roteadores localizados em áreas diferentes.
No roteamento entre domínios, as métricas de caminho de diferentes domínios geralmente não
são comparáveis, e as decisões de roteamento geralmente envolvem atributos de roteamento
de vários tipos (por exemplo, a preferência de um domínio sobre os outros e a contagem de saltos).
Um domínio de roteamento pode ser estruturado em várias áreas. Cada área constrói
e mantém um LSDB contendo o mapa de rede da área e três tipos de informações de
endereçamento: área interna, área externa (externa à área, mas interna ao domínio
de roteamento) e domínio externo (externo ao domínio). Os roteadores não têm
conhecimento do mapa de rede de outras áreas. A troca de informações de roteamento
entre áreas é realizada por meio de um protocolo de roteamento inter-área executado
entre os roteadores localizados na fronteira entre as áreas, denominados Area Border
Routers (ABRs).
3.1.1 Etapas na comunicação de informações externas entre

áreas
Considere a comunicação entre o roteador S, localizado em uma determinada área (a área de

origem), e o prefixo ap1, localizado em uma área diferente (a área de destino).
Em vez de um prefixo, o destino pode, em casos especiais, ser um roteador, mas a discussão é
semelhante. Antes de poder enviar mensagens de dados para ap1, o roteador S

ABR
2
custo de divulgação
ABR ABR 3
e atualização
ABR
1
ap1 S
sobreposição ABR
área de destino área de origem
FIGURA 3.3: Etapas na comunicação de informações externas entre as áreas.
precisa aprender que o prefixo existe e precisa determinar um caminho (espero que seja
um caminho mais curto) para ele. Conforme destacado na Seção 1.4.3, as informações de
roteamento começam a ser anunciadas pelo destino e fluem do destino para a origem.
Existem três etapas nesse processo, que representamos na Figura 3.3.
Coletar Primeiro, o ABR da área de destino coleta informações relativas ao prefixo ap1 e
injeta essas informações no protocolo de roteamento entre áreas.
Esta informação tem dois elementos: o prefixo e o custo do caminho mais curto do ABR ao
prefixo; vamos nos referir a ele como o par (prefixo, custo). Os ABRs obtêm essas
informações do LSDB da área de destino.
Custo de disseminação e atualização Em segundo lugar, o protocolo de roteamento entre

áreas divulga as informações de roteamento na sobreposição ABR e atualiza os custos de
caminho mais curto para o prefixo anunciado.
Conforme mencionado acima, o protocolo de roteamento entre áreas pode adotar uma
abordagem de estado de link ou de vetor de distância. Essas abordagens diferem no tipo
de informação de roteamento que é trocada entre os ABRs e em como ela é disseminada.
Na primeira abordagem, a informação de roteamento originada por um ABR é entregue
inalterada para todos os outros ABRs, ou seja, é transmitida diretamente de cada ABR de
origem para todos os outros ABRs. Na segunda abordagem, as informações de roteamento
são transmitidas apenas entre os ABRs vizinhos, e os custos estimados para os prefixos
anunciados são atualizados por cada ABR intermediário à medida que as informações se
afastam do ABR de origem. Essas duas abordagens de roteamento entre áreas serão
estudadas em detalhes na Seção 3.2.
Para a troca de informações de roteamento dentro da sobreposição ABR, é necessário
algum mecanismo de comunicação entre os ABRs. O mecanismo de inundação intrínseco
aos protocolos LSR fornece uma maneira natural de disseminar a rota

informações entre ABRs vizinhos. Como será discutido mais tarde, na abordagem de
roteamento de estado de link, as informações de roteamento entre áreas usam o procedimento
de inundação com escopo de inundação de domínio, para garantir que a informação seja
entregue sem modificações para todos os ABRs. Ao contrário, a abordagem de roteamento
do vetor de distância usa o procedimento de inundação com escopo de inundação de área,
de modo que as informações de roteamento entre áreas sejam comunicadas apenas entre
os ABRs vizinhos e não cruzem as bordas da área sem serem atualizadas.
Injetar Na terceira e última etapa, os ABRs injetam as informações de roteamento recebidas
por meio do protocolo de roteamento entre áreas na área de origem, para que cheguem ao
roteador S.
Esta última etapa não é obrigatória, pois os roteadores internos não precisam conhecer
os prefixos externos disponíveis: eles podem simplesmente encaminhar pacotes para um dos
ABRs da área e deixar que os ABRs cuidem das decisões de roteamento subseqüentes. Se
a área for stub, ou seja, uma área com um único ABR, nem mesmo é recomendável injetar
informações de roteamento externo na área, pois desperdiça recursos de memória e largura
de banda desnecessariamente; isso é semelhante à injeção de informações de
endereçamento externo de domínio em domínios stub, discutido na Seção 2.2.4.
Caso contrário, se a área tiver mais de um ABR, é necessário injetar informações de
roteamento para obter o roteamento ideal globalmente. Discutiremos mais essa questão na
Seção 3.3.
3.1.2 Determinando caminhos mais curtos de ponta a ponta

Quando a origem e o destino estão em áreas diferentes, a determinação do caminho mais
curto ponta a ponta é feita com a intermediação dos ABRs da área.
Do ponto de vista do roteador de origem, esse cálculo equivale a selecionar o ABR de saída
que leva ao destino, pois os roteadores desconhecem a topologia da rede além de sua área.
A Figura 3.4 ilustra o ponto de vista do roteador de origem. Um caminho de ponta a ponta
tem dois subcaminhos, um interno e outro externo à área. O subcaminho interno é do roteador
de origem (roteador S) para um ABR, e o subcaminho externo é desse ABR para o prefixo
de destino (prefixo ap1). O roteador de origem conhece sua área em detalhes: com base nas
informações topológicas presentes em seu LSDB, ele sabe quais roteadores são ABRs e
como calcular o custo do caminho de si para cada um dos ABRs. Seja cSi o custo do roteador
S para ABR i, ou seja, o custo de um subcaminho interno. Os custos dos subcaminhos
externos são fornecidos pelos ABRs. Os ABRs obtêm essas informações por meio do
protocolo de roteamento entre áreas e as disseminam dentro das áreas às quais estão
diretamente vinculados. Seja CiD o custo de ABR i até o destino D, ou seja, o custo de um
subcaminho externo.
Assim, o processo de determinar, em um roteador, o caminho mais curto ponta a ponta

para um destino compreende três etapas:
1. O roteador obtém os custos dos subcaminhos externos, ou seja, obtém os custos

de cada ABR até o destino (o custo CiD

Um sutiã
Cafajeste
cSa
cSb CDb
S ABR b ap1
cSc CcD
PEATE c
fonte rede
área restante
FIGURA 3.4: Visualização do roteador de origem ao determinar o caminho mais curto

para um destino externo à área.
componente); esses custos são injetados na área de origem pelos ABRs da

área e são disseminados na área por meio do procedimento de inundação.
2. Usando o mapa de rede da área, o roteador determina os custos dos

subcaminhos internos, ou seja, os custos dos caminhos mais curtos de si
para cada ABR (o componente de custo cSi ).
3. O roteador determina o custo do caminho fim-a-fim através de cada ABR, ou
seja, ele calcula cSi + CiD para cada ABR e seleciona o caminho de menor
custo e o ABR de saída correspondente.
Para determinar o caminho mais curto para um destino localizado em outra

área, um roteador soma o custo dos caminhos mais curtos de si mesmo para
cada um de seus ABRs de área, obtidos por meio do mapa da rede de área, ao
custo dos caminhos mais curtos desses ABRs para o destino, obtido através do
protocolo de roteamento entre áreas e injetado na área pelos ABRs; ele então
seleciona o melhor entre esses caminhos, ou seja, o de menor custo.
3.1.3 Área LSDB
A área LSDB inclui o mapa de rede da área e as informações de endereçamento internas

e externas à área. Como no caso das redes de área única, o mapa da rede é formado
pelos roteadores-NRs e slink-NRs. Esses

NRs agora são inundados apenas dentro das áreas, já que as informações topológicas
não interessam fora das áreas; dizemos que essas NRs estão inundadas com escopo de
inundação de área. Além disso, um roteador-NR de uma área descreve apenas as
interfaces do roteador representado que pertencem a essa área. Assim, um ABR terá
suas interfaces descritas em diferentes roteadores-NRs, pertencentes a diferentes LSDBs.
A informação de endereçamento interno a uma área, ou seja, os prefixos atribuídos
aos elementos da rede de área, é fornecida pelos aip-NRs, como no caso das redes de
área única.
O prefixo de área externa NR Para representar informações de endereçamento de área
externa dentro da área LSDB, introduzimos o prefixo de área externa NR (aep NR para
abreviar). Essas NRs são originadas pelos ABRs e disseminadas dentro das áreas às
quais estão diretamente vinculadas, para cumprir a terceira etapa da Figura 3.3. Assim,
o aep-NR inclui (i) o identificador do ABR de origem e (ii) os pares (prefixo, custo) obtidos
através do protocolo de roteamento interárea. Como roteador-NRs e slink-NRs, aep-NRs
são apenas disseminados dentro de uma área, ou seja, eles são inundados com escopo
de inundação de área.
Acréscimos ao domínio-externo-prefixo-NR As informações de anúncio domínio-externo
também precisam ser disseminadas dentro das áreas. Na Seção 2.2.4.2, introduzimos o
dep-NR para esse fim. Em redes de área única, o dep-NR é originado por um DBR e inclui
(i) o prefixo externo do domínio anunciado, (ii) o identificador do DBR de origem e (iii) um
atributo de custo externo do domínio (relativo ao sub -path externo ao roteamento do
main). Em redes multiárea, um roteador tentando se comunicar com um prefixo externo
de domínio pode estar localizado fora da área do DBR que o injetou no domínio de
roteamento. Assim, as informações de endereçamento externo do domínio devem ser
divulgadas em todas as áreas. Para isso, damos aos dep-NRs um papel semelhante aos
aep-NRs: os dep-NRs são injetados dentro de áreas pelos ABRs para anunciar prefixos
externos ao domínio e o custo do caminho mais curto do ABR ao DBR que injetou o
prefixo no domínio (esse custo é obtido através do protocolo de roteamento entre áreas).
Assim, dep-NRs devem ser adicionados com um atributo de custo (domínio interno) que
expressa esse valor de custo de caminho. No entanto, queremos manter o papel inicial
dos dep-NRs. Assim, como no caso de redes de área única, os dep-NRs podem ser
injetados no domínio de roteamento pelos DBRs para anunciar os prefixos externos ao
domínio (que eles obtêm por meio do protocolo de roteamento interdomínio); neste caso,
o custo interno do domínio é definido como zero.
Resumindo, os dep-NRs podem ser originados por ABRs ou DBRs e incluem (i) o prefixo
externo do domínio anunciado, (ii) o identificador do roteador de origem, (iii) um atributo
de custo externo do domínio e (iv ) um atributo de custo interno do domínio correspondente
ao custo do caminho mais curto do roteador de origem até o DBR que injeta o prefixo no
domínio.
Resumo de NRs adicionais necessários em redes multiárea A Figura 3.5 lista os NRs que
precisam ser introduzidos ou modificados para o suporte de redes multiárea. O dbr-NR
será apresentado na Seção 3.4.
Exemplo A Figura 3.6 dá um exemplo de uma rede multiárea e mostra

FIGURA 3.5: NRs introduzidas ou modificadas para suporte a redes multiárea, seu
papel e roteador de origem.
a LSDB de duas de suas quatro áreas. Os roteadores R2 a R7 são ABRs, os roteadores

R1, R8 e R9 são roteadores de área interna e o roteador R8 também é um DBR. A
área 1 inclui um link compartilhado (ls1). Todos os outros links são ponto a ponto. Para
facilitar o exemplo, os custos das interfaces de enlace ponto a ponto são os mesmos
em ambas as direções. Neste exemplo, apenas quatro prefixos de endereço devem
ser anunciados: (i) ap1, atribuído ao roteador R1, (ii) ap2, atribuído ao link ls1, (iii) ap3,
atribuído ao roteador R9 e (iv) ap4, injetado no domínio através do roteador R8.
Assumimos que o custo externo do domínio associado ao ap4 é zero. Os ABRs
conhecem os LSDBs de todas as áreas às quais se vinculam diretamente. Por
exemplo, o roteador R4 conhece os LSDBs das áreas 1 e 3. A Figura 3.6 mostra os LSDBs das área
O LSDB da área 1 tem quatro router-NRs e um slink-NR relativos aos roteadores
R1, R2, R3 e R4, e ao link ls1; estes são os NRs topológicos que descrevem a área 1.
Os NRs restantes transmitem informações de endereçamento. Existem dois aip-NRs
que descrevem os prefixos de endereço internos à área, ap1 e ap2, e sua associação
com o roteador R1 e o link ls1, respectivamente. O prefixo de endereço externo de
área ap3 é descrito por três aep-NRs, cada um injetado por um dos ABRs de área,
indicando o custo do caminho mais curto do ABR de origem para ap3. Por exemplo,
com base nessas informações, o roteador R1 determina que seu caminho mais curto
para ap3 é via roteador R2 com um custo de 4. Observe que o custo para ap3,
anunciado dentro da área 1 pelo roteador R2, não é o menor da área ABRs: o roteador
R4 anuncia um custo de 2 e o roteador R2 um custo de 3.
No entanto, o custo interno de R1 a R4 é muito maior do que o de R1 a R2 e, portanto,
o roteador R2 é selecionado como o ABR de saída para ap3. O LSDB da área 1
também inclui três dep-NRs descrevendo ap4, cada um injetado na área por um de
seus ABRs.
O LSDB da área 4 tem a mesma estrutura da área 1, porém com detalhes
diferentes. Ele contém (i) quatro router-NRs relativos aos roteadores R6, R7, R8 e R9,
(ii) um aip-NR descrevendo ap3 e sua associação com o roteador R9, (iii) quatro aep-
NRs descrevendo os prefixos de endereço externo ap1 e ap2, conforme injetado pelos
ABRs de área (roteadores R6 e R7), e (iv) um dep-NR descrevendo ap4 e sua
associação com o roteador R8. Por exemplo, com base nessas informações, o roteador
R8 seleciona o roteador R6 como o ABR de saída para alcançar ap1 e ap2.

Área 1 R1ÿ ap1

ls1ÿ ap2
7
R1
ls1
1
7 7
lp1
R2 R3 R4
1 5
3 Área 3
Área 2 R5 1
1
2
R6 R7
lp3
lp1 1 Área 4
1
lp2
R9
R8 ÿ ap4 4 R9 ÿ ap3
R8
LSDB da área 1
LSDB da área 4
R1 R2 ls1
lp1: 1 lp1: 1 R1
ls1: 7 R3 R6 R7 ap3
R4 R9
R4 lp1: 1 lp3: 1
R3 ls1: 7
ls1: 7 NRs de links compartilhados R8 R9 área-prefixo
lp1: 1 lp3: 1 interno-NRs
router-NRs
lp2: 4 lp2: 4
ap1 ap2 router-NRs
R1 ls1
ap1 ap1 ap4
área-interna-prefixo-NRs
R6: 4 R7: 3 R8
int. custo: 0
ap3 ap3 ap3 ap2 ap2
R2: 3 R3: 4 R4: 2 ext. custo: 0
R6: 11 R7: 8
domínio-externo
área-externa-prefixo-NRs área-externa-prefixo-NRs -prefixo-NRs
ap4 ap4 ap4

R2 R3 R4
int. custo: 4 int. custo: 7 int. custo: 5
ext. custo: 0 ext. custo: 0 ext. custo: 0
domínio-externo-prefixo-NRs
FIGURA 3.6: Rede multiárea com quatro áreas e os LSDBs de área das áreas 1 e 4.

Observe que os roteadores-NRs de uma área incluem apenas as interfaces que

pertencem a essa área. Por exemplo, na área 1 o roteador-NR de R3 possui apenas
uma entrada, relativa à interface com o link ls1. As outras duas interfaces, que se
conectam aos roteadores R5 e R7, respectivamente, estão incluídas no roteador-NR da área 3.
A área LSDB inclui as informações topológicas da área e as informações de

endereçamento. A informação topológica é fornecida por router-NRs e slink-
NRs, como em redes de área única, as informações de endereçamento de
área interna por NRs de prefixo interno de área (NRs de aip), as informações
de endereçamento de área externa por área- prefixo externo-NRs (aep-NRs),
e as informações de endereçamento externo do domínio por dep-NRs.
3.1.4 Gráfico da sobreposição ABR

Uma abstração conveniente para estudar o roteamento entre áreas é o gráfico da
sobreposição ABR. A Figura 3.7 mostra o gráfico de sobreposição da rede da Figura
3.6. Nesse tipo de grafo, os nós correspondem aos ABRs, os arcos aos caminhos mais
curtos intra-área entre os ABRs vizinhos e os pesos dos arcos correspondem aos
seus custos. Os roteadores internos não fazem parte do grafo. Além disso, cada
interface ABR é rotulada com informações sobre os prefixos disponíveis em sua área
anexa. Os prefixos internos ao domínio são caracterizados por pares (prefixo, custo),
onde o primeiro elemento identifica o prefixo e o segundo é o custo do caminho mais
curto intra-área do ABR ao prefixo. Os prefixos externos ao domínio são caracterizados
por trigêmeos (prefixo, custo interno, custo externo), onde o primeiro elemento identifica
o prefixo, o segundo é o custo do caminho mais curto intra-área do ABR ao DBR que
injetou o prefixo no domínio, e o terceiro elemento é o custo externo associado ao
prefixo.
No gráfico da Figura 3.7, os roteadores R2 a R4 são rotulados com os pares
(prefixo, custo) relativos aos prefixos ap1 e ap2, atribuídos aos elementos de rede da
área 1, e os roteadores R6 e R7 com os pares relativos aos prefixos ap3 e ap4 ,
atribuído aos elementos de rede da área 4. Por exemplo, o roteador R6 tem um rótulo
(ap3, 5), pois o custo do caminho mais curto intra-área de si mesmo para ap3 é 5,
através do caminho R6 ÿ R8 ÿ R9, e o roteador R2 é rotulado (ap2, 8), pois o o custo
do caminho mais curto intra-área de si mesmo para ap2 é 8, através do caminho R2 ÿ
R1 ÿ ls1. A figura também mostra os custos atribuídos a cada arco. Por exemplo, o
arco entre o roteador R3 e o roteador R5 representa o caminho mais curto entre esses
dois roteadores na área 3 e é atribuído um custo de 4, correspondente ao caminho R3 ÿ R7 ÿ R5.
Observe que o gráfico é totalmente malhado dentro de cada área, pois sempre há
algum caminho dentro de uma área entre cada par de ABRs vizinhos. Observe também
que, em geral, o grafo é direcionado, pois os custos do caminho mais curto podem
diferir em cada direção entre dois ABRs vizinhos.

Área 1 8
(ap1,1) (ap1,7) (ap1,7)

(ap2,8) (ap2,7) 7
(ap2,7)
8
R2 R3 R4
4
1 4 2
3 Área 2 1
Área 3
R5 3
2 1
R6 R7
(ap3,5) (ap3,1)
(ap4,1,0) 6 (ap4,5,0) Área 4
FIGURA 3.7: Gráfico de sobreposição ABR da rede da Figura 3.6.
O gráfico da sobreposição ABR é uma abstração útil para estudar o roteamento

entre áreas. Neste grafo, os nós representam os ABRs, os arcos dos caminhos
mais curtos intra-área entre os ABRs vizinhos e os arcos ponderam seus custos.
Os roteadores de área interna não são representados no gráfico.
3.1.5 Mecanismos de sincronização

Os mecanismos de sincronização das redes multiárea são os das redes de área única
com algumas modificações. Lembre-se de que esses mecanismos são o protocolo Hello,
o processo inicial de sincronização do LSBD e o procedimento de inundação. Uma adição
ao protocolo Hello é a inclusão do identificador de área nas mensagens Hello. Isso garante
que as relações de vizinhança podem, de fato, ser estabelecidas com base nas
informações da área. Além disso, o procedimento de inundação precisa ser definido, uma
vez que alguns tipos de informações de roteamento podem precisar ser inundados apenas
dentro de áreas, enquanto outros tipos podem precisar ser inundados em todo o domínio
de roteamento.

3.2 Abordagens de roteamento entre áreas 127
3.2 Abordagens de roteamento entre áreas

O protocolo de roteamento entre áreas pode adotar um estado de link ou uma abordagem de vetor
de distância. Descrevemos essas alternativas nas próximas seções.
3.2.1 Abordagem de roteamento de estado de link
A representação gráfica introduzida na seção anterior sugere imediatamente uma abordagem

LSR para roteamento entre áreas. Nesta abordagem, cada ABR constrói e mantém o gráfico da
sobreposição ABR. Para tanto, cada ABR envia para todos os outros ABRs sua visão local da
topologia overlay, ou seja, quem são seus ABRs vizinhos e quais são os custos de caminho mais
curto intra-área até eles; ele também inunda informações sobre os prefixos disponíveis nas áreas
às quais ele se conecta diretamente (ou seja, inunda os rótulos ABR). Lembre-se de que os ABRs
mantêm os LSDBs de todas as áreas às quais estão diretamente conectados e que cada LSDB
contém o mapa de rede da área correspondente. Um requisito dessa abordagem é que os LSDBs
incluam informações sobre se um roteador é um ABR ou apenas um roteador interno. Isso pode
ser facilmente obtido pela introdução de um sinalizador nos roteadores NRs.
O overlay LSDB A representação da topologia overlay ABR e dos prefixos roteáveis é feita pelo
overlay LSDB, contendo três novos tipos de NRs: (i) os overlay-router-NRs (ououter-NRs para
abreviar) para as informações topológicas, (ii) overlay-domain-internal-prefix-NRs (odip-NRs para
abreviar) para as informações sobre prefixos internos ao domínio de roteamento, e (iii) overlay-
domain-external-prefix-NRs (odep-NRs para short) para informações sobre prefixos externos ao
domínio. O orouter-NR inclui o identificador do ABR originário e de seus ABRs vizinhos, e os
custos dos caminhos mais curtos intra-área até eles. O odip-NR inclui (i) o prefixo interno do
domínio sendo anunciado, (ii) o identificador do ABR de origem e (iii) o custo do caminho mais
curto intra-área do ABR ao prefixo. O odep-NR inclui (i) o prefixo externo do domínio sendo
anunciado, (ii) o identificador do ABR de origem, (iii) o custo do caminho mais curto intra-área do
ABR ao DBR que injetou o prefixo em o domínio e (iv) o custo externo do domínio associado ao
prefixo.
O LSDB de sobreposição precisa apenas ser armazenado nos ABRs; ele pode ser ignorado
pelos roteadores internos da área. As NRs overlay podem ser trocadas entre ABRs usando o
procedimento flooding (ver Seção 2.4), mas com escopo de domínio, uma vez que as NRs devem
ser comunicadas como originadas, ou seja, não modificadas, para todos os ABRs.
A sobreposição LSDB correspondente à rede da Figura 3.6 é mostrada na Figura 3.8.
Como os ABRs calculam os caminhos mais curtos e comunicam essas informações aos roteadores
internos da área? Através da sobreposição LSDB, cada ABR pode construir o gráfico da
sobreposição ABR e calcular os caminhos mais curtos de

R2 R3 R4 R5 R6 R7
R3: 8 R2: 8 R2: 8 R2: 1 R2: 3 R3: 3
R4: 8 R4: 4 R3: 4 R3: 4 R5: 2 R4: 1
R5: 1 R5: 4 R5: 2 R4: 2 R7: 6 R5: 1
R6: 3 R7: 3 R7: 1 R6: 2 R6: 6
R7: 1
overlay-router-NRs (orouter-NRs)
ap1 ap1 ap1 ap3 ap3

R2: 1 R3: 7 R4: 7 R6: 5 R7: 1
ap2 ap2 ap2

R2: 8 R3: 7 R4: 7
overlay-domain-internal-prefix-NRs (odip-NRs)
ap4 ap4
R6 R7
int. custo: 1 int. custo: 5
ramal custo: 0 ramal custo: 0
overlay-domain-external-prefix-NRs (odep-NRs)
FIGURA 3.8: Overlay LSDB da rede da Figura 3.6.
a cada prefixo interno de domínio ou DBR, usando o algoritmo de Dijkstra. Os ABRs então
precisam injetar essas informações nas áreas às quais se conectam diretamente (terceira
etapa da Figura 3.3). Eles fazem isso usando os aep-NRs e os dep-NRs introduzidos na
Seção 3.1.3, ambos inundados com escopo de inundação de área. Lembre-se de que tanto
os aep-NRs quanto os dep-NRs são originados por ABRs para anunciar os prefixos de área
externa e de domínio externo e os custos de caminho mais curto (intradomínio) para alcançá-
los.
Para ilustrar como os caminhos mais curtos são computados através do gráfico de
sobreposição, considere a determinação do caminho mais curto do roteador R2 para ap3
usando o gráfico de sobreposição da Figura 3.7. Existem vários caminhos candidatos, por exemplo:
• R2 ÿ R6 ÿ ap3 com custo 8;
• R2 ÿ R5 ÿ R7ÿ ap3 com custo 3;
• R2 ÿ R3 ÿ R7ÿ ap3 com custo 12.
Cada custo de caminho (ponta a ponta) é calculado adicionando dois componentes de

custo: (i) o custo do caminho mais curto do roteador R2 até um ABR rotulado com ap3 e (ii)
o custo desse ABR até ap3 (presente na etiqueta ABR). O caminho de menor custo é o
segundo acima. O roteador R2 agora pode injetar essas informações em suas áreas
conectadas diretamente (área 1 e área 2) usando aep-NRs.

Especificamente, os aep-NRs anunciam que R2 pode fornecer um caminho para ap3 com um custo de 3.
Observe que, nesse tipo de abordagem, dois tipos de escopo de inundação são usados: os NRs de
sobreposição, ou seja, os orouter-NRs, os odip-NRs e os odep-NRs, são inundados com escopo de domínio,
enquanto todos os outros NRs são inundados com abrangência de área.
Até onde sabemos, ainda não há implementação deste link

abordagem de roteamento multi-área de estado.
Na abordagem LSR para roteamento entre áreas, os ABRs constroem e mantêm o gráfico da
sobreposição ABR. Cada ABR inunda todos os outros ABRs com sua visão local da topologia de
sobreposição, usando overlay-router-NRs (ououter-NRs) e informações sobre os prefixos
disponíveis dentro das áreas às quais ele se conecta diretamente, usando overlay-domain-internal-
prefix- NRs (odip-NRs) para prefixos internos ao domínio, e overlay-domain external-prefix-NRs
(odep-NRs) para prefixos externos ao domínio.
A informação de roteamento calculada pelos ABRs usando os NRs de sobreposição, ou seja, o

menor custo de caminho para cada prefixo, é injetada nas áreas usando aep-NRs e dep-NRs.
3.2.2 Atualizador de roteamento do vetor de distância Antes de
descrever em detalhes a abordagem do Roteamento de Vetor de Distância (DVR) para o roteamento entre
áreas, revisamos aqui seus princípios básicos (consulte também a Seção 5.2 de [6]). O DVR é baseado na
versão distribuída e assíncrona do algoritmo de Bellman Ford. Nesse algoritmo, cada roteador envia a
todos os seus vizinhos sua estimativa do custo do caminho mais curto para cada destino de rede. Um
roteador atualiza sua estimativa do custo do caminho mais curto para um destino por meio de um vizinho
específico adicionando dois componentes de custo: (i) a estimativa de custo recebida desse vizinho e (ii) o
custo do link dele mesmo para o vizinho. Em seguida, ele seleciona o vizinho que fornece o custo de
caminho mais curto (ou seja, o roteador do próximo salto). Quando um vizinho é removido (por exemplo,
devido a uma falha), o custo desse vizinho deve ser definido como ÿ. As mensagens transmitidas aos
vizinhos são chamadas de vetores de distância, e cada elemento do vetor é um par (destino, custo). Os
vetores de distância precisam ser enviados na inicialização e quando a estimativa de custo para um destino
muda.
Quais informações armazenar nos roteadores Para cada destino, os roteadores podem armazenar as
melhores informações recebidas de cada vizinho ou simplesmente as informações recebidas do melhor
vizinho (o roteador do próximo salto); a informação armazenada é o identificador do vizinho e o custo do
caminho mais curto que ele fornece.
A segunda abordagem é utilizada pelo protocolo RIP [30], e é também a utilizada em OSPF e IS-IS. Nesse
caso, ao receber um vetor de distância de um de seus vizinhos, um roteador atualiza o custo do caminho
mais curto armazenado e a estimativa do próximo salto de acordo com as seguintes regras:
• Se o roteador de próximo salto aumentar sua estimativa de custo em direção a um destino,

o custo armazenado é aumentado proporcionalmente, mas o próximo salto armazenado

permanece inalterado;
• Se algum vizinho fornecer um custo para um destino inferior ao atualmente armazenado, o custo
armazenado é atualizado para o menor e o roteador do próximo salto é definido para o vizinho
que fornece esse custo.
Transmissão confiável de vetores de distância A operação correta dos protocolos DVR requer (i)
que os vetores de distância sejam transmitidos de maneira confiável e (ii) que os roteadores
saibam quem são seus vizinhos. O último requisito garante que os roteadores possam detectar
novos vizinhos e falhas de vizinhos. Os dois requisitos podem ser atendidos pela transmissão
periódica de vetores de distância entre roteadores vizinhos, que é justamente a solução adotada
no RIP (os vetores de distância são enviados a cada 30 segundos). No protocolo EIGRP [4, 13],
os relacionamentos de vizinhança são estabelecidos por meio de um protocolo Hello, como no
LSR, e a confiabilidade das transmissões de mensagens é garantida por meio de proteção ACK.
Observe que nos protocolos DVR, os roteadores precisam apenas conhecer seus vizinhos e não o
mapa de rede completo, como no LSR.
Problema de contagem até o infinito Os protocolos DVR sofrem do conhecido problema da

contagem até o infinito, que ilustramos com a ajuda da Figura 3.9. Seja Di1 a estimativa da
distância do roteador i ao roteador R1; na figura, também indicamos o roteador do próximo salto
(nh) que leva ao roteador R1. Assuma que, em t = 0, o protocolo está em um estado estável, onde
cada roteador conhece a distância correta e o próximo salto correto para R1. Suponha que os
roteadores troquem vetores de distância de forma síncrona (ou seja, ao mesmo tempo) e que, logo
após t = 0, a conexão entre os roteadores R1 e R2 falhe. Após a falha, em t = 1, o roteador R2
envia para R3 uma distância de ÿ, e o roteador R3 envia para ambos os seus vizinhos, R2 e R3,
uma distância de 2, como de costume. Com base nessas informações, o roteador R2 é levado a
acreditar que agora pode alcançar R1 até R3 com uma distância de 3 e o roteador R2 acredita que
pode alcançar R1 até R4 com uma distância de 4. Após a próxima troca de vetores de distância,
em t = 2, os roteadores R2 e R3 entram em um ciclo de roteamento, do qual nunca sairão. A
distância de R2 a R1 continua aumentando em um a cada duas iterações, contando lentamente
até o infinito, mas R2 e, na verdade, todos os outros roteadores, nunca entenderão completamente
que o roteador R1 não pode mais ser alcançado.
Uma maneira de superar esse problema é “redefinir o infinito”; por exemplo, em RIP, infinito é
definido como 16. No entanto, esta solução impõe uma restrição topológica na rede. Na verdade,
as redes que executam o RIP não podem ter caminhos com mais de 15 saltos. Além dessa solução,
outras técnicas podem ser utilizadas para reduzir o impacto da contagem até o infinito, como
atualizações disparadas e split horizon. A técnica DUAL [13], utilizada no protocolo EIGRP, elimina
completamente este problema.

R1 R2 R3 R4
1 1 1
(t=0) D21=1, nh=R1 D31=2, nh=R2 D41=3, nh=R3
(t=1) D21=ÿ D31=2, nh=R2 D41=3, nh=R3
(t=2) D21=3, nh=R3 D31=4, nh=R4 D41=3, nh=R3
(t=3) D21=5, nh=R3 D31=4, nh=R2 D41=5, nh=R3
(t=4) D21=5, nh=R3 D31=6, nh=R2 D41=5, nh=R3
(t=5) D21=7, nh=R3 D31=6, nh=R2 D41=7, nh=R3

... ... ...... FIGURA 3.9: Problema de contagem até o infinito.
3.2.3 Abordagem de roteamento de vetor de distância Na
abordagem de vetor de distância para roteamento entre áreas, os ABRs executam um protocolo
DVR entre si. Os roteadores internos de área não participam desse processo, exceto como
intermediários na comunicação entre os ABRs. Observe que, nessa abordagem, os ABRs não têm
conhecimento da sobreposição ABR completa; eles só conhecem os ABRs de seus vizinhos. Cada
ABR transmite vetores de distância para todos os ABRs vizinhos, contendo pares (prefixo, custo).
Quando um ABR recebe um vetor de distância de um ABR vizinho em relação a algum prefixo,
ele atualiza sua estimativa do custo do caminho mais curto e ABR do próximo salto em direção a
esse prefixo usando as regras usuais do DVR, que revisamos na seção anterior. Para isso, ele
precisa calcular o caminho mais curto de si para o vizinho ABR, o que pode ser feito através da
análise do LSDB que ele tem em comum com o vizinho. Assim como na abordagem LSR inter-
área, cada ABR é responsável por originar informações relativas aos prefixos disponíveis dentro
de suas áreas conectadas diretamente, que aprende com os LSDBs correspondentes; esta
informação corresponde aos rótulos ABR do gráfico de sobreposição.
Exemplo Na Figura 3.10 damos um exemplo da operação da abordagem DVR relacionada à

sobreposição ABR da Figura 3.7. A figura mostra uma das muitas sequências possíveis de etapas
(assíncronas) pelas quais os ABRs conhecem o custo do caminho mais curto para ap3 e o ABR do
próximo salto que fornece esse custo. Os originadores dessas informações são os ABRs da área
4, ou seja, os roteadores R6 e R7. Observe que os custos do caminho mais curto e os ABRs do
próximo salto de qualquer ABR para ap3 podem ser antecipados inspecionando o gráfico de
sobreposição. Por exemplo, o custo do caminho mais curto do roteador R2 para o ap3 é certamente
3 via roteador R5 (o próximo salto). No entanto, na abordagem DVR, os roteadores não estão
cientes do gráfico de sobreposição; cada ABR só conhece detalhadamente as áreas às quais está
diretamente ligado

Área 1
8
(ap1,1) (ap1,7)
(ap2,8) (ap2,7)
8 7
R2 R3 R4
4
4 2
1
1
3 Área 2 3 Área 3
R5
2 1
R6 R7
(ap3,5) (ap3,1)
(ap4,1,0) 6 (ap4,5,0) Área 4
FIGURA 3.10: Exemplo de DVR na sobreposição ABR da Figura 3.7.
para. Deixe, para cada roteador, Di denotar sua estimativa na etapa i da distância (custo) para
alcançar o prefixo ap3.
• Passo 1 - Inicialmente, o roteador R6 anuncia para todos os vizinhos uma distância de 5 para
ap3; esse custo foi obtido através da análise do LSDB da área 4.
• Passo 2 - A seguir, o roteador R2 anuncia uma distância de 8, que corresponde à soma da

distância recebida de R6 com o custo do caminho mais curto entre R2 e R6; o custo do
caminho mais curto é obtido através da análise do LSDB da área 2, que é mantido por R2.
Observe que, neste ponto da computação (distribuída), o roteador R2 ainda tem uma
estimativa incorreta do custo do caminho mais curto para ap3.
• Etapa 3 - Nesta etapa, o roteador R7 anuncia uma distância de 1 para ap3 e, com base
nessas informações, os roteadores R3, R4 e R5 aprendem seus custos de caminho mais
curto corretos para ap3, que são 4, 2 e 2, respectivamente ; eles também aprendem o
roteador de próximo salto para ap3, que é R7 para todos eles. Novamente, os custos do
caminho mais curto são obtidos através da análise de um LSDB, o LSDB da área 3 neste caso.
• Etapa 4 - Finalmente, o roteador R5 anuncia uma distância de 2 para ap3 e, com base nesta
informação, o roteador R2 atualiza sua distância para 3 e o próximo salto para R5. Após
esta etapa, todos os ABRs aprenderam o custo correto do caminho mais curto e o ABR do
próximo salto para ap3. Qualquer outra sequência de etapas levaria ao mesmo resultado.

Como os vetores de distância são comunicados entre os ABRs e como as informações de

roteamento computadas pelos ABRs são comunicadas aos roteadores internos da área? Os
vetores de distância são trocados entre ABRs vizinhos. Duas perguntas ainda precisam ser
respondidas:
• Como os vetores de distância são comunicados entre os ABRs?
• Como as informações de roteamento computadas pelos ABRs são comunicadas aos roteadores
internos da área?
Acontece que tanto o processo de comunicação quanto as mensagens de controle que

comunicam as informações de roteamento podem ser iguais.
Processo de comunicação A comunicação (i) entre ABRs vizinhos e (ii) entre ABRs e roteadores
internos de área usa o procedimento de inundação com escopo de inundação de área (ver Seção
2.4). Lembre-se de que o protocolo de roteamento intra-área é do tipo LSR, mesmo na abordagem
DVR inter-área.
A comunicação entre ABRs contrasta com a abordagem inter-área LSR, onde os NRs overlay
(orouter-NR, odip-NR e odep-NR) são comunicados entre ABRs com escopo de inundação de
domínio (consulte a Seção 3.2.1) .
Além disso, como o mecanismo de inundação é confiável, as mensagens de controle são
transmitidas sem perda ou corrupção. Assim, ao contrário do RIP, onde não há mecanismo de
proteção explícito para a transmissão de vetores de distância, nesta abordagem, os vetores de
distância não precisam ser repetidos periodicamente.
Observe também que o protocolo LSR intra-área subjacente é o que estabelece implicitamente
as relações de vizinhança entre ABRs anexados à mesma área. É através do LSDB de área
mantido pelo protocolo LSR intra-área que um ABR sabe quem são seus ABRs vizinhos ativos
naquela área, e é através deste LSDB que ele pode detectar eventuais falhas de ABR. Podemos
dizer que o protocolo LSR intra-área desempenha o papel do protocolo Hello na sobreposição ABR.
Mensagens de controle Como no caso da abordagem LSR entre áreas, os aep NRs e os dep-NRs
introduzidos na Seção 3.1.3 são usados para comunicar as informações de roteamento computadas
pelos ABRs aos roteadores internos da área.
Além disso, como esses NRs têm a semântica (prefixo, custo) exigida pelos vetores de distância,
eles também podem ser usados para comunicar informações de roteamento entre ABRs vizinhos.
Lembre-se da Seção 3.1.3 que aep-NRs e dep-NRs são originados por ABRs para anunciar (i) um
prefixo (um prefixo externo de área, no caso de aep-NRs, e um prefixo externo de domínio, no
caso de dep-NRs) e (ii) o custo do caminho do ABR de origem até o prefixo (no caso de aep-NRs)
ou até o DBR que injetou o prefixo no domínio de roteamento (no caso de dep-NRs) .
Observe que dois tipos diferentes de mensagens de controle poderiam ter sido usados para
realizar as duas funções descritas acima, mas isso não é necessário neste caso. De fato, inundar
um vetor de distância dentro de uma área serve a dois propósitos simultaneamente, e esta é uma
propriedade importante. Primeiro, ele comunica informações de roteamento entre os ABRs (a
segunda etapa da Figura 3.3). Em segundo lugar, é

injeta em toda a área as informações computadas pelos ABRs, já que os vetores de

distância são disseminados para todos os roteadores internos (terceira etapa da Figura 3.3).
Na abordagem DVR para roteamento entre áreas, os ABRs vizinhos trocam

vetores de distância entre si contendo pares (prefixo, custo) e, com base nessas
informações, estimam seus custos de caminho para os prefixos anunciados
usando as regras usuais do DVR. Os aep-NRs e os dep-NRs são usados tanto
para comunicar as informações de roteamento entre os ABRs vizinhos (ou seja,
como vetores de distância) quanto para comunicar as informações de roteamento
calculadas pelos ABRs aos roteadores internos da área.
3.3 Ainda é possível ter um roteamento ótimo globalmente?

Uma questão importante é se o roteamento ótimo global é alcançável em uma rede
multiárea, ou seja, se os caminhos selecionados entre quaisquer dois roteadores ainda são
os caminhos mais curtos. Podem surgir problemas quando os roteadores são restritos na
quantidade de informações de roteamento disponíveis para determinar os caminhos mais
curtos e, na verdade, eles estão em OSPF e IS-IS. Daremos dois exemplos.
Preferência a caminhos intra-área Primeiro, os roteadores podem dar preferência a
caminhos intra-área. Um caminho intra-área é um caminho completamente contido em uma
área; um caminho entre áreas é um caminho que cruza mais de uma área. Se for dada
preferência a caminhos intra-área, o roteamento entre uma origem e um destino
pertencentes à mesma área não será ótimo sempre que houver um caminho inter-área
com menor custo do que o caminho intra-área de menor custo. Este caso é ilustrado na
Figura 3.11. O custo do caminho intra-área S ÿ D é 4 e o custo do caminho inter-área S ÿ
ABR 2 ÿ ABR 1 ÿ D é 3. Observe que os ABRs podem até ser proibidos de injetar em uma
área caminhos inter-área relativo a uma origem e um destino localizados naquela área;
essa restrição é feita tanto pelo OSPF quanto pelo IS-IS.
ABRs míopes O segundo caso é mais complexo. Isso acontece quando os ABRs não têm
noção da sobreposição de ABR e apenas resumem “o que eles veem” em uma área para
as outras áreas às quais estão anexados. Nós os chamamos de ABRs míopes. Considere
o exemplo da Figura 3.12.a. A origem e o destino estão em áreas diferentes, cada uma
com seu próprio LSDB. Fica claro na figura que o caminho mais curto de S para D é S ÿ
ABR 3 ÿ ABR 2 ÿ ABR 1 ÿ D com um custo de 4. Suponha que os ABRs injetem informações
na área 2 com base apenas nas informações contidas no LSDB da área 1; observe que o
link entre ABR 1 e ABR 2 não está incluído neste LSDB, pois não faz parte da área 1.
Nesse caso, ABR 1 anuncia um custo para D de 1, ABR 2 anuncia um custo de 4 e ABR 3
um custo 5. Com base nessas informações, o roteador S decide que o melhor caminho é S
ÿ ABR 1 ÿ D com um custo de 5, o que não é ótimo.

3.4 Informações de endereçamento externo do domínio de publicidade 135
$UHD
$%5 $%5
'
6
$UHD
FIGURA 3.11: Dando preferência a caminhos intra-área.
Esse problema aconteceu porque os ABRs lidam isoladamente com cada área.
Para ver como o problema poderia ser resolvido, a Figura 3.12.b mostra o gráfico da sobreposição
ABR. O gráfico indica os caminhos mais curtos entre todos os pares de ABRs em cada área, e
os rótulos ABR relacionados ao destino, determinados pelo LSDB da área 1. Um rótulo
corresponde ao custo do caminho intra-área mais curto do ABR ao destino; os rótulos são 1 para
ABR 1, 4 para ABR 2 e 5 para ABR 3. A partir dessas informações, ABR 3 pode determinar que
o caminho mais curto de si mesmo para D segue o caminho ABR 3 ÿ ABR 2 ÿ ABR 1 com um
custo de 3; ABR 3 pode então injetar esta informação na área 2, permitindo que S determine que
o caminho mais curto para D é S ÿ ABR 3 ÿ ABR 2 ÿ ABR 1 ÿ D com um custo de 4.
Os roteadores podem ser restritos na quantidade de informações disponíveis para

calcular os caminhos mais curtos, caso em que o roteamento ideal globalmente pode
não ser alcançado.
3.4 Publicando informações de endereçamento externo de domínio Nas seções anteriores, já
discutimos a disseminação de informações de endereçamento externo de domínio entre as

áreas. Os prefixos externos ao domínio são injetados em um domínio de roteamento por DBRs
usando dep-NRs com um custo interno de zero. Essas informações são captadas pelos ABRs
das áreas onde os DBRs estão localizados, que as divulgam por toda a sobreposição do ABR.
Na abordagem LSR para roteamento entre áreas, a informação é disseminada usando odep-
NRs, conforme discutido na Seção 3.2.1. Na abordagem DVR, ela é disseminada usando dep-
NRs distribuídos como vetores de distância, conforme discutido na Seção 3.2.3. Esta é a
solução adotada no IS-IS.

Área 1
D
1 5
4
1
ABR 1 ABR 2 ABR 3
D=1 1 D=4 D=5
4
4 1
S
Área 2
Área 1 6
D=1 D=4 D=5

5 1
ABR 1 ABR 2 ABR 3
1 5
5
Área 2
FIGURA 3.12: ABRs míopes; (a) exemplo de rede, (b) gráfico da sobreposição ABR.
A Figura 3.13.a ilustra a abordagem do DVR descrita acima. A zona “outras áreas”
representa as diversas áreas que podem existir entre as áreas de origem e destino; os
arcos representam os caminhos mais curtos entre os roteadores e os rótulos dos arcos
representam os custos correspondentes do caminho mais curto. O prefixo externo do
domínio ap1 é injetado no domínio por DBR 1 através de um dep-NR carregando um custo
interno de zero. Quando o ABR 2 recebe este dep-NR, ele o injeta no protocolo de
roteamento interárea com um custo interno de 5, que corresponde ao custo do caminho
mais curto dele para o DBR 1. Da mesma forma, quando o dep-NR atinge ABR 1, ABR 1
calcula o caminho mais curto para ap1, que é 8, e injeta essa informação na área de
origem. O roteador S, ao receber o dep-NR, determina que o custo para ap1 é 10 via saída

3.4 Informações de endereçamento externo do domínio de publicidade 137
dep-NR
ap1
dep-NR int. custo: 5 dep-NR
ap1 ramal custo: 0 ap1

int. custo: 8 int. custo: 0
ABR 1 ABR 2
3
2 5
S outras áreas DBR 1
ap1
fonte destino
área área
dep-NR
ap1
dep-NR DBR 1 dep-NR
ap1 ramal custo: 0 ap1

DBR 1 DBR 1
ABR 1 ABR 2
3
2 5
DBR 1
S int. custo: 5
DBR 1
DBR 1 dbr-NR
int. custo: 8 ap1

outras áreas
dbr-NR
destino
fonte área
área
FIGURA 3.13: Alternativas para divulgar informações externas do domínio em todas as áreas; (a)
apenas com dep-NRs, (b) com dep-NRs e dbr-NRs.
ABR 1. O custo externo ao domínio viaja inalterado do DBR para o roteador S.
Existe uma alternativa para disseminar informações de endereçamento externo de domínio

entre as áreas, que envolve dois tipos de NR. Nesta solução, um prefixo externo de domínio é
injetado em um domínio de roteamento por um DBR usando um dep-NR, como na solução
anterior, mas o dep-NR é disseminado por todo o domínio de roteamento, ou seja, com escopo
de inundação de domínio. Assim, o dep-NR passa pelo protocolo de roteamento inter-área,
alcança todos os roteadores de domínio inalterados

e, desta forma, não carrega nenhuma informação sobre como rotear para o DBR de
origem. Essas informações devem ser fornecidas por um novo tipo de NR, disseminado
por meio do protocolo de roteamento entre áreas. Diferentes tipos de NR devem ser
usados nas abordagens de roteamento entre áreas DVR e LSR. Vamos nos concentrar
no primeiro, pois é a solução adotada no OSPF. O tipo NR da abordagem DVR é chamado
de domínio-border-router-NR (dbr-NR para abreviar), é originado pelos ABRs e disseminado
como um vetor de distância, e contém (i) o identificador DBR e (ii) o menor custo de
caminho do ABR de origem para o DBR.
Nesta solução, o dep-NR deve incluir o identificador de seu DBR de origem, de forma que
os dois tipos de NR possam ser relacionados entre si.
Uma vantagem dessa solução é que os dbr-NRs atuam como elementos de reunião
de todos os prefixos externos ao domínio originados pelo mesmo DBR. Assim, caso um
DBR seja removido, a exclusão de todos os seus prefixos externos ao domínio originados
pode ser feita por meio de uma única indicação de exclusão, ou seja, a indicação para
excluir o dbr-NR correspondente.
Damos um exemplo na Figura 3.13.b. Nesse caso, o prefixo externo do domínio ap1
é anunciado por meio de um dep-NR que é disseminado usando o escopo de inundação
de domínio e inclui o identificador de DBR 1; o dep-NR não inclui informações de custos
internos. Ao mesmo tempo, ABR 2 injeta no protocolo de roteamento entre áreas um dbr-
NR descrevendo DBR 1 e o custo do caminho mais curto dele para DBR 1, que é 5.
Quando o dbr-NR atinge ABR 1, ABR 1 atualiza o custo para 8 e o injeta na área de
origem. Combinando as informações recebidas no dep-NR e no dbr-NR, o roteador S
conclui que pode atingir o DBR que injetou ap1 usando o ABR 2 como ABR de saída, com
um custo de 10.
Em redes multiárea, um prefixo externo ao domínio é injetado no domínio de

roteamento por um DBR e é anunciado dentro da área onde o DBR está
localizado usando um dep-NR; essas informações são então disseminadas entre
as áreas usando o protocolo de roteamento entre áreas. Uma solução alternativa
envolve dois tipos de NR: o prefixo externo ao domínio é anunciado através de
um dep-NR disseminado com escopo de inundação de domínio, ou seja,
passando o protocolo de roteamento entre áreas, e o DBR que originou o dep-
NR é anunciado usando um domain-border-router-NR (dbr-NR), que é
disseminado entre as áreas por meio do protocolo de roteamento entre áreas.

Parte III
tecnologias


4
Visão geral de OSPF e IS-IS
4.1 Um pouco de história

O primeiro protocolo LSR foi desenvolvido para a ARPANET no final dos anos 1970 [32].
Na época, era um protocolo muito simples, já que a própria ARPANET era uma rede muito
homogênea, composta por roteadores de um único fornecedor conectados por meio de
linhas seriais síncronas. Várias melhorias para este protocolo foram posteriormente
propostas em [40], e os esforços para padronizar as tecnologias LSR começaram na
década de 1980.
Tem havido muitas propostas para o uso de protocolos LSR em redes fixas e sem fio
(ver, por exemplo, o Capítulo 7 de [38], para propostas de redes sem fio). No entanto, seu
principal sucesso é, sem dúvida, em redes fixas. Os protocolos LSR são atualmente os
preferidos para roteamento intra-domínio na Internet. Ao longo dos anos houve várias
implementações de tecnologias LSR, por exemplo, LSP (para IPX), PNNI (para ATM), IS-IS
(para CLNP, IPv4 e IPv6) e OSPF (para IPv4 e IPv6). Uma descrição introdutória dessas
tecnologias pode ser encontrada no Capítulo 14 de [41].
4.2 Roteamento Link State de hoje

OSPF e IS-IS são os principais players de LSR na Internet atual. Eles são implementados
por praticamente todos os fornecedores de equipamentos de roteamento e amplamente
implantados na maioria das grandes redes IP em todo o mundo. Além disso, eles continuam
sendo adaptados às modernas tecnologias de roteamento, como na recente adoção do IS-
IS como o protocolo de roteamento das redes de pontes de caminho mais curto IEEE
802.1aq [5].
Padrões OSPF e IS-IS As versões atuais do OSPF são OSPFv2 (para IPv4), definido no
RFC 2328 [36], e OSPFv3 (para IPv6), definido no RFC 5340 [8]. Ao contrário do OSPF, o
IS-IS não nasceu como um protocolo de roteamento para redes IP: foi inicialmente definido
para redes ISO na especificação ISO/IEC 10589 [1] e só posteriormente estendido para
IPv4, na RFC 1195 [7], e IPv6 , na RFC 5308 [20].
Além dessas especificações, que lhe servem de base, existem muitas outras
141

142 4 Visão geral do OSPF e IS-IS
fornecendo vários tipos de aprimoramentos e extensões. Por exemplo, OSPF e IS-IS

foram estendidos para suportar engenharia de tráfego MPLS [19, 21, 23, 29], roteamento
multi-topologia [44, 45] e roteamento multicast [34, 44].
Principais aspectos dos protocolos LSR Conforme discutido na parte anterior do livro
dedicado aos princípios do LSR, os protocolos LSR envolvem três aspectos principais:
(i) a estrutura do LSDB, (ii) os mecanismos de sincronização necessários para manter
o LSDB atualizado e sincronizados, e (iii) as extensões dos dois aspectos anteriores
para lidar com grandes redes. As duas primeiras questões foram abordadas no Capítulo
2 e a terceira no Capítulo 3. Nesta parte do livro, dedicaremos um capítulo a cada um
desses aspectos, no contexto das tecnologias OSPF e IS-IS.
Lembre-se de que o LSDB inclui três tipos de informações de roteamento: (i)

informações topológicas, (ii) informações de endereçamento e (iii) informações de link.
As informações de endereçamento podem ser internas ou externas ao domínio de
roteamento. Os mecanismos de sincronização são (i) o protocolo Hello, (ii) o
procedimento de inundação e (iii) o processo inicial de sincronização do LSDB. Para
lidar com grandes redes, a rede geralmente é estruturada em várias áreas.
Diferenças entre OSPF e IS-IS OSPF e IS-IS diferem em vários aspectos fundamentais,
mas também compartilham muitos recursos comuns. As características comuns às
vezes se escondem atrás de nomenclaturas diferentes, assunto ao qual damos atenção
especial neste livro.
Ao comparar as versões IPv4 e IPv6 de cada tecnologia (OSPF e IS-IS), as
principais diferenças estão na estrutura do LSDB. Os mecanismos de sincronização
são essencialmente os mesmos dentro de uma determinada tecnologia. O OSPFv3 usa
o mesmo protocolo Hello, os mesmos procedimentos de disseminação e atualização e
o mesmo processo inicial de sincronização LSDB do OSPFv2; e isso também é verdade
para as versões IPv4 e IPv6 do IS-IS.
A estrutura LSDB adotada inicialmente pelo IS-IS facilitou a evolução do IPv4 para
o IPv6. No OSPF, as mudanças foram mais profundas. O OSPFv2 combina informações
topológicas e de endereçamento usando endereços IPv4 como identificadores
topológicos. O OSPFv3, certamente impulsionado pelo enorme crescimento do espaço
de endereços (de 32 para 128 bits), redesenhou substancialmente a estrutura do LSDB
e separou claramente as informações topológicas e de endereçamento.
4.3 A estrutura dos domínios de roteamento OSPF e IS-IS

A estrutura dos domínios de roteamento OSPF e IS-IS é ilustrada na Figura 4.1.
Os domínios de roteamento OSPF e IS-IS podem ser estruturados em várias áreas,
para manter o tamanho do LSDB gerenciável quando as redes se tornam grandes. No
entanto, nem o OSPF nem o IS-IS suportam topologias arbitrárias entre áreas (que
discutimos no Capítulo 3). A topologia entre áreas é restrita a uma hierarquia de dois
níveis, onde o nível superior pode ter apenas uma área, e todo o tráfego entre

4.3 A estrutura dos domínios de roteamento OSPF e IS-IS 143
Área 0 R5
(espinha dorsal) R4
R2 R3 R6
R1 R7
Área 1
Área 2
(a)
Área 2 R5
(subdomínio L2)
adjacência L2
R4 adjacência L2
adjacência L2 adjacência L2
R2 R3 R6
adjacência L1
adjacência L1 adjacência L1
R1 R7
Área 1
Área 3
(b)
FIGURA 4.1: Estrutura de (a) OSPF e (b) domínios de roteamento IS-IS.
áreas de nível inferior é forçada a passar pelo nível superior. A área de nível superior é
chamada de backbone em OSPF e subdomínio L2 em IS-IS; usaremos principalmente a
designação OSPF. Devido a essas restrições topológicas, as redes OSPF e IS-IS
estruturadas em várias áreas são geralmente chamadas de redes hierárquicas, e não de
redes multiárea. Adotaremos a última designação a seguir.
Uma proposta para uma extensão OSPF suportando topologias multiárea arbitrárias pode
ser encontrada em [51].

Tanto no OSPF hierárquico quanto no IS-IS, cada área mantém um LSDB separado. As
áreas trocam informações de roteamento entre si usando um protocolo de roteamento entre
áreas que, em ambos os casos, é um protocolo de vetor de distância. Os protocolos de vetor
de distância sofrem de problemas de convergência bem conhecidos, que provavelmente foram
a causa raiz para limitar a topologia entre áreas a uma (menos flexível) estrutura hierárquica
de dois níveis. No entanto, conforme discutido no Capítulo 3, existem soluções técnicas para
estruturar redes multiárea com topologias interáreas arbitrárias.
As informações de endereçamento externo do domínio são injetadas em um domínio de

roteamento por meio de seus roteadores de borda de domínio. Esta questão foi discutida na
Seção 2.2.4. Um roteador de borda de domínio pode ser conectado a (e injetar prefixos
externos de) um AS diferente ou outro domínio de roteamento do mesmo AS. O processo de
transferência de informações de endereçamento entre diferentes domínios de roteamento
geralmente é chamado de redistribuição.
4.3.1 OSPF
No OSPF, cada roteador dentro de um domínio de roteamento pertence a um dos três tipos
(ver Figura 4.1.a): (i) Autonomous System Border Router (ASBR), que estabelece a conexão
com outros domínios de roteamento, (ii) Area Border Router (ABR), que interliga o backbone
com uma ou mais áreas de nível inferior, e (iii) roteadores internos às áreas. O ASBR pode
estar localizado em qualquer área, e não apenas no backbone. Infelizmente, a designação
“ASBR” é enganosa, pois o ASBR pode interconectar dois domínios de roteamento localizados
no mesmo AS (por exemplo, pode interconectar um domínio de roteamento executando outro
protocolo de roteamento intradomínio, como RIP ou EIGRP).
No OSPF, cada interface do roteador é atribuída a uma área. Assim, os ABRs têm uma
interface atribuída à área de backbone e uma ou mais interfaces assinadas para áreas de
nível inferior. Isso também significa que os ABRs não pertencem a uma única área (podemos
dizer que pertencem ao backbone e a todas as áreas de nível inferior às quais se ligam
diretamente).
4.3.2 IS-IS
No IS-IS, a estrutura hierárquica é baseada em dois tipos de LSDB, chamados L1 LSDB e L2
LSDB. Esses LSDBs são independentes e cada LSDB é construído e mantido usando pacotes
de controle específicos (pacotes de controle L1 e L2). Para tanto, as interfaces do roteador
podem estabelecer dois tipos de relacionamentos, chamados de adjacências L1 e L2. Além
disso, as interfaces podem ser configuradas em três tipos: (i) somente L1, (ii) somente L2 e (iii)
L1/L2. O tipo de interface determina o tipo de informações de roteamento e pacotes de controle
que a interface pode trocar: interfaces somente L1 podem apenas trocar informações relativas
ao L1 LSDB (isto é, elas podem estabelecer apenas adjacências L1), interfaces somente L2
podem apenas trocar informações relativas ao L2 LSDB (ou seja, eles só podem estabelecer
adjacências L2), e as interfaces L1/L2 podem trocar informações relativas a ambos

4.4 Constantes arquitetônicas e parâmetros configuráveis 145
LSDBs (ou seja, eles podem estabelecer ambos os tipos de adjacências, usando diferentes tipos de
pacotes de controle).
Os roteadores IS-IS são então classificados de acordo com os tipos de interface que suportam:
(i) roteadores L1 possuem apenas interfaces somente L1, (ii) roteadores L2 possuem apenas interfaces
somente L2 e (iii) roteadores L1/L2 podem ter os três tipos de interfaces. No IS-IS, as áreas não são
atribuídas a interfaces de roteador como no OSPF, mas são atribuídas a roteadores.
Assim como no OSPF, um domínio de roteamento IS-IS estruturado em áreas possui um LSDB
distinto para cada área. Os LSDBs das áreas de nível inferior devem ser do tipo L1 e os LSDB da área
de backbone (subdomínio L2) devem ser do tipo L2.
A troca de informações de roteamento entre o backbone e uma área de nível inferior ou, dizendo de
outra forma, entre o L2 LSDB e um L1 LSDB, é feita em um roteador L1/L2. Assim, os roteadores L1/
L2 são os ABRs do IS-IS. Como um roteador é atribuído a uma área específica, os roteadores L1/L2
devem ser atribuídos a áreas de nível inferior. Assim, as áreas de nível inferior são formadas pelos
roteadores L1 e os roteadores L1/L2 que se interligam com o backbone (que estabelecem adjacências
L1 entre si para a construção do L1 LSDB), e o backbone é formado pelos roteadores L2 (que
estabelecem adjacências L2 entre si para a construção do L2 LSDB). Superficialmente, isso parece
muito diferente da estrutura de domínio de roteamento OSPF, mas, como será discutido no Capítulo 7,
não é!
Os roteadores que se interconectam a outros domínios de roteamento (ou seja, o equivalente

do ASBR do OSPF) são chamados simplesmente de roteadores de borda.
4.3.3 instâncias OSPFv3

O OSPFv3 inclui uma característica interessante, que é a possibilidade de sobrepor múltiplas redes
lógicas (chamadas de instâncias) sobre uma mesma infraestrutura física. Cada instância pode ter seu
próprio LSDB e, para isso, os roteadores OSPFv3 estabelecem uma adjacência distinta por instância.
Isso é semelhante às adjacências L1 e L2 do IS-IS (e os correspondentes L1 e L2 LS DBs), embora a
motivação não fosse o suporte de várias áreas. Um cenário de aplicação referido na especificação
OSPFv3 [8] é quando vários provedores conectam suas redes a um NAP (Network Access Point) para
troca de informações de roteamento e desejam executar domínios de roteamento OSPF separados
em algum conjunto de equipamentos comuns (roteadores). ou links). No entanto, esse recurso ainda
não foi totalmente explorado em redes reais!
4.4 Constantes arquitetônicas e parâmetros configuráveis

Tanto o OSPF quanto o IS-IS fazem uma clara distinção entre constantes arquitetônicas e parâmetros
configuráveis. Constantes arquitetônicas são parâmetros

que foram fixados pela especificação e não podem ser alterados pelo gestor da rede.
Eles estão listados no Apêndice B da RFC 2328 [36] e na Seção 7.5 da ISO/IEC 10589
[1]. Os parâmetros configuráveis do OSPFv2 estão listados no Apêndice C do RFC
2328, e os do OSPFv3 no Apêndice C do RFC 5340 [8]. Por exemplo, tanto no OSPF
quanto no IS-IS, o tempo de vida dos elementos LSDB é uma constante arquitetônica
e a periodicidade das transmissões HELLO é um parâmetro configurável. Neste livro,
vamos nos referir às constantes arquitetônicas anexando
“*” aos seus nomes.
4.5 Objetivos e estrutura desta parte do livro Nos capítulos de princípios
(Capítulos 2 e 3), esboçamos os aspectos fundamentais de um protocolo LSR,

discutindo várias alternativas de projeto, mas deixando de lado os detalhes
tecnológicos. Nosso objetivo era construir uma estrutura a partir da qual as
características essenciais do OSPF e do IS-IS – suas semelhanças e diferenças –
pudessem ser compreendidas de forma mais sólida. A partir de agora, nos referiremos
a este protocolo como o protocolo genérico.
Nesta parte do livro, mergulhamos nos detalhes tecnológicos do OSPF e do IS-IS.
Tendo em mente que OSPF e IS-IS ainda são tecnologias em evolução, com
acréscimos e aprimoramentos constantes, nosso objetivo é fornecer ao leitor
informações suficientes para que ele possa operar plenamente as redes OSPF e IS
IS da vida real (e aprender facilmente qualquer recurso específico que talvez não
tenhamos coberto).
Estrutura da parte No Capítulo 5, explicamos a estrutura LSDB do OSPF e IS-IS para
o caso de redes de área única e, no Capítulo 6, apresentamos os mecanismos de
sincronização necessários para manter o LSDB atualizado e sincronizado. Finalmente,
no Capítulo 7, discutimos as extensões para suporte ao roteamento hierárquico. Na
parte IV do livro, ilustramos através de vários exemplos obtidos com equipamentos
reais as diversas funcionalidades de OSPF e IS-IS apresentadas nesta parte do livro.

5
Estrutura LSDB de OSPF e IS-IS
Redes de área única
O LSDB contém as informações de roteamento necessárias para construir as tabelas de

encaminhamento nos roteadores. As informações de roteamento se enquadram em três tipos: (i)
informações topológicas, descrevendo os roteadores e a maneira como eles estão conectados
por meio de links, (ii) informações de endereçamento, descrevendo os endereços roteáveis da
camada 3 dos destinos de rede reais (onde residem os hosts), ( iii) informações do link,
descrevendo os endereços da camada 2 necessários para transportar pacotes entre os roteadores.
As informações de endereçamento podem ser internas ou externas ao domínio de roteamento
(domínio interno ou domínio externo). A descrição da topologia da rede, que também chamamos
de mapa da rede, envolve a abstração da rede física de forma adequada. Em particular, os links
entre roteadores variam de simples links ponto a ponto a redes de camada 2 relativamente
complexas. A abstração precisa definir como os roteadores e links são identificados e como os
links são tipificados.
OSPF e IS-IS usam filosofias e nomenclaturas diferentes para estruturar seus LSDBs. No
Capítulo 2, introduzimos uma estrutura LSDB genérica que agora será usada como referência.
Os blocos de construção básicos deste LSDB são os Registros de Rede (NRs), que possuem
duas propriedades importantes: (i) fornecem informações de roteamento elementares e (ii) podem
ser inundados independentemente.
Além disso, NRs podem transmitir separadamente informações topológicas e de endereçamento.
Dedicaremos atenção especial à capacidade das tecnologias atuais de alcançar essa separação.
Com exceção das informações de enlace, que possuem natureza local, as informações de
roteamento devem ser as mesmas nos LSDBs de todos os roteadores localizados na mesma
área. Os mecanismos necessários para garantir essa sincronização serão discutidos no Capítulo
6.
Estrutura do capítulo Neste capítulo, nos concentramos na estrutura LSDB de domínios de

roteamento contendo uma única área, mas possivelmente conectada a outros domínios de
roteamento. Começamos apresentando, na Seção 5.1, os elementos básicos dos LSDBs OSPF
e IS-IS. Então, na Seção 5.2 explicamos como os roteadores e links são identificados, e na Seção
5.3 como os links são tipificados. A estrutura geral dos elementos LSDB é apresentada na Seção
5.4. Em seguida, discutimos como esses elementos são usados para descrever as informações
de endereçamento topológico e interno do domínio no OSPFv2 (Seção 5.5), no IS-IS (Seção 5.6)
e no OSPFv3 (Seção 5.7). A representação do endereçamento externo ao domínio
147

148 5 Estrutura LSDB de redes de área única OSPF e IS-IS
informações são apresentadas na Seção 5.8. Finalmente, na Seção 5.9, discutimos a

representação das informações do link.
5.1 elementos LSDB

OSPF No OSPF, os elementos LSDB são chamados de anúncios de estado de link
(LSAs). Existem diferentes tipos de LSAs para transmitir diferentes tipos de informações
de roteamento, e os LSAs podem ser inundados independentemente. No entanto, no
OSPFv2, alguns LSAs misturam as informações topológicas e de endereçamento.
IS-IS No IS-IS, o LSDB é primeiro dividido em Link State PDUs (LSPs). Existem apenas
dois tipos de LSPs: (i) Nonpseudonode-LSPs, para transmitir informações de roteamento
associadas a roteadores, e (ii) Pseudonode-LSPs, para transmitir informações de
roteamento associadas a links compartilhados de trânsito. Os diferentes tipos de
informações de roteamento contidos em cada LSP são fornecidos por meio de um número
variável de registros Type-Length-Value (TLV). Assim, de uma perspectiva de informação
de roteamento, os TLVs são equivalentes aos LSAs. No entanto, ao contrário dos LSAs,
os TLVs não podem ser inundados independentemente: eles são forçados a ser inundados
junto com todos os outros TLVs pertencentes ao mesmo LSP. No IS-IS, os LSPs são
indivisíveis do ponto de vista do flooding. Por exemplo, os TLVs que descrevem as
informações topológicas e de endereçamento associadas a um roteador específico não
podem ser inundados separadamente, pois fazem parte do mesmo Nonpseudonode-LSP.
Roteadores de origem Os roteadores que criam LSAs e LSPs têm um papel importante
em manter o LSDB devidamente atualizado. Vamos nos referir a eles como roteadores de
origem ou como roteadores de publicidade (ARs), seguindo a nomenclatura OSPF.
Comparando o protocolo genérico, OSPF e IS-IS Na Figura 5.1, resumimos as

correspondências entre os elementos LSDB do protocolo genérico, OSPF e IS-IS a partir
das informações de roteamento e perspectivas de inundação. Do ponto de vista da
informação de roteamento, há uma equivalência entre NRs, LSAs e TLVs; do ponto de
vista da inundação, a equivalência é entre NRs, LSAs e LSPs.
Revisitar o princípio de separação IS-IS e OSPFv2 de certa forma compromete o princípio

de separação discutido na Seção 2.2.2. No IS-IS, os elementos de informação de
roteamento (os TLVs) não podem ser inundados independentemente. No OSPFv2, alguns
elementos de informação de roteamento (os LSAs) misturam informações topológicas e
de endereçamento. OSPFv3 é a única tecnologia que separa as informações topológicas
e de endereçamento das informações de roteamento e das perspectivas de inundação.
Na Figura 5.2, mostramos a correspondência, do ponto de vista da informação de

roteamento, entre as NRs do protocolo genérico apresentado no Capítulo 2

5.2 Identificadores de roteador e link 149
FIGURA 5.1: Correspondência entre os elementos LSDB do protocolo genérico, OSPF e IS-
IS.
e os elementos LSDB de OSPF e IS-IS. Esses elementos serão discutidos nas próximas seções.
No OSPF, os elementos LSDB são os anúncios de estado de link (LSAs). Diferentes

tipos de LSA transmitem diferentes tipos de roteamento em formação e podem
ser inundados independentemente. No IS-IS, o LSDB é primeiro dividido em Link
State PDUs (LSPs), e cada LSP inclui um número variável de registros Type-
Length-Value (TLV) para transmitir diferentes tipos de informações de roteamento.
Os TLVs contidos em um LSP não podem ser inundados independentemente.
Existem dois tipos de LSPs: Nonpseudonode-LSPs descrevem informações de
roteamento associadas a roteadores, e Pseudonode-LSPs descrevem informações
de roteamento associadas a links compartilhados de trânsito.
5.2 Identificadores de roteador e link

A representação da rede requer identificadores de roteador e link adequados. Nas próximas
seções, discutimos a estrutura desses identificadores em OSPFv2, OSPFv3 e IS-IS. Na
Figura 5.3 resumimos suas principais características.
5.2.1 Identificadores de roteador
Identificadores de roteador OSPF Em OSPFv2 e OSPFv3, o identificador de roteador é um

número de 32 bits exclusivo no domínio de roteamento, denominado ID do roteador (RID) e
expresso em notação decimal com pontos como um endereço IPv4. No OSPFv2, não é
obrigatório configurar explicitamente um RID em um roteador. Se não estiver configurado,

(dep-
NR)
domínio-
externo-
prefixo-
NR
(aip-
NR)
area-
internal-
prefix-
NR
FIGURA
5.2:
Tipos
de
elementos
informação
de
roteamento
do
protocolo
genérico,
OSPF
e
IS-
IS.
(la-
NR)
endereço-
link-
NR
(slink-
NR)
link
compartilhado-
NR
roteador-
NR
genérico
AS-
Externo-
LSA
Roteador-
LSA
e
Rede-
LSA Rede-
LSA
Roteador-
LSA
OSPFv2
AS-
Externo-
LSA
Rede-
LSA
Roteador-
LSA
Prefixo-
LSA Intraárea
Link-
LSA OSPFv3
IS
Neighbors
TLV
ou
Extended IS
Neighbors
TLV
ou
Extended
Informação
TLV
ou
Estendida Informação
TLV
ou
Estendida
Acessibilidade
externa
de
IP
Acessibilidade
interna
de
IP
IS
Alcançabilidade
TLV
de IS
Alcançabilidade
TLV
de
Nonpseudonode-
LSP
Acessibilidade
de
IP
TLV Acessibilidade
de
IP
TLV
Pseudonó-
LSP
IPv4
IS-
IS
IS
Neighbors
TLV
ou
Extended IS
Neighbors
TLV
ou
Extended
Acessibilidade
IPv6
TLV Acessibilidade
IPv6
TLV IS
Alcançabilidade
TLV
de IS
Alcançabilidade
TLV
de
Nonpseudonode-
LSP Nonpseudonode-
LSP
IPv6
IS-
IS
5 Estrutura LSDB de redes de área única OSPF e IS-IS 150
5.2 Identificadores de roteador e link 151
FIGURA 5.3: Identificadores de roteador e link em OSPF e IS-IS.
o RID é definido como um dos endereços IPv4 atribuídos às interfaces do roteador e as

implementações reais usam o mais alto. Assim, no OSPFv2, o RID pode ser um endereço
IPv4 roteável.
Identificadores de roteador IS-IS No IS-IS, os roteadores são identificados exclusivamente

pelo Network Entity Title (NET), mostrado na Figura 5.4. A rede usa endereços NSAP (ponto
de endereço de serviço de rede ISO) e é representada em notação hexadecimal. Inclui tanto
o identificador de área, denominado Area ID (AID), quanto o identificador do roteador dentro
de sua área, denominado System ID (SID). O AID pode ter um comprimento entre 1 e 13
octetos. No entanto, uma abordagem comum em redes IP é usar 3 octetos. O primeiro
octeto é chamado AFI (Authority and Format Identifier) e informa como interpretar a parte
restante do AID.
As redes IP geralmente usam o AFI de endereçamento privado, ou seja, 0×49. O campo
SEL (Seletor NSAP) nunca é examinado em redes IP; pode assumir qualquer valor e
geralmente é definido como 0 × 00.
5.2.2 Identificadores de link

Os links são identificados dinamicamente através do protocolo Hello. O identificador de
enlace é baseado no identificador de um dos roteadores atrelados ao enlace: o roteador do
outro lado do enlace, no caso de enlaces ponto a ponto, ou o DR do enlace, no caso de
enlaces compartilhados em trânsito.
Identificadores de enlace ponto a ponto Os enlaces ponto a ponto são representados em

um roteador por meio do identificador de seu vizinho no enlace, tanto em OSPF quanto em
1-13 bytes 6 bytes 1 byte
ID de área (AID) ID do Sistema (SID) SEL
AFI
1 byte
FIGURA 5.4: Estrutura do Título de Entidade de Rede (NET).

IS-IS (consulte a Seção 2.2.1.3). O identificador é o RID no caso de OSPF e o SID no

caso de IS-IS.
O link compartilhado DR, BDR e DIS A é identificado e representado no LSDB por meio
de seu DR (consulte a Seção 2.2.1.4). No IS-IS, o DR é chamado de Designated
Intermediate System (DIS). No OSPF, um segundo roteador é eleito nos enlaces
compartilhados de trânsito, denominado Backup Designated Router (BDR), com a
função de substituir o DR em caso de falha. No entanto, o BDR não desempenha
nenhum papel na identificação de links compartilhados.
Identificadores de link compartilhado OSPFv2 usa um método diferente do OSPFv3 e IS-
IS para identificar links compartilhados de trânsito. No OSPFv2, um link compartilhado é
identificado por meio do endereço IPv4 da interface DR anexada ao link; observe que
esse identificador é um endereço de interface e pode não coincidir com o RID do DR.
OSPFv3 e IS-IS utilizam uma concatenação do identificador DR com um tag local

gerado por este roteador, que deve ser único para cada link compartilhado que
representa. A tag é chamada de Interface ID em OSPFv3 e Pseudonode ID em IS-IS. O
ID da interface tem quatro octetos e o Pseudonode ID tem um octeto. Além disso, o
Pseudonode ID deve ter um valor diferente de zero no caso de links compartilhados de
trânsito.
A Figura 5.5 dá um exemplo de identificadores de links compartilhados. O roteador
R1 é o DR nos links compartilhados esquerdo e direito. A figura mostra como os
identificadores de link compartilhado de IS-IS, OSPFv2 e OSPFv3 são obtidos dos
Pseudonode IDs (IS-IS), endereços de interface IPv4 (OSPFv2) e Interface IDs (OSPFv3).
Distinção entre links paralelos Além disso, para distinguir entre links paralelos em um
roteador, o OSPFv2 concatena o RID do vizinho com o endereço IPv4 da interface que
conecta o roteador ao link, e o OSPFv3 o concatena com o identificador da interface.
IS-IS não tem provisão para distinguir entre links paralelos.
Uso do Pseudonode ID O Pseudonode ID, além de ser um componente do identificador

de enlace compartilhado de trânsito, também é utilizado para discriminar entre os
identificadores de roteadores e enlaces compartilhados de trânsito. O Pseudonode ID
deve ser zero no primeiro caso e diferente de zero no segundo. No OSPF, a distinção
entre o elemento ao qual se aplica um identificador (roteador, link ponto a ponto ou link
compartilhado de trânsito) é feita pelo contexto em que o identificador é usado, por
exemplo, o tipo de LSA e o chamado link descrição.
Um comentário sobre o comprimento dos identificadores do link Destacamos que o
comprimento do roteador e dos identificadores do link é claramente excessivo tanto no
OSPF quanto no IS-IS, visto que eles precisam ser únicos apenas dentro de um domínio
de roteamento: OSPF usa 4 octetos (um endereço IPv4) e o IS-IS usa 6 octetos (o SID).

5.3 Tipos de links 153
Link compartilhado Link compartilhado

identificado por: - 0000.0000.0003|1 (IS-IS) identificado por: - 0000.0000.0003|2 (IS-IS)
- 3.3.3.3|8.8.3.1 (OSPFv2) - 3.3.3.3|8.8.5.9 (OSPFv2)
- 3.3.3.3|7 (OSPFv3) - 3.3.3.3|3 (OSPFv3)
RID=3.3.3.3 (OSPFv2, OSPFv3)

SID=0000.0000.0003 (IS-IS)
R1
ID do pseudonó = 1 (IS-IS) ID do pseudonó = 2 (IS-IS)
Endereço IP = 8.8.3.1 (OSPFv2) Endereço IP = 8.8.5.9 (OSPFv2)
ID da interface = 7 (OSPFv3) ID da interface = 3 (OSPFv3)
FIGURA 5.5: Identificação de links compartilhados em IS-IS, OSPFv2 e OSPFv3.
Os roteadores são identificados por números de 32 bits expressos como endereços IPv4,
tanto no OSPFv2 quanto no OSPFv3, e por endereços NSAP no IS-IS.
Os links são identificados dinamicamente usando o protocolo Hello. Os links ponto a
ponto são identificados através do RID do roteador vizinho no link que, no caso do OSPF,
é concatenado com um endereço IPv4 (OSPFv2) ou uma tag gerada localmente
(OSPFv3), para distinguir entre links paralelos. Os links compartilhados são identificados
pelo endereço IPv4 da interface DR anexada ao link (OSPFv2) ou pelo RID do DR
concatenado com uma tag gerada localmente (OSPFv3 e IS-IS) para distinguir entre os
roteadores designados em mais de um link compartilhado .
5.3 Tipos de links

Os tipos de link são abstrações das tecnologias de link reais para fins de representação de rede.
Na Seção 1.7, classificamos os links da camada 2 em dois tipos: links ponto a ponto e links
compartilhados. Além disso, os links compartilhados foram classificados de acordo com seu grau
de conectividade e capacidade de transmissão.
O grau de conectividade afeta a maneira como os links compartilhados são representados no mapa
de rede e a capacidade de transmissão afeta a maneira como os pacotes de controle são
transmitidos nos links compartilhados. De acordo com o grau de conectividade, os enlaces podem
ser classificados como totalmente em malha ou parcialmente em malha. Em particular, links
compartilhados totalmente em malha podem ser representados pelo equivalente a um slink-NR. De
acordo com a capacidade de transmissão, os links podem ser classificados como transmitidos ou não transmitidos.
Os tipos de link considerados pelo OSPF e IS-IS não seguem exatamente essa classe

FIGURA 5.6: Correspondência entre os tipos de enlace do protocolo genérico, OSPF

e IS-IS.
e diferem ligeiramente entre eles. A Figura 5.6 mostra a correspondência entre os tipos
de link do protocolo genérico, OSPF e IS-IS.
Tipos de link IS-IS O IS-IS considera apenas dois tipos de link, chamados de sub-rede
de topologia geral e sub-rede de broadcast. Os últimos são equivalentes a links
compartilhados de transmissão ampla e os primeiros agregam os tipos de link restantes,
incluindo links compartilhados ponto a ponto e sem transmissão. As sub-redes de
topologia geral são representadas como uma coleção de links ponto a ponto. As sub-
redes de broadcast são representadas no LSDB pelo equivalente a um slink-NR.
Tipos de link OSPF O OSPF considera cinco tipos de link: links ponto-a-ponto, links
virtuais, links broadcast (o equivalente a links compartilhados broadcast) e dois tipos
de links compartilhados não broadcast chamados ponto-a-multiponto e Non-Broadcast
Multi -Acesso (NBMA). Um enlace ponto a multiponto é representado por meio de uma
coleção de enlaces ponto a ponto, como no IS-IS. Um link NBMA é representado pelo
equivalente a um slink-NR, como em links de transmissão OSPF e sub-redes de
transmissão IS IS. A representação NBMA aplica-se apenas a links compartilhados
totalmente em malha. Como os links NBMA não têm capacidade de transmissão, os
pacotes de controle enviados por um roteador devem ser transmitidos individualmente
para todos os outros roteadores conectados ao link. O OSPF inclui diversas adaptações
para minimizar a quantidade de tráfego de controle trocado neste tipo de links. Links
virtuais são links lógicos usados em OSPF hierárquico para superar as restrições
topológicas desses tipos de redes. Devido à sua preponderância nas redes atuais,
vamos nos concentrar em links compartilhados ponto-a-ponto e broadcast, deixando
de lado os detalhes de links compartilhados não broadcast e links virtuais.
Com exceção dos links virtuais, a especificação OSPFv2 [36] refere-se aos links
como redes, onde as redes são entendidas como sub-redes e não como links. De fato,
ao contrário do OSPFv3, no OSPFv2 não há distinção entre links e sub-redes, e todo
o processamento é por sub-rede. Lembre-se da discussão na Seção 1.4.2 de que
várias sub-redes podem ser atribuídas a um único link.

5.4 Estrutura geral dos elementos LSDB 155
O IS-IS abstrai os links entre os roteadores em dois tipos, chamados de

topologia geral e sub-redes de broadcast. O OSPF abstrai os links em cinco
tipos: ponto a ponto, broadcast, ponto a multiponto, Non Broadcast Multiple
Access (NBMA) e links virtuais.
5.4 Estrutura geral dos elementos LSDB
Os formatos de OSPFv2 e OSPFv3 LSAs, e de IS-IS LSPs, são mostrados nas Figuras
5.9, 5.12 e 5.15, respectivamente. Nas figuras, incluímos todos os campos de LSAs e
LSPs definidos nas especificações, exceto os campos não utilizados. No entanto,
descreveremos apenas os campos que são fundamentais para a operação dos
protocolos LSR. As figuras também indicam o comprimento de cada campo (em
octetos); av indica que o comprimento é variável. Campos ou grupos de campos que
podem se repetir várias vezes são encapsulados em um retângulo mais escuro. Neste
capítulo, vamos nos concentrar nos LSAs e LSPs necessários para descrever uma rede de área únic
Como NRs, LSAs e LSPs são estruturados em duas partes: um cabeçalho e um corpo.
O cabeçalho contém o equivalente ao identificador NR (consulte a Seção 2.2.5) e aos
atributos de atualização do NR (consulte a Seção 2.4.1); esses campos são resumidos
na Figura 5.7.
5.4.1 Cabeçalho LSA
Todos os tipos de LSA compartilham um cabeçalho comum de 20 octetos, que é quase

idêntico em OSPFv2 e OSPFv3, conforme pode ser verificado nas Figuras 5.9 e 5.15.
Os LSAs são identificados exclusivamente por três campos: o identificador AR
(Advertising Router), o tipo de LSA (LS Type) e um campo adicional para distinguir
entre LSAs do mesmo tipo originados pelo mesmo roteador (Link State ID).
Chamaremos esse conjunto de campos de LSA ID. A atualização do LSA é definida
pelo SN (LS Sequence Number), a idade (LS Age) e a soma de verificação (LS Checksum).
FIGURA 5.7: Campos que identificam LSAs e LSPs e descrevem sua atualização.

5.4.2 Cabeçalho LSP
Como os LSAs, todos os tipos de LSP compartilham um cabeçalho comum (consulte a Figura
5.12). Os LSPs podem ser do tipo L1 ou L2, conforme indicado no campo Tipo. Eles são
identificados exclusivamente pelo Source ID, que identifica o roteador de origem, e pelo
Pseudonode ID, que distingue entre diferentes LSPs originados pelo mesmo roteador.
Conforme mencionado acima, o Pseudonode ID deve ser zero para LSPs que descrevem
roteadores e um valor diferente de zero para LSPs que descrevem links compartilhados de trânsito.
Em redes IP, o campo Source ID é igual ao SID. A atualização dos LSPs é definida pelo SN
(Sequence Number), a idade (Remaining Lifetime) e a soma de verificação (Checksum).
O campo LSP Number é usado no processo de fragmentação e identifica exclusivamente

os fragmentos de um determinado LSP. Isso é necessário porque os pacotes de controle IS-
IS são encapsulados diretamente em pacotes da camada 2, que não têm suporte para
fragmentação. No IS-IS, a fragmentação ocorre apenas no roteador de origem, que deve
conhecer a priori o MTU mínimo entre todos os enlaces da rede para determinar o tamanho
máximo do fragmento; não há processo de descoberta de MTU de caminho, como no IPv6.
Além disso, no IS-IS, os fragmentos LSP nunca são remontados e, portanto, são listados
individualmente no LSDB; isso é complicado. Os fragmentos LSP são identificados
exclusivamente no LSDB através da concatenação de SID, Pseudonode ID e LSP Number,
que é chamado de LSP ID. Os pacotes OSPF são encapsulados em pacotes IP e, portanto,
dependem do mecanismo de fragmentação e remontagem do IPv4 ou IPv6.
5.4.3 Registros IS-IS TLV
O corpo dos LSPs compreende um número variável de registros TLV. A estrutura dos IS-IS
TLVs é mostrada na Figura 5.8.a. O campo Tipo indica o tipo de TLV, o campo Comprimento
indica o comprimento do campo Valor e o campo Valor é o conteúdo real do TLV, que varia
de acordo com seu tipo. O conteúdo de um TLV é limitado a 255 octetos.
TLVs estendidos A estrutura dos TLVs foi posteriormente estendida para permitir a organização
do conteúdo TLV em sub-TLVs (Figura 5.8.b) [29]. Nesse caso, o conteúdo de um TLV pode
incluir um número variável de sub-TLVs, permitindo uma organização em dois níveis das
informações de roteamento. A estrutura dos sub TLVs é semelhante à dos TLVs: cada sub-
TLV tem um campo Tipo de um octeto, um campo Comprimento de um octeto e um campo
Valor com zero ou mais octetos. Esses TLVs às vezes são chamados de TLVs estendidos. A
principal motivação para esta extensão foi o suporte de funções de engenharia de tráfego. No
entanto, como veremos mais adiante, os TLVs estendidos têm um uso mais amplo atualmente.
Tanto os LSAs quanto os LSPs incluem um cabeçalho que contém os campos

necessários para identificá-los exclusivamente no LSDB e para expressar sua atualização.
O corpo dos LSPs é estruturado com registros Tipo-Comprimento-Valor.

5.5 Informações topológicas e de endereçamento interno de domínio em OSPFv2 157
Tipo 1
1 Comprimento 1
Tipo
1 Campos comuns a todos os sub-

Comprimento
TLVs, incluindo v
Valor v Comprimento dos sub-TLVs
Tipo de sub-TLV 1
Comprimento do sub-TLV 1
Valor de sub-TLV v
FIGURA 5.8: Estrutura de IS-IS TLVs; (a) TLVs regulares, (b) TLVs organizados em
sub-TLVs (TLVs estendidos)
5.5 Informações topológicas e de endereçamento interno de

domínio em OSPFv2
O formato de OSPFv2 LSAs é mostrado na Figura 5.9. No OSPFv2, as informações
topológicas e de endereçamento são fornecidas conjuntamente pelo Roteador-LSA e
pela Rede-LSA. Do ponto de vista da informação topológica, o Router LSA pode ser
considerado o equivalente ao router-NR e o Network-LSA o equivalente ao slink-NR.
No entanto, o Router-LSA e o Network-LSA também fornecem informações de
endereçamento e também podem ser considerados equivalentes ao aip-NR. Essa
situação não se manteve na evolução do OSPFv2 para o OSPFv3, onde o Router-
LSAs e o Network-LSAs ficaram restritos a fornecer informações topológicas, conforme
será discutido na Seção 5.7 .
Os identificadores dos elementos de rede podem acabar sendo endereços IPv4
roteáveis. Conforme discutido na Seção 5.2, o RID, se não configurado explicitamente,
é igual a um dos endereços IPv4 atribuídos às interfaces do roteador. Além disso, o
identificador do link compartilhado sempre coincide com o endereço IPv4 atribuído à
interface DR anexada ao link. Assim, OSPFv2 não separa identificadores topológicos
de endereços roteáveis.
Na Seção 9.2.1.1, mostramos experimentos que destacam os recursos do OSPFv2
LSDB.
5.5.1 Roteador-LSA
O Roteador-LSA descreve um roteador, suas interfaces de saída e os endereços IPv4
atribuídos a ele e suas interfaces.
Roteador de origem O roteador que origina o LSA é identificado no campo Advertising
Router, utilizando seu RID.

LS idade 2 0 0 0 0 VBE 0 1 máscara de rede 4
Opções 1 Número de links 2 E todos os zeros 1
Tipo LS 1 ID do link 4 Métrica 3
ID do estado do link 4 dados de link 4 Endereço de encaminhamento 4
Roteador de Publicidade 4 Tipo 1 Etiqueta de Rota Externa 4
Número de Sequência LS 4 # PARA% S 2 AS-Externo-LSA

Soma de verificação LS 2 Métrica 2
máscara de rede 4
Comprimento 2 Roteador-LSA roteador conectado 4
Cabeçalho LSA
Rede-LSA
FIGURA 5.9: Formato de OSPFv2 LSAs (redes de área única).
Descrições de link As interfaces do roteador são caracterizadas usando as chamadas

descrições de link. Mais de uma descrição pode ser necessária para caracterizar
completamente uma interface; como veremos adiante, este é o caso das interfaces de enlace
ponto a ponto. O número de descrições de links contidos em um Roteador-LSA é indicado no
campo Number of Links. Os campos principais de uma descrição de link são Tipo, ID do link,
Dados do link e Métrica. O OSPFv2 considera quatro tipos diferentes de descrições de links,
discriminados pelo campo Tipo:
• tipo 1 - link ponto a ponto;
• tipo 2 - ligação à rede de trânsito;
• tipo 3 - link para rede stub;
• tipo 4 - link virtual.
As descrições dos tipos 1 e 2 transmitem informações topológicas e as descrições do tipo 3

transmitem informações de endereçamento. As descrições do tipo 4 são para links virtuais e
não serão mais discutidas.
Como as descrições de links são usadas? A Figura 5.10 mostra o conteúdo dos campos de
descrição do link para cada tipo de elemento que está sendo descrito. Esses elementos são:
(i) um endereço IPv4 atribuído a um roteador, (ii) uma interface para um link ponto-a-ponto,
(iii) uma interface para um link compartilhado de trânsito e (iv) uma interface para um stub
compartilhado link.
• Endereço IPv4 atribuído ao roteador - Um endereço IPv4 atribuído a um roteador, ou seja,

um endereço de loopback, é anunciado por meio de uma descrição de link tipo 3, onde
Link ID é o endereço IPv4, Link Data é uma máscara de sub-rede de 32 bits
(255.255.255.255 ) e Métrica tem um valor de zero.
• Interface para link ponto a ponto - Uma interface para um link ponto a ponto

FIGURA 5.10: Conteúdo dos campos de descrição do link (OSPFv2).
é caracterizado por dois tipos de descrição de link: uma descrição de tipo 1 para
transmitir informações topológicas e uma descrição de tipo 3 para transmitir informações
de endereçamento.
– A descrição do tipo 1 identifica o link e o custo correspondente na interface. Inclui

o RID do vizinho (Link ID), o endereço IPv4 atribuído à interface de saída do
roteador (Link Data) e o custo da interface com o link (Metric). O campo Link Data
garante a unicidade na identificação do link quando houver links paralelos.
– A descrição do tipo 3 identifica o prefixo atribuído ao link. Inclui o endereço IPv4 da

sub-rede (Link ID) e a máscara de sub-rede (Link Data) que definem o prefixo
atribuído ao link, bem como o custo da interface com o link (Metric). Esta última é
uma informação repetida, já contida na descrição do tipo 1.
A nomenclatura em torno das descrições do tipo 3 é confusa, pois, na especificação

OSPFv2, essa descrição caracteriza um “link to stub network”, enquanto neste caso é
usada para caracterizar um link ponto a ponto.
Curiosamente, o OSPFv2 acomoda links ponto a ponto não numerados, ou seja, links
ponto a ponto sem prefixo atribuído. Nesse caso, o link é caracterizado por uma única
descrição do tipo 1, onde Link Data é o número da interface anexada ao link. A
exigência de links ponto a ponto não numerados vem de uma época em que as sub-
redes eram classful e assinar um prefixo para um link ponto a ponto implicava no
desperdício de, pelo menos, um espaço de endereço classe C (256 endereços). No
entanto, a existência desse recurso é um reconhecimento implícito de que as
informações topológicas e de endereçamento podem realmente ser separadas.
• Interface para link compartilhado de trânsito - Uma interface para um link compartilhado de trânsito

é caracterizado por uma descrição do tipo 2, que inclui o identificador do link

compartilhado, ou seja, o endereço IPv4 da interface DR anexada ao link (Link ID), o
endereço IPv4 atribuído à interface de saída do roteador (Link Data) e o custo de a
interface com o link (Métrica).
• Interface para stub de link compartilhado - Finalmente, uma interface para um stub de
link compartilhado é caracterizada por uma descrição do tipo 3, que inclui o endereço
IPv4 da sub-rede (Link ID) e a máscara de sub-rede (Link Data) que definem o prefixo e
o custo da interface do roteador com o link (Métrica). Os links compartilhados do stub
não possuem representação topológica, pois não são identificados no mapa da rede.
Identificação do roteador-LSA Os roteadores-LSAs são identificados exclusivamente no

LSDB por dois campos, o roteador de publicidade e o tipo de LS. Nesses LSAs, o Link
State ID não tem significado e é igual ao Advertising Router.
5.5.2 Rede-LSA
O Network-LSA descreve um link compartilhado de trânsito e o prefixo atribuído a ele. Os

roteadores conectados ao link são identificados por meio de seus RIDs no campo Attached
Router. O identificador do link é colocado no campo Link State ID. O endereço IPv4
contido neste campo, juntamente com a máscara de sub-rede contida no campo Máscara
de Rede, caracterizam o prefixo atribuído ao link. Assim, Network-LSAs transmitem
informações topológicas e de endereçamento.
Ao contrário dos roteadores-LSAs, os Network-LSAs exigem que o campo Link State

ID seja identificado exclusivamente (consulte a Seção 2.2.5), pois o mesmo roteador pode
originar mais de um Network-LSA.
5.5.3 Fornecer informações topológicas e de endereçamento

A Figura 5.11 resume como as informações topológicas e de endereçamento são
fornecidas no OSPFv2. A figura inclui as mesmas informações relativas ao OSPFv3, para
fins de comparação. No entanto, a estrutura OSPFv3 LSDB será discutida apenas na
Seção 5.7.
Informações topológicas Os elementos topológicos relevantes para a construção do
mapa da rede são (i) os roteadores, (ii) os enlaces ponto a ponto e (iii) os enlaces
compartilhados de trânsito. A informação topológica diz respeito à forma como esses
elementos são identificados e conectados entre si.
• Um roteador é identificado através de seu RID, contido no Roteador-LSA de origem

inata.
• Um link ponto a ponto é descrito por meio de dois Roteadores-LSAs, cada um originado
por um roteador final de link e descrevendo uma direção de link. Em particular, a
interface de link ponto a ponto é caracterizada por uma descrição de link tipo 1,

FIGURA 5.11: Como as informações topológicas e de endereçamento são fornecidas

no OSPFv2 e OSPFv3.
usando o RID do vizinho como identificador de link (concatenado com o endereço

IPv4 da interface do roteador para distinguir entre linhas paralelas).
• Um link compartilhado de trânsito é caracterizado por um Network-LSA originado

pelo link DR, que inclui o identificador do link (ou seja, o endereço IPv4 da interface
DR anexada ao link) e lista todos os roteadores conectados ao link usando seus
RIDs. Além disso, uma interface de roteador anexada a um link compartilhado de
trânsito é caracterizada por meio de uma descrição de link tipo 2 incluída no
Roteador-LSA que descreve o roteador e usando o identificador de link como
referência ao link.
Informação de endereçamento A informação de endereçamento diz respeito à

identificação dos prefixos atribuídos à rede e sua associação com elementos de
rede. Os prefixos podem ser atribuídos a quatro tipos de elementos: (i) roteadores, (ii)
links ponto a ponto, (iii) links compartilhados de trânsito e (iv) links compartilhados stub.
• Endereços atribuídos a roteadores - Um endereço IPv4 atribuído a um roteador

5.6 Informações topológicas e de endereçamento interno de domínio em IS-IS 163
a estrutura desses LSDBs é idêntica. Ambos os LSDBs são formados por LSPs, e os
LSPs são estruturados com o mesmo conjunto de campos independente do tipo de
LSDB. A distinção entre LSPs da L1 LSDB e LSPs da L2 LSDB é feita através do valor
do campo IS Type (2 bits), que faz parte do cabeçalho LSP; este campo é igual a 1 no
primeiro caso e igual a 3 no segundo.
Observe que os TLVs estão contidos dentro dos LSPs e, portanto, herdam seu tipo
LSDB. A seguir, não faremos distinção entre L1 e L2 LSPs, pois sua estrutura é idêntica.
Nonpseudonode-LSPs e Pseudonode-LSPs Um roteador IS-IS pode originar apenas

dois tipos de LSPs: Nonpseudonode-LSPs e Pseudonode-LSPs.
O Nonpseudonode-LSP descreve um roteador, suas interfaces e os prefixos associados
a ele; o Pseudonode-LSP descreve um link compartilhado de trânsito, mas apenas
topologicamente. Um roteador pode originar tantos Pseudonode-LSPs quanto links
compartilhados de trânsito onde ele é o DIS, mas só pode originar um Nonpseudonode
LSP. Os tipos de LSP são discriminados pelo campo Pseudonode ID, que é igual a
zero no primeiro caso e assume um valor diferente de zero no segundo.
Os LSPs de registros TLV incluem um número variável de TLVs para transmitir
diferentes tipos de informações de roteamento. A informação topológica é fornecida
através do IS Neighbours TLV ou do Extended IS Reachability TLV, que usa endereços
NSAP como identificadores topológicos. Do ponto de vista da informação de roteamento,
os TLVs topológicos são equivalentes a um roteador-NR quando inseridos em um
Nonpseudonode-LSP, e equivalentes a um slink-NR quando inseridos em um
Pseudonode-LSP. Os TLVs topológicos mantêm a mesma estrutura nas versões IPv4
e IPv6 do IS-IS.
As informações de endereçamento são fornecidas pelos TLVs de acessibilidade
de IP (que também podemos chamar de TLVs de endereçamento). Esses TLVs diferem
nas versões IPv4 e IPv6 do IS-IS. A versão IPv4 usa o IP Internal Reachability
Information TLV ou o Extended IP Reachability TLV, e a versão IPv6 usa o IPv6
Reachability TLV. Esses TLVs não podem ser incluídos em Pseudonode-LSPs. Quando
inseridos em Nonpseudonode-LSPs, são equivalentes ao aip-NR.
Nas Seções 9.2.1.4 e 9.2.1.5, mostramos experimentos que destacam os recursos

dos LSDBs IS-IS IPv4 e IPv6.
5.6.1 IS Neighbors TLV e Extended IS Reachability TLV

Atualmente, existem dois tipos de TLVs que fornecem informações topológicas
(consulte a Figura 5.12): o IS Neighbors TLV (tipo 2) e o Extended IS Reacha bility
TLV (tipo 22). Esses TLVs são incluídos em Nonpseudonode-LSPs e Pseudonode-
LSPs para descrever os vizinhos do elemento de rede ao qual estão associados.
Quando o TLV é inserido em um Nonpseudonode-LSP, os vizinhos podem ser outros
roteadores ou links compartilhados de trânsito (pseudonodes); quando inseridos em
um Pseudonode-LSP, os vizinhos só podem ser outros roteadores.
Como os vizinhos são descritos? Os vizinhos são descritos dentro de um TLV usando

Protocolo de Roteamento Intradomínio 1 1

Tipo = 2 1 Tipo = 22
Discriminador
Indicador de comprimento 1 Comprimento 1 Comprimento

1
ID do protocolo 1 bandeira virtual 1 SID + ID do pseudonó 7
Comprimento do ID
1 0 I/E Métrica padrão 1 Métrica 3
Tipo 1 SI/E Métrica de atraso 1 Comprimento dos sub-TLVs 1
Versão 1 SI/E Métrica de despesas 1 Tipo de sub-TLV 1
Reservado 1 SI/E Métrica de erro 1 Comprimento do sub-TLV 1
Endereços de área máxima 1 SID + ID do pseudonó 7 Valor de sub-TLV v
2
Comprimento da PDU
IS vizinhos TLV Acessibilidade IS estendida
TLV
Vida útil restante 2 1
Tipo = 128
Tipo = 236 1
ID da fonte 6 1
Comprimento
Comprimento
1
ID do pseudonó 1 U/D I/E Métrica Padrão 1
Métrica 4
Número LSP 1 SR 1
Métrica de atraso
U/D x S Reservado 1
Número sequencial 4 SR 1
Métrica de despesas
Comprimento do prefixo 1
soma de verificação 2 SR Métrica de erro 1
Prefixo v
O É
P ATT 1 Endereço de IP 4
eu Tipo
Comprimento dos sub-TLVs 1
cabeçalho LSP máscara de sub-rede 4
Tipo de sub-TLV 1
Tipo = 135 1
Acessibilidade interna de IP 1
Comprimento do sub-TLV
Informação TLV
Comprimento
1
1 Valor de sub-TLV v
Tipo = 130
Métrica 4
Comprimento
1 Acessibilidade IPv6 TLV
SU/D Comprimento do prefixo 1
U/D I/E Métrica padrão 1
Prefixo v
SR Métrica de atraso 1
Comprimento dos sub-TLVs 1
Métrica de Despesas SR 1
Tipo de sub-TLV 1
SR Métrica de erro 1
Comprimento do sub-TLV 1
Endereço de IP 4
Valor de sub-TLV v
máscara de sub-rede 4
Acessibilidade estendida de IP
TLV Acessibilidade externa de IP
Informação TLV
FIGURA 5.12: Formato de IS-IS LSPs.
uma estrutura formada por um conjunto de campos (a estrutura vizinha), que se

repete para cada vizinho individual. Cada vizinho é identificado usando uma
concatenação do SID e o Pseudonode ID, que será chamado de Node ID. Quando
o vizinho é um roteador, ele é identificado pelo SID e

um Pseudonode ID igual a zero; quando o vizinho é um link compartilhado de trânsito, ele

é identificado através do SID do link DIS e um Pseudonode ID diferente de zero.
Informações de custo da interface A estrutura do vizinho também carrega o custo da
interface de saída que leva ao vizinho no campo Métrica Padrão (IS Neighbors TLV) ou no
campo Métrica (TLV Extended IS Reachability). O comprimento da métrica padrão é de 6
bits, permitindo apenas 64 valores diferentes. Este pequeno número foi uma das
motivações para a introdução do Extended IS Reachability TLV, onde o campo Metric tem
um comprimento de 3 octetos. Em Pseudonode-LSPs, o valor da métrica é zero para todos
os vizinhos listados.
Registros sub-TLV O Extended IS Reachability TLV pode incluir um número de sub-TLVs
em cada estrutura vizinha. Exemplos de sub-TLVs são o endereço de interface IPv4 (sub-
TLV do tipo 6) e o endereço do vizinho IPv4 (sub-TLV do tipo 8); os nomes desses sub-
TLVs falam por si. Observe que a inclusão de sub-TLVs não é obrigatória.
O Extended IS Reachability TLV eliminou a maioria dos campos métricos que existem
no IS Neighbours TLV, ou seja, a métrica de atraso, a métrica de despesa e a métrica de
erro. A filosofia por trás do projeto do Ex tented IS Reachability TLV foi manter apenas a
métrica padrão e permitir a inclusão de métricas adicionais somente quando necessário,
usando sub-TLVs.
Descrevendo enlaces paralelos ponto a ponto Um vizinho em um enlace ponto a ponto é
identificado por meio de seu SID e um Pseudonode ID igual a zero. Assim, IS IS não tem
nenhuma maneira explícita de diferenciar entre links ponto-a-ponto paralelos (isto é, links
que levam ao mesmo vizinho). Apesar disso, links paralelos podem ser descritos
individualmente em TLVs usando diferentes estruturas vizinhas com o mesmo identificador
de vizinho. Entretanto, nas implementações atuais, apenas um link é descrito, na verdade
aquele com menor custo de interface. Esta falta de informação topológica não é
problemática, uma vez que apenas a interface de menor custo é relevante para o cálculo
dos custos de caminho mais curto.
5.6.2 TLVs de acessibilidade de IP Os
TLVs de acessibilidade de IP fornecem as informações de endereçamento (consulte a

Figura 5.12). Existem vários tipos diferentes: (i) IP Internal Reachability Information TLV
(tipo 128), (ii) Extended IP Reachability TLV (tipo 135) e (iii) IPv6 Reachability TLV (tipo
236). Os dois primeiros descrevem prefixos IPv4 e o último, prefixos IPv6. O Extended IP
Reachability TLV usa sub-TLVs e foi introduzido para ampliar o IP Internal Reachability
Information TLV. O IPv6 Reachability TLV também usa sub-TLVs.
Como os prefixos são descritos? Os prefixos são descritos dentro de um TLV usando uma
estrutura formada por um conjunto de campos (a estrutura do prefixo), que se repete para
cada prefixo individual. O prefixo é identificado por meio dos campos Endereço IP e
Máscara de sub-rede (em TLVs de informações de acessibilidade interna de IP) e por meio
dos campos Prefixo e Comprimento do prefixo (em TLVs de acessibilidade de IP estendida
e TLVs de acessibilidade de IPv6).

O campo Prefixo no Extended IP Reachability TLV e no IPv6 Reachability TLV é de

comprimento variável. Deve conter um número inteiro de octetos, cujo número depende
do comprimento do prefixo. O número de octetos compactados no prefixo deve ser
igual à parte inteira de (Comprimento do prefixo + 7)/8.
A estrutura do prefixo também inclui o custo do roteador de origem até o prefixo

anunciado, no campo Default Metric (em IP Internal Reachability Information TLVs) ou
no campo Metric (em Extended IP Reachability TLVs e IPv6 Reachability TLVs).
Observe que a métrica padrão tem um comprimento de 6 bits e a métrica tem um
comprimento de 4 octetos.
A associação entre prefixos e elementos de rede No IS-IS, os pré-fixos estão sempre
associados a roteadores, mesmo que atribuídos a links, e são anunciados por meio
dos TLVs de acessibilidade de IP incluídos nos LSPs sem pseudonó. Um prefixo
atribuído a um link é anunciado por todos os roteadores conectados ao link, mesmo no
caso de links compartilhados. Pseudonode-LSPs não têm permissão para incluir IP
Reachability TLVs, ou seja, eles não têm meios para transmitir informações de
endereçamento. Esta opção penaliza desnecessariamente o tamanho do LSDB.
A associação entre os prefixos e os elementos de rede a que estão atribuídos está
implícita no facto de os prefixos estarem sempre associados aos routers e aos
Nonpseudonode-LSPs que os representam. Nesse caso, as informações de custo
incluídas nos TLVs de acessibilidade IP são sempre relevantes. O custo de um caminho
de um roteador para um prefixo atribuído a um link é sempre calculado em duas etapas:
(i) determinar o custo do caminho do roteador calculando o custo do caminho para o
roteador anunciando o prefixo (por exemplo, usando o algoritmo de Dijkstra); (ii)
adicionar o custo do caminho anterior ao custo incluído no IP Reachability TLV que
anuncia o prefixo (ou seja, o custo da interface com o link que possui o prefixo).

A Figura 5.13 resume como as informações topológicas e de endereçamento são
fornecidas no IS-IS (para simplificar, os TLVs estendidos não estão incluídos na figura).
É interessante comparar essas tabelas com as da Figura 5.11.
Uma deficiência da estrutura IS-IS LSDB é que as informações topológicas e de
endereçamento não podem ser transmitidas separadamente, uma vez que a
acessibilidade e os TLVs vizinhos devem ser sempre inundados juntos no mesmo LSP.
Informações topológicas Conforme mencionado na Seção 5.5.3, os elementos
topológicos relevantes para a construção do mapa da rede são (i) os roteadores, (ii) os
enlaces ponto a ponto e (iii) os enlaces compartilhados de trânsito.
• Um roteador é identificado por meio de seu SID (incluído no campo Source ID de seu
Nonpseudonode-LSP).
• Um link ponto-a-ponto é caracterizado por dois Nonpseudonode-LSPs, cada um

descrevendo uma direção de link e originado por uma das extremidades do link

FIGURA 5.13: Como as informações topológicas e de endereçamento são fornecidas no IS

IS.
roteadores. Os links ponto a ponto são identificados usando o SID do roteador vizinho
concatenado com um Pseudonode ID zero.
• Um link compartilhado de trânsito é caracterizado por um Pseudonode-LSP, originado pelo

link DIS, que inclui o identificador do link (SID do DIS concatenado com um Pseudonode
ID diferente de zero). Para permitir a referência cruzada, o Pseudonode-LSP inclui os
SIDs dos roteadores conectados ao link, e os Nonpseudonode-LSPs dos roteadores
conectados ao link incluem o identificador do link.
Informações de endereçamento As informações de endereçamento são fornecidas pelo IP

Internal Reachability Information TLV ou Extended IP Reachability TLV (em IPv4 IS-IS) e
IPv6 Reachability TLV (em IPv6 IS-IS). Um prefixo, seja atribuído a um roteador ou a um
link, está sempre associado a um roteador e seu Nonpseudonode-LSP. Assim, a
correspondência entre um prefixo e o elemento de rede ao qual ele é atribuído decorre
diretamente de ter os TLVs de acessibilidade IP dentro de Nonpseudonode-LSPs.

No IS-IS, existem dois tipos de LSPs, um representando um roteador,

chamado Nonpseudonode-LSP, e outro representando um link compartilhado
de trânsito, chamado Pseudonode-LSP. A informação topológica é fornecida
pelo IS Neighbors TLV ou Extended IS Reachability TLV, e está presente em
ambos os tipos de LSP. Esses TLVs são o equivalente do roteador-NR
quando incluído em um Nonpseudonode-LSP, ou o equivalente do slink NR
quando incluído em um Pseudonode-LSP. As informações de endereçamento
são fornecidas pelo IP Internal Reachability Information TLV ou Extended IP
Reachability TLV, no IPv4 IS-IS, e pelo IPv6 Reachability TLV, no IPv6 IS-
IS; estes são o equivalente do aip-NR. Os Pseudonode-LSPs não podem
incluir IP Reachability TLVs, o que significa que um prefixo atribuído a um
link compartilhado deve ser anunciado por todos os nós conectados ao link,
por meio de seus Nonpseudonode-LSPs. O IS-IS força os TLVs topológicos
e de endereçamento originados por um roteador a serem inundados juntos
no mesmo LSP.
5.6.4 IS-IS TLVs adicionais

Além dos TLVs mencionados até agora, os LSPs podem incluir outros TLVs, que
serão apresentados a seguir (ver Figura 5.14). Alguns desses TLVs também podem
ser incluídos nos pacotes de controle do IS-IS, que serão descritos na Seção 6.1.
Endereços de área TLV Os endereços de área TLV listam todos os IDs de área
atribuídos ao roteador de origem, usando o campo Endereço de área. Não está
incluído nos Pseudonode-LSPs, mas sua presença é obrigatória nos Nonpseudonode-LSPs.
Protocolos suportados TLV Os protocolos suportados TLV identificam os protocolos
da camada de rede suportados pela instância IS-IS, usando um identificador de 1
octeto chamado Network Layer Protocol Identifier (NLPID). O NLPID é 204 (0×cc)
para IPv4 e 142 (0×8e) para IPv6. O uso deste TLV é obrigatório em Nonpseudonode-
LSPs e em pacotes HELLO.
Tipo = 132 1 Tipo = 1 1
Comprimento
1 Comprimento
1
Endereço IPv4 4 Comprimento do endereço 1
Endereços de Interface IP TLV Endereço da área v
1
Endereços de área TLV
Tipo = 232
Comprimento
1 Tipo = 129 1
1
Endereço da interface Comprimento
1
6
Endereço de Interface IPv6 TLV NLPID 1
Protocolos suportados TLV
FIGURA 5.14: Formato de IS-IS TLVs adicionais.

Endereço de interface IP TLV O endereço de interface IP TLV lista um ou mais endereços

IPv4 atribuídos às interfaces IS-IS do roteador de origem.
Este TLV deve ser incluído em todos os Nonpseudonode-LSPs, quando o roteamento
IPv4 é configurado. Esse requisito não é fácil de entender, pois, para começar, um
roteador pode não precisar divulgar nenhum endereço IPv4 e, nesse caso, o IP Internal
Reachability Information TLV oferece uma solução melhor para esse fim.
As implementações geralmente incluem um único endereço IPv4 neste TLV. Este TLV
também está incluído nos pacotes HELLO.
Endereço de Interface IPv6 TLV O Endereço de Interface IPv6 TLV tem a mesma
finalidade que o Endereço de Interface IP TLV, mas para IPv6 IS-IS: lista um ou mais
endereços IPv6 atribuídos às interfaces IS-IS do roteador de origem. Este TLV também
é usado em pacotes HELLO. Quando usados em pacotes HELLO, os endereços
anunciados devem ser endereços de link local, mas quando usados dentro de LSPs, os
endereços anunciados não podem ser endereços de link local.
Dynamic Hostname TLV Uma característica interessante do IS-IS é a inclusão do
Dynamic Hostname TLV, para permitir a associação do SID com um nome codificado em
ASCII [48]. Dessa forma, os roteadores podem facilmente trocar nomes entre si, e esses
nomes podem ser usados, por exemplo, ao exibir o LSDB, em vez da notação
hexadecimal mais rígida. Este é um recurso muito conveniente para gerentes de rede e
é um bom exemplo da flexibilidade introduzida pelos IS-IS TLVs. O OSPF não possui um
recurso semelhante.
De IPv4 IS-IS para IPv6 IS-IS Note-se que a extensão de IS-IS para IPv6 foi muito
simples, uma vez que o formato TLV baseado em LSPs exigiu apenas a criação de dois
novos TLVs, nomeadamente o IPv6 Interface Address TLV e o IPv6 Reachability TLV.
Para sinalizar suporte a IPv6, os protocolos suportados TLV devem incluir um NLPID de
142 (0×8e).
5.7 Informações topológicas e de endereçamento interno de

domínio em OSPFv3
O OSPFv3 foi um grande avanço em relação à separação entre informações topológicas,
de endereçamento e de link. Ao contrário do OSPFv2, o OSPFv3 não usa endereços
roteáveis como identificadores topológicos. Os endereços roteáveis do OSPFv3 são
endereços IPv6, mas o OSPFv3 continuou usando endereços IPv4 como identificadores
topológicos. O formato de OSPFv3 LSAs é mostrado na Figura 5.15.
A informação topológica é fornecida por Router-LSAs e Network LSAs como em
OSPFv2. As informações de endereçamento são fornecidas por Intra-Area Prefix-LSAs.
As informações do link serão discutidas na Seção 5.9.
Na Seção 9.2.1.2, mostramos experimentos que destacam os recursos do OSPFv3
LSDB.

LS idade 2 Número de prefixos 2 Bandeiras 1
Tipo LS 2 Tipo de LS referenciado 2 Métrica 3
ID do estado do link 4 ID do estado do link referenciado 4 Comprimento do prefixo 1
Roteador de Publicidade 4 Roteador de publicidade referenciado 4 Opções de prefixo 1
Número de Sequência LS 4 Comprimento do prefixo 1 Tipo de LS referenciado 2
Soma de verificação LS 2 Opções de prefixo 1 Prefixo de endereço v
Comprimento 2 Métrica 2 Endereço de encaminhamento (opcional) 16
/6$KHDGHU Prefixo de endereço v Marca de Rota Externa (opcional) 4
ID do estado do link referenciado

4
Bandeiras 1 ,QWUD$UHD3UHIL[/6$ (opcional)
3
Opções
Prioridade do roteador 1 $6([WHUQDO/6$
Tipo 1
Opções 3 Opções 3
Métrica 2
Link-Local Interface Endereço 16 roteador conectado 4
ID da interface 4
Número de prefixos 4 1HWZRUN/6$
ID da interface do vizinho 4
Comprimento do prefixo 1
ID do roteador vizinho 4
Opções de prefixo 1
5RXWHU/6$ Prefixo de endereço v
/LQN/6$
FIGURA 5.15: Formato de OSPFv3 LSAs (redes de área única).
5.7.1 Roteador-LSA
O Router-LSA descreve um roteador e suas interfaces de saída e é o equivalente ao
roteador-NR. Ao contrário do OSPFv2, ele não inclui informações de endereçamento.
Roteador de origem Assim como no OSPFv2, o roteador que origina o LSA é

identificado no campo Advertising Router, utilizando seu RID.
Descrições de link As interfaces do roteador são caracterizadas por meio de
descrições de link, como no OSPFv2. No entanto, a descrição do tipo 3 foi removida,
pois fornecia informações de endereçamento e os roteadores-LSAs agora estão
restritos a fornecer informações topológicas. Os tipos de descrição de link restantes
são idênticos ao OSPFv2: tipo 1 (links ponto a ponto), tipo 2 (links compartilhados
de trânsito) e tipo 4 (links virtuais). Assim como no OSPFv2, não abordamos as
descrições do tipo 4.
O conteúdo das descrições do link é diferente do OSPFv2. Todas as descrições
de link incluem agora (i) o custo da interface (Metric), (ii) o identificador da interface
local (Interface ID), (iii) o identificador da interface vizinha (Neighbor Interface ID) e
(iv ) o RID do vizinho

FIGURA 5.16: Conteúdo dos campos de descrição do link (OSPFv3).
bor (ID do roteador vizinho). Conforme discutido nas Seções 2.2.1.3 e 2.2.1.4, os
identificadores de interface são necessários para garantir a unicidade na identificação do link.
O que é um vizinho nas descrições de link depende do tipo de interface: em interfaces de
link ponto a ponto, o vizinho é o roteador do outro lado do link e, em interfaces de link
compartilhado em trânsito, o vizinho é o link DR.
Assim, em interfaces de link compartilhado em trânsito, o Neighbor Router ID é o RID do
DR e o Neighbor Interface ID é o identificador da interface DR anexada ao link. Observe
que o conteúdo desses dois campos coincide com o identificador do link compartilhado,
conforme definido para OSPFv3 (consulte a Seção 5.2.2).
Como no caso do OSPFv2, o campo Link State ID não é necessário para identificar
exclusivamente o roteador-LSAs; geralmente é definido como 0.
A Figura 5.16 mostra o conteúdo dos campos de descrição do link, para cada tipo de
interface que está sendo anunciado. Exceto para links virtuais, agora existem apenas
duas possibilidades: (i) interface para um link ponto-a-ponto (tipo 1) e (ii) interface para um
link compartilhado de trânsito (tipo 2). Assim como no OSPFv2, os links compartilhados
stub não possuem representação topológica. A consequência no OSPFv3 é que o Router-
LSAs não tem referência a este tipo de link.
5.7.2 Rede-LSA
O OSPFv3 Network-LSA, como o Router-LSA, é restrito a fornecer informações

topológicas e é o equivalente ao slink-NR. Ele descreve os links compartilhados de
trânsito, mas não os prefixos atribuídos a esse tipo de link. Assim, em comparação com
sua contraparte OSPFv2, o OSPFv3 Network-LSA não carrega mais o endereço base da
sub-rede e a máscara de sub-rede. Os roteadores conectados ao link compartilhado são
identificados por seus RIDs, no campo Attached Router. O link compartilhado é identificado
através do identificador do DR (Advertising Router) e do número da interface que conecta
o DR ao link (Link State ID).
5.7.3 Intra-Área-Prefixo-LSA
OSPFv3 introduziu o Intra-Area-Prefix-LSA para divulgar prefixos de endereço IPv6 e

relacioná-los com elementos topológicos; este LSA é o equivalente do aip-NR (ver Seção
2.2.2.2).

Como os prefixos são descritos? Os prefixos IPv6 são descritos pelo endereço IPv6 (prefixo
de endereço) e comprimento do prefixo (tamanho do prefixo). O LSA inclui um campo Métrico
para descrever os custos da interface, mas, conforme discutido na Seção 2.2.2.2, essa
informação só é relevante quando o LSA está anunciando prefixos atribuídos a links
compartilhados stub.
A associação entre prefixos e elementos de rede A associação entre prefixos e elementos
topológicos é feita relacionando cada Intra-Area-Prefix-LSA com um LSA topológico (Router-
LSA ou Network-LSA) usando três campos: o Referenced LS Type, o Roteador de publicidade
referenciado e o ID do estado do link referenciado. Esses três campos formam um ponteiro
ligando as informações de endereçamento e topológicas. O conteúdo de Referenced LS Type,
Referenced Advertising Router e Referenced Link State ID é igual ao conteúdo de LS Type,
Advertising Router e Link State ID do LSA topológico referenciado, respectivamente. O tipo
LS de roteador-LSAs e rede-LSAs são 0 × 2001 e 0 × 2002, respectivamente.
Os prefixos podem ser atribuídos a quatro tipos de elementos: (i) roteadores, (ii) ponto
links to-point, (iii) links compartilhados de trânsito e (iv) links compartilhados stub.
• Endereços atribuídos a roteadores - Um endereço IPv6 atribuído a um roteador é anunciado

por meio de um Intra-Area-Prefix-LSA apontando para seu roteador-LSA e tendo um custo
de interface igual a zero.
• Prefixos atribuídos a links ponto a ponto - Como em OSPFv2 e IS-IS, um prefixo atribuído a
um link ponto a ponto é anunciado pelos dois roteadores finais do link. No OSPFv3, cada
roteador origina um Intra-Area-Prefix-LSA descrevendo o prefixo, apontando para o Router-
LSA que descreve o roteador e incluindo o custo da interface com o link. A informação de
custo da interface é duplicada, pois já está presente no Roteador-LSAs correspondente.
• Prefixos atribuídos a links compartilhados de trânsito - Um prefixo atribuído a um link

compartilhado de trânsito é anunciado por meio de um Intra-Area-Prefix-LSA apontando
para a Rede-LSA que representa o link e tendo um custo de interface igual a zero.
O Intra-Area-Prefix-LSA, assim como o Network-LSA, é originado pelo link DR. Assim, ao
contrário do IS-IS, os prefixos atribuídos aos links compartilhados de trânsito precisam ser
anunciados apenas por um roteador (e não por todos os roteadores conectados ao link).
• Prefixos atribuídos a links compartilhados stub - Um prefixo atribuído a um link compartilhado

stub é anunciado por meio de um prefixo intra-área-LSA originado pelo único roteador
conectado ao link, apontando para seu roteador-LSA e contendo o custo da interface com
o link. As informações de custo da interface são necessárias neste caso, uma vez que os
links compartilhados do stub não são representados topologicamente (ou seja, por meio de
roteador-LSAs ou rede-LSAs).
Quantos prefixos um LSA pode anunciar? Um LSA pode anunciar mais de um prefixo, cujo
número é definido pelo campo Number of Prefixes. No entanto, esses prefixos devem se
referir ao mesmo LSA topológico, pois

os campos de ponteiro (Referenced Advertising Router, Referenced Link State ID e

campo Referenced LS Type) não podem ser repetidos em uma base de prefixo.
Identificação Intra-Area-Prefix-LSA Um roteador pode originar mais de um Intra-Area-
Prefix-LSA. Assim, este LSA requer que o campo Link State ID seja identificado de
forma única, além do tipo de LSA (LS Type) e o RID do AR (Advertising Router); o
campo Link State ID carrega uma tag gerada localmente, exclusiva para cada LSA
desse tipo originado pelo roteador.
Comparação entre IS-IS, OSPFv2 e OSPFv3 em relação à associação entre
endereçamento e informações topológicas -IS não estão incluídos na figura). No IS-
IS, a associação está implícita no fato de que um prefixo, descrito por um IP
Reachability TLV, está sempre associado a um roteador e incluído no Nonpseudonode-
LSP que descreve o roteador. Tanto no OSPFv2 quanto no OSPFv3, os prefixos
podem ser associados a roteadores e links, e não apenas a roteadores como no IS-
IS. No OSPFv2, a associação está implícita no fato de que o roteador-LSAs e a rede-
LSAs fornecem informações topológicas e de endereçamento. Os prefixos estão
incluídos no LSA topológico (Router LSA ou Network-LSA) que descreve o elemento
de rede (router ou link) ao qual estão associados. No OSPFv3, a associação é feita
através de um ponteiro que compreende três campos, e relaciona o Intra-Area-Prefix-
LSA que descreve o prefixo com o LSA topológico que descreve o elemento de rede
ao qual estão associados.

A Figura 5.11 compara a maneira como as informações topológicas e de
endereçamento são fornecidas no OSPFv2 e no OSPFv3. A informação topológica é
fornecida da mesma forma em OSPFv2 e OSPFv3, com apenas pequenas diferenças
no conteúdo dos LSAs e nas descrições dos links. A principal diferença está na forma
como as informações de endereçamento são fornecidas. No OSPFv2 é fornecido por
Router-LSAs e Network-LSAs, e no OSPFv3 é sempre fornecido por Intra-Area-Prefix
LSAs. Além disso, um prefixo IPv6 é associado ao elemento de rede ao qual foi
atribuído (roteador ou link) fazendo uma correspondência entre o Intra Area-Prefix-
LSA que descreve o prefixo e o LSA topológico (Router LSA ou Network-LSA) que
anuncia o elemento de rede. Assim, os prefixos atribuídos a roteadores, links ponto a
ponto e links compartilhados stub são associados a LSAs de roteador, e os prefixos
atribuídos a links compartilhados de trânsito são associados a LSAs de rede.

Roteador-LSA
Nonpseudonode-LSP
descrição do
link tipo 3
Acessibilidade interna de IP
Informações TLV ou IPv6
Acessibilidade TLV Rede-LSA
ID do estado do link e
máscara de rede
Referenciado
Tipo LS
Tipo LS
Referenciado
ID do estado do link
ID do estado do link
Referenciado
Roteador de Publicidade
Roteador de Publicidade
Prefixo de endereço e Roteador-LSA ou

Comprimento do prefixo Rede-LSA
Intra-Área-Prefixo-LSA
FIGURA 5.17: Associação entre endereçamento e informações topológicas em (a) IS-IS, (b)
OSPFv2 e (c) OSPFv3.
No OSPFv3, as informações topológicas são fornecidas por Router-LSAs e Network-

LSAs e as informações de endereçamento são fornecidas por Intra-Area-Prefix-LSAs.
Esses LSAs são equivalentes ao roteador NR, slink-NR e aip-NR, respectivamente.
O Intra-Area-Prefix-LSA descreve um ou mais prefixos IPv6 e possui um ponteiro
para o LSA topológico (Router-LSA ou Network-LSA) que descreve o elemento de
rede ao qual os prefixos foram atribuídos. Os LSAs topológicos e de cobertura de
anúncios podem ser disseminados separadamente, e essa é uma grande diferença
em relação aos TLVs IS-IS.
5.8 Informações de endereçamento externo ao domínio

As informações de endereçamento externo do domínio são injetadas em um domínio de
roteamento por meio de seus roteadores de borda de domínio. Conforme discutido na Seção
4.3, os roteadores de borda de domínio são chamados de ASBRs no caso de OSPF e são
chamados simplesmente de roteadores de borda no caso F de IS-IS. Os roteadores de borda
de domínio injetam no domínio de roteamento prefixos externos usando LSAs e TLVs
específicos (incluídos em Nonpseudonode-LSPs).

5.8 Informações de endereçamento externo ao domínio 175
5.8.1 OSPF
AS-External-LSA Tanto no OSPFv2 quanto no OSPFv3, os prefixos de domínio externo são
anunciados por meio do AS-External-LSA originado por um ASBR (consulte as Figuras 5.9 e
5.15). Este LSA é o equivalente ao dep-NR introduzido na Seção 2.2.4.
Como os prefixos são descritos? No OSPFv2, o endereço de domínio externo da sub-rede e a

máscara de sub-rede são carregados nos campos Link State ID e Network Mask, e no OSPFv3
nos campos Address Prefix e Prefix Length.
Quantos prefixos um LSA pode anunciar? Cada AS-External-LSA só pode transportar
informações relativas a um prefixo de endereço.
Distinguindo entre LSAs originados pelo mesmo ASBR No OSPFv3, o Link State ID é uma tag
gerada localmente que distingue entre vários AS-External-LSAs originados pelo mesmo ASBR.
No OSPFv2, essa distinção está implícita no fato de que o Link State ID carrega o endereço
IPv4 que está sendo anunciado.
Referindo-se a outros LSAs no OSPFv3 O Referenced LS Type e o Referenced Link State ID

do OSPFv3 AS-External-LSAs fornecem a capacidade de referenciar outros LSAs. No entanto,
essa capacidade ainda não foi definida e, até lá, o Referenced LS Type deve ser definido como
zero e o Referenced Link State ID não deve ser incluído.
Injetando rotas padrão O AS-External-LSA também pode ser usado para anunciar rotas padrão
(0.0.0.0/0) dentro de um AS, injetadas pelo ASBR.
Um comentário sobre as designações OSPF Como já mencionado na Seção 4.3.1, as
designações usadas pelo OSPF em relação às informações de endereçamento externo do
domínio são enganosas. O roteador de borda de domínio é chamado de ASBR, mesmo que
esteja interconectando domínios de roteamento pertencentes ao mesmo AS. Além disso, a
designação “AS-External-LSA” esconde o facto de este tipo de LSA poder ser utilizado para
anunciar prefixos externos pertencentes ao AS onde o LSA está a ser divulgado.
Nas Seções 9.2.2, 9.2.3.1 e 9.2.5 mostramos experimentos que destacam as características
da estrutura OSPFv2 LSDB com informações de endereçamento externo ao domínio, vindo ou
não do mesmo AS e incluindo ou não rotas padrão.
5.8.2 IS-IS
TLVs de acessibilidade externa de IP No IS-IS, os prefixos externos de domínio IPv4 são
anunciados por meio do TLV de informações de acessibilidade externa de IP (tipo 130) ou TLV
de acessibilidade de IP estendido (tipo 135) e os prefixos externos de domínio IPv6 por meio
do TLV de acessibilidade de IPv6 (tipo 236). Esses TLVs são equivalentes ao dep-NR introduzido
na Seção 2.2.4 e estão incluídos nos Nonpseudonode-LSPs originados pelos roteadores de
borda. os dois últimos

Os TLVs (tipo 135 e tipo 236) também são usados para anunciar prefixos internos de
domínio, conforme discutido na Seção 5.6.2.
Como os prefixos são descritos? O prefixo é identificado por meio dos campos Endereço
IP e Máscara de sub-rede (em TLVs de informações de acessibilidade externa de IP) e
por meio dos campos Prefixo e Comprimento do prefixo (em TLVs de acessibilidade de
IP estendida e TLVs de acessibilidade de IPv6).
No IPv6 Reachability TLV, o sinalizador X indica se o prefixo anunciado é interno
ou externo ao domínio. O Extended IP Reachability TLV não faz distinção entre esses
dois tipos de prefixos.
Injetando rotas padrão Esses TLVs também podem ser usados para anunciar rotas
padrão (0.0.0.0/0) dentro de um AS, injetadas pelo roteador de borda.
Nas Seções 9.2.2.1 e 9.2.3.1 , mostramos experimentos que destacam os recursos
da estrutura IS-IS LSDB com informações de endereçamento externo ao domínio e
com rotas padrão.
5.8.3 Métricas OSPF tipo E

No OSPF, o campo Metric de AS-External-LSAs carrega um custo externo associado
ao prefixo anunciado (consulte a Seção 2.2.4). Este custo pode ser interpretado como
o custo do subcaminho externo, desde o ASBR que origina o LSA até o prefixo externo.
O OSPF considera dois tipos de métrica para determinar o caminho externo, chamados
de tipo E1 e tipo E2, e o AS-External-LSAs inclui um sinalizador, o sinalizador E, para
distingui-los. O sinalizador E define como os roteadores internos devem calcular o custo
do caminho em direção a um prefixo externo. Se a métrica for do tipo E1 (bandeira E
definida como 0), o custo para o prefixo externo é obtido adicionando o custo do
subcaminho interno (o custo do caminho mais curto do roteador interno ao ASBR que
injetou o LSA) e o custo externo anunciado pela LSA; o caminho calculado dessa forma
é chamado de rota externa E1. Caso contrário, se a métrica for do tipo E2 (bandeira E
definida como 1), o custo simplesmente será igual ao custo externo anunciado pelo
LSA e o custo do subcaminho interno será ignorado; o caminho calculado dessa
maneira é chamado de rota externa E2. As rotas E2 sempre cruzam o ASBR que
anuncia o menor custo externo para um prefixo externo. O tipo de métrica e o valor de
custo externo são configurados nos ASBRs.
Ilustramos o uso da métrica E-type do OSPF nos experimentos da Seção 9.2.4.
ASBRs injetam informações de endereçamento de domínio externo no

domínio de roteamento usando AS-External-LSAs (no caso de OSPF), TLVs
de informações de acessibilidade externa de IP ou TLVs de acessibilidade de
IP estendida (no caso de IPv4 IS-IS) ou TLVs de acessibilidade de IPv6 (no
caso de IPv6 IS IS); estes são o equivalente ao dep-NR. No OSPF, os ASBRs
atribuem um custo externo e um tipo de métrica (E1 ou E2) para cada prefixo
externo anunciado; o tipo de métrica indica se o custo do subcaminho interno
deve ou não ser considerado na seleção do caminho fim a fim.

5.9 Informações do link 177
5.9 Informações do link
As informações do link são trocadas dentro do link para fornecer a cada roteador os
endereços da camada de link necessários para transportar pacotes para o roteador do próximo salto.
Esta questão foi discutida na Seção 2.2.3. Diferentes tecnologias lidam com esse problema
de maneira diferente.
OSPFv2 No OSPFv2, o Roteador-LSA anuncia os endereços IPv4 das interfaces do roteador
no campo Link ID das descrições de link tipo 1 e tipo 2.
Assim, um Roteador-LSA originado por um roteador fornece aos seus roteadores vizinhos
os endereços IPv4 que devem ser usados como endereços de próximo salto da camada 3;
os endereços correspondentes da camada de enlace são obtidos por meio do protocolo ARP.
O Link-LSAs do OSPFv3 O OSPFv3 inclui o Link-LSA para auxiliar nesse processo, que é o
equivalente ao la-NR apresentado na Seção 2.2.3. É a única tecnologia para fazê-lo. O Link-
LSA é inundado apenas dentro do link, ou seja, tem escopo de inundação de link. O formato
do Link-LSA é mostrado na Figura 5.15. Cada LSA anuncia o endereço de link local IPv6
atribuído à interface, no campo Link-Local Interface Address. Lembre-se de que, no IPv6, o
endereço do próximo salto da camada 3 é precisamente o endereço local do link IPv6, e o
endereço da camada 2 é obtido por meio do processo de descoberta de vizinhos (consulte
o Capítulo 4 de [17]). Ao contrário do la-NR introduzido na Seção 2.2.3, o Link-LSA não inclui
o identificador do link onde os endereços serão usados. Em vez disso, inclui, no campo Link
State ID, o identificador da interface de origem, que deve ser correlacionado com o
identificador de interface incluído em Router-LSAs (Interface ID) e Network-LSAs (Link State
ID) para identificar o link.
Na Seção 9.2.1.2, mostramos experimentos que destacam os recursos do

OSPFv3 Link-LSAs.
Anunciando prefixos IPv6 configurados usando Link-LSAs O Link-LSA também inclui

informações sobre os prefixos IPv6 atribuídos a uma interface. Os prefixos são definidos por
(i) endereço do prefixo (Address Prefix) e (ii) comprimento do prefixo (Prefix Length). Esse
recurso introduz uma flexibilidade muito poderosa e elegante no OSPFv3, muito no espírito
da separação entre informações topológicas e de endereçamento: um prefixo IPv6 atribuído
a um link só precisa ser declarado em uma das interfaces anexadas ao link, pois o O Link-
LSA se encarrega de disseminar esse prefixo entre as interfaces vizinhas. Por exemplo, um
prefixo IPv6 atribuído a um link compartilhado não precisa ser configurado no DR do link,
mas pode ser configurado em qualquer outra interface anexada ao link.
Essa interface comunica as informações de prefixo ao DR por meio do Link-LSA que ele
divulga no link (e o DR então anuncia o prefixo para a rede restante por meio de um Intra-
Area-Prefix-LSA).
Esta característica será ilustrada no experimento da Seção 9.2.1.3.
IS-IS No IS-IS, as informações do link são transmitidas por meio de pacotes HELLO, usando
o endereço de interface IP TLV (em IPv4 IS-IS) ou o anúncio de interface IPv6

vestido TLV (em IPv6 IS-IS). O endereço de interface IP TLV carrega o endereço IPv4
atribuído à interface que envia o OLÁ, e o endereço de interface IPv6 TLV carrega o
endereço local de link IPv6. No entanto, os pacotes HELLO, apesar de terem um enlace
de escopo local, não são o melhor veículo para este tipo de informação. Esses pacotes
são transmitidos periodicamente, usando períodos curtos para permitir uma manutenção
granular das relações de vizinhança. Eles só precisam incluir identificadores topológicos
e não o endereçamento mais pesado na formação, que é transmitido com muito mais
frequência do que o necessário. É exatamente por isso que o OSPFv3 manteve o uso
de endereços IPv4 (na verdade, seus identificadores topológicos) em pacotes HELLO.
Os endereços dos links são fornecidos pelo Link-LSA no OSPFv3, sendo esta
a única tecnologia a divulgar essas informações em uma NR separada; é o
equivalente a la-NR. No OSPFv2, os endereços dos links são obtidos dos
Roteadores-LSAs, e no IS-IS eles são transmitidos periodicamente pelos
roteadores vizinhos em pacotes HELLO.

6
Sincronização OSPF e IS-IS
Mecanismos
O LSDB deve ser mantido atualizado e sincronizado em todos os roteadores de um

domínio de roteamento. Existem três mecanismos de sincronização: (i) o protocolo
Hello, (ii) o procedimento de inundação e (iii) o processo inicial de sincronização do
LSDB. Esses mecanismos são suportados na troca de pacotes de controle entre os
roteadores. O protocolo Hello é usado para estabelecer e manter relacionamentos de
vizinhança, para determinar se dois vizinhos devem sincronizar seus LSDBs e para
eleger o roteador designado de links compartilhados. O procedimento de flooding
dissemina pela rede os LSAs/LSPs originados por um roteador. Este procedimento
pode instalar, atualizar ou excluir LSAs/LSPs na rede. Por fim, a sincronização inicial
do LSDB é o processo de troca de informações de roteamento entre dois roteadores
que acabaram de estabelecer um relacionamento de vizinhança, para garantir que seus
LSDBs sejam sincronizados.
Estrutura do capítulo Começamos apresentando, na Seção 6.1, os pacotes de controle

de OSPF e IS-IS. O protocolo Hello e a escolha do roteador designado são discutidos
nas seções 6.2 e 6.3. Em seguida, a Seção 6.4 explica como as informações de
roteamento são disseminadas e a Seção 6.5 explica como elas são atualizadas. O
processo inicial de sincronização do LSDB é abordado na Seção 6.6. Por fim, a Seção
6.7 discute quando as informações de roteamento devem ser originadas e excluídas.
6.1 Pacotes de controle

6.1.1 Tipos de pacotes
OSPF e IS-IS usam tipos de pacotes de controle ligeiramente diferentes, que também
não coincidem com os tipos de pacotes do protocolo genérico apresentado no Capítulo
2. A correspondência entre os vários tipos de pacotes de controle é mostrada na Figura
6.1. Na especificação IS-IS [1], os pacotes de controle são chamados de Protocol Data
Units (PDUs). Observe que as designações dos tipos de pacote de controle são as
mesmas nas versões IPv4 e IPv6 de ambos os protocolos.
O OSPF tem cinco tipos de pacotes de controle e o IS-IS tem quatro. O formato
dos pacotes de controle usados em OSPFv2, OSPFv3 e IS-IS é mostrado nas Figuras 6.2,
179

180 6 Mecanismos de Sincronização OSPF e IS-IS
genérico OSPF IS-IS
L1 LAN IS-IS HELLO (tipo 15)
OLÁ OLÁ (tipo 1) L2 LAN IS-IS HELLO (tipo 16)
PONTO A PONTO IS-IS HELLO (tipo 17)
L1 LINK STATE PDU (tipo 18)

ATUALIZAR ou EXCLUIR ATUALIZAÇÃO LS (tipo 4)
L2 LINK STATE PDU (tipo 20)
L1 PSNP (tipo 26)

ACK (ATUALIZAÇÃO) ou
LS ACK (tipo 5)
ACK (EXCLUIR)
L2 PSNP (tipo 27)
LSDB PARCIAL L1 PSNP (tipo 26)

PEDIDO LS (tipo 3)
SOLICITAR
L2 PSNP (tipo 27)
L1 CSNP (tipo 24)

RESUMO DO LSDB DESCRIÇÃO DO BD (tipo 2)
L2 CSNP (tipo 25)
FIGURA 6.1: Correspondência entre os pacotes de controle do protocolo genérico, OSPF e

IS-IS.
6.3 e 6.4, respectivamente. Como no caso de LSAs e LSPs, os campos ou grupos de

campos que podem se repetir em um pacote são circundados por um retângulo em negrito.
Pacotes Hello Tanto o OSPF quanto o IS-IS usam pacotes HELLO para dar suporte ao
protocolo Hello (consulte a Seção 2.1). No OSPF, o pacote é chamado simplesmente de
HELLO. No IS-IS, existem dois tipos ligeiramente diferentes de pacotes HELLO, um para
links ponto a ponto, chamado POINT-TO-POINT IS-IS HELLO (ou POINT-TO-POINT IIH), e
outro para links compartilhados, chamado LAN IS-IS HELLO (ou LAN IIH).
Como os tipos de pacotes são identificados? No IS-IS, exceto para um tipo de pacote
HELLO, existem tipos de pacotes separados para pacotes transmitidos/recebidos pelas
interfaces L1 e L2. No entanto, as versões L1 e L2 possuem exatamente a mesma estrutura.
Os vários tipos de pacotes, incluindo a distinção entre as versões L1 e L2, são identificados
através do campo PDU Type (5 bits) do cabeçalho do pacote. Em pacotes IS-IS HELLO
PONTO A PONTO esta distinção é feita no campo Circuit Type. Na Figura 6.3 incluímos os
TLVs usados exclusivamente em pacotes de controle IS-IS. Esses TLVs são: (i) o IS
Neighbors TLV do tipo 6, (ii) o LSP Entries TLV (tipo 9) e (iii) o TLV de adjacência de três
vias ponto a ponto (tipo 240). Os TLVs usados tanto em pacotes de controle IS-IS quanto
em LSPs foram apresentados na Figura 5.12. No OSPFv2 e OSPFv3, o tipo de pacote é
identificado por meio do campo Tipo do cabeçalho do pacote.
Disseminação da informação de roteamento A disseminação da informação de roteamento

é realizada, no protocolo genérico, pelos pacotes UPDATE e DELETE (ver Seção 2.4.7). Os
pacotes UPDATE transportam as instâncias mais recentes de LSAs/LSPs e os pacotes
DELETE transportam as indicações para excluí-los.

6.1 Pacotes de controle 181
Versão 1 máscara de rede 4 Interface MTU 2
Tipo 1 AlôIntervalo 2 Opções 1
M
Comprimento do pacote 2 Opções 1 0 0 0 0 0 IM 1
S
ID do roteador 4 Prioridade do roteador 1 Número de Sequência DD 4
ID da área 4 RouterDeadInterval 4 Cabeçalho LSA 20
soma de verificação 2 Roteador Designado 4

DESCRIÇÃO DO BD
AuType 2 Roteador designado de backup 4

Tipo de estado do link 4
Autenticação 8 Vizinho 4
ID do estado do link 4
Cabeçalho da mensagem OSPFv2 OLÁ

Roteador de Publicidade 4
Número de LSAs 2 Cabeçalho LSA 20

LS PEDIDO
LSA v
LS RECONHECIMENTO
LS ATUALIZAÇÃO
FIGURA 6.2: Formato dos pacotes OSPFv2.
No entanto, tanto o OSPF quanto o IS-IS usam um único pacote para executar essas duas
funções, chamado LS UPDATE no OSPF e LINK STATE PDU no IS-IS.
Confusão entre “pacotes LSP” e “registros LSP” Ao contrário do OSPF, onde há uma distinção
clara entre os LSAs e os pacotes que os transportam de roteador para roteador (ou seja, os
LS UPDATEs), no IS-IS não há essa distinção: ambos são chamados de PDUs de estado de
link e abreviados como LSPs. Isso ocorre porque um “pacote LSP” só pode transportar um
“registro LSP” e a estrutura de “pacotes LSP” e “registros LSP” é a mesma. Para evitar
confusão, nos referiremos aos “pacotes LSP” como LINK STATE PDUs (usando letras
maiúsculas), sempre que necessário.
Pacotes de confirmação No OSPF, a recepção de um LSA é confirmada por meio de um

pacote LS ACKNOWLEDGMENT. No IS-IS, a recepção de um LSP é confirmada por meio de
um NÚMERO DE SEQUÊNCIA PARCIAL PDU (PSNP para abreviar), mas apenas no caso
de links ponto a ponto. Em links compartilhados, a recepção de LSPs é implicitamente
reconhecida por meio da transmissão periódica de COMPLETE SEQUENCE NUMBER
PDUs (CSNPs, para abreviar).
Esta questão será discutida na Seção 6.4.2.
Anunciando o resumo LSDB A publicidade do resumo LSDB é realizada por pacotes DB

DESCRIPTION em OSPF e CSNPs em IS-IS. Esses pacotes carregam informações resumidas
sobre todos os LSAs/LSPs contidos no LSDB. Eles são equivalentes ao LSDB SUMMARY do
protocolo genérico.
Solicitando LSAs e LSPs específicos A solicitação do conteúdo completo de instâncias

específicas de LSA e LSP é feita por meio de pacotes LS REQUEST no OSPF

Protocolo de Roteamento Intradomínio O circuito

1 Comprimento da PDU 2 Reservado 1
Discriminador Tipo
Indicador de comprimento 1 Vida útil restante 2 ID da fonte 6
ID do protocolo 1 ID da fonte 6 Temporizador de espera 2
Comprimento do ID 1 ID do pseudonó 1 Comprimento da PDU 2
RRR 1 Número LSP 1 R Prioridade 1
Versão 1 Número sequencial 4 ID da LAN 7
Reservado 1 soma de verificação 2 TLVs v
O É
Endereços de área máxima 1 P ATT 1
eu Tipo LAN OLÁ PDU
TLVs v
cabeçalho da mensagem IS-IS O circuito
Reservado 1
Tipo
LINK ESTADO PDU
Comprimento da PDU 2 ID da fonte 6
ID da fonte 7 Comprimento da PDU 2 2

Temporizador de espera
Iniciar ID do LSP 8 ID da fonte 7 2

Comprimento da PDU
Terminar ID do LSP 8 TLVs v ID do circuito local 1
TLVs v SEQUÊNCIA PARCIAL TLVs v

NÚMERO PDU (CSNP)
SEQUÊNCIA COMPLETA OLÁ PONTO A PONTO
NÚMERO PDU (CSNP) Tipo = 240 1 PDU
Tipo = 9 Comprimento 1 1
1 Tipo = 6
Comprimento Estado de três vias de adjacência 1 1

1 Comprimento
Vida útil restante ID de circuito local estendido 4 Endereço LAN 6

2
ID LSP ID do sistema vizinho v

8 IS-IS vizinhos TLV
Circuito local estendido vizinho
Número de Sequência LSP 4
4 EU IA
soma de verificação
2 Ponto a ponto de três vias
Adjacência TLV
LSP Entradas TLV
FIGURA 6.3: Formato dos pacotes IS-IS.
e através de PSNPs em IS-IS. No entanto, no IS-IS, os PSNPs assumem essa função

apenas em links compartilhados; conforme referido acima, são utilizados como
reconhecimentos em ligações ponto-a-ponto. Esses pacotes são equivalentes ao
PARTIAL LSDB RE QUEST do protocolo genérico.
Diferenças entre os tipos de pacote OSPFv2 e OSPFv3 Os pacotes de controle OSPFv2
e OSPFv3 têm uma estrutura muito semelhante. As principais diferenças do OSPFv3
em relação ao OSPFv2 são (i) a inclusão do Instance ID e a remoção dos campos de
autenticação no cabeçalho do pacote e (ii) a remoção da Máscara de Rede nos pacotes
HELLO.
Pacotes de controle que carregam apenas informações resumidas sobre LSAs e LSPs
Exceto para LS UPDATE de OSPF e LINK STATE PDU

6.1 Pacotes de controle 183
Versão 1 ID da interface 4 Opções 3
Tipo 1 Prioridade do roteador 1 Interface MTU 2
M
Comprimento do pacote 2 Opções 3 0 0 0 0 0 IM 1
S
ID do roteador 4 AlôIntervalo 2 Número de Sequência DD 4
ID da área 4 RouterDeadInterval 2 Cabeçalho LSA 20
soma de verificação 2 ID do roteador designado 4

DESCRIÇÃO DO BD
ID da instância 2 ID do roteador designado de backup 4

Tipo de estado do link 2
Identificação do vizinho 4
Cabeçalho da mensagem OSPFv3 ID do estado do link 4
OLÁ 4
Número de LSAs 2 Roteador de Publicidade
LSA v Cabeçalho LSA 20

LS PEDIDO
LS ATUALIZAÇÃO LS RECONHECIMENTO
FIGURA 6.4: Formato dos pacotes OSPFv3.
do IS-IS que carrega uma nova instância LSP, todos os outros pacotes de controle carregam
apenas informações resumidas sobre LSAs e LSPs.
• Em IS-IS, indicações para deletar LSPs (transportados em LINK STATE PDUs)

carregam apenas o cabeçalho LSP (o mesmo não ocorre no OSPF).
• No OSPF, os pacotes LS ACKNOWLEDGMENT e DB DESCRIPTION carregam apenas

cabeçalhos LSA; os pacotes LS REQUEST carregam apenas o LSA ID, ou seja, os campos
LS Type, Link State ID e Advertising Router.
• No IS-IS, os PSNPs e CSNPs carregam apenas resumos LSP descritos através do LSP
Entries TLV, que inclui os campos LSP ID, Sequence Number e Remaining Lifetime.
Lidando com resumos LSDB grandes Um diferencial dos CSNPs é que eles estão preparados
para lidar com LSDBs de grande porte, cujo sumário não cabe em um único CSNP. Nesse
caso, o resumo do LSDB é fragmentado e cada fragmento é transportado em um CSNP
diferente. O controle desse processo é feito através dos campos Start LSP ID e End LSP ID
dos CSNPs. Especificamente, se vários CSNPs forem necessários para transportar o LSDB
completo
resumo:
• o Start LSP ID do primeiro CSNP é definido como 0000.0000.0000.00-00;
• o End LSP ID do último CSNP é definido como ffff.ffff.ffff.ff-ff;
• para todos os outros CSNPs, o Start LSP ID e o End LSP ID são definidos como o LSP ID
do primeiro e do último LSPs contidos no CSNP (e descritos nas LSP Entries TLV
correspondentes).

Observe que, se o LSDB caber em um único CSNP, o Start LSP ID e o End LSP ID serão
definidos como 0000.0000.0000.00-00 e ffff.ffff.ffff.ff-ff, respectivamente. No OSPF, esse
problema é tratado enviando vários pacotes DB DE SCRIPTION, cada um com um
fragmento do resumo LSDB, durante o processo inicial de sincronização do LSDB (consulte
a Seção 6.6).
6.1.2 Encapsulamento Os
pacotes OSPF são encapsulados em pacotes IP (IPv4 ou IPv6) usando o protocolo IP

número 89. Os pacotes IS-IS são encapsulados diretamente nos quadros da camada 2; por
exemplo, em LANs Ethernet, eles são encapsulados em quadros 802.3 com um valor LSAP
de 0×fefe.
6.1.3 Endereços multicast usados em links compartilhados
No IS-IS, os pacotes de controle transmitidos em links compartilhados usam endereços

multicast da camada 2. Os pacotes do tipo L1 usam o endereço AllL1ISs (01:80:c2:00:00:14)
e os pacotes do tipo L2 usam o endereço AllL2ISs (01:80:c2:00:00:15). No OSPF, os
pacotes de controle transmitidos em links compartilhados podem ser unicast ou usar um
dos dois endereços multicast: o endereço AllSPFRouters (224.0.0.5 para IPv4 e ff02::05
para IPv6) ou o endereço AllDRouters (224.0.0.6 para IPv4 e ff02::6 para IPv6). As
circunstâncias em que cada tipo de endereço é usado ficarão claras na Seção 6.4.
6.1.4 Regras de aceitação da interface
Para que um pacote seja aceito em uma interface, diversas condições devem ser satisfeitas,
além daquelas que devem ser observadas nas camadas inferiores.
Por exemplo, em relação à aceitação em camadas inferiores, um pacote IPv4 só pode ser
entregue a um processo OSPFv2 se (i) o endereço IPv4 de destino for o endereço IPv4 da
interface receptora ou um dos dois endereços multicast IPv4 atribuídos ao protocolo
(AllSPFRouters ou AllDRouters), (ii) o número do protocolo IP é 89 e (iii) a soma de
verificação do IP está correta.
As regras de aceitação dependem dos parâmetros específicos associados a uma
interface. Por exemplo, no OSPF cada interface é atribuída a uma área e no IS-IS cada
interface é atribuída a um tipo (somente L1, somente L2 ou L1/L2), e essas configurações
determinam se um pacote pode ser aceito ou não . As regras de aceitação podem ser
genéricas, ou seja, podem ser aplicadas a qualquer tipo de pacote, ou podem ser aplicadas
apenas a tipos de pacotes específicos.
OSPFv2 No OSPFv2, um pacote só pode ser aceito em uma interface se (i) o número da
versão do protocolo fornecido pelo campo Versão for 2, (ii) o campo Area ID corresponder
ao Area ID configurado para a interface, (iii) o IP endereço multicast de destino está de
acordo com o estado da interface (roteadores não DR/BDR não podem aceitar pacotes
destinados ao endereço AllDRouters), (iv) o OSPF

a soma de verificação está correta e (v) o pacote está autenticado (caso a autenticação
seja necessária). As regras acima são válidas para todos os tipos de pacotes. Além
disso, pacotes HELLO só são aceitos se Network Mask, HelloInterval e RouterDeadInterval
corresponderem aos valores configurados para a interface. A verificação da máscara de
rede não é necessária no caso de links ponto a ponto.
OSPFv3 As condições de aceitação do OSPFv3 possuem algumas diferenças em relação
ao OSPFv2. O número da versão (que agora deve ser 3), o ID da área, o endereço
multicast de destino IP e a soma de verificação também devem ser verificados. Além
disso, o campo Instance ID deve corresponder a um dos Instance IDs configurados para
a interface. A autenticação não é mais feita pelo protocolo OSPF; O OSPFv3 depende
dos recursos de autenticação do protocolo IPv6, por exemplo, através do cabeçalho de
autenticação IP (consulte o Capítulo 5 de [17]). Além dessas condições, pacotes HELLO
só são aceitos se HelloInterval e RouterDeadInterval corresponderem aos valores
configurados para a interface, como em OSPFv2. Ao contrário do OSPFv2, OSPFv3
HELLOs não carregam uma máscara de rede.
IS-IS No IS-IS, um pacote só pode ser aceito em uma interface se (i) o checksum do IS-
IS estiver correto e (ii) o pacote for autenticado (caso a autenticação seja necessária). A
aceitação também depende do tipo de interface: as interfaces somente L1 aceitam
apenas pacotes L1 e as interfaces somente L2 aceitam apenas pacotes L2.
As regras acima são válidas para todos os tipos de pacotes. Além disso, os PSNPs
transmitidos em links compartilhados são aceitos apenas pelo link DIS e devem ser
rejeitados por todos os roteadores não DIS conectados ao link. Observe que, ao contrário
do OSPF, as interfaces IS-IS não são atribuídas a áreas específicas, pois os identificadores
de área são atribuídos a roteadores e não a interfaces. Assim, os roteadores IS-IS não
restringem a aceitação de pacotes em interfaces com base nas informações de área.
Qual o proximo? Quando pacotes HELLO são aceitos em uma interface baseada nas
regras descritas acima, eles devem ser entregues ao processo roteador que lida com o
protocolo Hello (ver Seção 6.2). Outros tipos de pacotes de controle são processados
apenas se a interface receptora já estiver adjacente à interface que enviou o pacote. As
condições para duas interfaces se tornarem adjacentes serão explicadas na Seção 6.2.3.

Tanto no OSPF quanto no IS-IS, os roteadores estabelecem e mantêm relações de
vizinhança em interfaces específicas usando o protocolo Hello, que foi discutido na Seção
2.1. Este protocolo permite (i) saber que um vizinho existe e está vivo e (ii) determinar o
tipo de relacionamento que pode ser estabelecido com o vizinho. O protocolo Hello
também é utilizado para eleger o DR, processo que será discutido na Seção 6.3.

6.2.1 Formato do pacote
Conforme referido na Secção 6.1, o OSPF utiliza um único tipo de pacote HELLO, e o
IS-IS utiliza dois tipos ligeiramente diferentes, um para ligações ponto-a-ponto (POINT
TO-POINT IS-IS HELLO) e outro para ligações LAN (LAN É-É OLÁ).
O formato desses pacotes é mostrado nas Figuras 6.2, 6.3 e 6.4. Além disso, IS-IS
HELLOs são diferenciados de acordo com o tipo de interface (L1 ou L2), utilizando o
campo PDU Type no caso de LAN IS-IS HELLOs e o campo Circuit Type no caso de
POINT-TO-POINT IS- É OLÁ. L1 LAN IS-IS HELLOs têm um tipo de PDU de 15 e L2
LAN IS-IS HELLOs têm um tipo de PDU de 16. Em POINT-TO-POINT IS-IS HELLOs, o
campo Circuit Type indica o tipo de interface que transmite o pacote : 1 significa apenas
L1, 2 significa apenas L2 e 3 significa L1/L2.
Identificação do vizinho Os pacotes HELLO incluem os identificadores do roteador que

envia o pacote e de seus vizinhos. No OSPF, o roteador de envio e os vizinhos são
identificados por meio de seus RIDs, carregados nos campos Router ID e Neighbor,
respectivamente.
No IS-IS, o roteador de envio é identificado por seu SID, incluído no cabeçalho do
pacote. No entanto, a maneira como os vizinhos são identificados difere em links ponto
a ponto e compartilhados. Nos pacotes LAN IS-IS HELLO (transmitidos em links
compartilhados), os vizinhos são identificados através dos endereços da camada 2
atribuídos às suas interfaces com o link, transportados em um IS Neighbors TLV do tipo
6. Assim, o IS-IS não use identificadores topológicos (ou seja, endereços NSAP) para
identificar vizinhos em pacotes LAN IS-IS HELLO.
Nos pacotes IS-IS HELLO PONTO A PONTO (transmitidos em enlaces ponto a
ponto), os vizinhos não são explicitamente identificados. Para atingir o objetivo de
verificar a bidirecionalidade das comunicações, os pacotes HELLO anunciam o estado
da interface de envio usando o TLV de adjacência de três vias ponto a ponto. Esta
questão será discutida com mais detalhes na Seção 6.2.6.
Os pacotes HELLO de informações de área também incluem informações de área, o
que é importante para determinar se as adjacências podem ser estabelecidas (consulte
a Seção 6.2.3). No OSPF, cada interface é atribuída a uma área específica, e os pacotes
HELLO enviados por uma interface indicam, no campo Area ID, a área à qual a
interface pertence. No IS-IS, as áreas são atribuídas a roteadores e não a interfaces, e
mais de uma área pode ser atribuída a um único roteador. Os pacotes IS-IS HELLO
indicam, nos Endereços de Área TLV, as áreas às quais um roteador pertence.
TLVs IS-IS Obrigatórios dos pacotes HELLO Os pacotes IS-IS HELLO devem incluir
também os Protocolos Suportados TLV, e o Endereço de Interface IP TLV (IPv4) ou
Endereço de Interface IPv6 TLV (IPv6), além dos TLVs mencionados acima, ou seja, a
Área Endereços TLV, IS Neighbors TLV do tipo 6 (links compartilhados) e TLV de
adjacência de três vias ponto a ponto (links ponto a ponto).
Pacotes OSPFv2 versus OSPFv3 HELLO Ao contrário do OSPFv2, os pacotes OSPFv3

HELLO incluem o número da interface de envio no campo Interface ID. A principal
utilização desta informação é na identificação

de links compartilhados. Lembre-se que (i) um dos papéis do protocolo HELLO é

permitir que o DR anuncie o identificador de link compartilhado, e que (ii) os links
compartilhados sejam identificados no OSPFv3 por meio dos identificadores do DR e
da interface DR anexada ao link (consulte a Seção 5.2.2). Os OSPFv3 HELLOs
carregam o identificador DR no campo Designated Router ID e, conforme mencionado
acima, o identificador de interface no campo Interface ID.
Os pacotes OSPFv3 HELLO também incluem mais espaço para opções (três
octetos contra um octeto no OSPFv2). Por fim, a Máscara de Rede foi removida, pois
nenhuma informação de endereçamento precisa ser transportada nesses pacotes.
6.2.2 Vivacidade dos relacionamentos

A verificação da vivacidade dos relacionamentos de vizinhança é feita (i) pela
transmissão periódica de pacotes HELLO e (ii) verificando se o vizinho continua
transmitindo pacotes HELLO.
O processo de verificação da vivacidade das relações de vizinhança será
ilustrado através de experimentos na Seção 10.1.1.
Periodicidade das transmissões HELLO No OSPF, a periodicidade das transmissões
HELLO é chamada de HelloInterval e tem um valor padrão de 10 segundos.
No IS-IS, a periodicidade das transmissões HELLO pode diferir no DIS e em outros
roteadores. A periodicidade é chamada dRISISHelloTimer no DIS e iSISHelloTimer em
roteadores não DIS; os valores típicos são 3 e 10 segundos, respectivamente [12].
Quando um vizinho é considerado morto? Uma interface considera um relacionamento

de vizinhança como ativo desde que continue recebendo pacotes HELLO do vizinho.
O tempo até que um relacionamento seja declarado morto, ao deixar de receber
pacotes HELLO de um vizinho, é chamado de RouterDeadInterval em OSPF e Holding
Timer em IS-IS. O padrão OSPF recomenda que o RouterDeadInterval seja 4 vezes o
HelloInterval, e o padrão IS-IS afirma que o Holding Timer deve ser 10 vezes o valor
do iSISHelloTimer; no entanto, as implementações IS-IS usam um valor de 3. Em IS-
IS, diferentes valores de Temporizador de Retenção podem ser usados para as
relações com o DIS e com roteadores não DIS; os valores típicos são 10 e 30
segundos, respectivamente. Ter um valor de Hold Timer menor para os relacionamentos
DIS permite uma recuperação mais rápida no caso de falha do DIS.
Os valores RouterDeadInterval (OSPF) e Holding Timer (IS-IS) são anunciados em

pacotes HELLO. A interpretação deste parâmetro quando anunciado por um roteador
é “considere-me morto se você não receber alôs de mim por mais do que este tempo”.
No OSPF, o HelloInterval também está incluído nos pacotes HELLO. Tanto o
RouterDeadInterval quanto o Hold Timer são expressos em segundos e têm um valor
mínimo de 1 segundo. Isso define um limite na rapidez com que os roteadores podem
se recuperar de falhas.
No OSPF, alterar os valores HelloInterval e RouterDeadInterval é uma tarefa difícil,
devido às regras de aceitação da interface (ver Seção 6.1.4).

FIGURA 6.5: Condições para se tornar adjacente, relacionadas ao tipo de interface

e à informação da área.
Especificamente, um pacote HELLO recebido em uma interface que não corresponde

aos valores HelloInterval e RouterDeadInterval configurados é imediatamente
rejeitado. Assim, ao alterar esses valores, todos os roteadores conectados ao mesmo
link devem ser reconfigurados ao mesmo tempo, para evitar a interrupção do serviço.
IS-IS é muito mais flexível a esse respeito.
6.2.3 Adjacências
Uma das funções do protocolo Hello é determinar se dois vizinhos podem se tornar
adjacentes. Somente se dois vizinhos forem adjacentes, a conexão entre eles
poderá fazer parte do mapa de rede. Existem duas condições básicas para se tornar
adjacente: (i) os pacotes Hello trocados entre os vizinhos devem obedecer às regras
de aceitação de interface descritas na Seção 6.1.4; (ii) a comunicação entre os
vizinhos deve ser bidirecional. No entanto, condições adicionais podem ser
necessárias. Além disso, tanto o OSPF quanto o IS-IS suportam diferentes tipos de
adjacências. Essas questões serão discutidas nas próximas seções. A Figura 6.5
resume as condições, relacionadas ao tipo de interface e à informação de área, que
os vizinhos devem observar para se tornarem adjacentes.
Adjacente versus totalmente adjacente A especificação OSPF não é totalmente clara

sobre o que significa adjacente. Na maioria das vezes, os vizinhos adjacentes são
definidos como vizinhos que já sincronizaram seus LSDBs; outras vezes, o termo
totalmente adjacente é usado para esse fim. Obviamente, ser capaz de sincronizar
LSDBs ou terminar de sincronizar LSDBs são dois estágios diferentes de um
relacionamento de vizinhança. Neste livro, o termo adjacente será usado com a
definição dada acima, ou seja, vizinhos adjacentes são vizinhos cuja conexão faz
parte do mapa de rede e que estão prontos para sincronização LSDB; o termo
totalmente adjacente designará roteadores adjacentes que sincronizaram seus
LSDBs. Observe que nem todos os roteadores adjacentes precisam

Deve se tornar
Abaixo Iniciar 2 maneiras
totalmente adjacente?
ExStart
FIGURA 6.6: Máquina de estados Hello do OSPF: evolução dos estados ao estabelecer com
sucesso um relacionamento bidirecional.
6.1.4) e a bidirecionalidade das comunicações (Seção 6.2.3.1) são observadas. No entanto,

uma condição adicional é imposta às adjacências de L1.
No caso de relacionamentos L1, as áreas configuradas nos vizinhos também determinam
se uma adjacência L1 pode ser estabelecida. Lembre-se de que pode haver mais de uma área
atribuída a um roteador e que os identificadores de área são anunciados em pacotes HELLO
por meio dos endereços de área TLV. Especificamente, uma adjacência L1 só pode ser
estabelecida entre dois vizinhos se eles declararem (em seus pacotes L1 HELLO) pelo menos
uma área em comum. As adjacências L2 não são limitadas pelas áreas declaradas, ou seja,
uma adjacência L2 pode ser estabelecida entre dois roteadores colocados em áreas diferentes.
De fato, como será visto no Capítulo 7, esse tipo de adjacência é utilizado em redes hierárquicas
IS-IS para comunicar informações de roteamento entre áreas.
Dentro de um link compartilhado, algumas adjacências podem ser do tipo L1 e outras do

tipo L2. Suponha que dois roteadores se conectem a um link compartilhado com suas interfaces
configuradas como L1/L2. Se os roteadores pertencerem à mesma área, eles estabelecem
adjacências L1 e L2. Caso contrário, eles estabelecem apenas adjacências L2.
Na Seção 10.1.6 ilustramos por meio de experimentos a adjacência IS-IS
processo.
6.2.4 Máquina de estado do protocolo OSPF Hello

Na especificação OSPF [36], o processo de estabelecimento de um relacionamento bidirecional
é definido por meio de uma máquina de estado detalhada, correspondente à parte do protocolo
Hello da máquina de estado vizinha, e descrita na Seção 10 da especificação . A Figura 6.6
mostra a evolução dos estados quando dois roteadores estabelecem comunicação bidirecional
com sucesso em links ponto a ponto ou compartilhados; note que a figura não inclui a máquina
de estado completa (está incluída apenas a parte relativa ao protocolo Hello). Uma instância
separada da máquina de estado é criada para cada vizinho em cada interface.

R1 R2
Abaixo Abaixo
Iniciar
2 maneiras
2 maneiras
tempo
FIGURA 6.7: Estabelecendo comunicação bidirecional em OSPF.
Evolução dos estados A máquina de estados inicia no estado Down. Quando o

primeiro pacote HELLO é recebido de um vizinho (evento Hello Received), a
máquina de estado transita para o estado Init. Neste ponto, o roteador já sabe que
o vizinho existe, mas não confirmou que a comunicação bidirecional é possível. A
máquina de estado abandona o estado de inicialização quando o roteador recebe
um pacote HELLO do vizinho com seu próprio RID listado (evento 2-Way Received).
O próximo estado depende se os vizinhos devem começar a sincronizar seus LSDBs
(ou seja, se eles devem se tornar totalmente adjacentes). Se for necessário, a
máquina de estado vai para o estado ExStart; caso contrário, ele vai para o estado
2-Way. Por exemplo, em links compartilhados, os roteadores apenas sincronizam
seus LSDBs com o DR ou BDR. O estado ExStart é o estado inicial do processo de
sincronização do LSDB, que será detalhado na Seção 6.6.
A Figura 6.7 ilustra a troca inicial de pacotes HELLO, onde os vizinhos verificam
se a comunicação bidirecional é possível (isto é, até atingirem o estado 2-Way).
Inicialização a frio em links compartilhados Durante uma inicialização a frio em um

link compartilhado, todas as interfaces se movem para o estado 2-Way (e não para
o estado ExStart). Isso porque, quando as interfaces abandonam o estado Init, o DR
e o BDR ainda não foram eleitos. De fato, como será visto na Seção 6.3, o DR e o
BDR só podem ser eleitos entre as interfaces para as quais a comunicação
bidirecional foi verificada.
As condições para se tornar totalmente adjacente devem ser reexaminadas
sempre que o DR ou BDR mudar. Assim, quando o DR e o BDR são finalmente
eleitos, os relacionamentos de vizinhança onde pelo menos um vizinho é DR ou
BDR passam do estado 2-Way para o estado ExStart e iniciam o processo de
sincronização LSDB; os relacionamentos de vizinhança restantes, onde os vizinhos
não são DR nem BDR, permanecem no estado 2-Way. A necessidade de reexaminar
as condições de adjacência é referida na especificação OSPF como AdjOK? evento.

Abaixo Inicializando Acima
FIGURA 6.8: Máquina de estado IS-IS Hello: evolução dos estados ao estabelecer
com sucesso uma relação bidirecional.
6.2.5 Máquina de estado do protocolo IS-IS Hello

A máquina de estado do protocolo IS-IS Hello para estabelecer comunicações
bidirecionais é semelhante à do OSPF. Existem também três estados, com o mesmo
significado, mas com nomes ligeiramente diferentes: Down, Initializing (chamado Init
no OSPF) e Up (chamado 2-Way no OSPF). Assim, uma interface fica no estado
Down até receber o primeiro HELLO do vizinho. No estado Initializing, a interface já
recebeu um HELLO do vizinho, mas não sabe se o vizinho recebeu seu próprio
HELLO (ou seja, a comunicação bidirecional não foi verificada). Finalmente, no
estado Up a interface sabe que o vizinho recebeu seu HELLO e, portanto, sabe que
a comunicação bidirecional é possível. Essa máquina de estado é mostrada na
Figura 6.8. O processo inicial de sincronização do LSDB sempre começa no estado
Up.
6.2.6 Bidirecionalidade de relacionamentos em links ponto a ponto IS-IS
Na especificação inicial do IS-IS, os pacotes IS-IS HELLO PONTO A PONTO não

incluíam o identificador de vizinho ou qualquer outra informação equivalente, o que
impossibilitava a verificação da comunicação bidirecional. A suposição nesta
especificação era que os links ponto-a-ponto eram totalmente confiáveis. Este
problema foi corrigido no RFC 3373 [24], posteriormente atualizado pelo RFC 5303
[25], que introduziu o Ponto-a-Ponto Three-Way Adjacency TLV (tipo 240).
O TLV de adjacência de três vias ponto a ponto O TLV de adjacência de três vias
ponto a ponto anuncia o estado atual da interface de envio usando o campo
Adjacency Three-Way State. Neste campo, o estado Up é codificado como 0, o
estado Initializing como 1 e o estado Down como 2. O TLV também inclui o campo
Neighbor System ID para anunciar o identificador de vizinho, mas seu uso não é
obrigatório. Assim, diferentemente dos casos de links compartilhados OSPF e IS-IS,
um roteador não verifica a comunicação bidirecional verificando se seu identificador
está incluído no HELLO recebido do vizinho; em vez disso, é verificado quando o
HELLO recebido indica que o vizinho está nos estados Inicializando ou Ativo.
Comparando IS-IS ponto-a-ponto e links compartilhados Na Figura 6.9 comparamos

a verificação de comunicações bidirecionais em IS-IS ponto-a-ponto e links
compartilhados. R1 envia o primeiro HELLO, declarando o estado Down, no

R1 R2
Abaixo Abaixo
Inicializando
Acima
Acima
tempo
R1 R2
Abaixo Abaixo
Inicializando
Acima
Acima
tempo
FIGURA 6.9: Estabelecendo comunicação bidirecional em IS-IS (a) links ponto a ponto e (b)
links compartilhados.
no caso de links ponto a ponto, ou o identificador do roteador, no caso de links compartilhados.

Quando o R2 recebe esse pacote, ele passa para o estado Inicializando. Então R2 responde
com outro pacote HELLO onde, em enlaces ponto a ponto declara o estado Inicializando, e em
enlaces compartilhados inclui o identificador de vizinho (o endereço MAC da interface de R1).
Quando R1 recebe este pacote, ele entende que a comunicação bidirecional com R2 é
possível e passa para o estado Up. Finalmente, no próximo pacote HELLO enviado para R2,
R1 declara o estado Up no caso de links ponto a ponto ou inclui o identificador de vizinho (o
endereço MAC da interface de R2) no caso de links compartilhados. Novamente, quando R2
recebe este pacote, ele entende que a comunicação bidirecional com R1 é possível e passa
para o estado Up.
Na Seção 10.1.4 ilustramos por meio de experimentos o processo de verificação de

comunicações bidirecionais em enlaces ponto a ponto IS-IS.
Canal do Telegram : @IRFaraExam

Comparando OSPF e IS-IS O processo de verificação de bidirecionalidade em links

ponto-a-ponto IS-IS tem a vantagem, sobre o OSPF, de declarar apenas o estado da
interface, o que requer um número muito menor de bits do que declarar o identificador
vizinho .
6.2.7 Respostas HELLO imediatas Além de
serem transmitidos periodicamente, os pacotes HELLO também podem ser transmitidos

imediatamente, em resposta a eventos específicos, sem que seja necessário aguardar o
próximo horário programado para um HELLO periódico. Esses pacotes serão chamados
de HELLOs imediatos. O objetivo dos HELLOs imediatos é acelerar a convergência
quando houver uma mudança na rede.
IS-IS Immediate HELLOs fazem parte da especificação IS-IS [1]. Por exemplo, a
especificação estabelece que, além das transmissões periódicas regidas pelo
iSISHelloTimer ou pelo dRISISHelloTimer, LAN IS-IS HELLOs devem ser transmitidos
quando (i) o conteúdo do próximo HELLO for diferente do conteúdo do último transmitido,
ou (ii) a interface determina que se tornará o DIS ou que renunciará a ser o DIS. As
transmissões são restritas de forma que deve haver um intervalo de pelo menos 1
segundo entre HELLOs consecutivos. A especificação também afirma que os
temporizadores Hello só podem ser redefinidos quando um LAN IS-IS HELLO é
transmitido como resultado de (i) expiração do temporizador (ou seja, quando chega a
hora de um novo HELLO periódico) ou (ii) ao se tornar o DIS ou renunciar ao DIS.
OSPF No OSPF, HELLOs imediatos não fazem parte da especificação, mas são
discutidos em um rascunho da Internet [26]. No entanto, as implementações enviam
HELLOs imediatos quando um roteador recebe um HELLO de um vizinho e o estado de
seu relacionamento com o vizinho é menor que 2-Way, ou seja, o HELLO recebido ainda
não reconhece o roteador como vizinho. Esses HELLOs imediatos são transmitidos em
unicast para o vizinho e não em multicast como nos HELLOs periódicos. Além disso, ao
contrário do IS-IS, o temporizador Hello só é redefinido como resultado da expiração do temporizador.
O rascunho da Internet refere outras circunstâncias em que HELLOs imediatos podem
ser enviados, mas apenas o descrito acima parece ser implementado.
As interfaces do roteador OSPF e IS-IS tornam-se adjacentes por meio do

protocolo Hello. A periodicidade das transmissões de pacotes HELLO é de 10
segundos nas LANs, tanto no OSPF quanto no IS-IS. Uma adjacência entre
duas interfaces só pode ser estabelecida se uma interface aceitar os pacotes
HELLO enviados pela outra e se for verificada a bidirecionalidade das
comunicações. No entanto, condições adicionais devem ser atendidas, com
base nas informações fornecidas pelo protocolo HELLO. Os vizinhos IS-IS
podem estabelecer dois tipos de adjacências, chamadas L1 e L2, para trocar
informações de roteamento relacionadas ao L1 LSDB ou L2 LSDB, respectivamente.
As adjacências OSPF e IS-IS do tipo L1 só podem ser estabelecidas entre
interfaces que declaram a mesma área em seus pacotes HELLO.

6.3 Eleição do roteador designado 195
6.3 Eleição do roteador designado

Os roteadores designados, chamados DR em OSPF e DIS em IS-IS, são eleitos por
meio do protocolo Hello, mas os processos de eleição são ligeiramente diferentes.
O OSPF também elege um segundo roteador como parte desse processo, chamado
BDR, com a função de substituir o DR em caso de falha. Em ambos os protocolos, o
processo de eleição é influenciado por uma prioridade configurável chamada Router
Priority em OSPF e Priority em IS-IS; uma prioridade mais alta significa que o roteador
terá mais chances de ser eleito, e uma prioridade zero significa que o roteador não
participará do processo de eleição.
6.3.1 Suporte a pacotes

A eleição do roteador designado é suportada na transmissão periódica de pacotes
HELLO. Para este fim, os pacotes HELLO incluem (i) os identificadores dos vizinhos
ativos no enlace, (ii) o(s) identificador(es) do(s) roteador(es) designado(s) eleito(s) e (iii)
os valores de prioridade.
Como os vizinhos são listados nos pacotes HELLO? No OSPF, os vizinhos são listados
no campo Neighbor e, no IS-IS, no IS Neighbours TLV do tipo 6. Este TLV é diferente
do IS Neighbors TLV incluído nos LSPs, que é do tipo 2. No tipo 6 IS Neighbors TLV,
um vizinho é uma interface identificada por meio de seu endereço MAC. O valor de
prioridade é carregado no campo Router Priority no OSPF e no campo Priority no IS-IS.
Como os roteadores designados são identificados nos pacotes HELLO? No OSPF, o

DR e o BDR são identificados nos pacotes HELLO por meio dos campos Designated
Router e Backup Designated Router. No OSPFv2, esses campos carregam os
endereços IPv4 atribuídos às interfaces DR e BDR anexadas ao link. No OSPFv3,
esses campos carregam o RID do DR e do BDR. No IS IS, o DIS é identificado nos
pacotes HELLO através do campo LAN ID, que carrega o SID do DIS.
Disseminação de identificadores de link compartilhado por meio de pacotes HELLO

Lembre-se de que o identificador de um link compartilhado é baseado no identificador
de seu roteador designado. No OSPFv2, os identificadores do link compartilhado e de
seu DR coincidem. No OSPFv3 e IS-IS, o link é identificado por dois elementos: o RID
do DR (no caso do OSPFv3) ou o SID do DIS (no caso do IS-IS), concatenado com um
tag local gerado por esses roteadores para garantir exclusividade na identificação do
link. Uma das funções do protocolo Hello é comunicar o identificador de link (completo)
do DR ou DIS para os roteadores vizinhos. Conforme mencionado acima, no OSPFv3,
o RID está incluído no campo Designated Router e, no IS-IS, o SID está incluído no
campo LAN ID. Além disso, no OSPFv3, o tag é incluído no campo Interface ID e, no IS-
IS, o tag é o Pseudonode ID e é incluído no campo LAN ID.

RD
Algoritmo
Abaixo Esperando Cópia de segurança
eleitoral
DROoutro
FIGURA 6.10: Máquina de estado de interface relacionada a interfaces de link compartilhado.
Essas tags não desempenham nenhum papel na escolha do roteador designado, mas são geradas
e comunicadas a todos os vizinhos assim que um roteador é designado.
6.3.2 Processo de eleição do OSPF

No OSPF, o DR e o BDR são eleitos de forma que, uma vez designados, nenhum outro roteador
possa assumir sua função, a menos que um ou ambos abandonem o link, devido a uma ação de
gerenciamento ou a uma falha. O objetivo é garantir que um roteador de entrada sempre obtenha o
LSDB mais atualizado em um link compartilhado durante o processo de sincronização inicial.
6.3.2.1 A máquina de estado da interface
O processo de eleição do OSPF é definido por meio da máquina de estado da interface, descrita na
Seção 9 da especificação do OSPF [36]. A Figura 6.10 mostra a parte da máquina de estado de
interface relacionada com a eleição do DR e do BDR. Esta máquina de estados define o estado de
uma interface como sendo DR (se a interface for o link DR), Backup (se a interface for o link BDR)
ou DR other (se a interface não for nem o link DR nem o link BDR) . Este estado deve ser
determinado inicialmente, assim que a interface for ligada, ou quando ocorrer uma alteração no link
(por exemplo, devido a uma falha do DR ou BDR atual).
Uma interface desligada está no estado Down. Quando a interface é ligada (evento InterfaceUp),
ela é colocada no estado Waiting, onde tenta determinar quem são o DR e o BDR. Neste estado, a
interface escuta os pacotes HELLO, mas não pode eleger um BDR ou um DR; além disso, é

deve anunciar endereços DR e BDR de 0.0.0.0 nos pacotes HELLO que envia. A
interface abandona esse estado em dois eventos: (i) após um período de timeout,
denominado Wait Timer (evento WaitTimer), ou (ii) quando, após estabelecer
comunicação bidirecional com um vizinho, esse vizinho se declara como sendo o DR
ou o BDR (evento BackupSeen). O Wait Timer é igual a RouterDeadInterval e, portanto,
tem um valor padrão de 40 segundos. Quando a interface abandona o estado Waiting,
ela deve executar o algoritmo de eleição.
O algoritmo de eleição também deve ser executado quando ocorrer uma alteração
no link, disparada pelo evento NeighborChange, que ocorre quando: (i) um novo vizinho
se conecta ao link, (ii) um vizinho existente abandona o link, (iii) um vizinho se declara
recentemente como DR ou BDR, (iv) um vizinho não se declara mais como DR e BDR,
ou (v) um vizinho muda sua prioridade de roteador.
6.3.2.2 Algoritmo de eleição
O algoritmo de eleição do DR e BDR é descrito na Seção 9.4 da especificação OSPFv2

[36]. Ele considera a possibilidade de vários vizinhos se declararem como DR ou BDR,
e possui os seguintes passos (também resumidos na Figura 6.11):
1. Liste todos os vizinhos para os quais a comunicação bidirecional foi

estabelecida; o roteador executando o algoritmo também deve ser colocado
na lista.
2. Determine o novo BDR da lista da etapa 1, mas excluindo os roteadores que

se declaram como DR. O novo BDR é o roteador classificado em primeiro
lugar de acordo com os seguintes critérios. Primeiramente, divida os
roteadores em dois grupos: (i) os roteadores que se declararam como BDR
(grupo 1) e (ii) os demais roteadores (grupo 2). O algoritmo considera
primeiro os roteadores do grupo 1, e somente se este grupo estiver vazio
(ou seja, nenhum roteador declarado como BDR) considera os roteadores
do grupo 2. Dentro de cada grupo, os roteadores com maior Prioridade de
Roteador são classificados primeiro e, em em caso de empate, aqueles
com maior RID são classificados em primeiro lugar.
3. Determine o novo DR, considerando primeiro os roteadores que se declararam
como DR. Como no caso da eleição do BDR, o roteador classificado em
primeiro lugar é aquele com maior prioridade de roteador e, em caso de
empate, aquele com maior RID. Se nenhum roteador se declarou como DR,
o novo DR é o BDR determinado na etapa 2.
4. Esta etapa avalia uma condição. Se houve uma mudança no status DR ou
BDR do roteador executando o algoritmo, ou seja, se o roteador é o novo
DR ou BDR, ou não é mais o DR ou BDR, e se as etapas 2 e 3 foram
executadas pela primeira vez, essas duas etapas devem ser executadas
uma segunda vez. Caso contrário, o algoritmo segue para o passo 5.
5. Finalmente, de acordo com o cálculo acima, o roteador deve ser

ÿ
ÿ
FIGURA 6.11: Algoritmo de eleição de DR e BDR.
colocado no estado DR (se foi eleito DR), no estado Backup (se foi eleito
BDR) ou no estado DR Other (caso contrário).
Uma característica importante desse algoritmo de eleição, claro nas etapas 2 e 3, é

que ele favorece DRs e BDRs já declarados. Outra característica é que ele pode eleger
o mesmo roteador tanto como DR quanto como BDR. No entanto, o roteador eleito
duas vezes não pode ser aquele que está executando o algoritmo.
6.3.2.3 Casos especiais
O algoritmo parece complexo, por isso é importante destacar suas principais

características. Discutimos vários casos a seguir.
Partida a frio Quando todas as interfaces são ligadas ao mesmo tempo (ou seja, um
cenário de inicialização a frio), a interface com a maior prioridade de roteador, ou RID
mais alto em caso de empate, torna-se o link DR e aquela com o segundo roteador
mais alto A prioridade, ou RID mais alto em caso de empate, passa a ser o link BDR.
Nesse caso, as interfaces entram no estado Waiting aproximadamente ao mesmo
tempo e permanecem lá por 40 segundos (valor padrão do Wait Timer). Durante esse
período, eles continuam recebendo pacotes HELLO de seus vizinhos e aprendem sobre
a prioridade do roteador e o RID de cada um. As interfaces abandonam o estado
Waiting aproximadamente ao mesmo tempo e executam imediatamente o algoritmo de
eleição. Quando isso acontece, nenhuma interface ainda se declarou como

DR ou BDR e, portanto, todos elegem o mesmo DR e BDR. No entanto, o comportamento

é diferente nos roteadores DR, BDR e não DR/BDR.
O DR se elege como DR e BDR na primeira passagem do algoritmo e é forçado a fazer
uma segunda passagem, pois seu papel mudou para DR. Na segunda passagem, no passo
2 ele é excluído do cálculo e elege o BDR correto e, no passo 3, ele se confirma como DR.
Assim, o DR chega à conclusão correta ao executar o algoritmo de eleição pela primeira
vez.
O BDR elege o DR correto tanto como DR quanto como BDR na primeira passagem do
algoritmo e, em seguida, interrompe o algoritmo, pois seu papel não mudou. O cálculo é
corrigido quando recebe um HELLO do DR, indicando o DR e o BDR corretos. Nesse caso,
o DR e o BDR corretos são calculados na primeira passagem do algoritmo, mas uma
segunda passagem é necessária, pois a função do roteador foi alterada para BDR. O
comportamento de um roteador não DR/BDR é semelhante ao do BDR. A única exceção é
que, ao receber as informações corretas do DR, ele realiza apenas uma passagem pelo
algoritmo, pois seu papel não mudou.
Os experimentos das Seções 10.2.1.1 e 10.2.1.2 ilustram a partida a frio

caso.
Roteador ingressando no link quando DR e BDR já foram eleitos Um roteador ingressando

em um link que já possui um DR e um BDR não produz alterações em relação a essas
funções. Quando sua interface é ligada no link, ele é colocado no estado Waiting, mas o
abandonará assim que a comunicação bidirecional for estabelecida com o DR ou com o
BDR (através do evento BackupSeen).
Assim, ao contrário do caso de inicialização a frio, a interface não ficará no estado Waiting
por segundos do Wait Timer. Quando o estado Waiting é abandonado, a interface executa
o algoritmo de eleição. Suponha que, quando o algoritmo é iniciado, tanto o DR quanto o
BDR tenham estabelecido comunicação bidirecional com o roteador de entrada. Como no
passo 2 o algoritmo considera primeiro os roteadores que se declararam como BDR, e
apenas o BDR atual o fez, esse roteador é eleito BDR. Da mesma forma, como no passo 3
o algoritmo considera primeiro os roteadores que se declararam como DR, o DR atual
também é eleito DR, e o algoritmo para.
O experimento da Seção 10.2.1.3 ilustra este caso.

Apenas um roteador iniciado no link Se apenas um roteador se conectar a um link
compartilhado, esse roteador será eleito DR. O roteador entrará no estado Waiting e o
abandonará através do evento WaitTimer. Em seguida, executará o algoritmo de eleição.
Na primeira passagem do algoritmo, o roteador se elege como DR e BDR. No entanto, é
forçado a fazer uma segunda passagem, já que seu papel mudou para DR. Na etapa 2
desta passagem, o roteador é excluído do cálculo, pois agora é o DR, e um BDR de 0.0.0.0
(ou seja, nenhum BDR) é determinado; a etapa 3 confirma que o roteador é o DR.
O experimento da Seção 10.2.1.4 ilustra este caso.

Falha de DR Quando o DR falha, o antigo BDR é promovido a DR e o novo

BDR é o roteador que, dentre os demais, tem a maior prioridade de roteador, ou maior
RID em caso de empate.
Quando o antigo BDR detecta a falha, ele executa o algoritmo de eleição. No
passo 2, ele se confirma como BDR, e no passo 3, elege-se como DR, pois o DR
falhou. Agora, como sua função mudou de BDR para DR, ele deve executar uma
segunda passagem pelo algoritmo. No passo 2, o roteador deve se retirar do cálculo,
pois agora é o DR. Assim, apenas os demais roteadores são considerados nesta
etapa, sendo eleito BDR aquele com maior Prioridade de Roteador. Na etapa 3, o
roteador é confirmado como DR. Assim, o antigo BDR chega à conclusão correta
quando executa o algoritmo pela primeira vez após a falha do DR.
Os demais roteadores, ao detectarem a falha do DR, irão inicialmente declarar o

antigo BDR, como DR e BDR simultaneamente. Eles terão que esperar um pacote
HELLO enviado pelo novo DR, declarando-se como DR, para executar novamente o
algoritmo de eleição e chegar à conclusão correta.
O experimento da Seção 10.2.1.5 ilustra o caso de falha de DR.
6.3.2.4 Procedimento para definição do DR e BDR
O algoritmo de eleição sugere um procedimento que os gerentes de rede podem

seguir para definir quais roteadores são DR e BDR, caso a solução em execução seja
insatisfatória: (i) desligar todas as interfaces conectadas ao link; (ii) ligar a interface
que se deseja que se torne o DR e aguardar 40 segundos (Wait Timer); (iii) repetir o
passo anterior para a interface que se deseja tornar o BDR; (iv) finalmente, ligue todas
as outras interfaces. Infelizmente, esse procedimento interrompe o serviço, mas não
há alternativa.
6.3.2.5 Eventos desencadeados pela eleição do DR
Quando um novo DR é eleito, o identificador do link compartilhado muda. Assim, o DR

deve originar um novo Network-LSA e os roteadores conectados ao link devem
originar novas instâncias de seus Router-LSAs, contendo o novo identificador do link.
No OSPFv2, o identificador de link é incluído no campo Link State ID de Network-LSAs
e no campo Link ID das descrições de link tipo 2 de Router-LSAs. No OSPFv3, o
identificador de link é incluído nos campos Advertising Router e Link State ID de
Network-LSAs, e nos campos Neighbor Router ID e Neighbor Interface ID das
descrições de link tipo 2 de Router-LSAs.
6.3.3 Processo eleitoral IS-IS

O processo de escolha de um roteador designado é muito mais simples no IS-IS do
que no OSPF. No IS-IS, a interface com maior prioridade sempre assume o papel de
DIS e, em caso de empate, a interface com maior endereço MAC passa a ser o DIS.
A prioridade é anunciada no campo Prioridade dos pacotes HELLO. Em links
compartilhados, um DIS distinto pode existir para adjacências L1 e L2.

6.3.3.1 Algoritmo de eleição
Sob condições estáveis, o processo de eleição é executado em uma interface toda vez
que um pacote HELLO é recebido. Os candidatos à eleição são (i) a interface que realiza
a eleição e (ii) seus vizinhos adjacentes. Como mencionado acima, entre esses
candidatos, vence aquele com maior prioridade e, em caso de empate, vence aquele
com maior endereço MAC.
O tempo de espera Quando uma interface é ligada, o processo de seleção só pode
começar após um período de espera de 2 × iSISHelloTimer (padrão de 20 segundos).
No entanto, as implementações IS-IS que analisamos usam um período mais curto. O
período de espera é o equivalente ao estado de espera do OSPF.
O campo LAN ID O DIS atual é identificado no campo LAN ID dos pacotes HELLO por
meio de seu SID. O LAN ID também inclui o Pseudonode ID, ou seja, a marca local
gerada pelo DIS para identificar exclusivamente o link. Durante o período de espera, o
campo LAN ID carrega o SID do roteador remetente e um tag local gerado pelo roteador
(que se tornará o Pseudonode ID caso este roteador seja eleito DIS). Após a eleição do
DIS, o campo LAN ID dos roteadores não DIS é copiado daquele transmitido pelo DIS.
Pelo menos algumas implementações usam HELLOs imediatos durante o período de
espera; no entanto, como no caso do OSPF, esse recurso não faz parte do padrão.
Mudando o DIS Configurar um novo DIS é uma tarefa simples no IS-IS: uma interface
pode se tornar o DIS em um link compartilhado aumentando sua prioridade para um
valor maior do que as prioridades das demais interfaces. Feita esta configuração, a
interface imediatamente se elege como DIS e transmite um pacote HELLO (i) indicando
no campo LAN ID que agora é o DIS e (ii) anunciando o novo valor de prioridade.
Detectando uma falha de DIS Quando o DIS falha, os roteadores restantes elegem um
novo DIS assim que detectam a falha. O DIS normalmente usa um Hold Timer menor
do que os roteadores restantes. Assim, detectar uma falha DIS é mais rápido do que
detectar a falha de qualquer outro roteador.
As seções 10.2.2.1, 10.2.2.2 e 10.2.2.3 ilustram, por meio de experimentos, o
comportamento do processo de eleição do DIS durante a inicialização a frio, quando um
novo DIS é configurado e quando o DIS falha.
6.3.3.2 Eventos desencadeados pela eleição do DIS
Como no caso do OSPF, quando um novo DIS é eleito, o identificador do link muda.
Assim, o DIS deve originar um novo Pseudonode-LSP, e os roteadores conectados ao
enlace devem originar novas instâncias de seus Nonpseudonode-LSPs.
O identificador de link compartilhado é o SID do DIS concatenado com o Pseudon ode
ID atribuído pelo DIS. Ele está incluído nos TLVs topológicos que descrevem os
vizinhos de um roteador (o IS Neighbours TLV ou o Extended IS Reachability TLV).
Além disso, se o novo DIS contiver em seu LSDB a origem Pseudonode-LSP

inado pelo DIS anterior, ele deve excluí-lo. Explicamos o processo de exclusão de LSPs na Seção
6.5.3. Esse comportamento não é permitido no OSPF, pois apenas o roteador de origem pode
excluir seus LSAs originados. Além disso, quando um DIS entende que deve renunciar (por
exemplo, porque um vizinho anunciou uma Prioridade mais alta), ele também deve iniciar a
exclusão de seu Pseudonode-LSP.
O roteador designado (chamado DR em OSPF e DIS em IS-IS) é eleito por meio do

protocolo Hello. O OSPF também elege um roteador designado de backup (chamado
BDR) dessa maneira, para substituir o DR em caso de falha. No OSPF, o DR e o BDR
são eleitos de forma que, uma vez eleitos, nenhum outro roteador possa assumir seu
papel. No IS-IS, o DIS é eleito de acordo com uma prioridade configurável.
6.4 Procedimento de inundação

OSPF e IS-IS usam o procedimento de flooding controlado e confiável descrito na Seção 2.4 para
disseminar informações de roteamento, com algumas exceções. Lembre-se da discussão na
Seção 5.1 de que os elementos de inundação indivisíveis de OSPF e IS-IS são os LSAs e os LSPs.
O procedimento de inundação confiável funciona da seguinte maneira:
• Quando um roteador origina um LSA/LSP para ser inundado, ele transmite o

LSA/LSP em todas as suas interfaces.
• Quando um roteador recebe em uma interface um novo LSA/LSP (ou seja, ainda não contido em
seu LSDB) ou uma instância mais recente (ou seja, mais recente) de um LSA/LSP armazenado,
ele retransmite o LSA/LSP em todas as outras interfaces; ele não retransmite o LSA/LSP na
interface de entrada.
• Quando um roteador recebe um LSA/LSP para o qual existe uma instância armazenada
com frescor igual ou superior, o LSA/LSP é descartado.
• Um roteador que recebe um LSA/LSP em uma interface confirma sua recepção ao roteador que
o transmitiu. A confirmação deve ser feita mesmo que o LSA/LSP deva ser descartado.
A noção de frescor em OSPF e IS-IS será discutida nas Seções 6.5.1 e 6.5.2. Estas seções
apresentam os atributos de atualização e explicam como esses atributos são usados para
classificar a atualização de LSAs/LSPs.
Além das ações enumeradas acima, a chegada de LSAs/LSPs aos roteadores aciona eventos
adicionais, que serão discutidos na Seção 6.5.4. Vamos nos concentrar agora no procedimento
de inundação.
OSPF e IS-IS diferem ligeiramente do procedimento descrito acima em relação à inundação
em links compartilhados. As características específicas do OSPF e do IS-IS serão detalhadas nas
próximas seções.

6.4 Procedimento de inundação 203
Na Seção 10.3, ilustramos o procedimento de inundação de OSPF e IS-IS por

meio de experimentos.
6.4.1 Inundação no OSPF

O OSPF usa o procedimento de flooding controlado e confiável descrito acima, com
algumas otimizações no caso de links compartilhados. A inundação confiável usa
proteção ACK em links ponto a ponto e compartilhados.
Suporte a pacotes Os LSAs e seus reconhecimentos são transportados em pacotes
LS UPDATE e LS ACKNOWLEDGMENT, respectivamente. O formato desses pacotes
é mostrado nas Figuras 6.2 (OSPFv2) e 6.4 (OSPFv3).
Ambos os tipos de pacotes podem transportar informações em mais de um LSA. Os
pacotes LS ACKNOWLEDGMENT carregam apenas os cabeçalhos dos LSAs
reconhecidos, e não seu conteúdo completo. Ressaltamos que o que precisa ser
reconhecido são os LSAs individuais, e não os pacotes LS UPDATE, que são apenas
contêineres LSA. Quando um LSA é transmitido, ele é colocado em uma lista, chamada
Link state retransmission list na especificação OSPF [36], onde permanece até que a
recepção do LSA seja finalmente confirmada.
O tempo limite de retransmissão para LSAs é um parâmetro configurável por interface,
chamado RxmtInterval, que normalmente é de 5 segundos para LANs; o número
máximo de tentativas de retransmissão não foi especificado.
Flooding em links compartilhados Em links compartilhados, o DR atua como
intermediário no processo de flooding. Um LSA inundado em um link compartilhado é
enviado primeiro para o DR, que o retransmite no link para todos os outros roteadores.
Posteriormente, cada um desses roteadores confirma a recepção do LSA enviado pelo
DR. Isso é obtido usando endereços multicast IP diferentes (consulte a Seção 6.1): o
DR e o BDR transmitem pacotes usando o endereço multicast AllSPFRouters, que é
lido por todos os roteadores conectados ao link; roteadores não DR/BDR transmitem
pacotes usando o endereço multicast AllDRouters, que é lido apenas pelo DR e BDR.
Assim, quando um roteador não DR precisa inundar um LSA em um link compartilhado,
ele envia o LSA para o DR encapsulado em um pacote LS UP DATE com endereço
multicast AllDRouters; o DR então retransmite o LSA para todos os outros roteadores
encapsulados em outro pacote LS UPDATE, mas agora com endereço multicast
AllSPFRouters. O BDR também recebe o LSA inicial, mas o ignora e aguarda o LSA
transmitido pelo DR; se por algum motivo o DR falhar, o BDR cuidará da própria
retransmissão.
Minimizando o número de transmissões ACK Em princípio, uma transmissão LSA em
um link compartilhado deve ser reconhecida por todos os outros roteadores
conectados a ele. No entanto, o OSPF inclui várias otimizações para minimizar o
número de transmissões de confirmação. Primeiro, a transmissão de pacotes LS AC
KNOWLEDGMENT pode ser retardada na esperança de agrupar várias confirmações
LSA em um único pacote; esse recurso é chamado de confirmação atrasada. Em
segundo lugar, o reconhecimento pode ser implícito. Se um roteador enviar um LSA
através de uma interface e, enquanto espera pelo correspondente ac

FIGURA 6.12: Resumo da inundação OSPF em links compartilhados.
conhecimento, recebe o mesmo LSA naquela interface, considera que o reconhecimento

foi efetivamente feito; isso é chamado de reconhecimento implícito. Além disso, o roteador
não precisa reconhecer a recepção deste LSA. O procedimento exato para a transmissão
de pacotes LS ACKNOWLEDGMENT está resumido na Tabela 19 da especificação OSPF
[36].
Resumo da inundação em links compartilhados A Figura 6.12 resume o procedimento de
inundação em links compartilhados, quando um roteador recebe um LSA e determina que
ele deve ser inundado (por exemplo, porque o LSA está ausente do LSDB ou é uma
instância mais recente de um LSA armazenado).
• Se o LSA for enviado pelo DR ou pelo BDR, todos os outros roteadores o ouvirão (porque
foi transmitido usando o endereço AllSPFRouters) e confirmarão seu recebimento.
• Se o LSA for enviado por um roteador não DR/BDR, apenas o DR e o BDR o ouvirão, pois
foi enviado para o endereço AllDRouters. Nesse caso, o DR retransmite o LSA no link.
A reação a esta transmissão é conforme o caso anterior, exceto que o roteador não DR/
BDR que originou o LSA não precisa reconhecer o pacote.
Três exemplos Na Figura 6.13, damos três exemplos de inundação em links compartilhados.
Na Figura 6.13.a, o LSA a ser inundado chega a um roteador não DR/BDR.
Nesse caso, o roteador encapsula o LSA em um pacote LS UPDATE e o transmite no link
usando o endereço multicast AllDRouters (etapa 1). Este pacote é lido apenas pelo DR e
BDR, mas esses roteadores não reconhecem a recepção do LSA. O DR retransmite o LSA
usando o endereço AllSPFRouters para que chegue a todos os outros roteadores (etapa
2), e cada um desses roteadores, exceto o roteador que inicialmente enviou o LSA,
confirma o recebimento usando um LS ACKNOWLEDGMENT (etapa 3); o roteador inicial
considera o LSA enviado pelo DR como uma confirmação implícita. Na Figura 6.13.b, o
LSA chega ao BDR, e o BDR o envia imediatamente para todos os outros roteadores
usando o endereço multicast AllSPFRouters (etapa 1); cada um desses roteadores,

3 Ack
TodosDesignados
Ack 3
Todos os roteadores
RD BDR
Atualizar
Todos os roteadores
2 Atualizar 1
TodosDesignados
(a)
2 Ack
Atualizar TodosDesignados
Atualizar 1
Todos os roteadores
RD BDR Atualizar
Ack
Todos os roteadores
2 Ack 2
2 Ack TodosDesignados
TodosDesignados
Ack 2 (b)
Todos os roteadores
Atualizar RD BDR
Atualizar
Todos os roteadores
1 Ack 2
TodosDesignados
(c)
FIGURA 6.13: Exemplo de inundação OSPF em links compartilhados.
incluindo o DR, confirme a recepção do LSA (etapa 2). Um comportamento semelhante é

obtido quando o LSA chega ao DR (Figura 6.13.c).
Retransmissões de LSA Se um LSA precisar ser retransmitido em um link compartilhado,
ele será enviado apenas para os vizinhos dos quais não foi recebida uma confirmação.
Assim, o LSA não será retransmitido usando um endereço IP multicast, mas, em vez disso,
os endereços IP unicast dos vizinhos que não respondem.
Esta opção dispensa os vizinhos que já receberam e reconheceram o LSA de ter que lê-lo
novamente. No entanto, um LSA (e, portanto, um pacote LS UPDATE) deve ser enviado
para cada vizinho que não responde. As confirmações de LSAs unicast também devem ser
unicast para o roteador que transmitiu o LSA.
Motivação para usar o DR como intermediário de inundação A motivação para usar o DR

como intermediário no processo de inundação costuma ser a escalabilidade. Isso merece
alguma discussão. Na verdade, o número total de transmissões necessárias para inundar
um LSA em um link compartilhado é o mesmo com ou sem um intermediário. Se houver N
roteadores em um link compartilhado, a inundação sem um intermediário requer a
transmissão de um LSA e N-1 confirmações,

ou seja, um total de N transmissões de pacotes. Se o link compartilhado tiver um

intermediário, a inundação requer uma transmissão LSA para o intermediário, outra do
intermediário e N ÿ 2 confirmações (devido à regra de confirmação implícita), ou seja, um
total de N transmissões de pacotes novamente.
Ao utilizar o DR como intermediário de flooding, alguns ganhos no número de
transmissões de pacotes podem ocorrer quando o mesmo LSA chega simultaneamente em
vários roteadores conectados ao link compartilhado. No entanto, esses ganhos não são
muito altos devido à regra de reconhecimento implícito. A vantagem de ter um DR é mais
óbvia no processo inicial de sincronização do LSDB, como ficará claro na Seção 6.6.
No OSPF, a inundação confiável usa proteção ACK em links ponto a ponto e

compartilhados. LSAs são encapsulados em pacotes LS UPDATE e são
reconhecidos usando apenas os cabeçalhos LSA encapsulados em pacotes LS
AC KNOWLEDGMENT. Em links compartilhados, o DR atua como um intermediário
no processo de flooding: primeiro um LSA é transmitido para o DR, e o DR
retransmite o LSA para todos os outros roteadores, que então confirmam a recepção
do pacote para o DR. O OSPF inclui várias otimizações para minimizar o número
de transmissões de confirmação em links compartilhados.
6.4.2 Inundação em IS-IS

O IS-IS usa um mecanismo de inundação diferente em links ponto a ponto e compartilhados.
Suporte a pacotes No IS-IS, os LSPs são transportados em LINK STATE PDUs; esses
pacotes carregam apenas um LSP (Nonpseudonode-LSP ou Pseudonode-LSP). Os pacotes
usados para reconhecer a recepção correta dos LSPs diferem em links ponto a ponto e
compartilhados. Nos enlaces ponto a ponto, esse papel é desempenhado pelos PSNPs e,
nos enlaces compartilhados, pelos CSNPs que são transmitidos periodicamente pelo DIS.
Tanto os PSNPs quanto os CSNPs podem reconhecer a recepção de vários LSPs
simultaneamente. Os PSNPs também são utilizados no processo de flooding de links
compartilhados, mas não como reconhecimentos; eles são usados para solicitar a
retransmissão de LSPs perdidos. Os PSNPs e CSNPs carregam apenas resumos LSP, e
não LSPs completos. O resumo do LSP é fornecido pelo LSP Entries TLV (veja a Figura
6.3), que compreende o LSP ID, o LSP Sequence Number e os campos Remaining Lifetime.
Enlaces ponto a ponto O IS-IS usa diferentes mecanismos em enlaces ponto a ponto e
compartilhados para proteger a transmissão de LSPs. Em enlaces ponto a ponto, o
mecanismo é semelhante ao OSPF: usa proteção ACK onde os reconhecimentos são
transportados em PSNPs. O tempo limite de retransmissão é chamado de
MinimumLSPTransmissionInterval e tem um valor padrão de 5 segundos. IS IS inclui uma
otimização relativa ao OSPF: se um roteador recebe um LSP para o qual possui uma
instância mais recente, o roteador responde imediatamente com essa instância LSP (em vez
do PSNP) e este LSP reconhece implicitamente a recepção do inicial.

Links compartilhados Em links compartilhados, a proteção de transmissões LSP não

é executada usando reconhecimentos explícitos (como em links ponto a ponto OSPF
e IS-IS). Em vez disso, ele conta com a transmissão periódica de resumos LSP
encapsulados em CSNPs, que é realizada pelo DIS. A periodicidade das transmissões
CSNP é chamada de completeSNPInterval e normalmente é de 10 segundos. A
transmissão periódica de CSNPs também é usada no processo inicial de sincronização
do LSDB em links compartilhados (consulte a Seção 6.6.2.2).
O processo de inundação em links compartilhados tem dois casos, dependendo
se o LSP é inundado por um roteador não DIS ou pelo DIS. No primeiro caso, o
roteador transmite o LSP no enlace e aguarda o próximo CSNP enviado pelo DIS,
para verificar se o resumo do seu LSP já está listado ali. Caso contrário, ele
retransmite o LSP no link e repete esse processo até que o resumo do LSP seja
listado. Assim, neste caso, a transmissão periódica de CSNPs atua como um
reconhecimento implícito da recepção de LSPs inundados.
No segundo caso, o DIS transmite o LSP no enlace e, posteriormente, adiciona
seu resumo aos CSNPs transmitidos no enlace. O DIS não possui nenhum
mecanismo para confirmar a recepção correta deste LSP. No entanto, em caso de
perda, os roteadores não DIS perceberão que está faltando o LSP ou que possuem
uma instância desatualizada do LSP, pois os CSNPs subsequentes transmitidos pelo
DIS incluem o resumo dos mais novos (e transmitidos anteriormente) instância LSP.
Nesse caso, os roteadores não DIS solicitam a transmissão do LSP enviando um
PSNP. O DIS responde reenviando o LSP, e esse processo se repete até que o LSP
seja efetivamente recebido. Observe que, neste caso, pode haver uma tempestade
de transmissões PSNP, pois todos os roteadores não DIS solicitarão o LSP e o IS-IS
não possui mecanismo para suprimir a transmissão de PSNPs programados. A Figura
6.14 ilustra este caso. O DIS transmite um LSP, mas o LSP se perde (etapa 1). No
próximo CSNP, o DIS inclui o resumo da instância LSP perdida (etapa 2). Roteadores
não-DIS, ao receberem o CSNP, notam que não possuem o LSP (ou que possuem
uma instância desatualizada do LSP), e solicitam sua transmissão utilizando um
PSNP (passo 3); finalmente, o DIS responde retransmitindo o LSP (etapa 4).
No IS-IS, os LSPs são transportados em LINK STATE PDUs. Os

reconhecimentos são realizados através do LSP Entries TLV, mas incluídos
em diferentes pacotes de controle em links ponto-a-ponto e compartilhados.
Nos enlaces ponto a ponto, os reconhecimentos são incluídos nos PSNPs e,
nos enlaces compartilhados, nos CSNPs transmitidos periodicamente pelo DIS.
6.4.3 Tempo de guarda entre as transmissões LSA e LSP
Tanto no OSPF quanto no IS-IS, o intervalo entre duas transmissões consecutivas

da mesma instância LSA ou LSP não pode ser inferior a 5 segundos, chamado
MinLSInterval* no OSPF e MinimumLSPTransmissionInterval no IS-IS.
Esses intervalos, além de limitar a taxa de transmissões LSA e LSP,

CSNP
$OO/.6V
LSP ',6 PSNP

LSP $OO/.6V
$OO/.6V PSNP
$OO/.6V
',6
LSP
$OO/.6V PSNP
$OO/.6V
FIGURA 6.14: Inundação em links compartilhados (IS-IS).
representam um tempo de guarda necessário para a correção do processo de exclusão de

LSAs e LSPs, conforme discutido na Seção 2.4.6.
6.5 Procedimento de atualização

Os pacotes de roteamento que circulam na rede estão associados a uma das seguintes
ações quando de sua recepção em um roteador: (i) inserção no LSDB de um novo LSA/LSP
(sendo divulgado pela primeira vez), (ii) atualização de um LSA/LSP armazenado por uma
instância mais recente e (iii) exclusão de um LSA/LSP existente.
Tanto no OSPF quanto no IS-IS, as indicações de exclusão são fornecidas por meio de
tipos especiais de LSAs/LSPs, em vez de pacotes de controle DELETE explícitos (como
sugerido na Seção 2.4.6). Assim, as informações de roteamento que são disseminadas nas
redes OSPF e IS-IS consistem apenas em LSAs/LSPs.
Os LSAs/LSPs possuem um atributo de atualização e um período de validade, que são
usados para determinar as ações executadas em um roteador após sua recepção ou
expiração de validade. As ações também dependem se o roteador que executa a ação é o
originador do LSA/LSP.
Essas questões serão discutidas nas próximas seções.
6.5.1 Atributos de frescor

Tanto o OSPF quanto o IS-IS usam três tipos de atributos para expressar a atualização de
um LSA/LSP: (i) o SN, (ii) a soma de verificação e (iii) a idade. No entanto, a maneira como
esses atributos são usados difere no OSPF e no IS-IS.

6.5 Procedimento de atualização 209
FIGURA 6.15: Atributos de atualização de LSAs (OSPF) e LSPs (IS-IS) e campos de

cabeçalho correspondentes.
Os atributos de atualização são incluídos nos cabeçalhos de LSAs/LSPs. Os campos

que descrevem a atualização de um LSA são o LS Sequence Number, o LS Checksum e o
LS Age; os campos correspondentes do cabeçalho LSP são o Sequence Number, o
Checksum e o Remaining Lifetime (veja a Figura 6.15).
O SN Tanto no OSPF quanto no IS-IS, o SN é obtido do espaço linear dos números de 32

bits. No OSPF, o SN é um valor com sinal, crescendo de 0×80000001 (valor inicial) a
0×7fffffff (valor final); em IS-IS, é um valor sem sinal, crescendo de 0×00000001 (valor inicial)
a 0×ffffffff (valor final). Usar um espaço linear de números coloca o problema do que fazer
quando o valor final é alcançado. Este problema será abordado na Seção 6.5.6.
A idade A idade expressa a idade de uma instância LSA/LSP, em relação ao seu tempo de
criação. A idade tem um valor máximo, chamado MaxAge* tanto no OSPF quanto no IS-IS.
O valor máximo é o tempo de vida do LSA/LSP. A idade conta no OSPF, de zero até
MaxAge*, mas faz uma contagem regressiva no IS-IS, de MaxAge* até zero. O MaxAge* é 1
hora (3600 segundos) em OSPF e 20 minutos (1200 segundos) em IS-IS. Os campos de
idade dos LSAs/LSPs têm comprimento de dois octetos e são contados em segundos. A
necessidade de usar a idade como atributo de frescor é discutível. Como os LSAs/LSPs são
antigos, sua idade precisa ser atualizada antes que o valor máximo seja atingido. Esta
questão será abordada na Seção
6.5.5.
A idade dos LSAs/LSPs é atualizada enquanto eles permanecem nos roteadores, usando
os relógios locais dos roteadores, mas também enquanto eles estão sendo inundados, para
contabilizar os atrasos de processamento e transmissão. O valor de atualização pode ser
específico da interface, pois diferentes velocidades de interface levam a diferentes atrasos
de transmissão. A especificação IS-IS diz que a idade de um LSP deve ser diminuída em
pelo menos 1 segundo sempre que o LSP for transmitido por meio de uma interface. O OSPF
apenas diz que deve ser incrementado por um valor maior que zero.
O checksum Tanto no OSPF quanto no IS-IS, o checksum é calculado sobre o conteúdo
completo do LSA/LSP, com exceção dos campos de idade (LS Age no OSPF e Remaining
Lifetime no IS-IS). A soma de verificação é essencialmente usada para verificar se duas
instâncias LSA/LSP com o mesmo SN têm de fato o mesmo conteúdo. No entanto, no OSPF,
a soma de verificação também é usada para classificar a atualização.

FIGURA 6.16: Geração de instâncias sucessivas de (a) LSAs ou (b) LSPs.
Geração de instâncias sucessivas de LSAs ou LSPs Quando um roteador precisa

originar uma nova instância LSA/LSP (por exemplo, porque possui informações de
roteamento mais recentes que precisam ser disseminadas pela rede), ele incrementa o
SN em um em relação ao anterior instância e define a idade para o valor inicial, que é
zero em OSPF e 20 minutos em IS-IS. Esse processo é ilustrado na Figura 6.16.
A atualização das instâncias LSA/LSP é determinada por três atributos: o SN,

a idade e a soma de verificação. O SN é retirado do espaço linear de números
de 32 bits. A idade expressa a idade de uma instância; aumenta de zero para 1
hora em OSPF, e diminui de 20 minutos para zero em IS-IS. A soma de
verificação é usada principalmente para determinar se duas instâncias com o
mesmo SN têm o mesmo conteúdo.
6.5.2 Determinando qual LSA e LSP é mais recente

As regras para determinar qual LSA/LSP é mais recente estão resumidas na Figura
6.17. Eles dependem dos atributos de atualização introduzidos na Seção 6.5.1: SN,
idade e checksum.
Papel do valor final de idade Tanto OSPF quanto IS-IS atribuem um significado especial
ao valor final de idade, em relação ao frescor de LSAs/LSPs: em uma situação de
igualdade de outros fatores que definem frescor, um LSA/LSP com idade igual ao valor
final é sempre considerado o mais recente. Conforme discutido na Seção 6.5.3, esse
recurso é usado tanto no OSPF quanto no IS-IS para a exclusão de LSAs/LSPs.
OSPF No OSPF, uma instância LSA com um SN maior é sempre considerada mais
recente. A soma de verificação é usada como desempate quando duas instâncias LSA
têm o mesmo SN e a soma de verificação mais alta vence. A idade é usada como desempate

FIGURA 6.17: Determinando qual instância LSA ou LSP, A ou B, é mais recente.
quando duas instâncias LSA têm o mesmo SN e checksum. Nesse caso, se apenas uma instância tiver uma
idade de 1 hora (MaxAge*), essa instância será considerada mais recente. Caso contrário, se as idades
diferirem em mais de 15 minutos (MaxAgeDiff*), o LSA com menor idade é considerado mais fresco. Por fim,
se as idades diferirem em 15 minutos ou menos, as instâncias são consideradas igualmente novas.
IS-IS No IS-IS, a atualização de um LSP é determinada principalmente pelo SN e pela idade (Remaining
Lifetime). A soma de verificação é usada para verificar se dois LSPs com o mesmo SN têm o mesmo conteúdo
e, ao contrário do OSPF, não é usada para classificar o frescor. Uma instância com um SN maior é sempre
considerada mais recente. Se duas instâncias tiverem o mesmo SN, o IS-IS usa a soma de verificação para
verificar se seus conteúdos são iguais. Se as somas de verificação forem as mesmas e uma das instâncias
tiver idade zero, essa instância será considerada mais recente. Caso contrário, se as duas instâncias tiverem
o mesmo SN, mesma soma de verificação e ambas tiverem idade diferente de zero ou ambas tiverem idade
zero, elas serão consideradas igualmente novas. Finalmente, quando duas instâncias têm o mesmo SN, mas
somas de verificação diferentes, uma condição de erro é gerada; as ações tomadas neste caso serão
discutidas na Seção 6.5.4.

Uma instância LSA/LSP com SN mais alto é sempre considerada mais recente.
No OSPF, o checksum é usado como desempate se duas instâncias LSA tiverem
o mesmo SN (maior soma de verificação vence), e a idade é usada como
desempate se duas instâncias tiverem o mesmo SN e checksum (menor idade
vence, exceto se a idade igual ao valor final). No IS-IS, o checksum é usado para
verificar se duas instâncias LSP com o mesmo SN possuem o mesmo conteúdo.
Tanto no OSPF quanto no IS-IS, se duas instâncias tiverem o mesmo SN e
checksum, mas uma tiver uma idade igual ao valor final, essa instância será
considerada mais recente. Este recurso é usado na exclusão de LSAs/LSPs.
6.5.3 Exclusão de LSAs e LSPs

Conforme mencionado na seção anterior, as indicações para excluir LSAs/LSPs são
fornecidas por meio do atributo age. Especificamente, tanto no OSPF quanto no IS IS,
quando um roteador deseja excluir um LSA/LSP, ele inunda a instância mais recente do
LSA/LSP, mas com uma idade igual ao valor final definido, ou seja, 1 hora no caso de LSAs
e zero segundos no caso de LSPs. Essas instâncias são disseminadas pela rede por serem
consideradas mais recentes que as instâncias armazenadas com o mesmo SN e idade
diferente do valor final.
Ao chegarem a um roteador, o roteador substitui a instância armazenada pela que está
chegando, pois esta é mais recente e, em seguida, apaga a instância do LSDB, pois a
instância tem uma idade igual ao valor final. Curiosamente, a especificação OSPF chama
esse mecanismo de envelhecimento prematuro.
As indicações de exclusão no OSPF carregam desnecessariamente o LSA completo,
enquanto no IS-IS eles carregam apenas o cabeçalho LSP.
Na Seção 10.4 , ilustramos por meio de experimentos o processo de exclusão de LSAs
e LSPs.
Tempo de guarda entre a indicação de exclusão e a próxima instância de LSA ou LSP Na
Seção 2.4.6 destacamos a necessidade de um tempo de guarda entre a indicação de
exclusão de um LSA/LSP e o flooding da próxima instância de LSA/LSP, tendo o mesmo
NR identificador e um SN igual ao valor inicial.
Em OSPF e IS-IS este guard-time é implementado através da restrição imposta ao tempo
mínimo entre transmissões LSA/LSP sucessivas, que é de 5 segundos em ambas as
tecnologias (ver Seção 6.4.3).
Qual roteador pode excluir um LSA ou LSP? No OSPF, a indicação para excluir um LSA só
pode ser emitida pelo roteador que originou o LSA. No IS IS, a indicação para excluir um
LSP pode ser emitida, em algumas situações especiais, por roteadores que não o originaram.
Um caso importante é quando o DIS muda.
Aqui, o novo DIS, além de inundar o novo Pseudonode-LSP, também deve deletar o
Pseudonode-LSP originado pelo DIS anterior. A vantagem deste procedimento é que o
antigo Pseudonode-LSP não permanece no LSDB até que expire, ocupando recursos de
memória desnecessariamente.

FIGURA 6.18: Ações na recepção de LSAs e LSPs.
Quando um roteador deseja excluir um LSA/LSP, ele inunda uma instância

do LSA/LSP com o SN atual e uma idade igual ao valor final, ou seja, 1 hora
em OSPF e zero segundos em IS-IS. Esta instância é considerada a mais
recente e, portanto, substitui a armazenada ao chegar em um roteador, mas
é deletada imediatamente, pois sua idade é igual ao valor final.
6.5.4 Ações na recepção de LSAs e LSPs Quando um LSA/LSP é
recebido em um roteador, o roteador executa uma ou mais ações que dependem

principalmente da atualização relativa dos LSAs/LSPs recebidos e armazenados e se
os LSAs/LSPs recebidos O LSA/LSP é auto-criado, ou seja, está sendo recebido pelo
originador do LSA/LSP. O comportamento do OSPF e do IS-IS difere ligeiramente a
esse respeito. Na Figura 6.18, resumimos as ações executadas por um roteador na
recepção de LSAs/LSPs. Na figura, o LSA/LSP de entrada é identificado pela letra “I”
e o LSA/LSP armazenado pela letra “S”. Primeiro dividimos as ações em dois grupos,
diferindo se o LSA/LSP recebido é auto-originado ou não: as ações 1 a 4 pertencem
ao primeiro grupo e as ações 5 a 8 ao segundo.

6.5.4.1 O LSA/LSP de entrada não é auto-originado
Ação 1 Se a atualização do LSA/LSP de entrada for maior que a armazenada ou se o LSA/LSP de

entrada for novo (inexistente no LSDB), o roteador deverá substituir a instância armazenada pela
entrada ou instalar a nova e inundar o LSA/LSP. Este comportamento é o mesmo em OSPF e IS-IS.
Observe que o LSA/LSP recebido pode ser uma indicação para excluir o armazenado, mas, mesmo
nesse caso, a ação é substituir e inundar; a indicação para excluir tem idade igual ao valor final e,
por isso, é imediatamente excluída após ser armazenada.
Ações 2 e 3 Quando o frescor do LSA/LSP entrante for igual ou menor que o armazenado, então o
LSA/LSP entrante deve ser descartado, pois não é novo e, portanto, seu flooding deve ser
interrompido. O IS-IS realiza uma ação adicional quando o frescor do LSA/LSP de entrada é menor
do que o armazenado: ele transmite o LSP armazenado através da interface onde o LSP de entrada
foi recebido, para garantir que o vizinho de envio seja atualizado corretamente.
Ação 4 Conforme mencionado na Seção 6.5.2, no IS-IS, quando dois LSPs possuem o mesmo SN
mas checksums diferentes, uma condição de erro é gerada, pois os LSPs possuem o mesmo SN
mas conteúdos diferentes. Quando isso acontece, o roteador define a idade do LSP como zero,
fazendo com que ele expire, e inunda a instância expirada (ou seja, uma indicação de exclusão)
para remover o LSP do domínio de roteamento.
O OSPF não executa uma ação específica neste caso, simplesmente usando a soma de verificação
para classificar o frescor do LSA.
6.5.4.2 A entrada de LSA/LSP é auto-originada O recebimento de
LSAs/LSPs auto-originados é uma ocorrência relativamente comum, por exemplo, durante o

processo de inundação. O que não é tão frequente é receber LSAs/LSPs auto-gerados mais
atualizados (por exemplo, com SN mais alto) do que a última instância gerada pelo roteador. Isso
pode acontecer quando um roteador é desligado e ligado antes da expiração de seus LSAs/LSPs
auto-gerados em roteadores vizinhos.
Observe que um roteador que recebe um LSA/LSP autogerado pode não estar mais interessado
nele. Por exemplo, isso acontece no OSPF quando um roteador recebe um Network-LSA auto-
originado e não é mais o DR do link correspondente. Este Network-LSA, se ainda estiver
armazenado no roteador, está envelhecendo e aguardando para ser removido.
Ações 5 e 6 Se o frescor do LSA/LSP recebido for maior que o armazenado, e o roteador ainda
estiver interessado no LSA/LSP, ele deve inundar uma nova instância com o SN incrementado em
um em relação ao SN recebido . Esse comportamento é o mesmo em OSPF e IS-IS e garante que
as encarnações anteriores de LSAs/LSPs originados sejam substituídas pelas instâncias mais
atualizadas desses LSAs/LSPs. O IS-IS também executa a mesma ação quando o

os LSPs recebidos e armazenados têm os mesmos SNs, mas somas de verificação diferentes (ou
seja, conteúdos diferentes).
Ação 7 Se o frescor do LSA/LSP de entrada for igual ou inferior ao armazenado, e o roteador ainda
estiver interessado no LSA/LSP, nenhuma ação deve ser tomada e o LSA/LSP deve ser descartado,
pois o LSA/LSP não é novo. Esse comportamento é o mesmo em OSPF e IS-IS e também é
semelhante às ações 3 e 4.
Ação 8 Também pode acontecer que o roteador de recebimento não esteja mais interessado no LSA/
LSP de entrada ou que o LSA/LSP de entrada não esteja mais armazenado no roteador. A ação a ser
tomada é definir a idade do LSA/LSP de entrada para o valor final e inundar a instância expirada (ou
seja, uma indicação de exclusão) para remover o LSA/LSP da rede.
As ações a serem tomadas quando um LSA/LSP chega a um roteador dependem

principalmente da atualização relativa da entrada e da instância LSA/LSP armazenada (se
existir) e se o LSA/LSP recebido é auto-originado. Quando o LSA/LSP de entrada não for
auto-originado, se sua atualização for maior do que a da instância armazenada ou se não
houver LSA/LSP armazenado, o LSA/LSP de entrada substituirá o armazenado ou será
instalado pela primeira vez , e é subseqüentemente inundado; caso contrário, é descartado.
Quando o LSA/LSP recebido é auto-originado, pode acontecer que seu frescor seja maior
que o armazenado. Isso significa que o LSA/LSP de entrada está desatualizado e o roteador
deve inundar uma nova instância do LSA/LSP com o SN incrementado em um em relação
ao de entrada. Além desse comportamento geral, existem outros eventos que levam a
ações específicas tanto no OSPF quanto no IS-IS.
6.5.5 Geração não solicitada de LSAs e LSPs Como os LSAs/LSPs têm um
atributo de idade e ficam envelhecidos, a idade precisa ser atualizada (ou seja, redefinida para o valor
inicial) antes de atingir seu valor final. Caso contrário, em condições estáveis (ou seja, se não houver
alterações na rede), os LSAs/LSPs atingiriam (suavemente) sua vida útil e seriam eliminados do
LSDB, causando mau funcionamento da rede. A atualização da idade é realizada gerando, em algum
momento, novas instâncias LSA/LSP com o SN incrementado em um, e a idade é redefinida para o
valor inicial. O intervalo de atualização precisa ser menor que o tempo de vida das instâncias LSA/
LSP. No OSPF, o intervalo de atualização é de 30 minutos (chamado LSRefreshTime*) e no IS-IS é
de 15 minutos (chamado maximumLSPGenerationInterval*).
Para evitar a expiração prematura de LSAs/LSPs, novos LSA/LSP em instâncias com SN

incrementado em um são gerados quando a idade da instância anterior atinge 30 minutos,
em OSPF, ou 15 minutos, em IS-IS.

6.5.6 Envolvimento de SNs

O OSPF e o IS-IS lidam de maneira diferente com o problema do wraparound, que foi
discutido na Seção 2.4.8. O OSPF exclui explicitamente a instância LSA com o SN mais
alto quando há uma solicitação para inundar uma nova instância LSA, enquanto o IS-IS
congela a instância LSA até que ela expire. Assim, o wraparound é mais rápido no OSPF.
Em particular, no OSPF, quando o roteador de origem precisa inundar uma nova instância
LSA e a atual tem SN igual ao valor final (0×7fffffff), ele primeiro exclui a instância atual
usando o mecanismo de envelhecimento prematuro descrito na Seção 6.5 . 3 e, em
seguida, inunda a nova instância LSA com o valor SN inicial (0 × 80000001). No IS-IS,
quando o SN atinge o valor final (0×ffffffff), a atualização da instância LSP atual congela
por 21 minutos (MaxAge* + ZeroAgeLifetime*), para garantir que ela expire antes de
transmitir uma nova instância LSP com o valor SN inicial (0 × 00000001).
Dado o intervalo de 5 segundos entre sucessivas transmissões LSA/LSP (ver Seção

6.4.3) e o espaço SN de 32 bits, levaria mais de 600 anos para ir do valor SN mais baixo
ao mais alto! Isso mostra claramente que o SN wraparound é um evento raro.
No OSPF, quando há uma tentativa de aumentar o SN de um LSA além do valor

final (o problema do wraparound), o roteador de origem primeiro exclui o LSA e
só então inunda a nova instância do LSA com um SN igual ao valor inicial. No IS-
IS, quando o SN de um LSP atinge o valor final, o originador congela sua
atualização por 21 minutos, para garantir que o LSP expire no LSDB de todos
os roteadores, antes de inundar uma nova instância LSP com um SN igual a o
valor inicial.
6.5.7 Expiração de idade de LSAs e LSPs Quando uma
instância LSA/LSP armazenada em um LSDB expira, ou seja, quando sua idade atinge o
valor final (seu tempo de vida), alguma ação precisa ser executada. A ação depende se
o roteador é o originador do LSA/LSP. A Figura 6.19 resume essas ações.
OSPF No OSPF, quando um LSA expira em seu roteador de origem, o roteador inunda
uma indicação de exclusão para remover o LSA do LSBD de todos os outros roteadores
e, subseqüentemente, limpa o LSA de seu próprio LSDB. Quando o LSA expira em um
roteador não originário, o roteador simplesmente limpa o LSA de seu LSDB.
IS-IS O processo no IS-IS é semelhante com duas exceções. Primeiro, quando um LSP
expira, ele permanece um minuto adicional no LSDB antes de ser purgado (esse
parâmetro é chamado de ZeroAgeLifetime*). Em segundo lugar, qualquer roteador, e não
apenas o originador do LSP, deve inundar as instâncias LSP expiradas. À primeira vista,
esse procedimento parece levar a uma inundação de LSPs. No entanto, os LSPs tendem
a expirar aproximadamente ao mesmo tempo. Portanto, é altamente provável que um
LSP expirado sendo inundado encontre instâncias armazenadas recentemente com igual atualização

FIGURA 6.19: Ações na expiração de LSAs e LSPs.
(mesmo SN e idade zero), caso em que será descartado, diminuindo as chances de uma
enchente. No entanto, esses recursos adicionais usados pelo IS-IS parecem desnecessários.
Quando a idade de um LSA/LSP expira no roteador de origem, o roteador deve

inundar uma indicação de exclusão para remover o LSA/LSP da rede e limpar o
LSA/LSP de seu LSDB. Outros roteadores apenas limpam o LSA/LSP do LSDB,
exceto no IS-IS, onde os roteadores também inundam uma indicação de exclusão.
6.5.8 Proteção contra corrupção de LSAs e LSPs

Tanto o OSPF quanto o IS-IS tomam medidas para proteger contra a corrupção de LSAs/
LSPs. A proteção é baseada na soma de verificação calculada sobre a maioria de seus
campos. O checksum não é computado sobre o campo idade (LS Age, no caso de OSPF, e
Remaining Lifetime, no caso de IS-IS), para permitir a atualização da idade sem recalcular o
checksum. A corrupção de LSAs/LSPs pode ocorrer em duas situações: durante a
transmissão entre dois roteadores ou enquanto reside na memória de um roteador. A
primeira situação é muito mais frequente do que a segunda, devido à falta de fiabilidade de
alguns meios de comunicação. Para lidar com a primeira situação, a soma de verificação é
verificada sempre que uma instância LSA/LSP chega a um roteador e, se a soma de
verificação for inválida, a instância que chega é descartada.
A segunda situação é tratada por meio da verificação periódica da soma de verificação de
todos os LSAs/LSPs armazenados em um roteador. No OSPF, isso ocorre sempre que a
idade das instâncias armazenadas atinge um múltiplo de 5 minutos (CheckAge*) e no IS-IS
a cada 15 minutos (máximo LSPGenerationInterval). Se for detectada uma falha na soma
de verificação, o processo de roteamento deverá ser reiniciado.
6.6 Sincronização LSDB inicial Dois roteadores que se
tornam adjacentes podem precisar sincronizar seus LSDBs.

Tanto no OSPF quanto no IS-IS, um roteador deve sincronizar seu LSDB com todos os seus

ExStart Intercâmbio Carregando Completo
FIGURA 6.20: Evolução dos estados durante uma sincronização inicial LSDB bem-
sucedida no OSPF.
vizinhos em enlaces ponto a ponto e com vizinhos selecionados em enlaces

compartilhados; no caso do IS-IS, sincroniza com o DIS e, no caso do OSPF, com o DR
e o BDR. O processo inicial de sincronização do LSDB começa assim que os dois
roteadores se tornam adjacentes por meio do protocolo Hello e tem duas fases, a
primeira para anunciar o resumo do LSDB e a segunda para recuperar LSAs/LSPs
específicos. OSPF e IS-IS usam métodos ligeiramente diferentes para a sincronização
inicial do LSDB, nenhum deles aderindo exatamente ao protocolo da Seção 2.5. Vamos
explicá-los nas próximas seções.
Os roteadores OSPF e IS-IS sincronizam seus LSDBS com todos os seus

vizinhos em links ponto a ponto; em links compartilhados, a sincronização é
com o DR e o BDR, no caso de OSPF, e com o DIS, no caso de IS-IS.
6.6.1 OSPF
No OSPF, o processo de sincronização LSDB é definido por meio de uma máquina de
estado detalhada, que faz parte da máquina de estado vizinha, e é descrita na Seção
10 da especificação OSPF [36]. A evolução dos estados durante um processo de
sincronização bem-sucedido é mostrada na Figura 6.20. Um roteador mantém uma
máquina de estado separada para cada instância de sincronização que estabelece.
As sincronizações são por interface de vizinho, e não apenas por vizinho.
Por exemplo, dois roteadores conectados por dois links paralelos ponto a ponto devem
sincronizar em ambos os links.
Suporte a pacotes O processo de sincronização LSDB do OSPF é suportado em quatro
tipos de pacotes de controle: (i) pacotes DB DESCRIPTION anunciam o resumo LSDB,
(ii) pacotes LS REQUEST solicitam LSAs específicos, (iii) pacotes LS UP DATE
transportam LSAs completos e (iv) pacotes LS ACKNOWLEDGMENT reconhecem a
recepção de LSAs completos.

6.6.1.1 Processo de descrição do banco de dados
Dois roteadores iniciam um processo de sincronização LSDB estabelecendo uma relação

mestre/escravo e trocando cabeçalhos LSA usando pacotes DB DESCRIÇÃO. O vizinho
com o RID mais alto se torna o mestre. A troca de pacotes DB DESCRIPTION é protegida
por meio de um protocolo Stop-and-Wait (SW) (consulte a Seção 1.8.1). Esse processo é
chamado de descrição do banco de dados na especificação OSPF.
Estados do processo de descrição do banco de dados O processo de descrição do banco

de dados é ainda dividido em dois estados: o primeiro para eleger o master (chamado
ExStart) e o segundo para trocar os cabeçalhos LSA (chamado Exchange).
O processo é controlado por três sinalizadores: o bit I, definido enquanto o roteador está
nos estados ExStart; o bit M, definido se o roteador tiver cabeçalhos LSA adicionais para
enviar; e o bit MS, definido sempre que o roteador acredita que é o mestre.
Proteção de transmissões DB DESCRIPTION Conforme mencionado acima, a troca de
pacotes DB DESCRIPTION é protegida por um protocolo SW.
O protocolo SW é controlado pelo mestre, e os números de sequência correspondentes
estão contidos no campo DD Sequence Number dos pacotes DB DESCRIÇÃO (ver
Figuras 6.2 e 6.4); vamos nos referir a esses números de sequência como ddSN, para
evitar confusão com os números de sequência das instâncias LSA.
Estado ExStart No início do estado ExStart, cada roteador se considera mestre. O pacote
inicial pode ser enviado por qualquer roteador; ele terá um ddSN arbitrário definido pelo
roteador de envio e os três sinalizadores de controle definidos.
Um roteador que recebe este pacote determina se é mestre ou escravo comparando seu
RID com o RID do vizinho, contido no pacote recebido (campo Router ID). A partir daí
apenas o mestre toma a iniciativa de enviar pacotes DB DESCRIPTION, e o escravo
apenas responde a esses pacotes usando o ddSN do mestre. Os pacotes enviados pelo
escravo servem como confirmação dos pacotes enviados pelo mestre e vice-versa. O
mestre incrementa o ddSN em um a cada novo pacote que envia, exceto no caso de
retransmissões. Para o pacote inicial, que pode ser enviado pelo mestre ou pelo escravo,
e para quaisquer pacotes subsequentes enviados pelo mestre, se a resposta não for
recebida dentro de um intervalo de tempo predefinido (chamado RxmtInterval), o pacote é
retransmitido usando o mesmo ddSN .
Estado Exchange A transição do estado ExStart para o estado Exchange ocorre quando
um roteador descobre que é o escravo (ou seja, recebe um pacote com os três bits de
controle definidos e o RID vizinho é maior que o seu) ou quando recebe a confirmação de
que é o mestre (ou seja, recebe um pacote com o bit I e o bit MS limpos e o RID vizinho é
menor que o seu próprio).
Quando um roteador entra no estado Exchange, ele coloca todos os seus cabeçalhos LSA
em uma lista chamada lista de resumo do banco de dados e transmite esses cabeçalhos
para o vizinho em pacotes DB DESCRIPTION. Observe que vários pacotes podem ser
necessários para transmitir todos os cabeçalhos LSA contidos na lista de resumo do banco
de dados. Os cabeçalhos LSA são removidos da lista quando sua recepção é confirmada
pelo vizinho.

Uso do M-bit O padrão OSPF [36] não é muito claro sobre como um roteador abandona o
estado Exchange e, em particular, sobre o manuseio do M-bit.
O padrão parece implicar que o bit M é limpo assim que o último cabeçalho LSA é transmitido
pela primeira vez (essa também é a interpretação dada na Figura 6.7 de [11]). Especificamente,
em sua Seção A.3.3 (página 196), a especificação diz em relação ao bit M: “Quando definido
como 1, indica que mais pacotes de descrição do banco de dados devem seguir”. No entanto,
analisando o comportamento das implementações existentes (ver Seção 10.5.1) concluímos
o seguinte:
• O bit M só é limpo quando a lista de resumo do banco de dados fica vazia, ou seja, quando
a recepção de todos os cabeçalhos LSA foi confirmada;
• Ambos os roteadores devem sinalizar ao vizinho que a lista de resumo do banco de dados
foi esvaziada, ou seja, um roteador deve enviar pelo menos um pacote DB DESCRIPTION
com o bit M limpo;
• O escravo abandona o estado Exchange quando recebe um DB DESCRIP

pacote TION do mestre com o bit M limpo e sua lista de resumo do banco de dados está
vazia;
• Da mesma forma, o mestre abandona o estado Exchange quando recebe um pacote DB

DE SCRIPTION do escravo com o M-bit limpo e sua lista de resumo do banco de dados
está vazia.
Observe que o mestre é sempre o último a abandonar o estado Exchange.

Quando isso acontece, o processo de descrição do banco de dados termina e nenhum outro
pacote DB DESCRIPTION é enviado.
6.6.1.2 Processo de carregamento
Solicitando LSAs Quando um roteador recebe cabeçalhos LSA (durante o estado Exchange),
ele compara as informações recebidas com as armazenadas em seu LSDB.
Se o roteador verificar que o vizinho tem instâncias mais recentes de LSAs ou LSAs
existentes, o roteador está ausente, ele coloca os IDs de LSA correspondentes em uma lista
chamada Lista de solicitação de estado de link e transmite esses IDs para o vizinho em
pacotes LS REQUEST. Observe que, ao contrário dos pacotes DB DESCRIPTION, os
pacotes LS REQUEST não carregam cabeçalhos LSA completos, mas apenas LSA IDs, ou
seja, os três campos que identificam um LSA. Ao receber um LS REQUEST, o vizinho
responde inundando os LSAs completos em um pacote LS UPDATE.
Os IDs LSA são removidos da lista de solicitação de estado de link quando os LSAs
correspondentes forem recebidos (em pacotes LS UPDATE). Um roteador pode começar a
enviar pacotes LS REQUEST mesmo antes do término do processo de descrição do banco
de dados.
Proteção de solicitações LSA A transmissão de cabeçalhos LSA contidos em pacotes LS
REQUEST é protegida por ACK usando RxmtInterval como período de tempo limite: se um
LSA solicitado não for recebido dentro desse intervalo, a solicitação será

retransmitido. Além disso, pode haver apenas um pacote LS REQUEST de cada vez.
Transmissão de LS REQUESTs e LS UPDATEs em links compartilhados Em links

compartilhados, um LS REQUEST é direcionado ao vizinho que contém o LSA solicitado
(esse vizinho só pode ser o DR ou o BDR); assim, o pacote é enviado para o endereço
unicast do vizinho e não para um endereço multicast OSPF. Da mesma forma, os
pacotes LS UPDATE enviados em resposta aos pacotes LS RE QUEST são
transmitidos em unicast para o vizinho solicitante.
Atingindo o estado Full Quando o processo de descrição do banco de dados termina, o
roteador pode passar para o estado Loading ou para o estado Full. Ele se moverá
imediatamente para o estado Completo se a lista de solicitações do estado do link
estiver vazia, o que significa que todas as solicitações enviadas ao vizinho (se houver)
foram atendidas. Caso contrário, o roteador passa para o estado de carregamento.
Nesse estado, ele continuará enviando pacotes LS REQUEST para o vizinho até que
sejam atendidos por pacotes LS UPDATE e a lista de solicitações de estado do Link
fique vazia, momento em que passa para o estado Full. Quando o estado Full é
atingido, o processo de sincronização LSDB termina. Nesse estado, diz-se que o
roteador está totalmente adjacente ao seu vizinho.
Comparação com o protocolo genérico O protocolo utilizado pelo OSPF não é
significativamente diferente daquele da Seção 2.5, sendo a principal diferença que o
OSPF não utiliza um pacote para solicitar o sumário LSDB. Isso não é necessário, pois
o OSPF começa elegendo um mestre, que posteriormente controla a troca de resumos
LSDB. Além disso, os três pacotes restantes da Seção 2.5 têm todos um equivalente
em OSPF: LSDB SUMMARY é o equivalente a DB DESCRIPTION, PARTIAL LSDB
REQUEST o equivalente a LS REQUEST e UPDATE o equivalente a LS UPDATE.
6.6.1.3 Lidando com LSAs autogerados desatualizados
Um cenário importante, discutido na Seção 2.5.3, ocorre quando um roteador é

desligado e ligado novamente e encontra em um vizinho encarnações anteriores de
LSAs auto-originados, ou seja, instâncias desatualizadas desses LSAs com atualização
maior ou igual.
Lembre-se de que os vizinhos trocam informações resumidas sobre os LSAs
armazenados em seus LSDBs durante a fase de descrição do banco de dados (usando
pacotes DB DE SCRIPTION). Assim, durante esta fase, um roteador aprende se seu
vizinho possui LSAs originados por ele com maior frescor do que os que acabou de
criar. Se for o caso, o roteador solicita ao vizinho a transmissão dos LSAs completos
(usando pacotes LS REQUEST); esse comportamento é comum a todas as instâncias
LSA com atualização mais alta encontradas no vizinho e não é específico de LSAs auto-
originados.
Porém, quando o roteador recebe um LSA auto-originado de um vizinho com frescor
maior que o armazenado, ele executa a ação 5 da Seção 6.5.4; inunda uma nova
instância do LSA com o SN incrementado em um

em relação ao SN recebido do vizinho. Isso garante que todos os outros roteadores

recebam a instância LSA mais atualizada.
O caso de SNs iguais Um cenário que vale a pena considerar é quando as instâncias
antigas e novas têm o mesmo SN (lembre-se de que o frescor dos LSAs é definido
por SN, checksum e idade). Esse cenário pode acontecer se um roteador for ligado,
desligado e ligado novamente, sem esperar muito tempo entre essas ações. Neste
caso, e de acordo com as regras de atualização do OSPF, o checksum é o desempate.
Existem três possibilidades ao comparar o frescor da nova instância (recém-criada
pelo roteador) e a instância antiga (deixada no vizinho):
• A nova instância tem um checksum maior que a instância antiga - Nesse caso, a
nova instância é considerada mais recente. O vizinho solicitará a instância como
parte do processo de sincronização LSDB (usando um pacote LS REQUEST) e a
inundará por toda a rede. Assim, a rede LSDB acabará sendo atualizada com as
informações mais recentes.
• A nova instância tem um checksum menor do que a instância antiga - Nesse caso, a
instância antiga é considerada mais recente. Assim, de acordo com a regra acima
(ação 5 da Seção 6.5.4), o roteador inundará uma nova instância do LSA com o SN
incrementado em um. Novamente, a rede LSDB acabará sendo atualizada com as
informações mais recentes.
• As instâncias novas e antigas têm checksum igual - Neste caso nada acontecerá, e
as informações desatualizadas permanecem na rede até que a próxima instância
do LSA seja gerada, o que pode levar até 30 minutos (LSRefreshTime*). No entanto,
a probabilidade de ter a mesma soma de verificação, mas conteúdos diferentes, é
muito baixa.
6.6.1.4 Exemplo
Considere o exemplo da Figura 6.21, ilustrando o processo inicial de sincronização

LSDB entre os roteadores R1 e R2, com RIDs 1.1.1.1 e 2.2.2.2, respectivamente. R1
foi desligado e ligado novamente antes da expiração de seus LSAs auto-originados no
LSDB de R2. Suponha que quando R1 é ligado, R2 contém em seu LSDB um roteador-
LSAs relativo aos roteadores R1, R2 e R3.
A figura mostra a troca de pacotes após o estabelecimento da relação de vizinhança,
ou seja, após os roteadores entrarem no estado ExStart. A troca de pacotes segue os
seguintes passos:
1. Suponha que R1 seja o primeiro a enviar um pacote DB DESCRIPTION.

Ele escolhe um ddSN de 634, define o bit MS porque acredita ser o mestre,
define o bit I porque está no estado ExStart e define o bit M porque tem
cabeçalhos LSA para enviar.
2. Ao receber o pacote, R2 verifica se seu RID é maior que o do vizinho. Assim,

ele responde com um pacote DB DESCRIPTION

RID = 1.1.1.1 RID = 2.2.2.2
R1 R2
ExStart ExStart
DESCRIÇÃO DO BD, ddSN = 634, I=1,M=1,MS=1

1
2
Intercâmbio 3
Cabeçalho do Roteador-LSA, R1, SN=1

4 Intercâmbio

5
6
Carregando 7 DESCRIÇÃO DO BD, ddSN = 8968, I=0,M=0,MS=0

8 Completo
LS PEDIDO
9
LSA ID do roteador-LSA, R1, SN=5
LSA ID do roteador-LSA, R2, SN=7 10
LSA ID do roteador-LSA, R3, SN=2
LS ATUALIZAÇÃO
Roteador completo -LSA, R1, SN=5

Completo 11
LS ATUALIZAÇÃO
Roteador Completo -LSA, R1, SN=6
tempo
FIGURA 6.21: Exemplo de sincronização LSDB inicial (OSPF).
ter um novo ddSN (ddSN = 8966) e o bit MS definido, pois agora é certo ser o
mestre.
3. Ao receber o pacote de R2, R1 passa para o estado Exchange e envia, em outro
pacote DB DESCRIÇÃO, o cabeçalho de seu único e recém-criado LSA, um
Roteador-LSA com SN=1. Nesse pacote, R1 limpa o bit I, pois abandonou o
estado ExStart. Ele também limpa o bit MS e usa o ddSN do anteriormente

pacote recebido (ddSN = 8966), pois agora ele sabe que é o escravo.
4. R2 recebe este pacote DB DESCRIPTION e passa para o estado Exchange, pois

o vizinho confirmou que não é o mestre. Além disso, R2 analisa o cabeçalho
LSA de entrada, verifica se há uma instância mais recente desse LSA
armazenada em seu LSDB e conclui que não está interessado em seu conteúdo
completo. Por fim, R2 envia um pacote DB DESCRIPTION contendo todos os
seus cabeçalhos LSA, com o ddSN incrementado em um (ddSN = 8967).
5. O pacote recebido nesta etapa confirma a correta recepção do cabeçalho LSA

enviado anteriormente por R1. Assim, R1 remove o cabeçalho de sua lista de
resumo do banco de dados e, como a lista ficou vazia, ele envia um pacote DB
DESCRIÇÃO com o bit M limpo. Além disso, com base nos cabeçalhos LSA de
entrada, R1 verifica se está faltando o roteador-LSAs de R2 e R3 e se o vizinho
possui uma instância mais recente de seu roteador-LSA auto-originado.
Portanto, ele coloca os cabeçalhos LSA correspondentes em sua lista de
solicitações de estado do Link para solicitar posteriormente a transmissão de
seu conteúdo completo.
6. Como no passo anterior, este pacote confirma a recepção correta dos três
cabeçalhos LSA enviados anteriormente por R2. Assim, R2 esvazia sua lista de
resumo do banco de dados e envia um pacote DB DESCRIP TION com o bit M
limpo e com o mesmo ddSN (8967).
7. Quando R1 recebe este pacote, ele entra no estado Loading, já que sua lista de
requisições Link state não está vazia, significando que R1 ainda precisa receber
LSAs completos de R2. R1 também responde com um pacote DB DESCRIPTION
com o mesmo ddSN (ddSN = 8968).
8. Ao receber este pacote, R2 entra no estado Full, pois sua lista de requisições de
Link state está vazia. Nesse ponto, R2 conclui o processo de descrição do banco
de dados.
9. R1 solicita o conteúdo completo dos LSAs contidos em sua lista de solicitação de
estado de link usando um pacote LS REQUEST unicast para R2. Essa etapa
poderia ter ocorrido antes, assim que R1 determinou que precisava solicitar
LSAs completos do vizinho.
10. Ao receber os pacotes LS REQUEST, R2 responde enviando o conteúdo completo
dos LSAs solicitados em um pacote LS UPDATE, unicast para R1.
11. Quando R1 recebe o pacote LS UPDATE, ele entra no estado Full, pois concluiu
o recebimento dos LSAs solicitados. Agora, como R1 recebeu uma instância de
um Router-LSA autogerado com um SN maior (com SN=5), ele cria uma nova
instância desse LSA (com SN=6) e a inunda por toda a rede.

Os experimentos da Seção 10.5.1 ilustram a sincronização LSDB inicial do OSPF.
No OSPF, o processo de sincronização LSDB entre duas interfaces vizinhas evolui

de acordo com quatro estados. Ao se tornarem adjacentes através do protocolo
Hello, os roteadores passam a trocar pacotes DB DESCRIÇÃO, eleger um mestre
para o controle da fase de comunicação subseqüente (estado ExStart) e trocar
cabeçalhos LSA (estado Ex change). Com base nos cabeçalhos LSA recebidos,
ambos os roteadores verificam se estão faltando alguma instância LSA e, em caso
afirmativo, solicitam-nas ao vizinho usando um pacote LS REQUEST; o vizinho
responde com um pacote LS UPDATE contendo o conteúdo completo dos LSAs
solicitados (estado de carregamento). Os vizinhos tornam-se totalmente adjacentes
quando recebem todos os LSAs solicitados (estado completo).
6.6.2 IS-IS
O IS-IS usa um processo ligeiramente diferente do OSPF para a sincronização inicial do
LSDB. Os roteadores não estabelecem um relacionamento mestre-escravo antes de trocar
os cabeçalhos LSP. Além disso, o processo de sincronização difere substancialmente em
links ponto a ponto e compartilhados.
Suporte a pacotes A sincronização LSDB inicial é suportada em três tipos de pacotes de
controle:
• Os CSNPs fornecem o resumo LSDB do roteador de envio. Eles são usados em links
ponto-a-ponto e compartilhados e carregam apenas resumos LSP (através de LSP
Entries TLVs). Os CSNPs são equivalentes aos pacotes DB DESCRIPTION do OSPF.
• Os PSNPs têm funções diferentes em links ponto a ponto e compartilhados. Em enlaces

ponto-a-ponto, são utilizados para reconhecer a recepção de LSPs (neste papel, são
equivalentes ao pacote LS ACKNOWLEDGMENT do OSPF).
Em links compartilhados, são utilizados para solicitar a transmissão de LSPs de um
vizinho (neste papel, são equivalentes ao pacote LS REQUEST do OSPF). PSNPs
carregam apenas resumos LSP (através de LSP Entries TLVs).
• LINK STATE PDUs transportam, entre vizinhos, os Nonpseudo node-LSPs e Pseudonode-

LSPs completos necessários para sincronizar seus LSDBs.
Eles são equivalentes aos pacotes LS UPDATE do OSPF. No entanto, os PDUs LINK
STATE podem transportar apenas um LSP, enquanto os LS UPDATEs podem transportar
vários LSAs.
6.6.2.1 Enlaces ponto a ponto
Quando dois roteadores se tornam adjacentes em um link ponto a ponto, eles imediatamente
enviam um ao outro seus Nonpseudonode-LSPs auto-originados. Cada roteador também

envia ao vizinho um CSNP contendo seu resumo LSDB, para fornecer informações resumidas
sobre os LSPs atualmente armazenados em seu LSDB. Se, com base nessas informações, o
vizinho detectar que o roteador está faltando alguns LSPs ou possui instâncias desatualizadas de
LSPs existentes, o vizinho envia ao roteador os LSPs completos. Observe que, diferentemente do
caso de links compartilhados, cada roteador transmite apenas um CSNP em links ponto a ponto.
O CSNP não é protegido por ACK e, portanto, pode não ser recebido pelo vizinho. No entanto,
inicialmente, o roteador também agenda a transmissão de todos os seus LSPs completos para um
momento posterior. Este atraso, se suficiente, permite receber o CSNP do vizinho e cancelar a
transmissão dos LSPs completos para os quais o vizinho já possui a instância mais recente.
A transmissão de LSPs completos é protegida por ACK usando os PSNPs como confirmações.
Assim, ambos os vizinhos são inicialmente sincronizados mesmo se os CSNPs forem perdidos.
Podemos dizer que durante a sincronização inicial do LSDB em links ponto-a-ponto, o IS-IS atrasa
a transmissão de todos os seus LSPs completos para um vizinho, esperando receber mais cedo,
via CSNP, informações resumidas sobre os LSPs que o vizinho realmente precisa receber.
6.6.2.2 Links compartilhados
A sincronização inicial do LSDB em links compartilhados é semelhante ao mecanismo de inundação

confiável explicado na Seção 6.4.2. Ele também conta com a transmissão periódica do resumo
LSDB pelo DIS. Além disso, similarmente aos enlaces ponto a ponto, quando um roteador
estabelece uma nova adjacência em um enlace compartilhado, ele transmite seus LSPs auto-
originados no enlace.
Um roteador não DIS que acabou de ingressar em um link compartilhado espera para receber
o primeiro CSNP do DIS. Se o roteador, com base no resumo LSDB incluído no CSNP, verificar
que o DIS possui informações mais recentes, ou seja, LSPs desconhecidos ou instâncias mais
recentes de LSPs conhecidos, ele enviará um PSNP ao DIS solicitando esses LSPs. Assim, no
caso de links compartilhados, os PSNPs assumem um papel similar aos pacotes LS REQUEST do
OSPF. O roteador continua enviando PSNPs até receber o LSP solicitado.
Além disso, um roteador não DIS também toma a iniciativa de enviar um LSP para o DIS se
verificar, com base nos CSNPs recebidos, que o LSP é desconhecido do DIS ou que o DIS possui
uma instância mais antiga do LSP. A recepção correta de LSPs não é explicitamente reconhecida
usando PSNPs, como é o caso de links ponto-a-ponto. Em vez disso, a transmissão periódica de
CSNPs atua como um reconhecimento implícito; se um roteador não DIS não vir o LSP transmitido
listado no próximo CSNP transmitido pelo DIS, ele retransmite esse LSP no link. Observe que os
pacotes IS-IS são transmitidos em links compartilhados usando endereços multicast de camada 2
direcionados a todos os roteadores IS-IS. Assim, quando um roteador não-DIS enviar um LSP e
houver vários outros vizinhos interessados neste LSP, todos irão recebê-lo (se o LSP não for
perdido) e, portanto, não precisarão mais solicitá-lo ao DIS.

6.6.2.3 Lidando com LSPs desatualizados de origem própria
Durante o processo inicial de sincronização do LSDB, um roteador pode encontrar

em um vizinho encarnações anteriores de seus LSPs auto-gerados. Esses LSPs
podem ter um SN igual ou superior ao LSP recém-criado pelo roteador, mas com
informações desatualizadas. Esta questão foi discutida na Seção 2.5.3.
Conforme explicado nas seções anteriores, quando um roteador estabelece uma
nova adjacência, ele envia ao vizinho seus LSPs auto-originados. Ao receber esses
LSPs, o vizinho verifica se possui instâncias armazenadas desses LSPs. Em caso
afirmativo, ele compara seu frescor e, caso tenham os mesmos SNs, compara suas
somas de verificação. Existem dois casos em que a instância armazenada no vizinho
se encontra desatualizada:
• A atualização da instância armazenada no vizinho é maior que a de entrada - Neste

caso, de acordo com a ação 3 da Seção 6.5.4, o vizinho envia de volta ao originador
do LSP informações sobre esta instância LSP desatualizada e seu SN. Essas
informações podem ser fornecidas de duas maneiras: usando um CSNP ou enviando
o LSP completo para o roteador. O CSNP anuncia apenas informações resumidas,
mas esse resumo inclui o SN dos LSPs, que é tudo o que é necessário nesse caso.
Fornecer esta informação através de CSNPs é sempre possível em links ponto-a-
ponto (ambos os roteadores podem fazê-lo), mas em links compartilhados apenas o
DIS pode fazê-lo (já que apenas o DIS pode enviar CSNPs em links compartilhados).
Finalmente, quando o originador do LSP recebe a informação de que um vizinho
tem uma encarnação anterior de um LSP originado por si mesmo com maior frescor,
ele executa a ação 5 da Seção 6.5.4: inunda uma nova instância do LSP, com o SN
incrementado em um em relação ao SN mantido pelo vizinho.
• Os SNs da instância armazenada no vizinho e das instâncias recebidas são os

mesmos, mas as somas de verificação são diferentes - Neste caso, o roteador
executa a ação 4 da Seção 6.5.4 : define a idade do LSP para zero segundos
( Remaining Lifetime) e inunda esta indicação de exclusão.
Finalmente, quando o LSP originador recebe esta indicação de delete, ele executa
a ação 5 da Seção 6.5.4, pois a indicação de delete é considerada mais recente que
a armazenada: inunda uma nova instância do LSP com o SN incrementado em um
em relação ao o SN mantido pelo vizinho.
Na Seção 10.5.2.3, ilustramos por meio de um experimento o papel da soma de

verificação no processo de sincronização LSDB inicial IS-IS.
6.6.2.4 Exemplos
Enlaces ponto a ponto Considere o exemplo da Figura 6.22. Da mesma forma que no
exemplo OSPF, R1 é desligado e ligado novamente, antes da expiração de seu
Nonpseudonode-LSP auto-originado em R2. Além disso, R2 contém um Nonpseudonode-
LSP do roteador R3. Na figura, os LSPs são identificados por meio de seus IDs de
LSP. Inicialmente, R1 e R2 enviam um ao outro seus dados completos

SID = 0000.0000.0001 SID = 0000.0000.0002
R1 R2
LSP completo, R1.00-00, SN=1

1

2
CSNP
3
Resumo LSP, R1.00-00, SN=1

CSNP
4


5

6
PSPN
7
PSPN
8
Resumo do LSP, R1.00-00, SN=8
tempo
FIGURA 6.22: Exemplo de sincronização LSDB inicial (enlaces ponto a ponto IS-IS).
Nonpseudonode-LSPs auto-originados (etapas 1 e 2). O Nonpseudonode LSP de R1

tem SN=1, e o de R2 tem SN=4. Os roteadores também enviam entre si CSNPs
contendo seus resumos LSDB (etapas 3 e 4). R1 anuncia seu Nonpseudonode-LSP
(R1.00-00 com SN=1), e o Nonpseudonode LSP recém-recebido de R2 (R2.00-00
com SN=4). R2 anuncia seu próprio Nonpseudonode-LSP (R2.00-00 com SN=4), o de
R3 (R3.00-00 com SN=9), e um Nonpseudonode-LSP de R1 (R1.00-00 com SN =7)
com um SN maior que o criado por R1. Observe que R2 já recebeu o Nonpseudonode-
LSP mais novo de R1 (R1.00-00 com SN=1, criado após R1 ter sido ligado), mas o
descartou por ter um SN menor que o armazenado.
Com base no CSNP enviado por R1 (na etapa 3), R2 descobre que R1 está perdendo
o Nonpseudonode-LSP de R3 e decide enviá-lo (etapa 5). Além disso, com base

no CSNP enviado por R2 (no passo 4), R1 descobre que R2 tem uma instância de seu
Nonpseudonode-LSP, e decide inundar uma nova instância deste LSP com o SN incrementado
em um (passo 6). As transmissões de LSPs são confirmadas usando PSNPs. Na etapa 7, R1
confirma a recepção de R2.00-00 (com SN=4) e R3.00-00 (com SN=9); no passo 8, R2 confirma
a recepção de R1.00-00 (com SN=8).
Na Seção 10.5.2.2 , ilustramos por meio de um experimento o processo inicial de

sincronização LSDB do IS-IS em enlaces ponto a ponto.
Links compartilhados Considere agora o exemplo da Figura 6.23. Assuma que R2 é o DIS e,
como nos exemplos anteriores, R1 é ligado e desligado depois de um tempo. Ao se tornarem
adjacentes, R1 e R2 transmitem no enlace seus próprios LSPs originados. R1 transmite seu
Nonpseudonode-LSP (R1.00-00 com SN=1) (step 1) e R2 transmite seu Nonpseudonode-LSP
(R2.00-00 com SN=8) (step 2) e também o Pseudonode-LSP ( R2.01-00 com SN=1) que
representa o link compartilhado de trânsito onde R2 é o DIS (etapa 3). R2 também transmite a
encarnação anterior do Nonpseudonode-LSP de R1 (R1.00-00 com SN=4) (passo 4), pois R1
transmitiu (no passo 1) o mesmo LSP mas com SN inferior.
Ao receber este LSP, R1 transmite no enlace uma nova instância do LSP, com o SN incrementado
em um em relação ao SN recebido (R1.00-00 com SN=5) (passo 5). O próximo pacote visto no
exemplo (passo 6) é o CSNP transmitido por R2 (já que é o link DIS). Neste pacote, R2 anuncia
R1.00-00 com SN=5, R2.00-00 com SN=8, R2.01-00 com SN=1 e R3.00-00 com SN=7. Com
base nessas informações, R1 descobre que ainda está faltando o Nonpseudonode-LSP de R3.
Ele solicita esse LSP usando um PSNP (etapa 7) e R2 responde com o LSP completo (etapa 8).
Na Seção 10.5.2.1 ilustramos por meio de um experimento o LSDB inicial

processo de sincronização de IS-IS sobre links compartilhados.
No processo de sincronização LSDB inicial IS-IS, os roteadores começam transmitindo

no link seus LSPs auto-originados. As etapas subsequentes são diferentes em links
ponto a ponto e compartilhados. Em enlaces ponto a ponto, cada roteador envia para
seu vizinho um CSNP contendo seu resumo LSDB e agenda a transmissão de todos
os seus LSPs completos para um momento posterior. A transmissão de um LSP é
cancelada se o roteador descobrir, através dos CSNPs recebidos, que o vizinho já
possui a instância mais recente daquele LSP. Em links compartilhados, o processo
inicial de sincronização do LSDB é baseado na transmissão periódica de CSNPs,
realizada pelo DIS. Um roteador não DIS que ingressa no enlace aguarda o próximo
CSNP transmitido no enlace e, com base em seu conteúdo, solicita ao DIS os LSPs
que faltam ou para os quais possui instâncias mais antigas, utilizando um PSNP.

SID = 0000.0000.0001 SID = 0000.0000.0002
R1 R2 (DIS)

1

2

3

4

5
CSNP
6
Cabeçalho LSP, R1.00-00, SN=5
PSPN
7

8
tempo
FIGURA 6.23: Exemplo de sincronização LSDB inicial (links compartilhados IS-IS).
6.7 Originação e exclusão de informações de roteamento

Agora damos uma explicação mais detalhada sobre quando os LSAs e os LSPs são
realmente originados. Deixamos esse assunto para a última seção, pois a origem dos
LSAs/LSPs depende das máquinas de estado do protocolo e das ações descritas nas
seções anteriores. Algumas das questões abordadas nesta seção já foram introduzidas
nas anteriores.
Novas instâncias LSA/LSP devem ser criadas ou excluídas quando as informações
de roteamento que elas transmitem mudam. Isso pode acontecer em muitas situações,
por exemplo, quando (i) o custo de uma interface de roteador muda, (ii) um vizinho
falha, (iii) um prefixo é atribuído a (ou removido de) um link ou (iv) um DR é eleito (ou
demitido) em um link compartilhado.
Quando uma nova instância de um LSA/LSP é originada, o SN é incrementado
por um e a idade é definida para o valor inicial (consulte a Figura 6.16).
Geração não solicitada de LSAs e LSPs Um mecanismo comum a OSPF e IS-IS é a
geração não solicitada de LSAs/LSPs.

6.7 Originação e exclusão de informações de roteamento 231
Conforme explicado na Seção 6.5.5, novas instâncias LSA/LSP devem ser criadas antes de
sua expiração (ou seja, antes que sua idade atinja o tempo de vida). Especificamente, uma
nova instância LSA deve ser criada quando a idade da instância anterior atingir 30 minutos
(LSRefreshTime*) e uma nova instância LSP deve ser criada quando a idade da instância
anterior atingir 15 minutos (máximo LSPGenerationInterval*).
Expiração de LSAs e LSPs Outro mecanismo comum a OSPF e IS-IS é a expiração de LSAs/
LSPs. Conforme explicado na Seção 6.5.7, quando um LSA/LSP expira em seu roteador de
origem, o roteador deve originar uma indicação de exclusão para que o LSA/LSP seja removido
do LSDB de outros roteadores. No IS-IS, esse comportamento também é seguido por roteadores
não originários.
Nas próximas seções, detalhamos os procedimentos utilizados pelo OSPF e IS-IS para originar
novas instâncias LSA/LSP (e possivelmente excluí-las).
6.7.1 OSPF
Tanto no OSPFv2 quanto no OSPFv3, os roteadores originam Router-LSAs, Network-LSAs e
AS-External-LSAs. Os roteadores OSPFv3 também originam Link-LSAs e Intra Area-Prefix-
LSAs. Isso é verdade para redes de área única. Como será visto no Capítulo 7, em redes OSPF
hierárquicas os roteadores originam outros tipos de LSAs.
De acordo com a especificação OSPF [36], em geral, o conteúdo de um LSA pode mudar
quando (i) o estado de uma interface muda, (ii) o DR muda, ou (iii) o relacionamento com um
roteador vizinho muda para/ do estado Pleno. Ressaltamos que, quando a máquina de estados
vizinha está envolvida, é a entrada ou saída do estado Full que dita a origem dos LSAs/LSPs.
Roteador-LSAs Um Roteador-LSA descreve um roteador e suas interfaces. Ele é criado em um

roteador imediatamente após a ativação de um processo OSPF e deve ser excluído quando o
processo OSPF for desativado. A decisão sobre quando adicionar ou remover uma interface
para um roteador-LSA depende do vizinho e das máquinas de estado da interface e de várias
ações de configuração.
No caso de um link ponto a ponto, um roteador adiciona/remove uma descrição de link tipo
1 (link ponto a ponto) quando atinge/abandona o estado Full com o vizinho correspondente (e
somente neste ponto). Isso é verdade para OSPFv2 e OSPFv3. Além disso, no caso do
OSPFv2, adiciona/remove uma descrição de link tipo 3 (link to stub network) assim que a
interface é ligada/desligada, e independentemente do estado do vizinho. Lembre-se da Seção
5.7.1 que as descrições de link tipo 3 não estão incluídas no OSPFv3 Router-LSAs.
No caso de um link compartilhado (OSPFv2 e OSPFv3), uma descrição do link tipo 3 é

adicionada quando a interface é ligada e entra no estado Waiting.
No caso de um link compartilhado stub, a interface permanece neste estado. Caso contrário,
se a interface estiver conectada a um link compartilhado de trânsito, o roteador adiciona um tipo 2

descrição do link (link to transit network) ao seu Roteador-LSA e remove a descrição do link 3
quando (i) for o link DR e ficar totalmente adjacente a pelo menos um outro roteador ou quando
(ii) não for o link DR e torna-se totalmente adjacente ao DR. O roteador substitui a descrição
do link 2 pela descrição do link 3 se essas condições cessarem e remove a descrição do link
se a interface for desligada. É possível que um roteador conectado a um link compartilhado de
trânsito anuncie primeiro um Roteador-LSA com uma descrição de link tipo 3 caracterizando a
interface e, quando o DR for eleito, substitua essa descrição por uma descrição tipo 2
(originando então um novo Roteador instância -LSA); lembramos que, em um cenário de
partida a frio, a eleição do DR leva aproximadamente 40 segundos.
Network-LSAs Um Network-LSA descreve um link compartilhado de trânsito e seus roteadores

conectados. É criado pelo link DR quando estabelece sua primeira adjacência completa no link
compartilhado; o DR atualiza posteriormente o LSA quando ele se torna totalmente adjacente
a novos vizinhos no link ou quando as adjacências existentes são encerradas. O Network-LSA
deve ser excluído quando o roteador de origem deixar de ter pelo menos um vizinho totalmente
adjacente ou quando o roteador perder sua função de DR. Esse comportamento é o mesmo
em OSPFv2 e OSPFv3.
AS-External-LSA AS-External-LSAs descrevem prefixos externos ao domínio de roteamento

OSPF e são originados por ASBRs. Um novo AS-External LSA é originado sempre que o
ASBR aprende um novo prefixo de domínio externo (por exemplo, através do protocolo de
roteamento entre domínios) e deve ser removido quando o ASBR perde o prefixo (por exemplo,
porque o protocolo de roteamento entre domínios indicou que o prefixo não existe mais).
Link-LSAs (OSPFv3) Um roteador origina um Link-LSA para cada link ao qual está conectado,
se houver pelo menos um outro roteador conectado ao link. Este LSA anuncia o endereço local
de link IPv6 e os prefixos de endereço IPv6 atribuídos a uma interface de link (consulte a
Seção 5.9). Assim, quando um desses endereços é alterado, uma nova instância de Link-LSA
é originada. O Link-LSA deve ser deletado quando o roteador deixar de ter vizinhos no link.
Intra-Area-Prefix-LSAs (OSPFv3) Um Intra-Area-Prefix-LSA descreve os prefixos IPv6

associados a um roteador. Esses prefixos podem ser atribuídos ao próprio roteador ou a seus
links conectados diretamente.
Um prefixo atribuído a um link compartilhado de trânsito é anunciado através de um Intra
Area-Prefix-LSA originado pelo link DR (o LSA é referenciado ao Network-LSA que descreve o
link topologicamente). Porém, conforme apontado na Seção 5.9, esses prefixos não precisam
ser configurados no DR; eles podem ser configurados em outros roteadores conectados ao
mesmo link e comunicados ao DR por meio de Link-LSAs. Assim, cada DR examina os Link-
LSAs associados à interface onde está o DR para determinar quais prefixos devem ser
adicionados/removidos ao/do seu Intra-Area-Prefix-LSA. Especificamente, o anúncio de DR
veicula apenas os prefixos anunciados em Link-LSAs originados por roteadores totalmente
adjacentes; ele também anuncia seus próprios prefixos associados à interface.
Prefixos atribuídos ao próprio roteador ou a outros tipos de links (ex.

6.7 Originação e exclusão de informações de roteamento 233
links compartilhados de ponto e stub) são anunciados por meio de Intra-Area-Prefix-

LSAs referenciados ao Roteador-LSA que representa o roteador. Esses prefixos são
adicionados ao LSA assim que são configurados no roteador e são excluídos quando
removidos do roteador.
Conforme apontado na especificação OSPFv3 [8], um roteador pode precisar
mover um prefixo de um Intra-Area-Prefix-LSA para outro. Por exemplo, isso acontece
quando um roteador é anexado a um link compartilhado stub (com um prefixo atribuído)
e o link muda para um link compartilhado de trânsito (porque um segundo roteador
está conectado a ele). Neste caso, o prefixo atribuído ao link compartilhado foi
inicialmente anunciado por um Intra-Area-Prefix-LSA referenciado a um Router-LSA, e
deve ser transferido para um Intra-Area-Prefix-LSA referenciado à Network-LSA que
representa (topologicamente) o link compartilhado de trânsito recém-criado.
Alterações nos custos de interface Note que novos Router-LSAs e Intra-Area Prefix-
LSAs (OSPFv3) devem ser originados quando o custo de uma interface é reconfigurado
em um roteador.
Alterações no identificador LSA Além disso, qualquer ação de configuração que
envolva a alteração do identificador LSA (por exemplo, o roteador RID), causa a
exclusão de todos os LSAs anteriormente originados pelo roteador e a origem de
novos (com o novo LSA ID).
6.7.2 IS-IS
Os roteadores IS-IS originam apenas dois tipos de LSPs: Nonpseudonode-LSPs e
Pseudonode-LSPs. A especificação IS-IS [1] não é tão detalhada quanto a do OSPF
em relação à origem dos LSPs. O IS-IS não possui um estado equivalente ao estado
Full do OSPF. Em eventos de originação que envolvem relacionamentos de
vizinhança, o que dita a originação de um LSP é a criação ou destruição de uma
adjacência.
De acordo com a especificação IS-IS, os eventos que acionam a origem de um
LSP são: (i) uma adjacência subindo/descendo, (ii) mudança de status do circuito
(somente L1, somente L2, L1/L2), (iii) alteração do DIS, (iv) alteração do SID, (v)
alteração do custo da interface e (vi) inserção/remoção de um endereço.
A origem de LSAs e LSPs é desencadeada por vários eventos e ações, como

uma adjacência subindo ou descendo, a inserção ou remoção de um prefixo,
alterando o custo de uma interface, a expiração de um LSA ou LSP e uma
mudança de designado roteador.


7
Redes Hierárquicas OSPF e IS-IS
As estruturas multiárea de OSPF e IS-IS são restritas a uma hierarquia de dois níveis, com apenas
uma área permitida no nível superior. As áreas de nível inferior devem se conectar diretamente à
superior, de modo que todo o tráfego entre as áreas de nível inferior seja forçado a cruzar a superior.
Isso é ilustrado na Figura 7.1.
A estrutura de redes hierárquicas OSPF e IS-IS já foi apresentada no capítulo de visão geral
(consulte a Seção 4.3 e a Figura 4.1). Tanto o OSPF quanto o IS-IS usam a abordagem de
roteamento de vetor de distância (DVR) para o roteamento entre áreas discutido na Seção 3.2.3.
As áreas são identificadas por meio de um identificador de área, conhecido como Area ID ou
AID. Tanto no OSPFv2 quanto no OSPFv3, o Area ID é um número de 32 bits, exclusivo dentro do
domínio de roteamento e expresso na notação decimal com ponto usada para endereços IPv4. O
Area ID do backbone é sempre 0.0.0.0, por isso o backbone também é chamado de área 0. No IS-
IS, o Area ID faz parte do identificador completo do roteador, ou seja, a NET, conforme discutido na
Seção 5.2 . 1. Ao contrário do OSPF, não há um ID de área específico reservado para o backbone.
Conforme explicado na Seção 4.3, no OSPF cada interface do roteador deve ter um ID de área
assinado e todas as interfaces conectadas ao mesmo link devem pertencer
área de nível superior
ABR ABR
áreas de nível inferior
comunicações diretas entre áreas de

nível inferior não são permitidas
FIGURA 7.1: Comunicação entre áreas de nível inferior em redes hierárquicas OSPF e IS-IS.
235

236 7 Redes Hierárquicas OSPF e IS-IS
para a mesma área. Os ABRs têm uma interface conectada ao backbone, com um ID de área
atribuído de 0.0.0.0, e uma ou mais interfaces conectadas a áreas de nível inferior, cada uma
atribuída a um ID de área diferente de 0.0.0.0. Lembre-se da discussão na Seção 6.2.3.2 de que,
no OSPF, as interfaces do roteador são impedidas de estabelecer relacionamentos de vizinhança
se não pertencerem à mesma área.
No IS-IS, os Area IDs são atribuídos a todo o roteador e não a interfaces individuais. No
entanto, mais de um ID de área pode ser configurado em um roteador.
Para oferecer suporte ao roteamento hierárquico, o IS-IS usa dois tipos de LSDB (os LSDBs L1 e
L2) e dois tipos de adjacências (as adjacências L1 e L2). As adjacências L1 e L2 trocam apenas
informações de roteamento relativas aos LSDBs L1 e L2, respectivamente. Os roteadores são
classificados de acordo com o tipo de adjacências que suportam: roteadores L1 suportam apenas
adjacências L1, roteadores L2 suportam apenas adjacências L2 e roteadores L1/L2 suportam
ambos os tipos de adjacências.
Além disso, uma adjacência L1 só pode ser estabelecida com dois roteadores se eles tiverem pelo
menos uma área em comum; As adjacências L2 não são restritas pelas áreas configuradas.
Consequentemente, uma rede IS-IS hierárquica pode ser configurada da seguinte maneira
(consulte a Figura 4.1):
• Os roteadores de borda de área são roteadores L1/L2, pois devem suportar adjacências L1 e L2.
Além disso, como os roteadores devem receber um ID de área, os roteadores L1/L2 devem ser
configurados com um ID de área de nível inferior;
• O backbone é implementado através de adjacências L2;
• As áreas de nível inferior são implementadas através de adjacências L1.
Estrutura do capítulo Neste capítulo, começamos comparando, na Seção 7.1, as estruturas

hierárquicas de OSPF e IS-IS. Em seguida, a Seção 7.2 mostra como o roteamento por vetor de
distância se aplica ao caso de redes hierárquicas. A Seção 7.3 apresenta a estrutura LSDB e os
vetores de distância de OSPF e IS-IS.
Finalmente, a Seção 7.4 discute várias restrições que podem levar à seleção de caminhos não
ótimos em redes hierárquicas.
7.1 Comparação da estrutura hierárquica OSPF e IS-IS

turas
As estruturas das redes hierárquicas OSPF e IS-IS são geralmente consideradas muito diferentes.
Essa ideia parece estar enraizada na forma como os roteadores OSPF e IS-IS lidam com os Area
IDs: no OSPF os Area IDs são por interface e no IS-IS são por roteador. No entanto, como se
verá, esta não é uma diferença significativa.
No OSPF, cada interface recebe um ID de área e os ABRs mantêm um LSDB para cada área
à qual estão diretamente conectados, ou seja, para cada ID de área distinto.

7.1 Comparação das estruturas hierárquicas OSPF e IS-IS 237
O IS-IS distingue entre interfaces anexadas ao backbone e interfaces anexadas

a áreas de nível inferior, não através do ID de área como no OSPF, mas através do
tipo de adjacência: conexões ao backbone são feitas através de adjacências L2 e
conexões a áreas de nível inferior são feitas através de adjacências L1. No entanto,
ainda resta uma questão: parece que um roteador L1/L2 só é capaz de se conectar a
uma única área de nível inferior, pois deve ser atribuído a ele um ID de área de uma
área de nível inferior. Essa restrição IS-IS estava presente nas primeiras
implementações, mas os fornecedores já oferecem soluções que a superam,
explorando as duas funcionalidades que descrevemos a seguir.
A primeira característica vem da especificação inicial do IS-IS [1], que já suportava
a possibilidade de atribuir diferentes Area IDs a um único roteador. Os vários IDs de
área são anunciados por meio do TLV de endereços de área, que apresentamos na
Seção 5.6.4. De acordo com a Seção 7.1.5 da especificação, esta característica foi
pensada para facilitar a reconfiguração de áreas dentro de um domínio sem
interromper o funcionamento da rede (ver também Seção 7.4.8 de [11]). No entanto,
suas consequências são mais amplas. O que isso significa efetivamente é que um
roteador pode ter mais de um NET atribuído a ele, desde que difiram apenas no ID da
área. Assim, embora os roteadores IS-IS sejam identificados pela NET e a NET
incorpore o Area ID, levando-nos a pensar que um roteador deve pertencer a uma
única área, o fato é que aos roteadores podem ser atribuídos diferentes NETs, um
para cada área que eles estão diretamente ligados e, portanto, podem ser vistos como
pertencentes a todas essas áreas. Infelizmente, a literatura IS-IS insiste em enfatizar
que os roteadores de borda IS-IS pertencem a uma única área e que esta é uma
diferença marcante em relação ao OSPF. Não é!
A segunda funcionalidade, esta já agregada pelos fornecedores, é a possibilidade
de associar os Area IDs configurados em um roteador com interfaces específicas.
Esse recurso às vezes é chamado de suporte multiárea IS-IS [2]. Neste caso, um
roteador L1/L2 mantém um L1 LSDB distinto para cada área de nível inferior, ou seja,
para cada Area ID distinta, assim como no OSPF. Observe que a adição desse
recurso não cria nenhum problema de interoperabilidade; é apenas uma questão de
suporte local nos roteadores e não requer a adição de novos TLVs. Tal recurso não
parece estar no espírito da especificação inicial do IS-IS, mas a especificação
certamente não o desautoriza.
Podemos então concluir que a estrutura das redes hierárquicas OSPF e IS IS é
de fato muito semelhante, sendo a principal diferença essencialmente a nomenclatura.
Os roteadores de borda de área são chamados de ABRs em OSPF e roteadores L1/
L2 em IS-IS. Mas ambos armazenam um LSDB por área à qual se conectam
diretamente e ambos trocam informações de endereçamento entre as áreas. O IS-IS
nomeia de maneira diferente o LSDB do backbone (chamado L2 LSDB) e o das áreas
de nível inferior (chamadas L1 LSDBs), mas isso é novamente um problema de
nomenclatura. Em ambos os casos, as interfaces dos roteadores de borda de área
devem estar associadas a áreas específicas. No IS-IS, a interface com o backbone é
a interface L2, e no OSPF é a interface associada à área 0.

Tanto o OSPF quanto o IS-IS restringem suas redes multiárea a uma hierarquia de
dois níveis, onde as áreas de nível inferior só podem se comunicar por meio da
superior. Além disso, ambos usam uma abordagem DVR em seu protocolo de
roteamento entre áreas. Os roteadores de borda de área são chamados de ABRs
em OSPF e roteadores L1/L2 em IS-IS. Tanto no OSPF quanto no IS-IS, cada
interface de roteador de borda de área está associada a uma área e os roteadores
de borda mantêm tantos LSDBs quantas áreas às quais eles se conectam diretamente.
7.2 DVR em redes hierárquicas
Nesta seção, damos um exemplo de DVR no contexto de redes hierárquicas, que se aplica
a OSPF e IS-IS. Essa questão já foi abordada na Seção 3.2.3, no cenário mais geral de
redes multiárea.
Considere a rede da Figura 7.2. Inclui duas áreas de nível inferior (áreas 1 e 2) e o
backbone, com um total de quatro ABRs: R2 e R3 interligam o backbone com a área 1, e
R4 e R5 interligam o backbone com a área 2. Considere o problema de determinar como o
roteador R1 aprende sobre o prefixo ap1 e calcula o caminho mais curto para esse prefixo;
na verdade, R1 só poderá determinar o subcaminho da área 1, de si mesmo para o ABR de
saída. A figura inclui perto de cada interface os custos de interface relevantes para esta
discussão.
Coleta de informações na área 2 Primeiro, os roteadores R4 e R5 coletam informações no

prefixo ap1 usando o LSDB da área 2. Com base nesse LSDB, os ABRs determinam os
caminhos mais curtos (intra-área) de si mesmos para o prefixo.
O custo do caminho mais curto é 10 (5+5) de R4 para ap1 e é 30 (25+5) de R5 para ap1.
Disseminação e computação no backbone Cada roteador então injeta um vetor de distância

no backbone anunciando o prefixo e seu custo de caminho mais curto para ele: R4 anuncia
(ap1, 10) e R5 anuncia (ap1, 30). Os DVs são inundados dentro do backbone, eventualmente
atingindo R2 e R3.
Os roteadores R2 e R3 determinam então os custos do caminho mais curto de cada um
para ap1 combinando duas informações: (i) os custos do caminho incluídos nos vetores de
distância recebidos de R4 e R5, e (ii) os custos do caminho mais curto de cada um para R4
e R5. A última informação é obtida do LSDB do backbone. O caminho mais curto de R2 a
R4 é R2 ÿ R7 ÿ R6 ÿ R4 com um custo de 50, e o de R2 a R5 é R2 ÿ R7 ÿ R5 com um custo
de 20. Usando agora as informações contidas nos DVs, R2 determina que o custo para ap1
via R4 é 50+10=60 e o custo via R5 é 30+20=50, e conclui que o custo de caminho mais
curto que pode fornecer é 50 (via R5). Em seguida, ele injeta essa informação na área 1,
usando o vetor distância (ap1, 50).
O roteador R3 faz o mesmo tipo de computação. O caminho mais curto de R3 a R4 é R3 ÿ

R6 ÿ R7 com um custo de 20, e o caminho de R3 a R5 é R3 ÿ

7.3 Estrutura LSDB e vetores de distância 239
R7
Espinha dorsal
30 10
10
R6
10 (ap1,30)
(ap1,10)
10 10
R2 R3 R4 5 25 R5
(ap1,50) (ap1,30)
R8
10 40 5
R1 ap1
Área 1 Área 2
FIGURA 7.2: Exemplo de DVR em redes hierárquicas.
R6 ÿ R7 ÿ R5 com um custo de 30. Assim, R3 conclui que o custo do caminho mais

curto que pode fornecer para ap1 é 30 (via R4) e injeta essa informação na área 1,
usando o vetor distância (ap1, 30).
Cálculo no roteador R1 Finalmente, R1 decide o caminho para ap1 com base nos DVs
injetados por R2 e R3 e nas informações contidas no LSDB da área 1. O caminho de
R1 para ap1 via R2 custou 10+50=60, e o caminho via R3 custou 40+30=70. Assim,
R1 determina que seu caminho mais curto para ap1 é via R2 com custo de 60, e
insere essa informação em sua tabela de encaminhamento.
7.3 Estrutura LSDB e vetores de distância

O suporte de roteamento hierárquico em OSPF e IS-IS pode exigir a adição de novos
elementos ao LSDB. Além disso, é preciso entender como os vetores de distância são
realmente implementados nas duas tecnologias. A Figura 7.3 resume a correspondência
entre os elementos LSDB do protocolo genérico necessário para disseminar
informações de roteamento entre áreas (apresentado na Seção 3.1.3) e os do OSPF
e do IS-IS.

genérico OSPFv2 OSPFv3
Rede-Resumo-LSA Inter-Area-Prefixo-LSA
área-externa-prefixo-NR IPv4 IS-IS IPv6 IS-IS

(aep-NR)
Informações TLV ou IP Estendido Acessibilidade IPv6 TLV
Acessibilidade TLV
OSPFv2 OSPFv3
AS-Externo-LSA AS-Externo-LSA
domínio-externo-NR
(dep-NR) IPv4 IS-IS IPv6 IS-IS
Informações TLV ou IP Estendido Acessibilidade IPv6 TLV
Acessibilidade TLV
OSPFv2 OSPFv3
domínio-border-router-NR (dbr-
NR) Inter-Area-Router-LSA
ASBR-Resumo-LSA
FIGURA 7.3: Correspondência entre os elementos LSDB necessários para disseminar informações
de roteamento entre áreas do protocolo genérico, OSPF e IS-IS, de uma perspectiva de
informações de roteamento.
7.3.1 OSPF
Informações de roteamento interno de área O OSPF mantém os LSAs de redes de área única
para descrever as informações de roteamento internas a uma área. No OSPFv2, as informações
topológicas e de endereçamento interno da área são fornecidas pelo roteador-LSAs e pela rede-
LSAs. No OSPFv3, as informações topológicas são fornecidas por Router-LSAs e Network-LSAs
e as informações de endereçamento interno de área por Intra-Area-Prefix-LSAs. Dado que a
informação topológica se restringe a descrever uma única área, os ABRs originam tantos Router-
LSAs quantas as áreas a que estão diretamente ligados, mas um Router-LSA injetado numa área
descreve apenas as interfaces pertencentes a essa área. Os Router-LSAs também incluem
informações sobre se o roteador de origem é um ABR ou um ASBR, usando os sinalizadores B-bit
e E-bit: o bit B é definido quando o roteador de origem é um ABR e o E-Bit é definido quando o
roteador de origem é um ASBR.
Informação de endereçamento de área externa No OSPF, os vetores de distância que distribuem

os prefixos de área externa pelas áreas (prefixos externos à área, mas internos ao domínio de
roteamento), ou seja, o equivalente a aep-NR (consulte a Seção 3.1.3) , são o Network-Summary-
LSA no OSPFv2 e o Inter

máscara de rede 4 Métrica 3
Métrica 3 Comprimento do prefixo

1
Opções de prefixo 1
Rede-Resumo-LSA
Prefixo de endereço em
Métrica 3
Inter-Area-Prefixo-LSA
ASBR-Resumo-LSA
Opções 3
Métrica 3
ID do roteador de destino 4
Inter-Area-Router-LSA
FIGURA 7.4: LSAs específicos de (a) OSPFv2 e (b) OSPFv3 hierárquicos.
Área-Prefixo-LSA em OSPFv3 (consulte a Figura 7.4). Esses LSAs são inundados com escopo
de área e, conforme mencionado na Seção 3.2.3, atingem dois objetivos simultaneamente:
eles comunicam os prefixos área-externa entre os ABRs e, ao mesmo tempo, disseminam os
prefixos dentro das áreas, para que se tornem conhecidos por roteadores internos.
Nos Network-Summary-LSAs (OSPFv2), os prefixos anunciados são definidos pelo

endereço IPv4 da sub-rede e pela máscara da sub-rede, carregados nos campos Link State ID
e Network Mask, respectivamente (lembre-se de que o campo Link State ID pertence ao LSA
cabeçalho comum a todos os tipos de LSA). Nos LSAs Inter-Area-Prefix (OSPFv3), as
informações correspondentes são transportadas nos campos Address Prefix e Prefix Length,
respectivamente. O campo Metric de ambos os LSAs é o custo de caminho mais curto do ABR
de origem até o prefixo que ele anuncia.
Cada LSA só pode anunciar um prefixo. O campo Link State ID distingue entre os prefixos de
anúncio de LSAs originados pelo mesmo roteador. Em Network-Summary-LSAs este campo
carrega um endereço IPv4, conforme referido acima; em Inter-Area-Prefix-LSAs, ele carrega
uma tag gerada localmente exclusiva para cada prefixo anunciado.
No OSPF, os vetores de distância que distribuem o endereçamento área-externo

entre as áreas, ou seja, o equivalente ao aep-NR, são o Network Summary-LSA no
OSPFv2 e o Inter-Area-Prefix-LSA no OSPFv3.
Esses LSAs são inundados com escopo de área e também são usados para
disseminar as informações de roteamento dentro das áreas.
Informações de endereçamento externo de domínio OSPFv2 e OSPFv3 usam a abordagem

mista com dep-NRs e dbr-NRs para anunciar informações de afixação de anúncio externo de
domínio em todas as áreas (consulte a Seção 3.4). O equivalente ao dep

NR é o AS-External-LSA, e os equivalentes do dbr-NR são o ASBR Summary-LSA no OSPFv2 e

o Inter-Area-Router-LSA no OSPFv3.
AS-External-LSAs já foram introduzidos no contexto de redes de área única (consulte a Seção
5.8.1): eles descrevem prefixos externos ao domínio e são originados por ASBRs. No OSPF
hierárquico, esses LSAs são inundados com escopo principal, ou seja, ignorando a sobreposição
ABR e, como tal, não trazem informações sobre como rotear para os ASBRs de origem.
Este problema é resolvido através do ASBR-Summary-LSAs, no OSPFv2, e do Inter-Area-

Router-LSAs, no OSPFv3. Esses LSAs são originados por ABRs para descrever os ASBRs das
áreas às quais eles se conectam diretamente e são disseminados como vetores de distância por
meio do protocolo de roteamento entre áreas. Ao contrário de AS-External-LSAs, ASBR-Summary-
LSAs e Inter-Area-Router LSAs são inundados com escopo de área. O AS-External-LSA faz
referência ao ASBR de origem por meio de seu RID, incluído no campo Advertising Router; o
ASBR-Summary-LSA transporta o RID do ASBR de origem no campo Link State ID, e o Inter-Area-
Router-LSA o transporta no campo Destination Router ID. A diferença nos campos usados para
transportar o RID do ASBR de origem reflete o escopo de inundação das mensagens: AS-External
LSAs usam o campo Advertising Router, pois são inundados sem modificações em todo o domínio;
ASBR-Summary-LSAs e Inter-Area-Router-LSAs usam outro campo (o Link State ID), pois o
campo Advertising Router deve ser reservado para identificar os ABRs que originam esses LSAs
enquanto eles estão sendo disseminados no ABR overlay. Nesta solução, os ABRs precisam
saber se existem ASBRs conectados às áreas às quais eles se conectam diretamente. Esta
informação é fornecida pelo E-bit do Router-LSAs.
No OSPF, o AS-External-LSA é inundado usando o escopo do domínio, e as informações

sobre como rotear para o ASBR de origem são fornecidas pelo ASBR-Summary-LSA no
OSPFv2 e pelo Inter-Area-Router LSA no OSPFv3. Os dois últimos LSAs são
equivalentes ao dbr-NR e são disseminados como vetores de distância entre os ABRs.
Originação e exclusão de LSAs Os vetores de distância (ou seja, os Summary LSAs do OSPFv2
e os Inter-Area LSAs do OSPFv3) são originados pelos ABRs sempre que novos destinos (prefixos
ou ASBRs) são adicionados ou as informações de custo relativas a um destino já anunciado são
alteradas . Os anúncios devem respeitar as restrições descritas na Seção 7.4. Além disso,
quando um destino anteriormente anunciado torna-se inacessível, ou quando seu anúncio se torna
proibido devido às restrições da Seção 7.4, o LSA correspondente deve ser excluído.
Na Seção 11.1.2, ilustramos a estrutura LSDB do OSPF hierárquico

redes através de experimentos.
7.3.2 IS-IS
IS-IS não introduz novos elementos LSDBs para suportar roteamento hierárquico.

Informações de roteamento interno de área Como no OSPF, o IS-IS mantém os TLVs de

redes de área única para descrever as informações de roteamento internas a uma área.
A informação topológica é fornecida pelo IS Neighbors TLV ou Ex tented IS Reachability
TLV de Nonpseudonode-LSPs e pelos Pseudonode LSPs. As informações de
endereçamento interno da área são fornecidas pelo IP Internal Reachability Information
TLV ou Extended IP Reachability TLV no IPv4 IS-IS e o IPv6 Reachability TLV no IPv6
IS-IS.
A distinção entre áreas é feita através do tipo LSP: os LSPs que descrevem áreas
de nível inferior são do tipo L1, e os que descrevem a área de nível superior são do tipo
L2. Os roteadores L1/L2 originam LSPs de ambos os tipos. Como no caso dos roteadores-
LSAs, o IS Neighbors TLV ou Extended IS Reachability TLV de uma área descreve
apenas os vizinhos pertencentes àquela
área.
Informações de endereçamento de área externa O IS-IS usa os TLVs de acessibilidade

de IP de redes de área única como vetores de distância, para distribuir os prefixos de
área externa entre os roteadores L1/L2. Conforme mencionado acima, esses TLVs são
o IP Internal Reachability Information TLV ou o Extended IP Reachability TLV em IPv4
IS-IS e o IPv6 Reachability TLV em IPv6 IS-IS; em seu papel de vetores de distância,
eles são equivalentes ao aep-NR introduzido na Seção 3.1.3. O campo Métrico desses
TLVs é o custo de caminho mais curto do roteador L1/L2 de origem até o prefixo
anunciado. O prefixo é definido pelos campos IP Address e Subnet Mask no IP Internal
Reachability Information TLV e os campos Prefix e Prefix Length nos Extended IP
Reachability e IPv6 Reachability TLVs.
Assim como no caso do OSPF, os IP Reachability TLVs cumprem duas funções:

eles comunicam prefixos de área externa entre roteadores L1/L2 e também disseminam
esses prefixos dentro de áreas.
A especificação inicial do IS-IS não permitia a injeção de informações de
endereçamento L2 no L1 LSDB. Assim, roteadores de áreas de nível inferior não tinham
acesso a prefixos externos, e a comunicação com outras áreas só era possível por meio
de rotas padrão apontando para os roteadores L1/L2. Se uma área de nível inferior
tivesse mais de um roteador L1/L2, os roteadores internos usariam o mais próximo no
sentido do custo do caminho. Para isso, os roteadores L1/L2 sinalizam sua presença
definindo o bit ATT em seu L1 Nonpseudonode-LSP (ver Figura 5.12). Esse tipo de
roteamento era cego para a localização real dos destinos e, portanto, o roteamento ideal
globalmente pode não ser alcançado. Para ver isso, considere o exemplo da Figura 7.5,
onde incluímos os custos da interface do roteador.
O caminho mais curto de R1 a R4 é via R3, com um custo de 30. No entanto, se a
informação externa da área não for injetada na área L1 e R1 usar o roteador L1/L2 mais
próximo, então o caminho selecionado é o caminho via R2, com um custo de 40.
Aparentemente, a razão para não permitir a injeção de endereçamento L2 em
formação no L1 LSDB era para evitar a possibilidade de reinjetar essa informação no
backbone, já que não havia como distinguir entre prefixos de área interna e área externa
em IP Internal Reachability Informações TLVs (ver discussão na Seção 7.4.6 de [11]).
O problema foi resolvido

Área 2
R4 (L2)
30 10
R2 (L1/L2) R3 (L1/L2)
10 20
R1(L1)
Área 1
FIGURA 7.5: Consequências da não injeção de prefixos área-externa em áreas L1 -

Exemplo de rede.
através do RFC 2966 [28], que especificava que os oito bits do campo Default Metric
nos TLVs de informações de acessibilidade IP interno e externo, não utilizados até
então, deveriam ser usados para distinguir entre os dois tipos de prefixos. O bit é
chamado de bit Up/Down (U/D) e é definido quando o prefixo correspondente é
injetado por um roteador L1/L2 em uma área de nível inferior, ou seja, quando é um
prefixo de área externa. Este bit também foi incluído no IPv6 Reachability TLV. A
injeção de informações de endereçamento L2 em áreas L1 às vezes é chamada de
vazamento de rota.
No IS-IS, os vetores de distância que distribuem os prefixos área-externa

entre as áreas, ou seja, o equivalente ao aep-NR, são o IP Internal
Reachability Information TLV ou o Extended IP Reachability TLV em IPv4 IS-
IS, e o IPv6 Reachability TLV em IPv6 IS-IS. O bit Up/Down distingue entre
pré-fixos de área interna ou externa dentro de uma área L1 (área de nível
inferior).
Informações de endereçamento externo de domínio O IS-IS usa a abordagem dep-

NR only para anunciar informações de endereçamento externo de domínio entre as
áreas (consulte a Seção 3.4). Como no caso de informações de endereçamento de
área externa, IS-IS usa os TLVs de redes de área única como vetores de distância
para anunciar prefixos externos de domínio entre as áreas. Assim, utiliza o IP
External Reachability Information TLV ou o Extended IP Reachability TLV em IPv4 IS-
IS e o IPv6 Reachability TLV em IPv6 IS-IS, que são equivalentes ao dep-NR. Esses
TLVs são originados por DBRs e ABRs e disseminados como vetores de distância
entre áreas. As informações relevantes estão incluídas nos campos Endereço IP,
Máscara de sub-rede e Métrica padrão (Informações de acessibilidade externa de IP
TLV) ou nos campos Prefixo, Comprimento do prefixo e Métrica (Extended

7.4 Restrições na seleção do caminho mais curto 245
Acessibilidade IP TLV e Acessibilidade IPv6 TLV). O IPv6 Reachability TLV também é usado para
anunciar prefixos internos de domínio; o sinalizador X faz a distinção entre prefixos internos e
externos ao domínio. Observe que a especificação inicial do IS-IS não suportava a presença de
ASBRs em áreas L1, uma vez que o IP External Reachability Information TLV não foi definido para
L1 LSPs; esta situação seria corrigida pelo RFC 2966 [28].
No IS-IS, os prefixos externos ao domínio são divulgados entre as áreas por meio do IP
External Reachability Information TLV ou Extended IP Reachability TLV, no IPv4 IS-IS, e
do IPv6 Reachability TLV, no IPv6 IS-IS. Esses TLVs são originados por DBRs e ABRs e
disseminados como vetores de distância entre os roteadores L1/L2.
Originação e exclusão de TLVs O IS-IS segue regras semelhantes ao OSPF para origem e exclusão
de vetores de distância, que neste caso são os TLVs de acessibilidade IP. Assim, um novo IP
Acessibilidade TLV deve ser originado quando um novo prefixo é adicionado ou o custo do caminho
para um prefixo existente é alterado, sujeito às restrições descritas na Seção 7.4. Além disso, um IP
Reach TLV com habilidade deve ser excluído quando o prefixo correspondente for removido, ou
quando seu anúncio for proibido devido às restrições da Seção 7.4. Lembre-se de que a origem e
exclusão de TLVs implica na criação de novas instâncias dos LSPs aos quais eles pertencem.
Na Seção 11.1.3, ilustramos a estrutura LSDB do IS-IS hierárquico

redes através de experimentos.
7.4 Restrições na seleção do caminho mais curto

Tanto o OSPF quanto o IS-IS impõem duas restrições na forma como os DVs são anunciados que
podem impedir o roteamento ideal globalmente. Esta questão foi discutida na Seção 3.3.
Especificamente, os DVs não podem anunciar dentro de uma área:
• Caminhos para destinos internos à área;
• Caminhos para destinos externos à área que cruzam essa área.
Tomando a rede da Figura 7.6 como exemplo, a primeira restrição mencionada acima proíbe
R3 de anunciar na área 1 o custo do caminho R3 ÿ R4 ÿ R2 ÿ R1 ÿ ap1 mesmo que os caminhos intra-
área R3 ÿ R1 ÿ ap1 ou R3 ÿ R2 ÿ R1 ÿ ap1 tem custo mais alto. A segunda restrição proíbe R3 de
anunciar na área 1 o custo do caminho R3 ÿ R2 ÿ R4 ÿ ap2 mesmo que o caminho R3 ÿ R4 ÿ ap2
tenha custo maior. Conforme discutido na Seção 3.3, a primeira restrição implica que o caminho
selecionado entre um roteador e um destino localizado na mesma área pode não ser o mais curto.

ap2
Área 2
R4
R2 R3
R1
Área 1
ap1
FIGURA 7.6: Restrições na seleção do caminho mais curto - Exemplo de rede.
Outra característica que restringe o processo de seleção de rotas é a preferência dada aos
caminhos intra-área sobre os caminhos inter-áreas ao construir a tabela de encaminhamento.
Tomando novamente a rede da Figura 7.6 como exemplo, esta regra força R3 a selecionar o
caminho intra-área R3 ÿ R4 ÿ ap2 mesmo que o caminho inter-área R3 ÿ R2 ÿ R4 ÿ ap2 tenha
custo menor.
Na Seção 11.2, apresentamos experimentos que ilustram as restrições no processo de
seleção do caminho mais curto de redes hierárquicas OSPF e IS-IS.
OSPF e IS-IS proíbem a injeção de vetores de distância em uma área quando eles
anunciam caminhos para prefixos internos de área ou caminhos para prefixos externos
de área que cruzam a área. Além disso, ao computar sua tabela de encaminhamento,
um roteador deve dar preferência aos caminhos intra-área sobre os caminhos inter-área.
Essas restrições podem impedir que o roteamento ideal globalmente seja alcançado.

Parte IV
Estudos de caso


8
Ferramentas e configurações
Experimentar é um passo importante na aquisição de habilidades efetivas em redes de

computadores. Você não pode se tornar um especialista em redes de computadores
apenas lendo livros! Bem, esta parte do livro propõe e discute um grande número de
experimentos que ilustram as principais características do OSPF e do IS-IS. Os
experimentos foram pensados para serem facilmente reproduzidos pelo leitor (e alguns
deles são bem divertidos!). Eles exigem roteadores IP que implementam OSPF e IS-IS
hierárquicos e de área única para redes IPv4 e IPv6 e um analisador de protocolo.
Entretanto, elas podem ser realizadas em ambiente emulado, ou seja, utilizando apenas
o sistema operacional dos roteadores e não o equipamento real. Em nossos experimentos,
usamos GNS3 como emulador de rede, uma imagem Cisco IOS como sistema
operacional do roteador e Wireshark como analisador de protocolo.
Estrutura desta parte do livro Este capítulo apresenta os principais recursos do GNS3,
Cisco IOS e Wireshark e explica as configurações básicas do roteador. Os próximos
capítulos discutem vários tipos de experimentos. O Capítulo 9 aborda a estrutura das
tabelas de encaminhamento, o processo de seleção de rota e a estrutura LSDB de redes
de área única. O Capítulo 10 discute os mecanismos de sincronização. Finalmente, o
Capítulo 11 aborda as extensões necessárias para suportar redes hierárquicas.
Duas palavras de cautela Não há especificações perfeitas nem implementações perfeitas

de protocolos LSR, nem as ferramentas usadas para emulá-los e analisá-los são perfeitas
(como tudo em nossas vidas...). Assim, ao executar experimentos com protocolos LSR,
você pode se deparar com um comportamento inesperado devido a especificações pouco
claras, bugs de implementação, recursos específicos de fornecedores não documentados,
limitações intrínsecas de hardware e software e assim por diante. Porém, na maioria das
vezes o comportamento inesperado surge porque você não conseguiu entender aquela
parte específica do protocolo... Então, esteja preparado para as surpresas!
Os protocolos LSR são protocolos assíncronos. Uma característica desse tipo de
protocolo é que a sequência de eventos que leva a um determinado resultado pode variar.
Por exemplo, a sequência de pacotes LS UPDATE transmitidos em um link compartilhado
em reação a alguma falha do roteador depende (i) do tempo relativo da detecção da falha
pelos vizinhos do roteador com falha e (ii) da carga dos roteadores e links nas várias
rotas entre os vizinhos e o link compartilhado. A beleza dos protocolos assíncronos - se
estiverem corretos - é que o resultado é sempre o mesmo, independentemente da
sequência de eventos.
249

250 8 Ferramentas e Configurações
Portanto, esteja sempre preparado para uma sequência diferente de eventos ao tentar
reproduzir os experimentos desta parte do livro.
O que é uma rede convergente? Iremos nos referir muitas vezes a redes convergentes.
Uma rede convergente é uma rede em um estado estável. No contexto dos protocolos de
roteamento, isso significa que as informações de roteamento usadas para construir as
tabelas de encaminhamento não mudam e são consistentes em todos os roteadores.
Após um evento como falha de roteador ou inicialização a frio, geralmente há um período
transitório em que a rede está se adaptando às novas condições e as informações de
roteamento são alteradas; no entanto, se o protocolo estiver correto, as informações de
roteamento tornam-se estáveis depois de um tempo. Assim, a convergência da rede é
sempre o ponto final dos experimentos LSR que perturbam a estabilidade da rede.
Uma maneira de determinar se uma rede convergiu em experimentos LSR é observar
os pacotes de controle transmitidos pelos roteadores, por exemplo, usando o Wireshark.
As condições diferem ligeiramente em OSPF e IS-IS. No OSPF, uma rede convergente
é uma rede em que apenas os pacotes HELLO com informações corretas são trocados
entre os roteadores. A informação transmitida por um pacote HELLO está correta se listar
todos os vizinhos do roteador de envio e, em links compartilhados, se listar também os
DR e BDR corretos. As condições IS-IS são as mesmas, exceto em links compartilhados,
onde, além dos pacotes HELLO transmitidos por todos os roteadores, o DIS também
transmite CSNPs periódicos. Nesse caso, a convergência de rede é alcançada quando
os roteadores transmitem apenas pacotes HELLO corretos, e os DISes, além de pacotes
HELLO corretos, também transmitem CSNPs anunciando um resumo LSDB totalmente
atualizado.
8.1 Acostumando-se ao GNS3

GNS3 é um emulador de rede que permite testar configurações de rede usando o sistema
operacional real do equipamento de rede (por exemplo, Cisco IOS ou Junper JUNOS) e
usando o Wireshark para análise de pacotes. Em nossos experimentos usamos a versão
2.1.3 do GNS3.
Para realizar experimentos com dispositivos Cisco, você deve primeiro instalar uma
imagem do Cisco IOS. Outros elementos como os links, os switches Ethernet e os PCs
são fornecidos pelo GNS3.
Painel central A Figura 8.1 mostra a janela principal do GNS3. O painel central exibe a
rede que você configurou. Neste caso, a rede possui cinco roteadores (R1 a R5)
conectados através de links Fast Ethernet, exceto a conexão entre R4 e R5, que é um
link serial. Além disso, o roteador R5 está conectado a um switch Ethernet. As interfaces
são rotuladas com seus nomes.
Painel esquerdo Os dispositivos de rede podem ser arrastados e soltos no painel

esquerdo, onde são organizados em categorias. Por exemplo, no primeiro botão (Browse
Routers) você encontra os roteadores, no segundo (Browse Switches)

8.2 Acostumando-se ao GNS3 251
FIGURA 8.1: Janela principal do GNS3.
os switches, e no último (Adicionar um link) os links. Esses são os elementos de rede necessários
para quase todos os experimentos deste livro.
Painel superior O painel superior inclui botões para as principais ações executadas em uma
rede. Por exemplo, para iniciar todos os dispositivos ao mesmo tempo, clique em Iniciar/Reiniciar
todos os nós e, para interrompê-los, clique em Parar todos os nós. O botão Console conectar a
todos os nós também é muito útil e abre os consoles de todos os dispositivos ao mesmo tempo.
Executando ações em dispositivos individuais Há muitas ações que podem ser executadas em
dispositivos individuais. Para isso, você deve clicar com o botão direito do mouse no dispositivo.
A Figura 8.1 mostra a janela que se abre ao clicar com o botão direito do mouse no roteador R3.
Você pode, por exemplo, Iniciar, Parar ou Recarregar apenas este roteador, pode abrir seu
console (botão Console), configurar o roteador (botão Configurar) ou editar seu arquivo de
configuração de inicialização (botão Editar configuração). Além disso, para executar uma captura
do Wireshark em um link, clique com o botão direito do mouse no link e selecione Iniciar captura.
Estas são apenas as principais características do GNS3; tente explorar outros recursos por conta
própria. Divirta-se!

FIGURA 8.2: Janela principal do Wireshark.
8.2 Acostumando-se com o Wireshark

Wireshark é uma ferramenta de análise de protocolo. Ele pode capturar todos os pacotes que
atravessam uma interface de rede (em ambas as direções) e decodificar seu conteúdo completo,
por exemplo, identifica os protocolos das várias camadas e os endereços de origem e destino. É
uma ferramenta muito útil para especialistas em redes de computadores.
Além disso, o Wireshark é totalmente integrado ao GNS3. Ao emular uma rede usando GNS3,
várias capturas do Wireshark podem ser executadas simultaneamente, para observar diferentes
pontos da rede. Não poderíamos ter um ambiente melhor para estudar redes de computadores!
Além disso, o Wireshark é fácil de instalar e trabalhar. Em nossos experimentos, usamos a versão
2.4.4 do Wireshark.
A Figura 8.2 mostra a janela principal do Wireshark. Neste caso, a janela mostra informações
sobre os pacotes trocados durante uma sincronização inicial do LSDB no OSPF. Destacamos
três áreas principais: (i) a barra de ferramentas do filtro, (ii) o painel da lista de pacotes e (iii) o
painel de detalhes do pacote.
Barra de ferramentas Filtro Um filtro permite que você escolha o que deseja ver. No Wireshark, os
filtros são especificados na barra de ferramentas de filtro e existem muitos filtros predefinidos. Por
exemplo, a palavra-chave ospf, mostrada na Figura 8.2, nos permite ver apenas

8.3 Acostumando-se com o Cisco IOS 253
pacotes OSPF. Em nossos experimentos, usaremos filtros ospf ou isis. O Wireshark nos permite ser
mais específicos em relação a um protocolo. Por exemplo, para ver apenas pacotes OSPF HELLO,
você pode usar o filtro ospf.hello.
Painel da lista de pacotes Imediatamente abaixo da barra de ferramentas do filtro, você encontra o
painel da lista de pacotes. Este painel possui uma linha por pacote observado e exibe as informações
mais importantes sobre cada pacote. Tem sete colunas: (i) No. é o número do pacote, (ii) Time é o
tempo de captura, (iii) Source é o endereço de origem, (iv) Destination é o endereço de destino, (v)
Protocol é o mais alto protocolo de camada decodificado por Wireshark, (vi) Length é o comprimento
do pacote e (vii) Info inclui informações adicionais, como o tipo de pacote.
O número do pacote e o tempo de captura do pacote são relativos ao primeiro pacote observado.
O primeiro pacote observado recebe um número de 1 e um tempo de captura de 0. Os endereços de
origem e destino são os endereços IP, a menos que o pacote não tenha camada IP (que é o caso
dos pacotes IS-IS); neste caso, os endereços MAC de origem e destino (se existirem) são exibidos.
Painel de detalhes do pacote Abaixo do painel da lista de pacotes, você encontra o painel de detalhes
do pacote. Este painel mostra todos os campos do pacote selecionado no painel de lista de pacotes.
Na figura, o pacote selecionado é o pacote 42 (um pacote LS UPDATE) e o painel de detalhes do
pacote mostra seus cabeçalhos Ethernet e IPv4 (não expandidos) e mostra que o pacote OSPF
contém um roteador-LSA com um LS Age de 1 segundo (a maior parte do conteúdo não é mostrada
por falta de espaço).
Como as capturas do Wireshark serão mostradas neste livro Neste livro, mostraremos os resultados
de muitas capturas do Wireshark. No entanto, não os apresentaremos como na Figura 8.2, ou seja,
como instantâneos do Wireshark, porque queremos economizar espaço e adicionar informações
importantes não exibidas no painel de lista de pacotes. O que fazemos é (i) exportar cada captura
para um arquivo Excel, (ii) remover as colunas indesejadas (sempre removeremos a coluna
Comprimento) e (iii) editar a coluna Informações para que inclua as informações mais relevantes para
a explicação do experimento, que extraímos do conteúdo do pacote.
8.3 Acostumando-se com o Cisco IOS

8.3.1 Alguns antecedentes do IOS Um roteador
executa um sistema operacional para gerenciar seus recursos de hardware e software e fornecer
seus serviços. As funções são semelhantes aos sistemas operacionais de nossos computadores
pessoais. O sistema operacional dos roteadores Cisco é chamado de IOS (Internetwork Operating
System). O Cisco IOS pode ser configurado por meio de comandos para executar diferentes tarefas.
Em nossos experimentos, usamos a versão 12.4(25d) de uma imagem Cisco IOS c3725.
Níveis de acesso do Cisco IOS Há dois níveis de acesso aos comandos do Cisco IOS (também
chamados de modos de usuário): o nível EXEC do usuário e o nível EXEC privilegiado

nível. No nível EXEC do usuário, você só tem acesso a alguns comandos, os inócuos
(por exemplo, connect, login, ping e show). No nível EXEC privilegiado, você tem acesso
a todos os comandos, incluindo os mais poderosos e potencialmente destrutivos (por
exemplo, configurar, depurar, apagar e configurar).
Um administrador de rede geralmente trabalha no nível EXEC privilegiado.
O prompt “>”” indica que você está configurando no nível EXEC do usuário e o prompt
“#” indica que você está configurando no nível EXEC privilegiado. Para ir do nível EXEC
do usuário para o nível EXEC privilegiado, você deve inserir o comando enable e uma
senha pode ser solicitada. No GNS3, os roteadores são iniciados no nível EXEC
privilegiado.
Métodos de configuração A configuração de um roteador pode ser (i) entregue via
download de rede, (ii) copiada de uma imagem armazenada na memória do roteador ou
(iii) digitada a partir do terminal. O terceiro método será usado em nossos experimentos,
e o comando configure terminal indica ao Cisco IOS que esse método será usado.
Modos de configuração O Cisco IOS possui vários modos de configuração, que indicam
o elemento do roteador (por exemplo, interface ou protocolo) que está sendo configurado.
O modo de configuração global é o nível de entrada para as configurações do roteador;
os comandos inseridos neste modo afetam todo o roteador. Modos de configuração
importantes no contexto dos experimentos deste livro são o modo interface, onde as
interfaces são configuradas, e o modo roteador, onde os protocolos de roteamento IP
são configurados.
Arquivos de configuração Todo roteador tem dois arquivos de configuração: o arquivo
de configuração em execução e o arquivo de configuração de inicialização. O arquivo
startup-config contém os comandos que são carregados quando um roteador é ligado. O
arquivo running-config está na RAM e contém os comandos inseridos durante uma
sessão de configuração. O comando write salva o conteúdo running-config no arquivo
startup-config. Use a gravação com frequência se não quiser perder seu trabalho.
8.3.2 Configuração de interfaces e endereços IP

A primeira coisa a configurar em um roteador são suas interfaces e endereços IP. Você
precisa ligar as interfaces e atribuir a cada uma delas um endereço IP e uma máscara de
sub-rede. Isso pode não ser estritamente necessário no caso de interfaces IPv6, que
podem ser configuradas para obter um endereço local de link IPv6 automaticamente.
Ilustraremos essas configurações em um único roteador com duas interfaces: uma
interface Fast Ethernet e uma interface serial. Essa configuração é mostrada na Figura
8.3, juntamente com os endereços IPv4 e IPv6 que serão atribuídos a cada interface.
Nomes de roteador e interface Os roteadores e as interfaces têm nomes pelos quais são
conhecidos para fins de configuração. Nesse caso, o nome do roteador é R1 e os nomes
das interfaces são FastEthernet0/0 e Serial0/0.
Felizmente, os nomes das interfaces podem ser abreviados, neste caso para f0/0 e s0/0,
respectivamente. O nome de um roteador pode ser alterado usando o nome do host

FIGURA 8.3: Um roteador, duas de suas interfaces e os endereços IP atribuídos a elas.
comando no modo de configuração global, mas você não precisará fazer isso nos experimentos
deste livro.
Endereços e interfaces IPv4 A Figura 8.4.a mostra a sequência de comandos do Cisco IOS que
devem ser inseridos ao configurar as duas interfaces.
O comando configure terminal coloca o Cisco IOS no modo de configuração global; uma sessão
de configuração do roteador sempre começa com este comando.
O comando interface f0/0 coloca o IOS no modo interface, para configurar a interface f0/0. O
comando ip address configura o endereço IPv4 (222.222.10.1) e a máscara de sub-rede
(255.255.0.0) da interface, e o comando no shutdown liga a interface. Os comandos 5 a 7
repetem as ações dos comandos 2 a 4, mas para a interface s0/0. Observe que não há diferença
nas configurações básicas de interface Fast Ethernet e interfaces seriais.
O comando end força o IOS a sair do modo de configuração global e o comando write salva a
configuração no arquivo startup-config.
Endereços e interfaces IPv6 A configuração dos endereços IPv6 é mostrada na Figura 8.4.b. É
exatamente igual aos endereços IPv4, com uma exceção: o comando que configura os
endereços IPv6 é o endereço ipv6, e o comprimento do prefixo deve ser inserido em notação de
barra. Veremos mais adiante que, em alguns casos, não há necessidade de configurar endereços
IPv6 nas interfaces.
Sugestões muito úteis sobre como atribuir endereços IP Ao fazer experimentos, ou mesmo na
vida real de um gerente de rede, é mais útil atribuir endereços IP com alguma lógica que permita
associar facilmente um endereço IP ao roteador ao qual pertence. Isso nos poupará muito tempo
na configuração e depuração de nossos experimentos! Neste livro, usaremos as seguintes
regras:
• O último octeto de um endereço IP é sempre o número do roteador. Por exemplo, 222.222.20.3

diz que este endereço IPv4 pertence ao roteador R3 e 2001:a:a:10::1 diz que este endereço
IPv6 pertence ao roteador R1.
• Exceto ao usar endereços privados ou endereços externos ao domínio, nossos endereços IPv4
terão o formato 222.222.XY/24 onde, conforme explicado acima, Y é igual ao número do
roteador e X identifica a sub-rede real o endereço

FIGURA 8.4: Configuração de interfaces e endereços IP no caso de (a) IPv4 e (b) IPv6.
pertence a. Usaremos múltiplos de 10 para X; assim, nossas sub-redes IPv4 assumirão

o formato 222.222.10.0/24, 222.222.20.0/24 e assim por diante.
• Nossos endereços IPv6 terão o formato 2001:a:a:X::Y/64, onde X e Y têm o mesmo

significado que nos endereços IPv4. Além disso, ao atribuir vários prefixos ao mesmo
link, mudaremos o segundo e o terceiro hex tets (:a:a:) para a próxima letra do
alfabeto. Por exemplo, dois prefixos atribuídos ao mesmo link compartilhado de trânsito
podem ser 2001:a:a:X::/64 e 2001:b:b:X::/64.
• Os RIDs que precisam ser configurados no OSPFv2 e OSPFv3 serão do

formulário XXXX, onde X é o número do roteador.
Custos de interface Um parâmetro importante de uma interface é o custo de interface,

que permite configurar soluções de roteamento específicas. No OSPFv2, o custo da
interface pode ser configurado usando o comando ip ospf cost, no OSPFv3 usando o
comando ipv6 ospf cost e no IS-IS usando o comando isis metric. Os custos de interface
padrão são sempre 10 em IS-IS. No OSPF, eles são uma função da velocidade do link
da interface, sendo 10 para interfaces Fast Ethernet e 64 para interfaces seriais.

FIGURA 8.5: Inserindo comandos IOS em um lote.
8.3.3 Recursos adicionais do IOS

O comando show O comando show permite visualizar os vários tipos de informação que o Cisco
IOS pode fornecer, e é inserido no nível EXEC. Experimente você mesmo os comandos show
interfaces, show interfaces f0/0, show ip interface, show ip interface f0/0, show ip interface brief,
show ip interface brief f0/0 e show ip route, para aprender o tipo de informação que você pode
obter deles.
Vendo o conteúdo dos arquivos running-config e startup-config Você pode ver o conteúdo dos
arquivos running-config e startup-config usando os comandos show running-config e show
startup-config. Um bom exercício é inserir os comandos da Figura 8.4 e tentar identificá-los nos
arquivos running-config e startup-config usando os comandos show correspondentes.
Editando o arquivo startup-config Às vezes é mais fácil fazer alterações diretamente nos
arquivos startup-config. Você pode editar esses arquivos dentro do GNS3. Basta clicar com o
botão direito do mouse em um roteador e selecionar Editar configuração; uma janela onde
você pode editar o conteúdo do arquivo startup-config será aberta.
Inserindo os comandos em lote Você achará este recurso muito útil!
Em vez de inserir os comandos um a um no console, você pode escrever um grupo de comandos
em um processador de texto e copiá-los e colá-los no console, tudo ao mesmo tempo. A ordem
dos comandos deve ser a mesma como se os comandos fossem digitados um a um. Por
exemplo, para configurar o roteador R1 como na Figura 8.4.a, escreva os comandos em um
processador de texto (como na Figura 8.5) e copie e cole todos os comandos ao mesmo tempo
no console. A primeira linha é um comentário. Esse recurso nos poupará muito tempo!
Sobrescrevendo configurações Ao sobrescrever uma configuração sobre outra, a configuração

mais antiga pode não ser completamente substituída; alguns comandos da configuração antiga
podem permanecer e precisarão ser negados para serem deletados. Por exemplo, ao inserir
uma nova configuração OSPF, as redes anunciadas

FIGURA 8.6: Utilizando o sistema de ajuda para conhecer as opções do OSPFv2

disponíveis no modo interface.
pelo OSPF na configuração antiga permanecerá na nova configuração, e isso pode

causar muitos problemas se você não prestar atenção. Por isso tem cuidado!
Negando um comando A negação de um comando geralmente é feita acrescentando a
palavra-chave no ao comando. Por exemplo, a remoção de um endereço IPv4 é feita por
meio do comando no ip address e a ativação de uma interface por meio do comando no
shutdown.
Usando abreviações para os comandos do IOS Os comandos do Cisco IOS podem ser
abreviados sempre que a abreviação não for ambígua. Por exemplo, configure terminal
pode ser abreviado para conf t, interface para int, no shutdown para no shut, show
interfaces para sh int e write para wr.
O sistema de ajuda O Cisco IOS possui um sistema de ajuda sensível ao contexto
integrado. Para obter ajuda, basta inserir o ponto de interrogação e você obterá a lista de
comandos disponíveis onde estiver no IOS. Quando um comando tem várias partes e
não se lembra da parte seguinte, pode introduzir “o que sabe”, seguido de um espaço e
um ponto de interrogação, para obter as várias opções para a parte seguinte.
Por exemplo, se você estiver no modo interface e quiser saber quais são as opções
disponíveis para configurar o OSPFv2, basta digitar ip ospf ? e você obterá o resultado
da Figura 8.6. Isso informa, por exemplo, que para configurar o custo OSPF de uma
interface, você terá que adicionar a palavra-chave cost ao comando ip ospf.
O comando debug IOS inclui um comando debug que ajuda a rastrear a evolução dos
eventos relacionados aos diferentes protocolos implementados no IOS.

8.4 Configuração básica de roteamento 259
FIGURA 8.7: Comandos de depuração a serem inseridos no arquivo startup-config.
Por exemplo, você pode usar o comando debug ip ospf para rastrear os eventos relacionados ao
OSPF e o comando debug isis para rastrear os eventos relacionados ao IS-IS. Ambos os
comandos têm várias opções de filtragem. Por exemplo, para ver apenas os eventos relacionados
ao protocolo Hello do OSPF, você deve inserir o comando debug ip ospf hello.
Depuração desde o início Às vezes é importante iniciar a depuração quando um roteador é

ligado. Você precisará disso, por exemplo, para estudar cenários de inicialização a frio. Nesse
caso, os comandos debug não podem ser fornecidos no console e devem ser inseridos no
arquivo startup-config. Para fazer isso, você terá que escrever, imediatamente antes da palavra-
chave end do arquivo startup-config, o conjunto de comandos da Figura 8.7, adaptado às
necessidades específicas. O exemplo é para OSPF.
Os nomes DebugOSPF (primeira linha) e adjacências Debug OSPF (última linha) podem ser
alterados. A única outra coisa que você pode alterar é a linha action 2.0, que configura o comando
debug real. Neste exemplo, incluímos o comando debug ip ospf adj, que rastreia eventos
relacionados a adjacências OSPF.
8.4 Configuração básica de roteamento

Nesta seção, explicamos as configurações básicas de roteamento de todas as tecnologias
abordadas neste livro. As configurações serão ilustradas usando novamente o roteador da Figura
8.3, com uma interface Fast Ethernet e uma interface serial. Assumiremos que as interfaces e
endereços IP já foram configurados, conforme explicado na Seção 8.3.2.
A configuração de um protocolo de roteamento no Cisco IOS sempre envolve a criação de

um processo de roteamento. Isso é executado usando o comando router no modo de configuração
global. Dependendo da tecnologia específica, a configuração de roteamento também pode
envolver configurações no modo de interface. Observe também que um roteador pode executar
vários protocolos de roteamento ao mesmo tempo.
Além de criar o processo de roteamento, a configuração básica de roteamento envolve a
configuração do identificador do roteador (o RID) e a definição dos prefixos que devem ser
anunciados pelo roteador. Um roteador só pode ser configurado para anunciar prefixos atribuídos
a si mesmo ou a suas interfaces.

Nos exemplos de configuração, incluiremos todos os comandos necessários para

configurar o roteamento desde o início, ou seja, desde entrar no modo de configuração
global até que a configuração seja salva no arquivo startup-config. As configurações
básicas de roteamento de todas as tecnologias são mostradas na Figura 8.8.
8.4.1 OSPFv2
A Figura 8.8.a mostra a configuração de roteamento básica do OSPFv2. O comando
router ospf 1 cria o processo de roteamento OSPFv2 e coloca o IOS no modo de
configuração do roteador. Que o modo de configuração atual é o modo roteador pode ser
reconhecido pela palavra-chave config-router nos prompts. Nesse modo, você pode
configurar o RID e os prefixos anunciados. O comando router-id 1.1.1.1 configura o RID
como sendo 1.1.1.1; observe que a configuração RID não é obrigatória no OSPFv2. O
comando network define os prefixos anunciados pelo roteador e a área a que pertencem.
Como neste exemplo existem duas interfaces com endereços IPv4 222.222.10.1/24 e
222.222.20.1/24, respectivamente (ver Seção 8.3.2), é necessário configurar os prefixos
222.222.10.0/24 e 222.222.10.0/ 24. Observe que a máscara de sub-rede é inserida
como complemento da máscara usual. Por exemplo, na configuração atual a máscara é
255.255.255.0 e você deve inserir 0.0.0.255.
8.4.2 OSPFv3
A Figura 8.8.b mostra a configuração de roteamento básica do OSPFv3. A lógica é um
pouco diferente da do OSPFv2. A primeira configuração, ou seja, o comando ipv6 unicast-
routing, habilita o roteamento IPv6. Isso não é necessário no roteamento IPv4, mas é
obrigatório no roteamento IPv6; você também verá este comando na configuração IPv6
IS-IS. Em seguida, o comando ipv6 router ospf 1 cria o processo OSPFv3 e coloca o IOS
no modo de configuração do roteador.
A única configuração necessária neste modo é o RID, que é feito exatamente como no
OSPFv2, ou seja, com o comando router-id. Em seguida, o OSPFv3 deve ser configurado
em cada interface, usando o comando ipv6 ospf 1 área 0. Isso informa ao IOS que o
OSPFv3 deve ser habilitado na interface e que a interface pertence à área 0. O roteador
anunciará automaticamente o prefixo associado à interface endereço (ver Seção 8.3.2);
ao contrário do OSPFv2, não há necessidade de declarar esses prefixos no modo de
configuração do roteador.
8.4.3 IPv4 IS-IS

A Figura 8.8.c mostra a configuração básica de roteamento do IPv4 IS-IS. Depois de
entrar no modo de configuração global, o comando router isis cria o processo IPv4 IS IS
e coloca o IOS no modo de configuração do roteador. O comando net
49.0001.0000.0000.0001.00 configura a NET do roteador. Lembre-se da Seção 5.2.1 que
a NET inclui tanto o identificador de área quanto o identificador de roteador (chamado
SID em IS-IS). O identificador de área ocupa o primeiro

8.4 Configuração básica de roteamento 261
FIGURA 8.8: Configurações básicas de roteamento de (a) OSPFv2, (b) OSPFv3, (c)
IPv4 IS-IS, e (d) IPv6 IS-IS.

três octetos, o SID os próximos seis octetos e o SEL o último octeto. A parte SEL é
sempre zero. O primeiro octeto do identificador de área (0×49) é o AFI. As partes
restantes indicam que o roteador pertence à área 1 e tem um SID de 1. O próximo
comando, is-type level-1, configura o roteador para ser um roteador L1. Por fim, assim
como o OSPFv3, o IS-IS deve ser habilitado em cada interface, e essa é a função do
comando router isis, inserido nos modos de configuração de interface f0/0 e s0/0.
Conforme explicado na Seção 4.3.2, existem três tipos de roteadores IS-IS: roteadores
L1, roteadores L2 e roteadores L1/L2. Nos roteadores L1, as interfaces são todas do tipo
somente L1; em roteadores L2, as interfaces são todas do tipo somente L2; e em
roteadores L1/L2, as interfaces podem ser de qualquer tipo, ou seja, somente L1,
somente L2 ou L1/L2. A configuração padrão do IOS é considerar os roteadores como
roteadores L1/L2 e as interfaces do tipo L1/L2. Qualquer desvio dessa configuração
padrão deve ser configurado explicitamente. Conforme mencionado acima, para
transformar um roteador em um roteador L1, o comando is-type level-1 deve ser inserido
no modo roteador. Da mesma forma, para transformar um roteador em um roteador L2,
insira o comando is-type level-2-only no mesmo modo. Além disso, para transformar uma
interface em uma interface somente L1 ou somente L2, digite os comandos isis circuit-
type level-1 ou isis circuit-type level-2-only no modo de interface.
8.4.4 IPv6 IS-IS

A Figura 8.8.d mostra a configuração básica de roteamento do IPv6 IS-IS. Como no caso
do OSPFv3, o primeiro comando (ipv6 unicast-routing) habilita o roteamento IPv6. Além
disso, a configuração é muito semelhante ao IPv4 IS-IS. O comando ipv6 router isis 1 cria
o processo IPv6 IS-IS e informa ao IOS para entrar no modo de configuração do roteador.
As configurações neste modo são as mesmas do IPv4 IS-IS. Em seguida, as interfaces
também devem ser configuradas para habilitar o IPv6 IS-IS, e isso é feito através do
comando ipv6 router isis 1.
8.5 Lista de comandos do IOS

Listamos aqui os principais comandos do Cisco IOS que serão utilizados nesta parte do
livro. A Figura 8.9 mostra a lista de comandos genéricos do Cisco IOS; As Figuras 8.10,
8.11 e 8.12 mostram os comandos de configuração de OSPFv2, OSPFv3 e IS-IS (IPv4 e
IPv6). Por fim, as Figuras 8.13 e 8.14 apresentam os comandos de configuração dos
protocolos BGP e RIP, que serão utilizados em alguns experimentos.

8.5 Lista de comandos do IOS 263
FIGURA 8.9: Lista de comandos genéricos.

FIGURA 8.10: Lista de comandos OSPFv2.

8.5 Lista de comandos do IOS 265
FIGURA 8.11: Lista de comandos OSPFv3.
FIGURA 8.12: Lista de comandos IS-IS.

FIGURA 8.13: Lista de comandos BGP.
FIGURA 8.14: Lista de comandos RIP.

9
Experimentos em tabelas de encaminhamento e
LSDB
Nos protocolos LSR, os roteadores mantêm um LSDB contendo as informações topológicas e

de endereçamento necessárias para construir suas tabelas de encaminhamento. A estrutura
LSDB de OSPF e IS-IS foi apresentada no Capítulo 5. Neste capítulo, apresentamos primeiro
as tabelas de encaminhamento e analisamos o processo de seleção de caminho na Seção 9.1.
Em seguida, a Seção 9.2 ilustra a estrutura LSDB de OSPF e IS-IS em diferentes cenários.
9.1 Rotas e tabelas de encaminhamento

Os protocolos de roteamento constroem tabelas de encaminhamento nos roteadores, que
indicam como um pacote recebido deve ser encaminhado para o próximo elemento de rede da
camada 3 (roteador ou host). Nesta seção, analisamos o processo de seleção de caminhos e
a estrutura das tabelas de encaminhamento obtidas com os protocolos de roteamento IPv4 e IPv6.
Consideraremos as tabelas de encaminhamento obtidas com IPv4 IS-IS, OSPFv2 e OSPFv3.
Ignoramos o IPv6 IS-IS, pois suas tabelas de encaminhamento são semelhantes ao OSPFv3.
Montagem experimental Esta questão será ilustrada com a ajuda da rede da Figura 9.1. A rede
tem três roteadores, dois links seriais, um link compartilhado de trânsito e um host. Selecionamos
essa topologia para garantir a existência de caminhos alternativos de cada roteador para cada
sub-rede. O host está incluído para tornar nossos experimentos de traceroute mais claros. Os
roteadores precisam ser configurados com a configuração de roteamento básico (consulte a
Seção 8.4.3 para a configuração IPv4 IS-IS, a Seção 8.4.1 para a configuração OSPFv2 e a
Seção 8.4.2 para a configuração OSPFv3). O host usa o elemento VPCS do GNS3.
Sua configuração é simples: basta digitar o comando ip 222.222.30.100/24 222.222.30.2 no

console VPCS. Na figura “DG” significa Default Gate
caminho.
As tabelas de encaminhamento IPv4 podem ser visualizadas com o comando show ip route
e as IPv6 com o comando show ipv6 route. A forma como as tabelas de encaminhamento são
exibidas pelo Cisco IOS varia de acordo com a família de endereços e o protocolo de roteamento,
sem muita lógica entre eles. É principalmente um
267

268 9 experimentos em tabelas de encaminhamento e LSDB
FIGURA 9.1: Experimentos de tabelas de encaminhamento - Topologia de rede.
questão de gosto do vendedor! No entanto, as tabelas de encaminhamento têm uma entrada

por sub-rede de destino, incluindo pelo menos o identificador de sub-rede (ou seja, o prefixo
ao qual a entrada se aplica), o endereço IP da interface do próximo salto e o nome da interface
de encaminhamento.
9.1.1 Tabelas de encaminhamento IPv4 obtidas com IPv4 IS-IS

Na Figura 9.2, mostramos a tabela de encaminhamento do roteador R1 obtida com IPv4 IS-IS.
A tabela tem três entradas, cada uma correspondendo a uma sub-rede de destino.
A entrada relativa a 2222.222.30.0/24 tem duas linhas, pois existem dois caminhos mais
curtos de custo igual do roteador R1 para esta sub-rede.
Como as informações de roteamento foram obtidas? Uma entrada na tabela de
encaminhamento começa com uma palavra-chave indicando como a entrada foi obtida: “C”
diz que o caminho é para um link conectado diretamente e “i L1” diz que o caminho foi obtido
do L1 LSDB do IS-IS. Esses códigos são explicados nas linhas anteriores à tabela de
encaminhamento.
Rotas conectadas diretamente As entradas relativas aos links conectados diretamente incluem,
após a palavra-chave “C”, o prefixo que identifica a sub-rede, o texto “está conectado
diretamente” e o nome da interface que leva à sub-rede.
Por exemplo, a primeira linha diz que, se um pacote chega em R1 e tem como destino
222.222.20.0/24, ele deve ser encaminhado pela interface Serial0/1 (também conhecida
dentro do roteador como s0/1).
Caminhos IS-IS As entradas obtidas através dos protocolos de roteamento começam com a
palavra-chave que os identifica (no nosso caso “i L1”) e contêm quatro informações. O primeiro
é o prefixo ao qual a entrada se aplica. O segundo é colocado entre colchetes e inclui primeiro
a distância administrativa do protocolo e, após a barra, o custo do caminho mais curto que
leva ao prefixo. A terceira parte inclui o endereço do próximo salto, precedido pela palavra

9.1 Rotas e tabelas de encaminhamento 269
FIGURA 9.2: Tabela de encaminhamento IPv4 obtida com IPv4 IS-IS no roteador R1.
"através da". Finalmente, a quarta parte é o nome da interface de encaminhamento. Quando

há mais de um caminho mais curto levando a um destino, a entrada tem mais de uma linha e
cada linha descreve um caminho alternativo. A palavra-chave inicial e as informações do
prefixo são incluídas apenas na primeira linha. Assim, de nossa tabela de roteamento,
aprendemos que a distância administrativa do IS-IS é 115, que existem dois caminhos mais
curtos que levam a 222.222.30.0/24, ambos com custo 20, que um dos caminhos passa pelo
roteador R2 (o um definido pela interface de encaminhamento Serial0/0 e o endereço do
próximo salto 222.222.10.2) e que o outro caminho é através do roteador R3 (aquele definido
pela interface de encaminhamento Serial0/1 e o endereço do próximo salto 222.222.20.3) .
Endereços do próximo salto Lembre-se de que o endereço do próximo salto é o endereço

IPv4 da próxima interface que recebe os pacotes enviados por um roteador. Por exemplo, na
terceira entrada, o endereço do próximo salto da primeira linha é 222.222.30.3, pois um pacote
destinado a 222.222.30.0/24 e encaminhado de acordo com esta linha deve ser transmitido
pela interface Serial0/1 e recebido pelo interface do próximo roteador com endereço IPv4
222.222.20.3.
Cálculo do custo do caminho Para entender o valor do custo do caminho, lembre-se que o
custo do caminho é obtido somando os custos das interfaces transmissoras pertencentes ao
caminho; lembre-se também que os custos de interface padrão do IS-IS são 10,
independentemente do tipo de interface. Um pacote enviado do roteador R1 para 222.222.30/24
é transmitido por duas interfaces, independentemente do caminho percorrido. Se for via R2, é
transmitido pela interface s0/0 de R1 (que custa 10) e pela interface f0/0 de R2 (que também
custa 10). Assim, o custo desse caminho é 10 + 10 = 20. O mesmo raciocínio se aplica ao
outro caminho. Observe que os custos das interfaces de recebimento não são incluídos no
cálculo do custo do caminho. Assim, neste exemplo, o custo da interface s0/0 de R2 e de

FIGURA 9.3: Tabela de encaminhamento IPv4 obtida com IPv4 IS-IS - Resultado do
traceroute de R1 para host.
a interface s0/0 de R3, que recebe pacotes de R1, não é incluída nos cálculos dos custos de
caminho de R1 a 222.222.30.0/24.
Dividindo o tráfego entre caminhos de custo igual Quando há vários caminhos mais curtos
levando ao mesmo destino, o tráfego é igualmente dividido entre esses caminhos. No nosso
caso, como existem dois caminhos que levam a 222.222.30.0/34, 50% do tráfego passa
pelo primeiro caminho (via R2) e os outros 50% passam pelo segundo (via R3). Isso pode
ser verificado usando o comando traceroute. A Figura 9.3 mostra o resultado da sonda
traceroute 222.222.30.100 6 executada em R1; a última parte (sonda 6) instrui o Cisco IOS
a repetir o traceroute seis vezes antes de prosseguir para o próximo roteador no caminho
(ou seja, ele envia seis solicitações de eco ICMP com um determinado valor de TTL). A
figura mostra que o traceroute alterna entre passar por R3 (o primeiro) e passar por R2 (o
segundo).
9.1.2 Tabelas de encaminhamento IPv4 obtidas com OSPFv2

Na Figura 9.4, mostramos a tabela de encaminhamento do roteador R1 obtida com OSPFv2.
Existem apenas três diferenças em relação à tabela obtida com IPv4 IS-IS. Primeiro, os
caminhos aprendidos pelo OSPF são identificados pela palavra-chave “O”. Em segundo
lugar, o custo do caminho das entradas OSPF agora é 74 (e não 20, como no IPv4 IS-IS).
Isso ocorre porque, no OSPF, o custo da interface padrão é 64 para links seriais e 10 para
links Fast Ethernet.
Por fim, as entradas relativas ao OSPF incluem um tempo, colocado entre o endereço
do próximo salto e o nome da interface de encaminhamento. Este é o tempo decorrido desde
a última atualização da entrada que, no caso da Figura 9.4, é de 6 minutos e 13 segundos
para ambas as entradas OSPF. Você pode dizer quanto tempo mais você tem que esperar
até que essas entradas sejam atualizadas (ou seja, o tempo é zerado)?
Enquanto o protocolo de roteamento está convergindo... As tabelas de encaminhamento não
convergem imediatamente para seu estado final. Os protocolos de roteamento levam algum

!!"!#$$%&$%
'$%'&#(')$%'& #() !$%#(!)$%# () (*+ *)+)
,-.
$
(-
)))/)))/)0/01)2(01 )))/)))/0/01)2(01
$)))/)))/30/01)2401526+)))/ )))/)0/30007 0
301 401526+)))/)))/0/)00073010
FIGURA 9.4: Tabela de encaminhamento IPv4 obtida com OSPFv2 no roteador R1.
hora de fazer o seu trabalho! Nesse ínterim, enquanto um protocolo está convergindo, a tabela
de encaminhamento pode ter informações ausentes ou mesmo erradas. Para observar isso,
reinicie todos os roteadores ao mesmo tempo (uma situação de inicialização a frio) e continue
exibindo a tabela do roteador R2 inserindo sucessivamente o comando show ip route. Os
resultados desse experimento são mostrados na Figura 9.5. Sabemos qual deve ser o
resultado final em relação ao caminho de R2 para 222.222.20.0/24: deve ser via roteador R3,
pois o custo do caminho via esse roteador é 74, e o do roteador R1 é 128 (porque inclui dois
interfaces de link serial, cada uma com custo 64). No entanto, a tabela de encaminhamento
inicial (consulte a Figura 9.5.a) indica que o caminho é via R1 (o endereço do próximo salto é
222.222.10.1 e a interface de encaminhamento é s0/0) e o custo do caminho é 128. Assim, o
caminho ainda não é o mais curto. Se você continuar digitando show ip route, notará que leva
aproximadamente 40 segundos até que essa entrada OSPF seja substituída pela correta. A
tabela de encaminhamento correspondente é mostrada na Figura 9.5.b; indica que o caminho
de R2 para 222.222.20.0/24 passa pelo roteador R3 (o endereço do próximo salto é
222.222.30.3 e a interface de encaminhamento é f0/0) e tem um custo de 74. Na verdade,
isso acontece porque, no OSPF , a convergência em links ponto a ponto é muito mais rápida
do que em links compartilhados. Em links compartilhados, os roteadores devem eleger o DR
e o BDR antes de estabelecer adjacências entre si, e isso leva aproximadamente 40 segundos.
9.1.3 Tabelas de encaminhamento IPv6

Na Figura 9.6, mostramos a tabela de encaminhamento do roteador R1 obtida com OSPFv3.
Esta tabela parece mais complexa do que sua contraparte IPv4, mas não é. As entradas
abrangem mais de uma linha, e é isso que chama a atenção; eles ocupam duas linhas se
houver um único caminho mais curto para o destino correspondente. Todas as entradas
seguem a mesma estrutura e incluem o seguinte

FIGURA 9.5: Tabelas de encaminhamento IPv4 obtidas com OSPFv2 no roteador R2 -

(a) Tabela inicial, (b) tabela após a convergência da rede.
partes: (i) palavra-chave identificando como as informações de roteamento foram obtidas,

(ii) definição do prefixo, (iii) distância administrativa e custo do caminho entre colchetes,
(iv) endereço do próximo salto precedido pela palavra-chave “via” e (v ) nome da interface
de encaminhamento. A tabela inclui informações locais, identificadas pela palavra-chave
“L”, por exemplo, identificando os endereços IPv6 globais atribuídos às interfaces do
roteador, mas essa é uma informação menos interessante.
Rotas conectadas diretamente Como a topologia da rede é a mesma dos experimentos
IPv4, os caminhos também são os mesmos. R1 está diretamente ligado aos links com os
prefixos 2001:a:a:10::/64 e 2001:a:a:20::/64, e esses caminhos são identificados pela
palavra-chave “C”. O primeiro prefixo é alcançado através
FIGURA 9.6: Tabela de encaminhamento IPv6 obtida com OSPFv3 no roteador R1.

interface Serial0/0 (s0/0 abreviado) e a segunda através da interface Serial0/1 (s0/1

abreviado). Ao contrário das tabelas IPv4, as rotas conectadas diretamente agora incluem as
informações de distância administrativa e custo do caminho, mostrando que esse tipo de
caminho tem distância administrativa zero. O texto “via::” significa nenhum endereço de
próximo salto.
OSPFv3 paths A palavra-chave “O” indica que a entrada correspondente foi aprendida através
do OSPFv3. Como no caso do IPv4, existem dois caminhos mais curtos de custo igual de R1
para o link compartilhado de trânsito, que agora recebe o prefixo 2001:a:a:30::/64.
Uma característica importante do OSPFv3 é que os endereços do próximo salto são

endereços locais de link IPv6. Na verdade, R1 aprendeu esses endereços dos Link-LSAs
originados por R2 e R3 nos links seriais. O primeiro caminho para 2001:a:a:30::/64 é via
roteador R2, tendo fe80::c002:34ff:fe0c:0 como o endereço do próximo salto e Serial0/0 como
a interface de encaminhamento; o segundo caminho é via roteador R3, tendo
fe80::c002:34ff:fe6c:0 como o endereço do próximo salto e Serial0/1 como a interface de
encaminhamento.
9.1.4 Mudando os caminhos

Uma das tarefas mais importantes de um gestor de rede é a definição dos caminhos dos
vários fluxos de tráfego que atravessam a sua rede. Isso pode ser feito por meio da
configuração adequada dos custos de interface de OSPF ou IS-IS. Nas seções anteriores,
havia dois caminhos mais curtos de custo igual de R1 a 222.222.30.0/24.
Suponha que queremos garantir que o tráfego seja completamente roteado por meio de R2.
Para isso, o custo do caminho através do roteador R3 deve ser maior do que aquele através
de R2. Isso pode ser implementado aumentando o custo da interface s0/1 de R1 ou da
interface f0/0 de R3; também pode ser implementado diminuindo o custo da interface s0/0 de
R1 ou da interface f0/0 de R2. Suponha que aumentamos o custo da interface s0/1 de R1
para 40. Isso pode ser feito através do comando isis metric 40, inserido no modo de interface
s0/1. A tabela de encaminhamento resultante é mostrada na Figura 9.7.a. Agora há uma única
linha relativa a 222.222.30.0/24, indicando que o próximo salto é 222.222.10.2 (roteador R2)
e a interface de encaminhamento é s0/0. O traceroute de R1 para 222.222.30.100 (Figura
9.7.b) confirma que o tráfego é todo roteado por R2, pois a primeira resposta sempre vem de
222.222.10.2.
9.1.5 Prevalência de rotas conectadas diretamente

Na Seção 1.5 discutimos a questão das rotas diretamente conectadas. Esses caminhos são
preferidos em relação aos caminhos obtidos por meio de qualquer protocolo de roteamento,
devido à menor distância administrativa. O exemplo da seção anterior confirma esse
comportamento. Lembre-se de que aumentamos o custo da interface s0/1 de R1 para 40.
Nesse caso, o custo do caminho de R1 para 222.222.20.0/24 torna-se mais curto através de
R2 (ou seja, via interface s0/0). Neste caminho, os pacotes são transmitidos através de três
interfaces (s0/0 de R1, f0/0 de R2 e s0/0 de R3)

FIGURA 9.7: Alterando os caminhos - (a) Tabela de encaminhamento de R1 e (b) saída do

rastreador de R1 para o host quando o caminho passa por R2.
e, portanto, o custo do caminho é 30. Porém, a tabela de encaminhamento da Figura 9.7 indica
que o caminho para 222.222.20.0/24 é o direto, através da interface s0/1, que tem custo 40.
9.2 Estrutura LSDB de redes de área única

Nesta seção, analisamos a estrutura LSDB de redes de área única. Essa questão foi discutida
na Seção 2.2 e no Capítulo 5. Começamos apresentando, na Seção 9.2.1, a estrutura LSDB de
redes de área única não conectadas a outros domínios de roteamento, ou seja, sem informações
de endereçamento externo ao domínio.
Em seguida, na Seção 9.2.2, mostramos a estrutura LSDB de redes conectadas a outros ASes
e, na Seção 9.2.3, discutimos como o LSDB acomoda as rotas padrão. A Seção 9.2.4 ilustra as
métricas OSPF E-type. Finalmente, a Seção 9.2.5 mostra a estrutura LSDB de redes OSPF
conectadas a um domínio RIP do mesmo AS.
9.2.1 Estrutura LSDB sem informações de endereçamento externo ao

domínio
Esta seção discute a estrutura LSDB de OSPFv2, OSPFv3, IPv4 IS-IS e IPv6 IS-IS, quando as
informações de endereçamento externo do domínio não estão presentes.
Todos os experimentos, exceto os dois últimos, serão baseados na topologia de rede da Figura
9.8. Essa topologia foi selecionada porque possui um pequeno número de roteadores e contém
todos os tipos de links: links ponto a ponto, links compartilhados de trânsito e links compartilhados
stub.
Procedimento experimental O procedimento experimental é simples. Para cada tecnologia,

comece configurando os roteadores com a configuração básica de roteamento

9.2 Estrutura LSDB de redes de área única 275
FIGURA 9.8: Experimentos relacionados à estrutura LSDB de redes de área única,

sem informações de endereçamento externo ao domínio - topologia de rede.
ção. Em seguida, ligue os roteadores ao mesmo tempo e aguarde até que a rede
converja. Os resultados desses experimentos são discutidos nas próximas seções.
9.2.1.1 OSPFv2
Um resumo das informações do OSPFv2 LSDB é mostrado na Figura 9.9. Pode ser
visualizado com o comando show ip ospf database. A estrutura do OSPFv2 LSDB foi
discutida na Seção 5.5.
Resumo do OSPFv2 LSDB O resumo do LSDB exibido pelo Cisco IOS inclui, para cada
LSA, informações sobre Link State ID (coluna Link ID), Advertising Router (coluna ADV
Router), LS Age (coluna Age), LS Sequence Number (Seq# coluna) e campos LS
Checksum (coluna Checksum); todos esses campos pertencem ao cabeçalho LSA
(consulte a Figura 5.9). No caso de Router-LSAs, inclui também o campo Number of
Links (coluna Contagem de links).
A exibição está organizada em duas partes, a primeira relacionada aos Router-LSAs

(Router Link States) e a segunda aos Network-LSAs (Net Link States).
Existem quatro LSAs diferentes: três Router-LSAs, cada um descrevendo um

roteador e suas interfaces, e um Network-LSA, descrevendo o link de trânsito
compartilhado, ou seja, aquele com o prefixo 222.222.10.0/24. Observe que o link
compartilhado do stub não é representado por um Network-LSA.
A idade desses LSAs indica que os roteadores foram ligados há alguns minutos (a
julgar pelo Roteador-LSA de R3 há pouco mais de 2 minutos). Observe que os Router-
LSAs de R1 e R2 possuem um SN maior que o valor inicial (que é 0×80000001). Isso
ocorre porque novas instâncias de roteador-LSA são criadas sempre que um novo
relacionamento de vizinhança é criado, e isso acontece várias vezes quando um
roteador é ligado.
Os Router-LSAs têm valores iguais nos campos Link State ID (Link ID) e Advertising
Router (ADV Router). Este é um recurso do Roteador-LSAs; como um roteador só pode
originar um roteador-LSA, o Link State ID não é

FIGURA 9.9: LSDB sem informações de endereçamento externo ao domínio - Resumo do

OSPFv2 LSDB.
necessário para identificar exclusivamente o LSA no LSDB e acaba tendo o mesmo valor do
Advertising Router.
Observe que, nos Roteadores-LSAs de R2 e R3, o Número de Links (Link Count) é um
mais o número de interfaces que esses roteadores possuem. Isso se deve aos links ponto a
ponto, que exigem duas descrições de link por interface. Abordaremos esse recurso a seguir.
Roteador-LSAs Os três Roteadores-LSAs são mostrados na Figura 9.10. Eles podem ser
exibidos por meio do comando show ip ospf database router.
Roteador-LSA de R2 O Roteador-LSA de R2 inclui todos os tipos de interfaces: para links
ponto-a-ponto, para trânsito de links compartilhados e para stub de links compartilhados. O
LSA tem quatro descrições de link. Os dois primeiros referem-se à interface de enlace ponto
a ponto. A primeira descrição (Link conectado a: outro Roteador) é uma descrição do tipo 1,
que fornece informações topológicas, e a segunda (Link conectado a: uma Rede Stub) é uma
descrição do tipo 3, que fornece informações de anúncio. O Cisco IOS nomeia as descrições
de link de forma diferente da especificação, o que pode ser confuso. Da primeira descrição,
aprendemos que este link ponto a ponto conecta o roteador R2 ao roteador R3 (já que o Link
ID é 3.3.3.3) usando uma interface com endereço IPv4 222.222.30.2 (Link Data), que tem um
custo de 64 (métrica). A partir da segunda descrição, aprendemos que o link ponto a ponto
é atribuído ao prefixo 222.222.30.0/24 (Link ID e Link Data). A informação de custos incluída
nesta descrição do tipo 3 é irrelevante, uma vez que já foi fornecida na descrição do tipo 1.
Sabemos que as duas primeiras descrições estão associadas uma à outra (ou seja, que o
prefixo 222.222.30.0/24 da segunda descrição é atribuído ao link ponto a ponto da primeira
descrição), pois o endereço da interface do roteador da primeira descrição ção (222.222.30.2)
está contida no intervalo de prefixo definido por 222.222.30.0/24.
Observe que o mesmo não é verdadeiro para o intervalo de prefixo da descrição do terceiro
link (222.222.20.0/24).

FIGURA 9.10: LSDB sem informações de endereçamento externo ao domínio -

OSPFv2 Router-LSAs.
A terceira descrição de link (Link conectado a: uma Rede Stub) é novamente

uma descrição de link tipo 3, indicando que o prefixo atribuído ao link compartilhado
stub é 222.222.20/24 (ID do Link e Dados do Link) e que o custo de a interface que
conecta o roteador com o link é 10 (métrica).
Por fim, a quarta descrição do link (Link conectado a: uma Rede de Trânsito) é
uma descrição do tipo 2 que caracteriza a interface com o link compartilhado do
trânsito. A partir desta descrição, aprendemos que o roteador R2 está conectado a
um link identificado por 222.222.10.2 (Link ID), através de sua interface com o
endereço IPv4 222.222.10.2 (Link Data), que tem um custo de 10 (Metric). O fato de
o identificador do link e o endereço da interface serem os mesmos indica que o
próprio roteador é o DR do link compartilhado de trânsito. Lembre-se que no OSPFv2 um

O link compartilhado de trânsito é identificado pelo endereço da interface DR anexada ao

link.
Roteador-LSA de R1 O Roteador-LSA de R1 mostra que R1 possui apenas uma interface,

que é anexada a um link compartilhado de trânsito. O LSA possui uma única descrição
de link do tipo 2 (Link conectado a: uma Rede de Trânsito), informando que o roteador R1
está conectado a um link identificado por 222.222.10.2 (Link ID), através de sua interface
com endereço IPv4 222.222.10.1 ( Link Data) e custo 10 (Métrico). O identificador do
enlace é o mesmo da descrição do quarto enlace do Roteador-LSA de R2, pois as duas
interfaces referidas por essas descrições estão ligadas ao mesmo enlace compartilhado
de trânsito.
Roteador-LSA de R3 O Roteador R3 é apenas conectado a um link ponto a ponto.
Assim, seu Roteador-LSA possui duas descrições de link, uma transmitindo informações
topológicas e a outra endereçando informações. A primeira descrição do link é do tipo 1
(Link conectado a: outro Roteador), e informa que o vizinho de R3 no link é R2 (já que o
Link ID é 2.2.2.2), o endereço IPv4 da interface anexada ao link é 222.222.30.3, (Link
Data), e o custo da interface é 64 (Metric). A segunda descrição é do tipo 3 (Link
conectado a: uma Rede Stub), e informa que o link ponto-a-ponto possui o prefixo
222.222.30.0/24 (ID do Link e Dados do Link). Observe que as informações do prefixo
são exatamente as mesmas do Roteador-LSA de R2 (descrição do segundo link). Isso
mostra que um prefixo atribuído a um link ponto a ponto é anunciado por seus dois
roteadores finais.
Rede-LSA A Figura 9.11 mostra a Rede-LSA que descreve o link compartilhado. Pode ser
obtido através do comando show ip ospf database net work. Este LSA fornece
informações topológicas e de endereçamento. No campo Link State ID, aprendemos que
o identificador do link é 222.222.10.2, e nos campos Attached Router, aprendemos que
os roteadores R1 (1.1.1.1) e R2 (2.2.2.2) estão conectados ao link; esta é uma informação
topológica. O prefixo atribuído ao link, ou seja, a informação de endereçamento, é obtido
aplicando-se o campo Network Mask (/24) ao endereço IP contido no campo Link State
ID, que resulta em 222.222.10.0/24.
9.2.1.2 OSPFv3
Resumo do OSPFv3 LSDB A Figura 9.12 mostra um resumo das informações do OSPFv3
LSDB. Pode ser visualizado com o comando show ipv6 ospf database. A estrutura do
OSPFv3 LSDB foi discutida nas Seções 5.7 e 5.9.
Em relação ao OSPFv2 (consulte a Figura 9.9), agora existem muito mais LSAs.
A exibição tem quatro partes, uma para cada tipo de LSA: Estados de link do roteador
para LSAs de roteador, Estados de link de rede para LSAs de rede, Estados de link de
link (tipo 8) para LSA de link e Estados de prefixo de área intra para Intra- Prefixo de
área-LSAs. As informações exibidas pelo Cisco IOS variam de acordo com o tipo de LSA,
mas sempre incluem o Advertising Router (ADV Router col

FIGURA 9.11: LSDB sem informações de endereçamento externo ao domínio - Rede

OSPFv2-LSA.

Resumo do OSPFv3 LSDB.
umn), os campos LS Age (coluna Age) e LS Sequence Number (coluna Seq#).
O Router-LSAs e o Network-LSA são semelhantes ao OSPFv2, exceto que agora

fornecem apenas informações topológicas. Da coluna Link count (campo Number of
Links) conclui-se que, em todos os roteadores e

Trariamente para OSPFv2, o número de descrições de link coincide com o número de

interfaces. O resumo Network-LSA inclui o Link State ID (coluna Link ID), pois é uma parte
do identificador do link.
As informações de endereçamento são fornecidas pelos Intra-Area-Prefix-LSAs.
O resumo Intra-Area-Prefix-LSA inclui também os campos Link State ID (coluna Link ID),
tipo Referenced LSA (coluna Ref-lstype) e Referenced Link State ID (coluna Ref-LSID). A
partir das informações sobre esses LSAs, aprendemos que o LSDB tem três Intra-Area-
Prefix-LSAs, dois deles referentes a um roteador-LSA (aqueles em que o tipo de LSA
referenciado é 0 × 2001) e um referente a um Network- LSA (com tipo de LSA referenciado
0×2002). Aprendemos também que o roteador R2 origina dois LSAs desse tipo,
discriminados pelo campo Link State ID, que é 0 em um LSA e 4096 no outro.
Os Link-LSAs fornecem as informações do link e também são um complemento

relativo ao OSPFv2. As informações resumidas do Link-LSA incluem também o campo
Link State ID (coluna Link ID), que contém o número da interface à qual o LSA está
associado e a designação da interface na coluna Interface. Aprendemos que existem
cinco Link-LSAs, que coincidem com o número total de interfaces vistas pelo roteador R2.
R2 origina três LSAs desse tipo, e R1 e R3 originaram apenas um cada.
Roteador-LSAs A Figura 9.13 mostra os Roteadores-LSAs dos roteadores R1 e R2. Esta

informação pode ser visualizada usando o comando show ipv6 ospf database router.
Esses LSAs são mais simples do que os correspondentes no OSPFv2 (consulte a Figura
9.10) porque transmitem apenas informações topológicas.
No Roteador-LSA de R2 existem apenas duas descrições de link. A primeira (Link
conectado a: outro Roteador) é uma descrição do tipo 1 que caracteriza a interface com
o link ponto a ponto. A partir desta descrição, aprendemos que (i) o link ponto-a-ponto
conecta este roteador com o roteador R3 (uma vez que o Neighbor Router ID é 3.3.3.3),
(ii) o vizinho se conecta ao link por meio de sua interface número 6 (uma vez que O
Neighbor Interface ID é 6), (iii) este roteador conecta-se ao link através de sua interface
número 6 (já que o Local Interface ID é 6) e (iv) o custo dessa interface é 64 (já que a
Métrica é 64). Observe que o ID da interface é um número local e precisa ser exclusivo
apenas dentro de cada roteador.
A descrição do segundo link (Link conectado a: uma Rede de Trânsito) é uma

descrição do tipo 2 que caracteriza a interface com o link compartilhado de trânsito. O
identificador do link é colocado nos campos Neighbor Router ID e Neighbor Interface ID.
O primeiro carrega o RID do link DR e o segundo o número da interface que conecta o
DR ao link. A partir desta descrição, aprendemos que (i) o identificador do link é 2.2.2.2
(Neighbor Router ID) concatenado com 4 (Neighbor Interface ID), (ii) este roteador se
conecta ao link por meio de sua interface número 4 (Local Interface ID) , e (iii) o custo
desta interface é 10 (Métrica). Assim, concluímos que este roteador é justamente o DR
do enlace, visto que o Neighbor Router ID é o mesmo que o Advertising Router, e o
Neighbor Interface ID é o mesmo que o Local Interface ID.

FIGURA 9.13: LSDB sem informações de endereçamento externo ao domínio - OSPFv3 Router-
LSAs.
O roteador R1 possui apenas uma interface, que conecta o link compartilhado de trânsito.
Assim, seu Roteador-LSA possui apenas uma descrição de link, do tipo 2 (Link conectado a: uma
Rede de Trânsito), semelhante à segunda descrição de link do Roteador-LSA de R2. Os campos
Neighbor Router ID e Neighbor Interface ID carregam novamente o identificador do link (2.2.2.2
concatenado com 4). Aprendemos também que o roteador se conecta ao link por meio de sua
interface número 4 (local interface id) e o custo da interface é 10 (métrica).
O roteador R3 apenas faz a interface do link ponto a ponto. Assim, seu Roteador-LSA possui

FIGURA 9.14: LSDB sem informações de endereçamento externo ao domínio - Rede OSPFv3-
LSA.
apenas uma descrição de link, do tipo 1 (Link conectado a: outro Roteador), semelhante à
primeira descrição de link do Roteador-LSA de R2. Ele informa que o vizinho do outro lado do
link é R2 (Neighbor Router ID é 2.2.2.2) e se conecta ao link por meio de sua interface número
6 (Neighbor Interface ID é 6) e que R3 se conecta ao link por meio de seu interface número 6
(o ID da interface local é 6), com um custo de 64 (a métrica é 64). É apenas uma coincidência
que as interfaces local e vizinha tenham o mesmo número.
Observe que não há endereços IPv6 nesses LSAs. Conforme referido anteriormente,
OSPFv3 Router-LSAs apenas transmitem informação topológica, sendo que esta informação
recorre apenas a identificadores topológicos, que neste caso são endereços IPv4. O campo
Link State ID recebe valor zero, pois, como no caso do OSPFv2, ele não tem papel no Router-
LSAs.
Rede-LSA Na Figura 9.14, mostramos a Rede-LSA que descreve o link compartilhado de
trânsito. Esta informação pode ser visualizada usando o comando show ipv6 ospf database
network. Esse LSA é muito semelhante ao OSPFv2 (consulte a Figura 9.11). O LSA é originado
pelo roteador R2 (Advertising Router), pois R2 é o link DR. O identificador do link é definido
pelos campos Advertising Router e Link State ID. Assim, aprendemos que o identificador do link
é 2.2.2.2 concatenado com 4. A associação entre este LSA e as interfaces anexadas ao link
que ele representa é feita através do identificador do link. Conforme referido anteriormente, o
identificador do link está incluído no Router LSA de R2, nomeadamente na descrição do link
tipo 2 que caracteriza a interface do link partilhado. Dos campos Attached Router, aprendemos
que os roteadores conectados ao link são R1 (1.1.1.1) e R2 (2.2.2.2).
Como no caso do Router-LSAs, não há endereços IPv6 neste LSA, pois ele apenas
transmite informações topológicas. É também por isso que, em relação ao OSPFv2 Network-
LSA, a máscara de rede foi suprimida.
Intra-Area-Prefix-LSA A Figura 9.15 mostra os Intra-Area-Prefix-LSAs. Esta informação pode ser
visualizada usando o comando show ipv6 ospf database prefix. O roteador R2 origina dois LSAs
desse tipo e o roteador R3 origina


OSPFv3 Intra-Area-Prefix-LSAs.
um. O roteador R2 precisa originar dois Intra-Area-Prefix-LSAs porque anuncia

prefixos que estão relacionados a diferentes LSAs topológicos.
O primeiro Intra-Area-Prefix-LSA originado por R2 aponta para o roteador LSA de
R2. Sabemos disso porque o conteúdo de Referenced LSA Type, Referenced Link
State ID e Referenced Advertising Router é igual aos campos LS Type, Link State ID
e Advertising Router do Router LSA. Este Intra-Area-Prefix-LSA anuncia dois prefixos,
conforme indicado no campo Number of Prefixes: o prefixo atribuído ao link ponto a
ponto (2001:a:a:30::/64) e o atribuído ao o link compartilhado stub (2001:a:a:20::/64);
isso é feito usando os campos Prefixo de endereço e Comprimento do prefixo. O
campo Métrica inclui o custo da interface anexada ao link ao qual o prefixo foi atribuído,
ou seja, 64 para o link ponto a ponto e 10 para o link compartilhado. O primeiro é
desnecessário, pois também é anunciado no Roteador-LSA de R2.
O prefixo atribuído ao link ponto a ponto (2001:a:a:30::/64) também é

anunciado através do Intra-Area-Prefix-LSA originado pelo outro roteador final do link, ou

seja, roteador R3. Lembre-se de que, como no OSPFv2, um prefixo atribuído a um link
ponto a ponto é anunciado por seus dois roteadores finais. Este LSA aponta para o
roteador-LSA originado por R3. Novamente, isso pode ser verificado por meio do conteúdo
dos campos de ponteiro (tipo de LSA referenciado, ID do estado do link referenciado e
roteador de publicidade referenciado). O valor da métrica é novamente 64, pois a interface
de R3 para o link ponto a ponto voltou a custar 64.
Por fim, o prefixo atribuído ao link compartilhado de trânsito (2001:a:a:10::/64) é
anunciado por meio de um Intra-Area-Prefix-LSA originado pelo link DR, que é o roteador
R2. Este LSA aponta para o Network-LSA que descreve o link, e isso pode ser verificado
novamente através do conteúdo dos campos do ponteiro. Agora, Referenced LSA Type é
igual ao LS Type de uma Network-LSA, (0×2002) e Referenced Link State ID e Referenced
Advertising Router contém o identificador de link compartilhado (2.2.2.2 concatenado com
4). O campo Métrica é igual a zero e não tem utilidade aqui.
Link-LSAs de R2 A Figura 9.16 mostra os Link-LSAs do roteador R2. Esta informação

pode ser visualizada usando o comando show ipv6 ospf database link. Os Link-LSAs
fornecem informações de link e podem diferir entre os roteadores, pois eles têm apenas
escopo de link (ou seja, não são inundados fora do link).
No entanto, como em nossa rede de exemplo, R2 está conectado a todos os links, seu
LSDB inclui todos os Link-LSAs. Há um Link-LSA por interface, totalizando cinco LSAs. A
interface é identificada por meio dos campos Advertising Router e Link State ID; o último
contém o número da interface. Cada LSA contém o endereço local do link (Link Local
Address) e os prefixos globais atribuídos à interface, definidos nos campos Prefix
Address e Prefix Length, como no caso de Intra-Area-Prefix-LSAs. Observe, por exemplo,
que o roteador R2 origina três Link LSAs, um associado à interface número 5 (que anuncia
2001:a:a:20/64), outro com a interface 6 (que anuncia 2001:a:a:30/ 64) e um terceiro com
interface 4 (que anuncia 2001:a:a:10/64).
9.2.1.3 Recursos específicos do OSPFv3
Neste experimento, ilustramos três características importantes do OSPFv3 relacionadas

à separação entre informações topológicas e de endereçamento: (i) a possibilidade de
atribuir mais de uma sub-rede a um link, (ii) a possibilidade de atribuir prefixos roteáveis
apenas a alguns enlaces, e (iii) a possibilidade de declarar um prefixo em apenas um dos
roteadores vinculados ao enlace.
Procedimento experimental Nestes experimentos, usamos a topologia de rede da Figura
9.8. No entanto, conforme mostrado na Figura 9.17, nós (i) removemos o prefixo
2001:a:a:10::/64 da interface f0/0 de R2 (para que apenas R1 tenha esse pré-fixo
configurado), (ii) removemos o prefixo 2001 :a:a:30::/64 das interfaces s0/0 de R2 e R3
(para que o link serial não tenha nenhum endereço roteável atribuído a ele) e (iii) adicione
o prefixo 2001:b:b:20:: /64 para interface f0/1 de R2 (para que o link compartilhado do
stub tenha dois prefixos atribuídos a ele). Observe que as interfaces

FIGURA 9.16: LSDB sem informações de endereçamento externo ao domínio - OSPFv3 Link-
LSAs do roteador R2.
sem prefixo atribuído agora deve incluir o comando ipv6 enable, para que a interface continue
gerando um endereço link-local. A Figura 9.18 mostra a configuração dos três roteadores
para este experimento.
Tabela de encaminhamento de R3 Mostramos primeiro a tabela de encaminhamento IPv6
de R3 (Figura 9.19). Todos os três prefixos estão presentes na tabela de roteamento,
incluindo os dois prefixos sobrepostos no link compartilhado do stub, mesmo que nenhum prefixo seja

FIGURA 9.17: Experimento de recursos específicos do OSPFv3 - topologia de rede.
atribuído ao link serial. O endereço do próximo salto de todas as entradas é o endereço link-
local da interface s0/0 de R2, ou seja, fe80::c002:39ff:fe18:0. Isso mostra que, no OSPFv3,
os caminhos podem ser completamente determinados a partir das informações topológicas
fornecidas pelos Router-LSAs e Network-LSAs, e os endereços locais de link fornecidos
pelos Link-LSAs; lembre-se que esses endereços podem ser gerados automaticamente sem
a intervenção do gerente de rede. Não
FIGURA 9.18: Configurações do roteador - experimento de recursos específicos do OSPFv3.

FIGURA 9.19: Experimento de recursos específicos do OSPFv3 - Tabela de encaminhamento do

roteador R3.
prefixos roteáveis são necessários para esta finalidade. Precisamos apenas saber quais são os
destinos em nossa rede, ou seja, quais prefixos roteáveis foram atribuídos à rede e a quais
elementos de rede. Esta é precisamente a informação fornecida pelo Intra-Area-Prefix-LSAs.
Portanto, os prefixos roteáveis foram desacoplados da topologia da rede, o que é ótimo!
Intra-Area-Prefix-LSAs Os Intra-Area-Prefix-LSAs são mostrados na Figura 9.20. Existem apenas

dois LSAs e ambos são originados por R2. O primeiro LSA está associado ao Roteador-LSA de
R2 e anuncia os dois prefixos atribuídos ao link compartilhado do stub. O segundo LSA está
associado ao Network-LSA que descreve o link compartilhado de trânsito. É originado por R2 já
que R2 é o link DR. No entanto, observe que o prefixo não foi configurado em R2, mas em R1;
foi comunicado a R2 através do Link-LSA originado por R1.
Link-LSAs do link compartilhado de trânsito Os Link-LSAs do link compartilhado de trânsito são

mostrados na Figura 9.21. O Link-LSA originado por R1 inclui o prefixo roteável 2001:a:a:10::/64
configurado neste roteador. É por meio desse LSA que o R2 aprende sobre o prefixo. O Link-
LSA originado por R2 não possui
#)
-
!"#$#$#$# %&'() # *+' 1, !"#$#$#$# %&'()
##) *+' ,22
, --
+!# +! +!# # +!-
+!!"#$#$#$#
+!!"#$#$#$# &'(# !!# # ,-./
&.0+ !!# # ,-./ &'(
&.0+ !!# ,-./
&.0+
FIGURA 9.20: Experimento de características específicas do OSPFv3 - Intra-Area-Prefix-LSA.

FIGURA 9.21: Experimento de recursos específicos do OSPFv3 - Link-LSAs do link

compartilhado de trânsito.
prefixo roteável, já que nenhum foi configurado na interface. Portanto, os prefixos roteáveis
foram desacoplados das interfaces do roteador, o que é realmente ótimo!
9.2.1.4 IS-IS para IPv4
Resumo do IPv4 IS-IS LSDB Um resumo das informações do IPv4 IS-IS LSDB é mostrado na
Figura 9.22. Pode ser visualizado com o comando show isis database. A estrutura do IS-IS
LSDB foi discutida na Seção 5.6.
As informações exibidas pelo Cisco IOS incluem o LSP ID (coluna LSPID), o número de
sequência (coluna LSP Seq Num), a soma de verificação (coluna LSP Checksum), os campos
Remaining Lifetime (coluna LSP Holdtime) e o conteúdo dos bits ATT , P e OL (coluna ATT/P/
OL).
Primeiro, observe que o Cisco IOS associa o SID do roteador ao nome do roteador, devido
à presença do Dynamic Hostname TLV (consulte a Seção 5.6.4).
Por exemplo, o LSP ID do Nonpseudonode-LSP originado por R1 é exibido como R1.00-00 e
não como 000000000001.00-00.
O LSDB inclui quatro LSPs. Existem três LSPs Nonpseudonode (R1.00-00, R2.00-00,
R3.00-00), cada um descrevendo um roteador, e um Pseudonode-LSP (R2.01-00), descrevendo
o link compartilhado de trânsito. Os Pseudonode-LSPs são caracterizados por terem um
Pseudonode ID diferente de zero, o que
FIGURA 9.22: LSDB sem informações de endereçamento externo do domínio - Resumo do

IPv4 IS-IS LSDB.

FIGURA 9.23: LSDB sem informações de endereçamento externo do domínio -

Informações detalhadas do IPv4 IS-IS LSDB.
é o penúltimo octeto do LSP ID. A partir dessas informações, também aprendemos que
o DIS do link compartilhado de trânsito é o roteador R2, pois o SID do Pseudonode-
LSP (R2.01-00) é precisamente R2. Observe que o link compartilhado do stub não é
representado por um Pseudonode-LSP, da mesma forma que o OSPF, onde não é
representado por um Network-LSA.
IPv4 IS-IS LSDB detalhado A Figura 9.23 mostra informações detalhadas do IPv4 IS-IS
LSDB. Pode ser visualizado com o comando show isis database detail. A informação
não é fácil de ler, pois algumas linhas correspondem a um TLV completo e outras a
parte de um TLV. A primeira linha relacionada a cada LSP (mostrada em negrito) inclui
o mesmo conteúdo das informações resumidas da Figura 9.22 (ou seja, LSPID, LSP
Seq Num, LSP Checksum, LSP Holdtime e ATT/P/OL).
Nonpseudonode-LSP de R2 Vamos nos concentrar no Nonpseudonode LSP de R2

(ou seja, aquele com LSP ID R2.00-00). A segunda linha refere-se aos Endereços de
Área TLV; ele exibe o Area ID configurado no roteador, que é 0×490001. A terceira
linha refere-se aos protocolos suportados TLV e

indica que o protocolo da camada de rede associado ao LSP é IPv4, pois o NLPID
(Network Layer Protocol Identifier) é igual a 0×cc. A quarta linha refere-se ao Dynamic
Hostname TLV, que associa o SID do roteador de origem ao seu nome; o nome colocado
neste TLV é o nome dado pelo Cisco IOS ao roteador, que é R2. A quinta linha refere-se
ao endereço IP da interface TLV e inclui o endereço IPv4 atribuído a uma das interfaces
do roteador.
As próximas três linhas correspondem aos três TLVs de informações de acessibilidade

interna IP que fornecem as informações de endereçamento. A palavra-chave usada para
identificar esses TLVs é “IP”. Cada TLV anuncia um prefixo atribuído a uma interface de
roteador. Os prefixos são identificados nos campos Endereço IP e Máscara de sub-rede.
Os TLVs também incluem os custos de interface no campo Default Metric (exibido como
Metric), que são todos 10 neste caso.
A informação topológica é fornecida pelo IS Neighbours TLV, exibido na nona e na
décima linhas. A palavra-chave usada para identificar esses TLVs é “IS”. Os vizinhos são
identificados usando seus IDs de nó (SID concatenado com Pseudonode ID). As entradas
indicam que o roteador está conectado a R2.01, ou seja, ao link compartilhado de trânsito,
e a R3.00, ou seja, ao roteador R3 por meio de um link ponto a ponto. O custo das
interfaces com esses links também está incluso (no campo Default Metric).
Pseudonode-LSP O Pseudonode-LSP (R2.01-00) inclui apenas os vizinhos IS TLV. Este

TLV indica que o link compartilhado de trânsito está conectado aos roteadores R2 (com
ID de nó R2.00) e R1 (com ID de nó R1.00). O campo Default Metric tem valor zero em
ambas as entradas, mas esta informação é inútil.
Observe que o Pseudonode-LSP não possui informações de endereçamento. Na

verdade, esse tipo de LSP não tem permissão para transportar TLVs de informações de
acessibilidade interna de IP. Por isso, o prefixo atribuído ao link compartilhado de trânsito
(222.222.10.0/24) deve ser anunciado tanto por R1 (no R1.00-00 LSP) quanto por R2 (no
R2.00-00 LSP). Esse recurso contrasta com o OSPF, onde os prefixos atribuídos aos
links compartilhados de trânsito são anunciados apenas pelo link DR, usando um Network-
LSA (OSPFv2) ou um Intra-Area-Prefix-LSA (OSPFv3).
Nonpseudonode-LSPs de R1 e R3 Os Nonpseudonode-LSPs de R1 e R3 são mais
simples que o de R2. O IS Neighbors TLV de R1 indica que o roteador está conectado ao
link compartilhado de trânsito (R2.01-00) e, como mencionado acima, o IP Internal
Reachability Information TLV anuncia o prefixo atribuído a este link. O IS Neighbors TLV
de R3 indica que o roteador está conectado a R2 por meio de um link ponto a ponto
(R2.00-00) e o IP Internal Reachability Information TLV anuncia o prefixo atribuído a esse
link (222.222.30.0/24) . Observe que esse prefixo é anunciado pelos dois roteadores finais
de link (R2 e R3). Esse recurso é semelhante ao OSPF.

FIGURA 9.24: LSDB sem informações de endereçamento externo do domínio -

Informações detalhadas do IPv6 IS-IS LSDB.
9.2.1.5 IS-IS para IPv6
IPv6 IS-IS LSDB detalhado As informações detalhadas do IPv6 IS-IS LSDB são
mostradas na Figura 9.24. Pode ser visualizado com o comando show isis database
detail, como no caso do IPv4 IS-IS. A estrutura do IPv6 IS-IS LSDB foi discutida na
Seção 5.6.
Este LSDB é quase igual ao IP4 IS-IS LSDB (consulte a Figura 9.23).
O código dos Protocolos Suportados TLV (NLPID) mudou para 0 × 8e, já que o
protocolo da camada de rede agora é IPv6. Os LSPs agora incluem um endereço
de interface IPv6 TLV, que tem a mesma função do endereço de interface IP TLV:
ele anuncia um endereço IPv6 atribuído ao roteador (que não pode ser um
endereço local de link IPv6). A informação topológica, que é fornecida pelos IS
Neighbors TLVs, é exatamente a mesma, pois a topologia da rede não foi alterada.
A mudança mais significativa está nas informações de endereçamento.
Os prefixos agora são descritos por IPv6 Reachability TLVs, usando os campos
Prefix e Prefix Length, e são identificados no display do Cisco IOS pela palavra-
chave “IPv6”. Esses TLVs também incluem as informações de custo na métrica

FIGURA 9.25: Adjacências ponto a ponto em links compartilhados - Resumo do IPv4 IS-
IS LSDB quando os roteadores de conexão Fast Ethernet R1 e R2 são configurados
como um link ponto a ponto.
campo. Observe que o critério para anunciar prefixos é o mesmo do IPv4 IS-IS. Em
particular, um prefixo atribuído a um link (ponto-a-ponto ou compartilhado) é anunciado
por todos os roteadores conectados ao link por meio de seus LSPs Nonpseudonode. Por
exemplo, o roteador R1 anuncia 2001:a:a:10::/64 apesar de não ser o link DIS.
9.2.1.6 Adjacências ponto a ponto em links compartilhados
O IS-IS possui uma característica muito interessante, que é a possibilidade de suprimir

pseudonós (Pseudonode-LSPs) da representação da rede quando os enlaces
compartilhados que eles representam possuem apenas dois roteadores conectados.
Quando isso é feito, o link compartilhado se comporta como um link ponto-a-ponto, ou
seja, nenhum DIS é eleito para o link e os CSNPs não são transmitidos periodicamente no link.
Na verdade, esse recurso destaca que os tipos de link (ponto a ponto versus
compartilhado) são apenas abstrações para fins de representação de rede e não precisam
estar vinculados a tecnologias específicas. No nosso caso, um link Fast Ethernet, que é
uma tecnologia de link compartilhado no sentido de que permite conectar vários
dispositivos (hosts ou roteadores), será representado no LSDB como um link ponto a
ponto (já que está sendo usado para conectar apenas dois roteadores).
Procedimento experimental Para este experimento, vamos recorrer novamente à topologia
de rede da Figura 9.8. Os roteadores devem ser configurados com a configuração de
roteamento IS-IS IPv4 básica, modificada nas interfaces f0/0 dos roteadores R1 e R2. Em
particular, o comando isis network ponto-a-ponto deve ser adicionado a essas interfaces.
Resumo do IPv4 IS-IS LSDB A Figura 9.25 mostra as informações resumidas do IPv4
LSDB. Pode-se ver que o LSDB inclui apenas Nonpseudonode-LSPs, e o Pseudonode-
LSP R2.01-00 que antes representava o link compartilhado de trânsito (consulte a Figura
9.22) não está mais presente.
9.2.1.7 Uso de tags locais para identificar links
Nesta seção, analisamos em detalhes como links paralelos ponto a ponto e links
compartilhados de trânsito com o mesmo DR são descritos no LSDB. Iremos nos
concentrar em OSPFv3 e IPv4 IS-IS, uma vez que essas tecnologias utilizam tags
geradas localmente para identificar links de forma única. No OSPFv2, esse problema é
menos complexo, pois os links são sempre identificados usando endereços IPv4. IPv6 IS-IS tem

FIGURA 9.26: Experimentos relacionados ao uso de tags locais para identificação de

links - topologia de rede.
uma estrutura semelhante ao IPv4 IS-IS a esse respeito; portanto, não vale a pena repetir
o experimento.
A topologia de rede para este experimento é mostrada na Figura 9.26. Inclui apenas
dois roteadores, mas quatro enlaces entre eles: dois enlaces ponto a ponto e dois enlaces
compartilhados de trânsito (Fast Ethernets). Os roteadores devem ser configurados com
a configuração básica do roteador. Além disso, como queremos nos concentrar nos
aspectos topológicos, não há necessidade de configurar endereços roteáveis na rede
OSPFv3. Finalmente, para facilitar a análise do experimento IS-IS, é importante que os
custos de interface dos enlaces ponto a ponto sejam diferentes. O custo padrão da
interface é 10, e configuraremos um custo de 50 nas interfaces s0/0. Para fazer isso,
insira o comando isis metric 50 no modo de interface s0/0 de ambos os roteadores.
Nesses experimentos, queremos garantir que R2 se torne o DR em ambos os links

compartilhados de trânsito. Isso pode ser facilmente alcançado se os dois roteadores
forem iniciados ao mesmo tempo, pois R2 tem um RID maior.
OSPFv3 O OSPFv3 LSDB tem dois Router-LSAs, descrevendo os dois roteadores e
suas interfaces, e dois Network-LSAs, descrevendo os dois links compartilhados de
trânsito. Ele também tem seis Link-LSAs, anunciando os endereços de link local IPv6
atribuídos às seis interfaces. Não possui Intra-Area-Prefix-LSAs, pois nenhum endereço
IPv6 roteável foi configurado nos roteadores. Podemos verificar isso usando o comando
show ipv6 database. Na Figura 9.27, mostramos o Roteador-LSA completo de R1. Inclui
quatro descrições de links, uma para cada interface. As duas primeiras descrições (Link
conectado a: uma Rede de Trânsito) são descrições do tipo 2 que caracterizam os links
compartilhados de trânsito. O identificador do link é colocado nos campos Neighbor
Router ID e Neighbor Interface ID. Como o DR em ambos os links compartilhados de
trânsito é R2, o Neighbor Router ID é 2.2.2.2 em ambas as descrições. Os identificadores
dos links são diferenciados pelo número da interface que liga R2 a cada link, contido no
campo Neighbor Interface ID: é 5 para a primeira interface e 4 para a segunda.
As duas últimas descrições de link (Link conectado a: outro roteador)

FIGURA 9.27: Utilização de tags locais para identificação de links - OSPFv3 Router-LSA de R1.
são descrições do tipo 1 que caracterizam os dois enlaces ponto a ponto. Os links são
identificados pelo RID do vizinho (colocado no Neighbor Router ID) e o número da interface
que conecta o roteador com o link (colocado no campo Local Interface ID). Como o vizinho é o
mesmo para ambos os links (2.2.2.2), os identificadores são diferenciados pelo número da
interface local, que é 7 no primeiro link e 6 no segundo.
IPv4 IS-IS O IPv4 IS-IS LSDB detalhado é mostrado na Figura 9.28. Existem dois
Nonpseudonode-LSPs representando os dois roteadores (R1.00-00 e R2.00-00) e dois
Pseudonode-LSPs representando os dois links compartilhados de trânsito (R2.01-00 e
R2.02-00). Como o DIS é o mesmo nos dois enlaces compartilhados, os identificadores dos
enlaces são diferenciados pelo valor do Pseudonode ID, que é 1 no primeiro enlace e 2 no
segundo. Nos Nonpseudonode-LSPs, a informação topológica é dada pelo IS Neighbors TLV.
Observe que, em ambos os LSPs, existem apenas três TLVs desse tipo (apesar de possuírem
quatro links). Dois desses TLVs indicam a vizinhança com os links compartilhados de trânsito
(R2.01-00 e R2.02-00). Em relação aos enlaces ponto a ponto, apenas um é representado,
aquele com custo de interface 10. Isso mostra que, no IS-IS, os enlaces ponto a ponto paralelos
são representados – topologicamente – por meio de um único IS Neighbours TLV que anuncia
tica o link com o menor custo de interface. Na verdade, isso é tudo o que é necessário para
calcular os caminhos mais curtos. No entanto, os custos de interface estão incluídos nos TLVs
de acessibilidade que descrevem os prefixos atribuídos aos links (identificados pela palavra-
chave “IP”). Observe que os TLVs de acessibilidade que descrevem o prefixo 222.222.10.0/24
incluem uma métrica de 50.

FIGURA 9.28: Uso de tags locais para identificar links - Detalhado IPv4 IS-IS LSDB.
9.2.2 Estrutura LSDB quando conectado a outro AS
Analisamos agora a estrutura do LSDB quando o domínio de roteamento é conectado

diretamente a outro AS. A topologia de rede para os experimentos realizados nesta
seção é mostrada na Figura 9.29. A topologia é semelhante à da Figura 9.8, mas os
roteadores agora estão colocados em diferentes ASes: R1 e R2 em AS 200 e R3 em
AS 100. O link entre os ASBRs, ou seja, entre R2 e R3, usa endereços privados da
faixa 10.0.0.0/24, e os roteadores são conectados através de BGP. AS 200 inclui o
prefixo 222.222.10.0/24 e AS 100 inclui o prefixo 150.150.0.0/16. Cada prefixo deve
ser exportado para o AS vizinho usando BGP. O AS 200 usa um protocolo de
roteamento intradomínio, que é OSPFv2 ou IPv4 IS-IS. Não incluiremos os protocolos
de roteamento IPv6 nesses experimentos, pois as diferenças não são significativas.

FIGURA 9.29: Experimentos de estrutura LSDB quando o domínio de roteamento está

conectado diretamente a outro AS - topologia de rede.
9.2.2.1 OSPFv2
Configurações do roteador A novidade em relação aos experimentos LSDB anteriores

são as configurações necessárias para exportar informações de endereçamento para
outros ASes e disseminar internamente as informações de endereçamento importadas de
outros ASes. Na Figura 9.30 mostramos as configurações completas de R2 e R3.
Destacamos em negrito os comandos que são novidades em relação à configuração
básica do OSPFv2. R1 só precisa da configuração básica.
Primeiro, observe que R2 está configurado com OSPFv2, mas apenas em sua interface
f0/0. A interface s0/0 é usada para conectar a outro AS, e esta comunicação
FIGURA 9.30: Estrutura LSDB quando conectado a outro AS - configurações OSPFv2 de

R2 e R3.

A comunicação é por BGP, e não por OSPF (que é um protocolo de roteamento intra-
domínio).
Para configurar o BGP, precisamos criar um processo de roteamento, assim como
no caso do OSPF. Isso é feito através dos comandos roteador bgp 200 em R2 e
roteador bgp 100 em R3. O número nesses comandos é o número AS do AS onde o
roteador está localizado. O segundo comando na configuração do BGP configura a
conexão com o vizinho BGP (localizado no outro AS).
No roteador R2, o comando é vizinho 10.0.0.3 remoto como 200, e no roteador R3 é
vizinho 10.0.0.2 remoto como 100. Este comando indica o endereço IPv4 da interface
do vizinho BGP e o número AS do vizinho BGP. As próximas configurações são
diferentes em R2 e R3. Em R3, o comando network 150.150.0.0 diz ao roteador para
exportar este prefixo para seu vizinho BGP. Em R2, o comando redistribute ospf 1 diz
ao roteador para exportar para seu vizinho os prefixos que aprendeu internamente do
OSPFv2. Finalmente, a configuração OSPFv2 do R2 precisa de um comando instruindo
o roteador a disseminar através do OSPFv2 o que aprendeu com o BGP; esta é a
função do comando redistribuir bgp 200. É este comando que solicita R2 para originar
o AS-External-LSA que anuncia 150.150.0.0/16 dentro do AS 200.
Os roteadores podem ser iniciados assim que essas configurações forem concluídas.
LSDB e tabela de encaminhamento A Figura 9.31.a mostra o resumo do OSPFv2 LSDB

(que pode ser obtido com o comando show ip ospf database). O resumo agora tem três
partes. As duas primeiras partes listam o roteador-LSAs e a rede-LSAs. Há dois
Roteadores-LSAs, descrevendo R1 e R2, e um Rede-LSA, descrevendo o link de
trânsito compartilhado de 222.222.10.0/24. Observe que, ao contrário do experimento
da Seção 9.2.1.1 (consulte a Figura 9.9), não há nenhum Roteador-LSA representando
R3, pois R3 agora está fora do domínio de roteamento OSPF. A última parte do resumo
LSDB (Type-5 AS External Link States) refere-se aos AS-External-LSAs e indica que
existe um LSA deste tipo no LSDB, originado por R2 (coluna ADV Router) e anunciando
um prefixo com endereço de sub-rede 150.150.0.0 (coluna Link ID).
O AS-External-LSA é mostrado na Figura 9.31.b (pode ser obtido com o comando

show ip ospf database external). Além das informações resumidas, pode-se observar
que a máscara de sub-rede é /16 (campo Máscara de Rede), o tipo de métrica é E2
(campo Tipo de Métrica, que corresponde ao sinalizador E) e o custo externo (campo
Métrica) é 1.
Finalmente, a Figura 9.31.c mostra a tabela de encaminhamento de R1. A segunda
entrada refere-se ao prefixo externo de domínio 150.150.0.0/16, que se tornou
conhecido em R1 através do AS-External-LSA injetado por R2. A palavra-chave “O E2”
indica que esta entrada foi aprendida do OSPF e é uma rota externa E2.
9.2.2.2 IPv4 IS-IS
Configurações do roteador A configuração deste experimento possui algumas alterações

em relação à configuração básica do roteamento IS-IS. Mostramos na Fig.

!"#$%&'(
#$)* '*+!" ',%-. 01 01 $"/ #$" 0 2

0'1
3#$%&'(
&(
#$)* '*+!" ',%-. 01 $"/
04 1
567'%0#$%
#$)* '*+!"',%-. $"/ 5,

101 08*
!",2%#%' #%,8
6&35%769*( #%56'%0#$
#$%)*&03:$3"/9( ',!"
#%%-3"/91 $ "/08* #, 3:$;$ ;56&#,$6 ( 5%
&9(
;
:'
0!"5,
&(
FIGURA 9.31: Estrutura LSDB quando conectado a outro AS - (a) Resumo do OSPFv2 LSDB,
(b) OSPFv2 AS-Externo-LSA, e (c) tabela de encaminhamento de R1.
ure 9,32 para todos os três roteadores. Primeiro, R1 e R2 são configurados como roteadores L2.
Em segundo lugar, o comando metric-style wide é inserido no modo isis do roteador.
Este comando solicita o uso dos TLVs estendidos, ou seja, o TLV de alcance de IS estendido
(tipo 22) e o TLV de alcance de IP estendido (tipo 135). Isso é necessário ao se conectar a ASes
externos, pelo menos em implementações da Cisco. A designação de estilo métrico largo vem
do fato de que o comprimento da métrica nesses TLVs é muito maior do que o de seus
predecessores (o IS Neighbors TLV, o IP Internal Reachability Information TLV e o IP External
Reachability Information TLV) (consulte Figura 5.12).
A configuração do BGP é semelhante à da Seção 9.2.2.1 (consulte a Figura 9.30). Em R3,

é exatamente o mesmo. Em R2, e em seu modo de roteador bgp,

FIGURA 9.32: Estrutura LSDB quando conectado a outro roteador AS - IPv4 IS-IS
configurações.
o comando redistribute isis level-2 deve ser inserido, ao invés de redistribuir ospf 1.
Além disso, o comando redistribute connected também deve ser inserido. O primeiro
comando instrui o roteador a exportar todos os prefixos aprendidos através do IS-IS
de nível 2, e o segundo instrui a exportar os prefixos atribuídos aos links aos quais o
roteador está diretamente conectado (na verdade, apenas o último comando é
necessário, pois o AS 200 tem apenas um prefixo, e esse prefixo é atribuído ao link
compartilhado de trânsito, diretamente anexado ao R2).
LSDB e tabela de encaminhamento O IPv4 IS-IS LSDB não é muito diferente do LSDB
da Seção 9.2.1.4. O LSDB (consulte a Figura 9.33.a) agora é um LSDB L2, mas sua
estrutura é a mesma do LSDB L1. O LSDB não possui mais um Nonpseudonode-LSP
do roteador R3, pois R3 não pertence ao AS 200. Em relação aos TLVs, há duas
diferenças. Uma delas é a presença do Extended IS Reachability TLV (tipo 22) ao
invés do IS Neighbors TLV (tipo 2), que é identificado através da palavra-chave “IS
Extended”. Conforme explicado acima, essa alteração ocorreu devido ao comando
largo de estilo métrico. O segundo

FIGURA 9.33: Estrutura LSDB quando conectado a outro AS - (a) IPv4 IS-IS LSDB
detalhado, e (b) tabela de encaminhamento de R1.
é a presença do Extended IP Reachability TLV (tipo 135) que anuncia o prefixo externo do
domínio 150.150.0.0/16; este TLV é destacado em negrito na figura. Por causa desse TLV,
a tabela de encaminhamento de R1 (consulte a Figura 9.33.b) agora inclui uma entrada
para 150.150.0.0/16. A palavra-chave “i L2” indica que a entrada foi criada a partir do IS-IS
L2 LSDB.
9.2.3 Estrutura LSDB com rotas padrão
Conforme discutido na Seção 2.2.4, a injeção de prefixos externos ao domínio em um AS

deve ser evitada e não é necessária quando o AS tiver um único ASBR de saída.
Em vez disso, as rotas padrão devem ser usadas. A rota padrão é uma entrada na tabela
de encaminhamento com máscara e endereço de sub-rede zero, ou seja, 0.0.0.0/0, que é
usada como último recurso no encaminhamento de pacotes quando seus endereços de
destino não correspondem a nenhuma outra entrada. Tanto o OSPF quanto o IS-IS incluem
a possibilidade de disseminar rotas padrão dos roteadores de borda de domínio, ou seja,
da mesma forma que os prefixos externos ao domínio são injetados em um AS. Ilustraremos
esse recurso usando novamente a topologia de rede da Seção 9.2.2 (consulte a Figura 9.29).
São necessárias apenas pequenas modificações nas configurações do roteador em relação
ao item 9.2.2. Basta substituir a redistribuição do BGP no protocolo de roteamento intra-
domínio (OSPF ou IS-IS) no roteador de borda do domínio pela injeção de uma rota padrão.

FIGURA 9.34: Estrutura LSDB com rotas default - (a) OSPFv2 AS-External LSA e
(b) tabela de encaminhamento de R1 obtida com OSPFv2.
9.2.3.1 OSPFv2
Configurações do roteador Em relação à configuração da Seção 9.2.2.1, basta

substituir, em R2, o comando redistribute bgp 200 do modo ospf do roteador (ver
Figura 9.30), pelo comando default-informações originam sempre.
AS-External-LSA e tabela de encaminhamento de R1 A rota padrão é divulgada

dentro do AS da mesma forma que os prefixos externos de domínio, ou seja,
usando um AS-External-LSA. Este LSA é mostrado na Figura 9.34.a. Os campos
Link State ID e Network Mask definem o prefixo a ser instalado, e agora são 0.0.0.0
e 0, respectivamente. A tabela de encaminhamento de R1 (Figura 9.34.b) confirma
que a rota padrão foi de fato instalada.
9.2.3.2 IPv4 IS-IS
Configurações do roteador Em relação à configuração da Seção 9.2.2.2, basta

substituir, em R2, o comando redistribute bgp 200 do modo isis do roteador (ver
Figura 9.32), pelo comando default-information origin.
Tabela de encaminhamento de R1 A consequência desta alteração é a substituição,
na tabela de encaminhamento de R1, da entrada relativa a 150.150.0.0/16 pela
rota default (ver Figura 9.35). Essas informações foram disseminadas dentro do
AS 200 por meio de um Extended IP Reachability TLV, o mesmo que dissemina
os prefixos externos ao domínio.

FIGURA 9.35: Estrutura LSDB com rotas padrão - Tabela de encaminhamento de R1

obtida com IPv4 IS-IS.
9.2.4 Métricas OSPF tipo E

Nesta seção, realizamos vários experimentos que ilustram o uso da métrica E-type do
OSPF. Esta questão foi discutida na Seção 5.8.3. Os experimentos serão baseados na
topologia de rede da Figura 9.36. Nesta rede, existem novamente dois ASes (100 e 200),
mas o AS 200 agora possui dois ASBRs (R3 e R4) e dois roteadores internos (R1 e R2).
Configurações do roteador Com algumas exceções, os roteadores devem ser configurados

de acordo com as instruções da Seção 9.2.2.1 (consulte a Figura 9.30). O
FIGURA 9.36: Experimentos relacionados à métrica OSPF E-type - topologia de rede.

FIGURA 9.37: Métricas OSPF tipo E - Configurações dos roteadores R1, R3 e R5.
as configurações completas dos roteadores R1, R3 e R5 são mostradas na Figura 9.37.

Destacamos em negrito os novos comandos em relação às configurações básicas.
Para simplificar a topologia, agora configuramos um endereço de loopback em R5;
isso evita incluir uma interface Fast Ethernet conectada a um switch Ethernet (como
fizemos na AS 100 da Seção 9.2.2.1). Configurar uma interface de loopback não é
diferente de configurar outros tipos de interfaces, apenas o nome da interface

mudanças; l0 é a abreviação de loopback 0. O endereço de loopback atribuído à interface

é 150.150.5.5.
Queremos também forçar o custo da interface s0/0 do roteador R1 para 10 (seu valor
padrão é 64); para isso, o comando ip ospf cost 10 deve ser inserido nesta interface.
Observe que na configuração BGP de R5 agora existem dois vizinhos sendo declarados:
um é R3 (com endereço IPv4 10.0.3.3) e o outro é R4 (com endereço IPv4 10.0.4.4).
Agora vamos discutir vários casos.
Caso 1 O primeiro caso corresponde às configurações que acabamos de descrever. Na
Figura 9.38, mostramos o resumo do LSDB, a tabela de encaminhamento de R1 e o
resultado de um traceroute de R1 para R5 (150.150.5.5). O resumo do LSDB (Figura
9.38.a) mostra que existem quatro Router-LSAs, pois o AS 200 possui quatro roteadores,
e quatro Network-LSAs, pois existem quatro links compartilhados de trânsito dentro deste
AS; o link restante é um link ponto a ponto entre R1 e R2 e, portanto, é descrito por meio
dos Roteadores-LSAs de R1 e R2. Além desses LSAs, existem dois AS-External-LSAs,
ambos anunciando o prefixo externo do domínio 150.150.0.0/16, um originado por R3 e
outro por R4.
Com as configurações descritas acima, os ASBRs têm um tipo de métrica E2 e um
custo externo de 1. Podemos verificar isso examinando o conteúdo completo do AS-
External-LSAs usando o comando show ip ospf database external; o tipo de métrica pode
ser encontrado na linha Tipo de Métrica e o custo externo na linha Métrica. Nesse caso,
não há ASBR de saída preferencial para AS 200, e R1 acaba instalando duas entradas
que levam a 150.150.0.0/16 em sua tabela de encaminhamento ( Figura 9.38.b): uma via
R3 (com endereço de próximo salto 222.222. 10.3) e outro via R4 (com endereço de
próximo salto 222.222.20.4). Observe que existem três caminhos diferentes de R1 para
R3 ou R4. Por exemplo, os caminhos de R1 a R3 são R1ÿR3 (a rota direta), R1ÿR2ÿR3
(com custo 20) e R1ÿR4ÿR2ÿR3 (com custo 30); o caminho de menor custo é R1ÿR3.
No entanto, as entradas da tabela de roteamento relativas a 150.150.0.0/16 têm um custo

de caminho de um. Isso porque, como o tipo de métrica é E2, os roteadores ignoram o
custo do subcaminho interno (de um roteador interno para um ASBR) e o custo do
caminho é o menor entre os custos externos anunciados pelos ASBRs (neste caso, ambos
os ASBRs anunciam um custo externo de 1).
Podemos confirmar que R1 usa de fato dois caminhos para chegar a R1 por meio do
comando traceroute (consulte a Figura 9.38.c.) Observe que os caminhos alternam entre
passar por R3 ou R4.
Caso 2 Agora vamos alterar o custo externo de R4 para 2, mantendo o tipo de métrica
como E2. O objetivo é garantir que R3 se torne o ASBR de saída preferido para o domínio.
Podemos fazer isso inserindo o comando redistribuir bgp 200 metric-type 2 metric 2, no
modo roteador ospf de R4. Isso substitui o comando anterior que era simplesmente
redistribuir bgp 200. O resultado desse experimento é exibido na Figura 9.39. O roteador
R1 ainda recebe dois AS-External-LSAs (podemos confirmar isso usando show ip ospf
database external), mas o originado por R4 agora tem um custo externo de 2. Assim, R3
se torna o melhor ASBR e a tabela de encaminhamento de R1 (Figura 9.39.a) agora inclui
apenas um caminho para 150.150.0.0/16, aquele através de R3 (com o próximo

FIGURA 9.38: Métricas OSPF tipo E (caso 1) - (a) Resumo de OSPFv2 LSDB, (b)
tabela de encaminhamento de R1 e (c) traceroute de R1 para 150.150.5.5.
endereço de salto 222.222.10.3). Isso é confirmado pelo traceroute da Figura 9.39.b.
Caso 3 Nos dois experimentos anteriores, o subcaminho interno em direção a R3 foi

sempre a rota direta R1ÿR3, via interface f0/0 de R1. Para ver isso

FIGURA 9.39: Métrica OSPF tipo E (caso 2) - (a) Tabela de encaminhamento de R1 e (b)
traceroute de R1 para 150.150.5.5.
o ASBR de saída preferido é mantido quando o subcaminho interno muda, agora vamos
aumentar o custo OSPF da interface f0/0 de R1 para 40. Podemos fazer isso inserindo o
comando ip ospf cost 40 no modo interface f0/0 .
A tabela de encaminhamento de R1 (Figura 9.40.a) mostra que há novamente apenas
uma entrada para 150.150.0.0/16, mas o roteador do próximo salto agora é R2 (o
endereço do próximo salto é 222.222.30.2). O traceroute (Figura 9.40.b) mostra que o
caminho para R5 agora é R1ÿR2ÿR3ÿR5. Assim, R3 ainda é o ASBR de saída, pois seu
custo externo é menor que o de R4. Além disso, o custo do subcaminho interno R1ÿR2ÿR3
é 20. No entanto, o custo do caminho indicado no 150.150.0.0/16 ainda é o custo externo
(ainda 1), pois o tipo de métrica é E2.
Caso 4 Vamos agora forçar o caminho mais curto de R1 a R3 para cruzar R4.
Uma possibilidade de implementação dessa solução de roteamento é aumentar o custo
da interface s0/0 do roteador R1 para 30. Feito isso, o caminho mais curto de R1 para R3
passa a ser R1ÿR4ÿR2ÿR3, com um custo de 30. A Figura 9.41.a mostra que o próximo
salto para 150.150.0.0/16 mudou para R4 (o endereço do próximo salto agora é
222.222.20.4). Porém, de acordo com o traceroute (Figura 9.41.b) os pacotes saem do
AS 200 por R4 (e não por R3). Embora a intenção do R1 seja que os pacotes saiam do
AS pelo R3 (pois o AS-External LSA originado pelo R3 tem um custo externo menor), o
fato é que o R4 desvia os pacotes diretamente para o R5. De fato, sob o paradigma de
roteamento do próximo salto do roteamento da Internet, os roteadores não têm controle
sobre os caminhos completos; eles controlam apenas o caminho para o próximo salto.
Isso pode ser verificado através da tabela de encaminhamento do R4 (Figura 9.41.c).
Conforme a tabela, os pacotes que chegam a este roteador e são destinados a 150.150.5.5
são encaminhados através de sua última entrada, que foi aprendida por BGP e tem como
próximo salto R5 (o endereço do próximo salto é 10.0.4.5). Observe que o roteador R4
também contém em seu LSDB o AS-External

FIGURA 9.40: Métrica OSPF tipo E (caso 3) - (a) Tabela de encaminhamento de R1

e (b) traceroute de R1 para 150.150.5.5.
FIGURA 9.41: Métrica OSPF tipo E (caso 4) - (a) Tabela de encaminhamento de R1,
(b) traceroute de R1 para 150.150.5.5 e (c) tabela de encaminhamento de R4.
LSA originado por R3 (podemos verificar isso através do comando show ip ospf
database external). Assim, R4 sabe que existe um caminho para 150.150.0.0/16 por
meio de R3. No entanto, ao decidir qual caminho usar, R4 prefere o caminho

FIGURA 9.42: Métrica OSPF tipo E (caso 5) - (a) Tabela de encaminhamento de R1 e (b)
traceroute de R1 para 150.150.5.5.
aprendeu diretamente com seu par BGP, porque o BGP externo tem uma distância
administrativa menor que o OSPF: o OSPF tem 110 e o BGP externo tem 20.
Essas distâncias administrativas também são exibidas na tabela de encaminhamento.
Caso 5 Vamos agora alterar o tipo de métrica para E1 e retornar todos os custos de
interface para 10. Para alterar o tipo de métrica, insira o comando redistribute bgp 200
metric-type 1 metric 1 no modo roteador ospf de R3 e R4. O resultado líquido é o mesmo
do caso 1. Na tabela de encaminhamento de R1 (Figura 9.42.a) há novamente duas
entradas para 150.150.0.0/16, e o traceroute (Figura 9.42.b) confirma que os caminhos
alternam entre passando por R3 e R4. No entanto, as entradas indicam que a métrica
agora é do tipo E1 (palavra-chave “O E1”). Além disso, o custo agora é 11, que
corresponde à soma do custo do caminho mais curto de R1 ao ASBR com o custo externo
configurado no ASBR.
Caso 6 Para alterar o ASBR de saída, podemos alterar o custo do subcaminho interno ou
o custo externo. Começamos com a segunda opção. Aumentaremos o custo externo
configurado em R4 para 10 (usando o comando redistribute bgp 200 metric-type 1 metric
10). A tabela de encaminhamento de R1 (Figura 9.43.a) e o traceroute (Figura 9.43.b)
mostram que o caminho agora passa por R3 e tem um custo ponta a ponta de 11.
Caso 7 Vamos agora alterar novamente o ASBR de saída, mas através da manipulação
do subcaminho interno. Aumentaremos o custo da interface f0/0 de R1 para 20. Nesse
caso, o custo do caminho fim a fim para R5 passa a ser 21


!"!#! !"!
#!
!"!#! $
%&!#'
(")!)*'!## (!+#'#
,-!.-!,-! -!$-!,-!

por meio de R3: o custo interno é 20 diretamente via interface f0/0 ou via interface
s0/0, e o custo externo é 1. No entanto, o custo de ponta a ponta por meio de R4 é
20 e R4 se torna a saída preferida ASBR. Isso pode ser confirmado através da
tabela de encaminhamento de R1 (Figura 9.44.a) e do traceroute (Figura 9.44.b).
9.2.5 Estrutura OSPF LSDB quando conectado ao domínio RIP
Nesta seção, discutimos a estrutura LSDB quando um domínio OSPFv2 está

diretamente conectado a um domínio RIP e ambos os domínios estão no mesmo AS.

FIGURA 9.45: Experimentos relacionados à estrutura OSPF LSDB quando conectado ao

domínio RIP - topologia de rede.
Nosso principal objetivo é mostrar que a estrutura LSDB é a mesma como se o domínio
de roteamento estivesse conectado a outro AS (que discutimos na Seção 9.2.2.1).
A topologia de rede para este experimento é mostrada na Figura 9.45. O roteador R2

está na fronteira entre os dois domínios de roteamento (o OSPF o chama de ASBR
mesmo neste caso). O roteador R1 e a sub-rede 222.222.10.0/24 pertencem ao domínio
OSPF (assim como metade do roteador R2); o roteador R3 e as sub-redes 222.222.20.0/24
e 222.222.30.0/24 pertencem ao domínio RIP (assim como a outra metade do roteador
R2).
Configurações do roteador Na Figura 9.46, mostramos as configurações dos roteadores
R2 e R3. O roteador R1 só precisa ser configurado com a configuração de roteamento
OSPFv2 básica. R3 deve ser configurado com RIP. A configuração do RIP é muito
semelhante à do OSPFv2. Precisamos apenas criar um processo RIP, usando o comando
router rip no modo de configuração global, e declarar as sub-redes às quais o roteador
está diretamente conectado (e que serão anunciadas através do RIP). Não precisamos
(nem é possível) dar um número ao processo RIP, como faríamos no OSPF.
No roteador R2, um OSPFv2 e um processo RIP devem ser criados e configurados.

No processo OSPFv2, devemos declarar as sub-redes diretamente conectadas ao
roteador (que serão anunciadas através do OSPFv2), e no processo RIP devemos fazer
a mesma coisa. O roteador também deve ser configurado para redistribuir os prefixos
aprendidos por um protocolo para o outro. Isso é semelhante à configuração do BGP,
exceto pelo fato de ocorrer no mesmo roteador. Assim, (i) o comando redistribute rip
incluído no modo router ospf 1 diz ao R2 para injetar no processo OSPF os prefixos
aprendidos através do RIP, e (ii) o redistribute ospf 1 metric 1 incluído no processo router
rip diz ao R2 para injetar no processo RIP, os prefixos aprendidos por meio do OSPF,
dando a eles uma métrica de 1.
LSDB e tabela de encaminhamento A Figura 9.47 mostra o resumo do OSPFv2 LSDB e

a tabela de encaminhamento do roteador R1. Existem dois roteadores LSAs, descrevendo
R1 e R2 e suas interfaces, e um Network-LSA,

FIGURA 9.46: Estrutura OSPF LSDB quando conectado ao domínio RIP -

Configurações dos roteadores R2 e R3.
FIGURA 9.47: Estrutura OSPF LSDB quando conectado ao domínio RIP - (a)
Resumo de OSPFv2 LSDB, e (b) tabela de encaminhamento de R1.
descrevendo o link compartilhado de trânsito e seu prefixo atribuído (222.222.10.0/24).

Além disso, os dois prefixos externos ao domínio importados do RIP do main
(222.222.20.0/24 e 222.222.30.0/24) são descritos através de dois AS

External-LSAs (como se os prefixos fossem importados de outro AS usando BGP). Na

tabela de encaminhamento do R1, as entradas relativas a esses prefixos iniciam com a
palavra-chave “O E2”, indicando que são prefixos externos ao domínio e foram aprendidos
através do OSPF com métrica do tipo E2. Observe que o valor da métrica E2 é 20. Esse
é o valor padrão dado à métrica E2 quando a redistribuição é do RIP. Conforme mostrado
na Seção 9.2.4, o valor da métrica seria um caso a redistribuição fosse do BGP, mas esse
valor é configurável. Podemos então concluir que a estrutura LSDB é a mesma se a
informação de endereçamento externo for importada de outro AS ou de outro domínio de
roteamento do mesmo AS.

10
Experimentos de Sincronização
Mecanismos
Os mecanismos de sincronização estabelecem as relações de vizinhança entre os

roteadores e mantêm o LSDB atualizado e sincronizado. Essa questão foi discutida
no Capítulo 6. Neste capítulo, apresentamos experimentos que ilustram a operação
dos diversos mecanismos. Começamos abordando o protocolo Hello na Seção 10.1 e
a eleição do roteador designado na Seção 10.2.
As seções 10.3 e 10.4 cobrem os procedimentos de inundação e exclusão. Finalmente,
na Seção 10.5, ilustramos o processo inicial de sincronização do LSDB.

Nesta seção, realizamos vários experimentos que ilustram a operação do protocolo
Hello. A topologia de rede da Figura 10.1 é utilizada em todos os experimentos, exceto
aquele da Seção 10.1.4 relacionado a enlaces ponto a ponto IS-IS. Ele inclui quatro
roteadores conectados ao mesmo link compartilhado usando um hub Ethernet. Os
roteadores devem ser configurados inicialmente com a configuração de roteamento
básica. No caso do OSPFv3, não há necessidade de configurar endereços IPv6 nas
interfaces. No caso de IS-IS, os roteadores devem ser configurados como roteadores
L1/L2, sem restrições quanto ao tipo de interface (nesse caso, as interfaces também
serão do tipo L1/L2). Não mostramos experimentos com IPv6 IS-IS, pois o
comportamento é o mesmo que IPv4 IS-IS.
Por que os roteadores devem ser conectados por meio de um hub? Destacamos que
os roteadores devem ser conectados através de um hub e não através de um switch.
Isso é importante para os experimentos do OSPF, pois alguns pacotes são transmitidos
em unicast durante o processo de eleição do roteador designado. Os switches filtram
o tráfego unicast e, portanto, esse tipo de tráfego pode não ser observado por sondas
Wireshark localizadas fora do caminho do tráfego. Por exemplo, um probe instalado
na interface f0/0 do roteador R1 não veria o tráfego unicast trocado entre os roteadores
R2 e R3.
313

314 10 Experimentos sobre Mecanismos de Sincronização
FIGURA 10.1: Experimentos do protocolo Hello - topologia de rede.
10.1.1 Transmissão periódica de pacotes HELLO

Analisamos primeiro a transmissão periódica de pacotes HELLO em OSPF e IS-IS em
condições estáveis, ou seja, em uma rede convergente.
Procedimento experimental O procedimento experimental é muito simples neste caso:
(i) iniciar todos os roteadores ao mesmo tempo e esperar até que a rede converja (pelo
menos 40 segundos), (ii) instalar uma sonda Wireshark no link compartilhado com um
ospf ou filtro isis, dependendo do caso.
Captura Wireshark OSPFv2 A Figura 10.2 mostra a captura OSPFv2 Wire shark. Os
pacotes HELLO são todos transmitidos usando o endereço multicast OSPFv2
AllSPFRouters (224.0.0.5). Observe que cada roteador transmite pacotes HELLO no
link com uma periodicidade de aproximadamente 10 segundos.
Uma olhada em um OSPFv2 HELLO A Figura 10.3 mostra um pacote HELLO enviado
por R2. Observe primeiro os cabeçalhos de encapsulamento da camada 2 e da camada
3, ou seja, o cabeçalho Ethernet e o cabeçalho IPv4. Como a rede é estável, o pacote
lista todos os vizinhos de R2 nos campos Active Neighbor, usando seus RIDs; os
vizinhos são R1 (RID=1.1.1.1), R3 (RID=3.3.3.3) e R4 (RID=4.4.4.4).
Além disso, indica que o roteador R4 é o DR e o roteador R3 o BDR. No entanto, ele
não identifica o DR e o BDR por meio de seus RIDs, mas sim pelos endereços IPv4
atribuídos às suas interfaces. O endereço IPv4 do DR atua como o identificador de link
compartilhado. O OSPFv2 HELLO também inclui os valores de Network Mask, Hello
Interval, Router Dead Interval e Router Priority, além dos diversos sinalizadores de
opções.
Uma olhada em um OSPFv3 HELLO A transmissão periódica de pacotes HELLO no
OSPFv3 é semelhante ao OSPFv2 (portanto, não o mostramos). No entanto, o
conteúdo dos pacotes HELLO é um pouco diferente. A Figura 10.4 mostra um pacote
HELLO enviado por R2. É interessante comparar com o OSPFv2 HELLO de

FIGURA 10.2: Transmissão periódica de pacotes OSPFv2 HELLO em condições

estáveis - Captura Wireshark.
Figura 10.3. O cabeçalho de encapsulamento da camada 3 agora é um cabeçalho

IPv6; observe que o endereço de origem é o endereço de link local IPv6 atribuído à
interface f0/0 de R2 e o endereço de destino é o endereço IPv6 AllSPFRouters
(ff02::5). Os vizinhos de R2 são identificados como em OSPFv2, ou seja, incluindo
seus RIDs nos campos Active Neighbor. A principal diferença está na identificação
do DR e BDR que, no OSPFv3, também é feita utilizando os RIDs.
O ID da interface é o número da interface de envio, que neste caso é 4. Lembre-se
de que o ID da interface do DR, junto com seu RID, é o que define o identificador do
link compartilhado. Os campos Hello Interval, Router Dead Interval e Router Priority
também existem no OSPFv2 HELLO.

estáveis - pacote OSPFv2 HELLO transmitido pelo roteador R2.


estáveis - pacote OSPFv3 HELLO transmitido pelo roteador R2.
No entanto, a máscara de rede foi removida, pois OSPFv3 HELLOs não carregam
informações de endereçamento.
Captura Wireshark IS-IS A Figura 10.5 mostra a captura IS-IS Wireshark. Em relação à
captura original, mantivemos apenas os pacotes HELLO; lembramos que, nos links
compartilhados IS-IS, os CSNPs também são transmitidos periodicamente. Como as
interfaces do roteador são do tipo L1/L2, cada interface envia L1 e L2 LAN IS-IS
HELLOs. A origem e o destino indicados pelo Wireshark são os endereços MAC, pois
os pacotes de controle IS-IS são encapsulados diretamente em pacotes da camada 2
(neste caso, pacotes Ethernet). Observe que os pacotes do tipo L1 são enviados usando
o endereço multicast AllL1ISs (indicado como ISIS-all-level-1-IS's no Wireshark) e os
pacotes do tipo L2 são enviados usando o endereço AllL2ISs (indicado como ISIS-all-
level-2 -IS no Wireshark). Em relação à periodicidade das transmissões HELLO, observe
que o R4 transmite HELLOs com mais frequência que os outros roteadores, pois é o link
DIS. A periodicidade é de aproximadamente 3 segundos para R4 e aproximadamente
10 segundos (às vezes menos) para os demais roteadores.
Uma olhada em um L1 LAN IS-IS HELLO A Figura 10.6 mostra um pacote L1 LAN IS-IS
HELLO enviado pelo roteador R2. Observe primeiro o cabeçalho da camada 2, que
inclui o endereço multicast AllL1ISs (01:80:c2:00:00:14) como o endereço de destino.
Não mostramos o cabeçalho do pacote IS-IS, mas é onde o tipo de pacote é indicado
(L1 LAN IS-IS HELLOs tem um tipo de pacote de 15).
No pacote HELLO há muitas coisas a serem observadas. Os bits Circuit Type confirmam
que este pacote foi enviado de uma interface L1/L2 (seu valor é 3).
O campo Source ID (indicado como SystemID Sender of PDU) confirma que o pacote
foi enviado pelo roteador R2. O campo LAN ID (indicado como SystemID Designated
DIS) confirma que o roteador R4 é o DIS. Também aprendemos que o Hold Timer é de
30 segundos e a prioridade da interface é de 64. O restante do conteúdo do HELLO são
TLVs: os protocolos suportados, o anúncio de área

FIGURA 10.5: Transmissão periódica de pacotes LAN IS-IS HELLO em condições

estáveis - Captura Wireshark.
vestidos, o endereço de interface IP, a sinalização de reinicialização (não abordada

neste livro) e os vizinhos IS (do tipo 6). O pacote também inclui vários Padding
TLVs, que não incluímos na figura. Em relação aos TLVs, apenas o conteúdo do IS
Neighbours TLV é mostrado. Este TLV identifica os vizinhos de R2 usando seus
endereços MAC. De acordo com a captura do Wireshark da Figura 10.5, podemos
verificar que c2:04:44:4c:00:00 pertence a R4, c2:03:0f:f8:00:00 pertence a R3 e
c2:01:2f :40:00:00 pertence a R1.
10.1.2 Detecção de falhas do roteador
Agora vamos simular uma falha no roteador e observar a reação. O comportamento

é semelhante em OSPF e IS-IS. Assim, ilustramos apenas o caso do OSPFv2.
Procedimento experimental O procedimento é o seguinte: (i) ligar todos os roteadores
ao mesmo tempo e aguardar a convergência da rede; (ii) instalar uma sonda
Wireshark no link compartilhado com um filtro ospf; (iii) desligue o roteador R1.

FIGURA 10.6: Transmissão periódica de pacotes LAN IS-IS HELLO em condições

estáveis - pacote L1 LAN IS-IS HELLO transmitido pelo roteador R2.
Captura do Wireshark A Figura 10.7 mostra a captura do Wireshark. Em relação à

captura original, mantivemos apenas os pacotes HELLO. A captura começa com o
último HELLO enviado por R1, antes da falha (pacote 31); ele lista R2, R3 e R4 como
vizinhos. Segue-se então um período em que os roteadores restantes continuam
anunciando R1 como vizinho (do pacote 32 ao pacote 56). O primeiro roteador
reconhecendo que R1 não está mais ativo é o roteador R4 no pacote 57, e então R2 e
R3 também o reconhecem nos pacotes 67 e 68.
É interessante observar detalhadamente o tempo dos eventos (ver Figura 10.8).
O tempo para detectar uma falha é RouterDeadInterval, que tem um valor padrão de
40 segundos. Quando R2, R3 e R4 recebem o último HELLO de R1, eles redefinem
seus temporizadores de atividade Hello. Como eles não receberão mais HELLOs de
R1, os cronômetros continuarão avançando até atingirem 40 segundos, momento em
que declaram R1 como morto. Isso acontece aproximadamente no segundo
30,06+40=70,06. O tempo em que o primeiro pacote HELLO sem R1 listado é
transmitido depende do tempo relativo das transmissões HELLO dos vários roteadores.
A captura mostra que as transmissões R4 ocorrem imediatamente após a transmissão
R1, e as transmissões R2 e R3 ocorrem imediatamente antes. Assim, quando os timers
Hello liveness expirarem (e todos eles irão no segundo 70.06), R4 tem uma transmissão
HELLO programada para acontecer em menos de um segundo (pacote 57 no segundo
70.28), mas o próximo HELLO

FIGURA 10.7: Detecção de falha de roteador em OSPFv2 - Captura Wireshark.
as transmissões de R2 e R3 acontecem apenas 10 segundos depois (pacotes 67 e 68

no segundo 80).
10.1.3 Verificando relacionamentos bidirecionais no OSPF

Neste experimento, analisamos como os roteadores verificam se podem se comunicar
em ambas as direções com os vizinhos. O processo é o mesmo para todas as
tecnologias e tipos de link, exceto para links ponto a ponto IS-IS. Nesta seção,
ilustramos o processo para o caso de links compartilhados OSPFv2. Os links ponto a
ponto IS-IS serão discutidos na Seção 10.1.4.
Procedimento experimental Neste experimento, usamos o Wireshark e o recurso de
depuração do Cisco IOS. O procedimento é o seguinte: (i) iniciar os roteadores
FIGURA 10.8: Detecção de falha do roteador em OSPFv2 - Sincronização relativa das

transmissões HELLO e expiração do liveness timer.

FIGURA 10.9: Verificando relacionamentos bidirecionais em OSPFv2 - (a) Captura

Wireshark e (b) mensagens de saída de depuração de R4.
R2, R3 e R4 e aguarde até que a rede converja; (ii) inserir os comandos debug ip ospf
hello e debug ip ospf adj no roteador R4; (iii) instalar uma sonda Wireshark no link
compartilhado com um filtro ospf; (iv) ligue o roteador R1.
Captura do Wireshark e saída de depuração A Figura 10.9 mostra a captura do

Wireshark e a saída de depuração do roteador R4. Em relação à captura original do
Wire shark, mantivemos apenas os pacotes HELLO. Em nossa discussão, usaremos
essas duas informações em paralelo.
HELLO inicial de R1 e HELLO periódico de R4 Quando R1 é ligado, ele imediatamente
envia um pacote HELLO (pacote 32). Este pacote não lista nenhum vizinho, porque R1
ainda não recebeu nenhum pacote HELLO. A recepção deste pacote é sinalizada pela
saída de depuração de R4 (mensagem 1).
De acordo com esta saída, R4 decide enviar um HELLO imediato para R1 (mensagem
2), o que na verdade não acontece. Os HELLOs imediatos são unicast em OSPF, e a
captura do Wireshark mostra que não há HELLO unicast de R4 para R1. Achamos que
esta transmissão foi cancelada, pois houve

FIGURA 10.10: Verificando relacionamentos bidirecionais em OSPFv2 - Quando os

relacionamentos de vizinhança se tornam bidirecionais.
uma transmissão HELLO periódica programada para o mesmo horário (pacote 41 e

mensagem 3). No pacote 41, o roteador R4 já lista R1 como vizinho.
Reação ao pacote 41 Quando R1 recebe o pacote 41, sua relação de vizinhança com
R4 passa para o estado 2-Way (porque R1 se vê listado, pela primeira vez, em um
HELLO enviado por R4). R1 também decide enviar um HELLO imediato para R4 (pacote
42); lembre-se da discussão na Seção 6.2.7, que um roteador envia um HELLO imediato
a um vizinho quando recebe um HELLO desse vizinho e o estado de seu relacionamento
é menor que 2 vias; este é justamente o caso de R1 quando recebeu o HELLO de R4
(pacote 41).
Observe que no pacote 42, R1 lista apenas R4 como vizinho.
Reação ao pacote 42 A mensagem 6 da saída de depuração de R4 sinaliza a recepção
do pacote 42 enviado por R1. Neste ponto, a relação entre R4 e R1 (como visto por R4)
atinge o estado 2-Way, e este evento é sinalizado pela mensagem 7 da saída de
depuração.
Reação ao pacote 46 O pacote 46 é um HELLO periódico enviado por R2 onde R1 já
está listado. Novamente, quando R1 recebe este pacote, seu relacionamento com R2
muda para o estado 2-Way, e R1 também decide enviar um HELLO imediato para R2
(pacote 47). Neste pacote, R1 ainda não lista R3 como vizinho.
Reação ao pacote 47 Quando R2 recebe o pacote 47, o estado de seu relacionamento
com R1 muda para o estado 2-Way.
Pacotes 49 e 77 O pacote 49 é o primeiro HELLO periódico enviado por R3, que já lista
R1 como vizinho, e o pacote 77 é o primeiro HELLO periódico enviado por R1 onde todos
os vizinhos são listados.
Quando cada relacionamento se torna bidirecional, a Figura 10.10 resume os eventos
pelos quais cada relacionamento se move para o estado de 2 vias. Apenas os seis
relacionamentos envolvendo R1 são listados, uma vez que todos os outros relacionamentos
foram formados antes de R1 ser ativado.

FIGURA 10.12: Verificando relacionamentos bidirecionais em enlaces ponto a ponto

IS-IS - IS-IS HELLO PONTO A PONTO enviado pelo roteador R2.
Ponto de adjacência de três vias TLV (tipo 240) onde o estado de inicialização é
declarado (codificado com valor 1).
10.1.5 Adjacências OSPF

Vamos agora verificar se as adjacências OSPF não podem ser estabelecidas entre
duas interfaces se elas não estiverem configuradas com o mesmo Area ID,
HelloInterval ou RouterDeadInterval. Esta questão foi discutida na Seção 6.2.3.2. As
três regras mencionadas acima se aplicam tanto ao OSPFv2 quanto ao OSPFv3, e
vamos ilustrá-las usando uma rede OSPFv2. Deixamos as regras específicas de cada
tecnologia como experimentos adicionais.
Procedimento experimental Faremos uma sequência de modificações na configuração
básica de roteamento. Assim, ligue todos os roteadores ao mesmo tempo e espere
até que a rede converja. Para começar, execute o comando show ip ospf vizinho no
roteador R4 para verificar se R4 reconhece R1, R2 e R3 como vizinhos adjacentes
(vamos ficar de olho em R4; R2 e R3 seguem o mesmo comportamento). O resultado
desse comando é mostrado na Figura 10.13.a. Vamos agora realizar três experimentos.
Alteração de HelloInterval Na interface f0/0 de R1, digite ip ospf hello interval 20.
Isso define o valor HelloInterval como 20 segundos. Agora, vá até o console do R4 e
espere até ver uma mensagem de aviso indicando que a adjacência com o R1
terminou (você terá que esperar aproximadamente 40 segundos).
Em seguida, execute o comando show ip ospf vizinho em R4 para verificar se R1 não
é mais considerado vizinho. Isso é mostrado na Figura 10.13.b.
Alteração de RouterDeadInterval Novamente na interface f0/0 de R1, insira no ip ospf
hello-interval; isso retornará o HelloInterval de volta ao padrão

FIGURA 10.13: Adjacências OSPF entre R4 e outros roteadores (a) antes e (b) depois
de alterar o HelloInterval de R1.
valor (10 segundos). Use o comando show ip ospf vizinho para verificar se a
adjacência entre R1 e R4 foi restabelecida muito rapidamente. Agora, digite ip ospf
dead-interval 100 na mesma interface. Isso define o valor de RouterDeadInterval para
100 segundos. O resultado é o mesmo do experimento anterior: após um período de
espera de aproximadamente 40 segundos, R1 deixa de ser considerado vizinho de
R4 (verifique novamente com o comando show ip ospf vizinho).
Alteração do ID da área Novamente na interface f0/0 de R1, não insira nenhum

intervalo morto ip ospf para redefinir RouterDeadInterval para seu valor padrão.
Vamos agora mudar a área da interface f0/0 de R1 para a área 1. Para isso, digite o
comando network 222.222.10.0 0.0.0.255 area 1 no modo roteador. Você verá um
comportamento semelhante ao dos dois experimentos anteriores.
Agora mude também a área da interface f0/0 de R2 para a área 1. Você notará
que R2 se torna adjacente a R1 (porque eles têm parâmetros correspondentes), e R3
e R4 permanecem como vizinhos adjacentes. Assim, houve uma partição nas relações
de vizinhança. No entanto, esta configuração não é permitida no OSPF, pois um link
deve pertencer a apenas uma área.
10.1.6 Adjacências IS-IS

O objetivo nesta seção é explorar os vários tipos de adjacências em IS-IS, conforme
determinado pelo tipo de interface (somente L1, somente L2 e L1/L2) e os endereços
declarados (na área Endereços TLV) .
Procedimento experimental Realizamos uma sequência de quatro alterações na
configuração do roteador R1 e observamos os resultados no roteador R4, partindo da
configuração básica do roteamento IS-IS, com todos os roteadores e interfaces
configurados como L1/L2. Usamos o Wireshark em um experimento. Para começar,
ligue todos os roteadores ao mesmo tempo e espere até que a rede converja.

FIGURA 10.14: Adjacências IS-IS vistas por R4 quando (a) todas as interfaces são L1/L2,
(b) a interface R1 é somente L1, (c) a interface R1 é somente L1 e R1 está em uma área
diferente, e ( d) A interface R1 é somente L2 e R1 está em uma área diferente.
Todas as interfaces do tipo L1/L2 A Figura 10.14.a exibe o resultado da exibição de

vizinhos isis em R4. Como todas as interfaces são do tipo L1/L2, R4 estabelece três
adjacências L1 e três adjacências L2 com seus vizinhos.
A interface R1 é somente L1 Agora configure a interface f0/0 do roteador R1 como
somente L1. Para fazer isso, digite o comando isis circuit-type level-1 nesta interface.
Como uma interface somente L1 só pode estabelecer adjacências L1, a adjacência L2
que existia anteriormente entre R1 e R4 é destruída; apenas a adjacência L1 permanece.
Isso é mostrado em 10.14.b.
A interface R1 é somente L1 e R1 tem duas áreas configuradas. O próximo experimento
é adicionar a área 2 ao roteador R1. Para isso, insira o comando net
49.0002.0000.0000.0001.00 no modo isis do roteador R1. Agora, R1 está configurado
com duas áreas e anunciará esse fato nos pacotes L1 HELLO que ele transmitir. Isso é
mostrado na Figura 10.15. Os endereços de área TLV anunciam duas áreas, área 1 e área
2. Observe também que o tipo de circuito da interface de envio é somente L1. Neste caso,
não há mudança nas adjacências

FIGURA 10.15: Adjacências IS-IS - L1 HELLO enviado por R1 anunciando duas áreas
configuradas.
entre R1 e R4, pois ainda possuem uma área em comum (que é a área 1). Você pode
verificar isso usando o comando show isis vizinhos.
A interface R1 é somente L1 e R1 em uma área diferente Agora, vamos remover a
área 1 do roteador R1. Para fazer isso, digite o comando no net
49.0001.0000.0000.0001.00 no modo isis do roteador de R1. O resultado é mostrado
na Figura 10.14.c. Não há mais adjacências entre R1 e R4, pois (i) R1 só transmite
L1 HELLOs e, portanto, só pode estabelecer adjacências de L1 com vizinhos e (ii)
não possui área em comum com seus vizinhos.
A interface R1 é somente L2 e R1 em uma área diferente Finalmente, alteramos o

tipo de interface de R1 para somente L2 (sem alterar a área configurada).
Para fazer isso, digite o comando isis circuit-type level-2 na interface f0/0 do roteador.
A Figura 10.14.d mostra que R1 e R4 restabeleceram uma adjacência do tipo L2. Isso
ocorre porque as adjacências L2 não são restritas pelas áreas configuradas: elas
podem ser estabelecidas entre duas interfaces que transmitem L2 HEL LOs (ou seja,
configuradas como L2-only ou L1/L2) mesmo que os roteadores correspondentes não
tenham área em comum.

FIGURA 10.16: Experimentos relacionados à escolha dos roteadores designados -

Topologia da rede.
10.2 Eleição do roteador designado

Esta seção apresenta vários experimentos que ilustram o processo de eleição do
roteador designado em OSPF e IS-IS. Esta questão foi discutida na Seção 6.3.
Configuração experimental Os experimentos usam a topologia de rede da Figura 10.16,
com três roteadores conectados a um link compartilhado. Serão realizadas com as
versões IPv4 de ambos os protocolos, pois o comportamento das versões IPv6 é
semelhante. Os roteadores devem ser configurados inicialmente com as configurações
básicas de roteamento. Tanto o Wireshark quanto o recurso de depuração do Cisco
IOS serão usados nesses experimentos.
10.2.1 OSPF
Abordaremos cinco casos diferentes: (i) inicialização a frio, (ii) inicialização a frio com
prioridades de roteador, (iii) roteador entrando no link quando DR e BDR já foram
eleitos, (iv) apenas um roteador iniciou no link e (v) Falha de DR.
10.2.1.1 Partida a frio
O objetivo deste experimento é analisar como um conjunto de roteadores conectados a

um link compartilhado elegem o DR e o BDR quando iniciados aproximadamente ao
mesmo tempo.
Procedimento experimental Antes de iniciar os roteadores, instale uma sonda Wireshark
em uma das interfaces do link (por exemplo, interface f0/0 de R1) e configure

um filtro ospf. Em seguida, inicie todos os roteadores ao mesmo tempo. O experimento pode ser
interrompido quando o DR e o BDR corretos forem eleitos. Isso pode ser verificado observando
o conteúdo dos pacotes HELLO; ele também pode ser verificado executando o comando show ip
ospf vizinho em cada roteador. No final do experimento, o DR deve ser o roteador R3 porque tem
o RID mais alto e o BDR deve ser o roteador R2 porque tem o segundo RID mais alto. Observe
que, neste experimento, todos os roteadores têm a mesma prioridade. Podemos confirmar a
função de cada interface executando o comando show ip ospf vizinho em cada console do
roteador.
Captura do Wireshark A Figura 10.17 mostra a captura do Wireshark. Em relação à captura

original, mantivemos apenas os pacotes HELLO e o primeiro pacote DB DESCRIPTION
transmitidos por cada roteador. Mantivemos os pacotes DB DE SCRIPTION, pois indicam o fim
do processo de eleição em um roteador. Começamos descrevendo as principais partes da
captura:
• Pacotes 6, 11, 20 - Primeiros pacotes HELLO enviados por cada interface.
• Pacotes 34 a 39 - pacotes HELLO enviados quando as interfaces completam o estabelecimento

de suas relações de vizinhança, ou seja, quando a comunicação entre cada par de roteadores
se torna bidirecional; alguns OLÁ imediatos são observados durante este período.
• Pacotes 43 a 45, 49 a 51, 55, 56, 60 - pacotes HELLO enviados quando todas as interfaces já
reconhecem seus dois vizinhos, mas o DR e BDR ainda não foram eleitos.
• Pacotes 57 a 59, 61, 89, 90 - Primeiro pacote DB DESCRIÇÃO trans

emitidos por cada roteador após a eleição do DR e BDR.
• Pacotes 88, 99, 101 - pacotes HELLO enviados após a eleição do DR

e BDR.
First HELLOs Os primeiros pacotes HELLO enviados por cada interface (pacotes 6, 11, 20)
anunciam um DR e um BDR de 0.0.0.0 e não listam vizinhos ativos. Os pacotes subseqüentes
listam pelo menos um vizinho, e alguns deles são HELLOs imediatos.
Por que os HELLOs imediatos são menores do que o esperado? A transmissão de pacotes
HELLO imediatos não é fácil de rastrear durante a inicialização a frio. Em princípio, um roteador
deve enviar um HELLO imediato a um vizinho quando recebe um HELLO periódico desse vizinho
e o estado de seu relacionamento é menor que 2 vias (consulte a Seção 6.2.7 ). Por exemplo,
seria de esperar ver um HELLO imediato de R3 para R2 imediatamente após a recepção do
pacote 11 (enviado por R2). No entanto, os roteadores demoram algum tempo para se estabilizar
após serem ligados e, durante esse período, os roteadores (i) podem atrasar a transmissão de
seus pacotes e (ii) podem não receber pacotes transmitidos por outros roteadores.
Além disso, supomos que as implementações podem cancelar a transmissão de um HELLO

imediato agendado se, enquanto isso, o relacionamento com o

FIGURA 10.17: Eleição do DR e BDR em cenário de cold start - Wireshark

capturar.
vizinho correspondente atingiu o estado 2-Way, ou quando chegou a hora de enviar um OLÁ
periódico. Esses fatos podem explicar por que o número de HELLOs imediatos observados
geralmente é menor do que o esperado.
Explicando os HELLOs imediatos Na captura do Wireshark, os pacotes HELLO imediatos são
observados apenas no período em torno do segundo 12 (pacotes 34 a 39). Eles são facilmente
reconhecidos por seus endereços de destino unicast.
O pacote 35 enviado de R2 para R3 e o pacote 36 de R1 para R3 provavelmente foram uma
resposta ao pacote 34. De fato, quando R2 e R1 recebem o pacote 34, o estado de seus
relacionamentos com R3 vai para o estado 2-Way ( esta é a perspectiva de R1 e R2 sobre sua
relação com R3); ambos reagem enviando os HELLOs imediatos para R3 porque querem ter certeza
de que o estado de

FIGURA 10.18: Eleição do DR e BDR no cenário de cold start - Quando os

relacionamentos de vizinhança se tornam bidirecionais.
as relações vistas por R3 (ou seja, de R3 para R1 e de R3 para R2) evolui para o
estado 2-Way o mais rápido possível.
O pacote 36 lista apenas R3 como vizinho. Quando esse pacote foi agendado para
transmissão no roteador R1, o roteador ainda não reconheceu R2 como vizinho, o que
significa que perdeu o pacote 11. Observe que um roteador precisa receber um HELLO
de um vizinho para reconhecê-lo como vizinho; não basta ver o vizinho listado em um
HELLO enviado por algum outro roteador.
Por exemplo, o roteador R1 não pôde reconhecer R2 como vizinho com base nas
informações fornecidas por R3 no pacote 34. Reconhecer um vizinho significa que o
relacionamento com o vizinho muda para o estado inicial.
O pacote 38, enviado de R1 para R2, é outro OLÁ imediato. Este pacote foi
provavelmente uma resposta ao pacote 37 e confirma que R1 pode não ter recebido o
pacote 11. Observe que o roteador R3 não enviou um HELLO imediato para o roteador
R2 em resposta ao pacote 37. Isso ocorre porque o relacionamento deles já era
bidirecional estado em R3 (após a recepção do pacote 35).
Quando os relacionamentos se tornam bidirecionais É interessante determinar quando
cada relacionamento de vizinhança se torna bidirecional (ou seja, atinge o estado 2-
Way). Isso acontece quando um roteador se vê listado em um pacote HELLO recebido
de um vizinho. Observe que os dois vizinhos envolvidos em um relacionamento não
atingem esse estado ao mesmo tempo. Com três roteadores, há um total de seis
relacionamentos. Por exemplo, em relação ao relacionamento entre R1 e R3, ele atinge
o estado 2-Way em R1 quando R1 recebe o pacote 34, pois este é o primeiro HELLO
enviado por R3 onde R1 está listado. No entanto, o relacionamento só atinge o estado
2-Way em R3 quando R3 recebe o pacote 36, pois este é o primeiro HELLO enviado
por R1 onde R3 está listado. A Figura 10.18 mostra quando os vários relacionamentos
de vizinhança atingem o estado 2-Way.
HELLOs periódicos não são afetados por HELLOs imediatos Os pacotes HELLO
periódicos são transmitidos aproximadamente a cada 10 segundos, independentemente
dos imediatos. Observe, por exemplo, que o roteador R1 envia pacotes HELLO
periódicos nos segundos 3,1 (pacote 20), 13,0 (pacote 39), 22,5 (pacote 45), 32,5
(pacote 51) e assim por diante.
Esperando até que a eleição comece No segundo 21 (pacotes 43 a 45), todas as
interfaces indicaram em seus pacotes HELLO que reconhecem todos os seus

FIGURA 10.19: Eleição do DR e BDR em cenário de cold start - Dessincronização

entre a eleição do roteador designado e a transmissão de HELLOs periódicos.
vizinhos. No entanto, o processo de eleição só é iniciado quando o estado Waiting (da

máquina de estado da interface) é abandonado, o que acontece quando o tempo de
permanência neste estado atinge 40 segundos. Nesse momento, as interfaces elegem
o DR e o BDR, movem-se para o estado ExStart com seus dois vizinhos e enviam a
eles pacotes DB DESCRIPTION para iniciar o processo de sincronização LSDB. Assim,
o primeiro pacote DB DESCRIPTION transmitido por um roteador indica que o roteador
já escolheu o DR e o BDR. No nosso caso, como existem apenas três roteadores
conectados ao link compartilhado, todas as interfaces devem sincronizar entre si: o DR
e o BDR sincronizam entre si e cada um deles sincroniza com o roteador não DR.
Assim, todos os roteadores transmitem pacotes DB DESCRIPTION.
A captura do Wireshark mostra que o roteador R3 é o primeiro a abandonar o

estado Waiting e eleger o DR e BDR, pois é o primeiro a enviar os pacotes DB
DESCRIPTION (pacotes 57 e 58, no segundo 41.4). Os roteadores restantes fazem
isso mais tarde.
Dessincronização entre a eleição do roteador designado e a transmissão de HELLOs
periódicos Os primeiros pacotes HELLO indicando o DR e BDR corretos são os pacotes
88, 99 e 101. Esses pacotes são transmitidos após os primeiros pacotes DB
DESCRIPTION, porque ocorre a transmissão de pacotes HELLO periodicamente e não
é sincronizado com outros eventos.
Terminado o Waiting period (neste caso, através do evento WaitTimer), as interfaces
imediatamente elegem o DR e o BDR, passam para o estado ExStart com os vizinhos
que foram selecionados para se tornarem adjacentes e enviam a eles pacotes DB
DESCRIPTION. O anúncio do DR e BDR selecionado via pacotes HELLO periódicos
terá que aguardar até o próximo horário programado para a transmissão desses
pacotes. Isso explica porque o pacote 88 é enviado vários segundos após os pacotes
DB DESCRIPTION enviados por R3 (pacotes 57 e 58).
A Figura 10.19 ilustra a dessincronização entre a eleição do roteador designado e a
transmissão de HELLOs periódicos.
Usando a saída de depuração A análise deste experimento pode ser complementada
com informações fornecidas pela saída de depuração dos roteadores. Com o comando
debug ip ospf adj pode-se acompanhar a evolução do inter

máquinas de estado de face e vizinho. Em particular, pode-se observar que todos os roteadores
abandonam o estado Waiting por meio do evento WaitTimer.
EXPERIMENTO ADICIONAL - Após a convergência da rede, aumente a prioridade do roteador

R1 para 2 (a prioridade anterior era 1). Para isso digite o comando ip ospf priority 2 na interface
f0/0 deste roteador. Você pode verificar com o comando show ip ospf vizinho que nada mudou
em relação a quem são o DR e o BDR. Na verdade, alterar a prioridade de um roteador aciona
o evento NeighborChange e o processo de eleição é executado novamente. Porém, o resultado
da eleição é o mesmo de antes: R3 continua sendo o DR e R2 o BDR. Que o processo de
eleição seja executado novamente em cada roteador pode ser verificado usando o comando
debug ip ospf adj.
10.2.1.2 Partida a frio com prioridades do roteador
Este experimento repete o da seção anterior, mas com prioridades de roteador pré-configuradas.
Daremos a prioridade mais alta a R1 e a segunda prioridade mais alta a R2. Além de analisar o
resultado do experimento, também estaremos interessados em acompanhar de perto a evolução
do processo eleitoral. Usaremos a saída de depuração do Cisco IOS para essa finalidade. As
capturas do Wireshark não serão usadas desta vez.
Procedimento experimental Antes de realizar este experimento, precisamos alterar a

configuração básica de roteamento de R1 e R2. Primeiro, devemos incluir no arquivo startup-
config de R2 os comandos necessários para depurar as adjacências OSPF desde o início
(consulte a Figura 8.7). Segundo, devemos configurar uma prioridade de roteador 3 na interface
f0/0 de R1 e uma prioridade de roteador 2 na interface f0/0 de R2. Isso também pode ser feito
editando o arquivo startup-config. Por exemplo, para definir a prioridade em R1, insira o
comando ip ospf priority 3 no modo de interface de f0/0.
Após realizar essas configurações basta repetir o procedimento do experimento anterior:

iniciar os roteadores todos ao mesmo tempo e parar o experimento quando forem eleitos os DR
e BDR corretos.
Resultado do experimento O resultado do experimento é diferente daquele da seção anterior. O
roteador com maior prioridade (roteador R1) torna-se o DR e o roteador com a segunda
prioridade mais alta (roteador R2) torna-se o BDR. Isso pode ser confirmado executando o
comando show ip ospf neigh bor em R3 (consulte a Figura 10.20). Como no experimento
anterior, os roteadores saem do estado Waiting aproximadamente ao mesmo tempo e
imediatamente executam o algoritmo de eleição. Como cada roteador teve a chance de aprender
o RID e a prioridade do roteador de todos os seus vizinhos durante o período de espera, todos
concluíram que R1 deve ser o DR e R2 o BDR.
O processo de eleição em R2 e R3 É interessante notar que os roteadores R2 e R3 demoram

para chegar ao DR e BDR corretos; eles inicialmente elegem R1 como DR e BDR, e só mais
tarde elegem R2 como BDR. Podemos confirmar isso observando a saída de depuração de R2
ou R3. O comportamento é o

FIGURA 10.20: Eleição de DR e BDR em cenário de cold start com prioridades de roteador -
vizinhos OSPF de R3.
o mesmo em R2 e R3, mas mostramos apenas, na Figura 10.21, a saída de depuração de R2

(somente as mensagens relevantes são mostradas). As mensagens 1 e 2 indicam os instantes
de tempo em que o relacionamento com R1 e R3 atingiu o estado 2-Way.
A mensagem 5 sinaliza o fim do período de espera (através do evento WaitTimer). As
mensagens 6 a 9 referem-se à primeira eleição, imediatamente após R2 ter abandonado o
estado Waiting. O roteador R2 elege R1 como BDR na etapa 2 do algoritmo de eleição
(mensagem 7) e então R1 novamente como DR na etapa 3 (mensagem 8).
Em seguida, ele termina a computação, pois sua própria função não mudou (mensagem 9).
Assim, por algum tempo, R2 acredita que R1 é tanto o DR quanto o BDR.
Essa situação só é alterada quando R2 recebe um pacote HELLO de R1 anunciando R1
como DR e R2 como BDR. Quando o HELLO chega, o evento NeighborChange é acionado
(mensagem 35) e o algoritmo de eleição é executado novamente (mensagens 35 a 41). No
passo 2, R2 é eleito BDR (mensagem 37), pois R1 já se anunciou como DR e, portanto, deve
ser retirado da computação. Na etapa 3, R1 é confirmado como DR (mensagem 38). o
algoritmo
FIGURA 10.21: Eleição de DR e BDR em cenário de inicialização a frio com prioridades de

roteador - Mensagens de saída de depuração de R2.

tem que passar por uma segunda passagem desde que o papel de R2 mudou (mensagens
39 e 40), mas DR e BDR permanecem os mesmos.
Observe que esse comportamento é típico do BDR e de outros roteadores não DR em
uma situação de inicialização a frio e, às vezes, pode ser revelado por pacotes HELLO; você
pode ver os roteadores BDR e não DR anunciando o mesmo DR e BDR. No entanto, isso
depende do tempo relativo das transmissões de pacotes HELLO dos vários roteadores.
EXPERIMENTO ADICIONAL - Tente observar pacotes HELLO onde R2 ou R3 anunciam R1

como DR e BDR. Você precisa instalar uma sonda Wireshark no link compartilhado e repetir
o experimento anterior várias vezes. Seja persistente!
10.2.1.3 Roteador ingressando no link quando DR e BDR já foram eleitos
Este experimento analisa o que acontece quando um roteador se junta a um link

compartilhado que já possui um DR e um BDR. Como no experimento anterior, usaremos a
saída de depuração do Cisco IOS para rastrear a evolução do processo de eleição.
Procedimento experimental e resultado Antes de realizar o experimento, inclua no arquivo
startup-config do R3 os comandos necessários para depurar as adjacências OSPF desde o
início (consulte a Figura 8.7). Em seguida, inicie os roteadores R1 e R2 ao mesmo tempo e
aguarde até que a rede converja. Neste ponto, verifique se R2 foi eleito DR e R1 foi eleito
BDR (usando o comando show ip ospf vizinho). Por fim, inicie R3 e pare o experimento
quando a rede convergir novamente, ou seja, quando R3 eleger o DR e BDR corretos (com
base nas informações fornecidas pela saída de depuração). Você pode executar o comando
show ip ospf vizinho novamente para confirmar que R2 ainda é o DR e R1 o BDR, apesar do
fato de R3 ter um RID mais alto (e a mesma prioridade de roteador).
O processo de eleição em R3 As mensagens relevantes da saída de depuração de R3 são

mostradas na Figura 10.22 (algumas mensagens de depuração foram excluídas). O roteador
primeiro estabelece comunicação bidirecional com R1 (mensagem 1). Quando isso acontece,
R3 abandona o estado Waiting através do evento BackupSeen, pois R1 se declarou como
BDR em seu pacote HELLO, e imediatamente executa o algoritmo de eleição. Na primeira
execução (mensagens 3 a 6), o algoritmo declara R1 como DR e BDR. Observe que o
HELLO recebido de R1 já indica R2 como o DR, mas no passo 3 do algoritmo um roteador
só é considerado no primeiro grupo se ele se declarou como DR. Posteriormente, quando
R3 estabelece comunicação bidirrecional com R2 (mensagem 23), o evento NeighborChange
é acionado (mensagem 24) e o algoritmo de eleição é executado novamente (mensagens
25 a 28). Nesta execução, R2 é finalmente eleito como DR e R1 é confirmado como BDR.
As mensagens de depuração ausentes (de 7 a 22) referem-se à sincronização LSDB entre
R3 e R4, que começa assim que eles se tornam vizinhos.

! !"
#!!$
% &'# (!)*+,
!*
-%-. !
/ 0. !%-
1 0. !-
2 - 3+45%-3+45
!!"
#!!$
/ 1678* 8 7(!
1 1-%-. !
2 10. !%-
0. !-
- 3+45%-3+45
FIGURA 10.22: Eleição de DR e BDR quando o roteador ingressa no link com DR e BDR
previamente eleitos - Depurar mensagens de saída de R3.
10.2.1.4 Apenas um roteador iniciado no link
Neste experimento, ilustramos o que acontece quando apenas um roteador é iniciado em um

link compartilhado. Para analisar este experimento, usaremos o Wireshark e o recurso de
depuração do OSPF.
Procedimento experimental O procedimento é o seguinte: (i) instale uma sonda Wire shark no
link compartilhado (por exemplo, na interface f0/0 do roteador R1), (ii) inicie o roteador R1 e
digite o comando debug ip ospf adj (não estresse ; você terá 40 segundos para fazer isso). O
experimento pode ser interrompido quando a saída de depuração indicar que o DR foi eleito.
Podemos confirmar que R1 foi de fato eleito DR por meio do comando show ip ospf interface
brief.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.23. Os pacotes HELLO
até o pacote 16 indicam um DR de 0.0.0.0, e os seguintes indicam que o DR é o roteador R1
(222.222.10.1). O primeiro pacote que anuncia o DR eleito é o pacote 18 enviado no segundo
48.7. Este pacote é enviado após o período de espera de 40 segundos.
A saída da depuração (Figura 10.24) mostra que a interface abandona o estado Waiting
por meio do evento WaitTimer (mensagem 1). O algoritmo de eleição é executado
imediatamente (mensagens 2 a 7). O algoritmo executa duas passagens. Na primeira passagem
(mensagens 3 e 4), o roteador R1 é eleito como DR e BDR. Assim, tendo em vista a condição
4, o algoritmo deve realizar uma segunda passagem (mensagens 5 a 7). Na etapa 2 da segunda
passagem, o DR é excluído do cálculo e, como não há mais roteador, o BDR é definido como
0.0.0.0.
Finalmente, no passo 3 da segunda passagem, R1 é confirmado como DR.

FIGURA 10.23: Eleição de DR quando apenas um roteador no link - captura Wireshark.
10.2.1.5 Falha de DR
Este experimento ilustra o comportamento do OSPF em caso de falha de DR.

Analisamos o experimento com a ajuda do Wireshark e o recurso de depuração do
Cisco IOS.
Procedimento experimental e resultado O procedimento é o seguinte: (i) iniciar todos
os roteadores ao mesmo tempo, (ii) inserir o comando debug ip ospf adj nos roteadores
R1 e R2, (iii) instalar uma sonda Wireshark no link compartilhado (por exemplo na
interface f0/0 do roteador R1) e (iv) desligar o roteador R3 (para simular sua falha). O
experimento pode ser interrompido quando o DR e o BDR corretos forem eleitos
(conforme indicado pela saída de depuração). Nesse caso, espera-se que R2 se torne
o novo DR e R1 o novo BDR. Podemos confirmar isso por meio do comando show ip
ospf vizinhos emitidos em R1 e R2.
Captura do Wireshark e saída de depuração de R1 A Figura 10.25 mostra a captura do
Wireshark e a Figura 10.26 mostra a saída de depuração do roteador R1. Nenhum
pacote foi removido da captura do Wireshark, exceto os pacotes HELLO inicial e final,
transmitidos enquanto a rede estava em um estado estável. Começamos descrevendo
as principais partes da captura do Wireshark:
• Pacotes 8 a 10 - pacotes HELLO enviados antes da falha do DR.
FIGURA 10.24: Eleição de DR quando apenas um roteador no link - Depurar mensagens

de saída de R1.

FIGURA 10.25: Eleição de DR e BDR quando DR falha - Captura Wireshark.
• Pacotes 14, 15, 19, 20, 23, 24, 26, 27 - pacotes HELLO enviados após a falha do DR,
mas antes que outros roteadores detectassem a falha.
• Pacotes 29 a 33 - LS UPDATEs trocados entre R1 e R2 para atualizar

o LSDB e LS ACKNOWLEDGMENTs correspondentes.
• Pacote 34 - pacote HELLO onde R1 anuncia R2 como sendo o DR

e BDR.
• Pacotes 36, 39, 41 - pacotes HELLO anunciando o DR e BDR corretos.
Enquanto R1 e R2 não detectam a falha... Após a falha de DR, R1 e R2 levam

segundos de RouterDeadInterval para detectá-la (ou seja, 40 segundos padrão).
Enquanto isso, R1 e R2 continuam anunciando R3 como vizinho ativo e DR. Isso
corresponde aos pacotes 14 a 27 da captura do Wireshark.
Detecção de falha em R1 Quando o temporizador RouterDeadInterval expira em cada
roteador (R1 ou R2), o roteador R3 é declarado morto, o estado da máquina de estado
vizinho com R3 vai para baixo e o evento NeighborChange é

FIGURA 10.26: Eleição de DR e BDR quando DR falha - Depurar mensagens de saída

de R1.
provocado. A saída de depuração de R1 (ver Figura 10.26) mostra essa sequência de

eventos nas mensagens 1 a 3. O evento NeighborChange solicita a reeleição do DR e
BDR, que é sinalizado nas mensagens 4 a 8 da saída de depuração.
Curiosamente, nesta primeira execução, o algoritmo de eleição em R1 determina que
R2 é tanto o DR quanto o BDR, e isso é anunciado por R1 no pacote 34.
A razão para este resultado é a seguinte. Na etapa 2 do algoritmo, R1 determina

que R2 é o BDR porque R2 se declarou anteriormente como BDR e ninguém mais o
fez. Então, na etapa 3, o algoritmo determina que R2 é o DR, pois R3 falhou e nenhum
roteador se declarou como DR. Finalmente, como o papel de R1 não mudou como
resultado das etapas anteriores, o algoritmo para.
Detecção de falha em R2 Não mostramos a saída de depuração do roteador R2, mas
é fácil ver que na primeira passagem do algoritmo nas etapas 2 e 3, o roteador R2
conclui o mesmo que R1 (ou seja, que R2 é DR e BDR). No entanto, como o papel de
R2 (que é o roteador que faz a computação) mudou de BDR para DR devido à condição
4, o algoritmo é forçado a executar uma segunda passagem pelas etapas 2 e 3. Na
etapa 2, R2 é excluído da lista de candidatos, pois agora é o DR e R1 é promovido a
BDR. Na etapa 3, o algoritmo confirma que R2 é o DR e então para. É por isso que o
roteador R2 anuncia

o DR e BDR corretos no primeiro pacote HELLO que ele envia após a falha do DR
(pacote 36).
R1 corrige seu cálculo de BDR Quando R1 recebe este HELLO de R2, o evento
NeighborChange é acionado novamente, pois R2 está se declarando recentemente
como DR. Assim, R1 executa novamente o algoritmo de eleição. Na etapa 2, declara-
se como BDR, pois R2 é excluído desta etapa e, na etapa 3, R2 é confirmado como
DR. Como a função do BDR mudou, o algoritmo faz uma segunda passagem nas
etapas 2 e 3 e depois para. Isso corresponde às mensagens 9 a 15 da saída de
depuração.
Finalmente, como o papel do roteador mudou para BDR, o evento NeighborChange
é novamente acionado e o algoritmo de eleição é executado uma última vez, chegando
à mesma conclusão. Isso corresponde às mensagens 16 a 20 da saída de depuração.
Neste ponto, a rede convergiu novamente.
Pacotes LS UPDATE e LS ACKNOWLEDGMENT Também é interessante rastrear os
pacotes OSPF trocados para atualizar o LSDB. Quando R2 é eleito o novo DR, o
identificador do link compartilhado muda. Assim, R1 e R2 inundam novas instâncias do
Roteador-LSA (pacotes 29 e 30) com o novo identificador de link. No OSPFv2, o
identificador de link é carregado no campo Link ID das descrições de link tipo 2, e esse
campo muda para 222.222.10.2 (anteriormente era 222.222.10.3). Observe que o LS
UPDATE enviado por R1 (pacote 29) é enviado para o endereço multicast AllDRouters
(224.0.0.6), pois quando R1 envia esse pacote ele ainda acredita que é um roteador
não DR (nem o DR nem o BDR).
O roteador R2 também precisa inundar uma nova rede-LSA, pois é o novo DR.
Isso é feito no pacote 31. Este LS UPDATE também carrega o Roteador-LSA de R1.
Isso ocorre porque R2 é o novo DR e é função do DR retransmitir (usando o endereço
AllSPFRouters) os LSAs que ele recebe de roteadores não DR (recebidos no endereço
AllDRouters). Finalmente, os pacotes LS ACKNOWL EDGMENT (pacotes 32 e 33)
confirmam a recepção dos vários LSAs.
EXPERIMENTO ADICIONAL - Conecte um quarto roteador ao link compartilhado da

Figura 10.16, digamos roteador R4 (com RID 4.4.4.4). Inicie os quatro roteadores e
deixe a rede convergir. Neste ponto, o roteador R4 deve se tornar o DR e o roteador
R3 o BDR. Agora altere a Prioridade do roteador R1 para 2, usando o comando ip ospf
priority na interface f0/0. Então, provoque a falha do DR, ou seja, do roteador R4.
Quando a rede convergir, use o comando show ip ospf vizinho para verificar quem são
o DR e o BDR. Observe que o novo DR é R3, porque anteriormente era o BDR, e o
novo BDR é R1, porque é o roteador que, entre os restantes (R1 e R2), tem a maior
Prioridade de Roteador.
10.2.2 IS-IS
Abordaremos três casos diferentes: (i) partida a frio, (ii) alteração do DIS e (iii) falha do
DIS.

Endereços MAC e sua ordenação Nas capturas do Wireshark desta seção adicionamos, na
coluna Source, informações sobre o roteador ao qual cada endereço MAC pertence.
Especificamente, o endereço ca:03:73:ec:00:00 (chamado r3) é de R3, ca:02:d2:74:00:00
(chamado r2) é de R2 e ca:01:c0:14: 00:00 (denominado r1) é de R1. A ordem desses
endereços é definida pelo segundo octeto (já que o primeiro octeto é o mesmo em todos os
endereços): R3 tem o endereço MAC mais alto e R2 tem o segundo endereço MAC mais alto.
Esta informação é relevante uma vez que o endereço MAC é utilizado como desempate na
eleição do DIS, sempre que as prioridades da interface forem as mesmas.
Também removemos a coluna Destination das capturas do Wireshark, pois o destino é o

mesmo para todos os pacotes: o endereço multicast AllL1ISs (01:80:c2:00:00:14).
10.2.2.1 Partida a frio
Este experimento analisa o comportamento do IS-IS quando todos os roteadores são ligados
ao mesmo tempo em um link compartilhado.
Procedimento experimental e resultado O procedimento é semelhante ao experimento OSPF

cold start descrito na Seção 10.2.1.1, exceto que agora um filtro isis deve ser configurado no
Wireshark. Como todas as interfaces têm a mesma prioridade, o roteador R3 se tornará o DIS
no link compartilhado, pois seu endereço MAC é o mais alto.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.27. Nenhum pacote foi
removido da captura original. Começamos descrevendo as principais partes da captura do
Wireshark:
• Pacotes 8, 13, 20, 22, 24, 28, 30, 32 - pacotes HELLO iniciais, antes
eleição do DIS.
• Pacotes 29, 33, 34, 38 - Nonpseudonode-LSPs e o Pseudonode-LSP

enviado após a eleição do DIS.
• Pacotes 36, 37, 39, 40, 42, 46 a 48 - pacotes HELLO anunciando o

DIS.
• Pacote 41 - Primeiro CSNP.
Pacotes HELLO iniciais Nos pacotes HELLO iniciais, enviados antes da eleição do DIS, o
campo LAN ID inclui o SID do roteador de envio e um tag gerado pelo roteador (que é “01” em
todos os casos). Essa tag se tornará o Pseudonode ID do link compartilhado se o roteador de
envio se tornar o DIS. Nesta fase, os HELLOs enviados por R1 têm LAN ID R1.01, os enviados
por R2 têm LAN ID R2.01 e os enviados por R3 têm LAN ID R3.01.
Os dois primeiros HELLOs (pacotes 8 e 13) não têm vizinhos IS TLV, pois, neste ponto,
nenhum vizinho é conhecido pelos roteadores de envio. O pacote 20 é um HELLO imediato
enviado por R3 em resposta ao pacote 13. Nesse pacote, R3

FIGURA 10.27: Eleição de DIS em cenário de inicialização a frio - captura Wireshark.
já lista R1 como vizinho em um IS Neighbours TLV do tipo 6. Neste tipo de TLV os vizinhos são
identificados por seus endereços MAC. Quando R1 recebe o pacote 20, ele se torna adjacente
a R3, pois se vê listado no pacote enviado por R3.
O pacote 22, enviado por R2, também é um OLÁ imediato, mas em resposta aos pacotes
8 ou 20. Quando R2 agendou esse pacote para transmissão, ele ainda não reconheceu R1
como vizinho, pois apenas R3 está listado. Este é o último OLÁ que não lista todos os vizinhos
do roteador de envio. Quando R3 recebe o pacote 22, ele se torna adjacente a R2, pois R3 se
vê listado no HELLO enviado por R2.
Quando os relacionamentos se tornam bidirecionais Como no caso do experimento de

inicialização a frio do OSPF, é interessante determinar quando a vizinhança é redefinida.

FIGURA 10.28: Eleição de DIS no cenário de inicialização a frio - Quando as relações de

vizinhança se tornam bidirecionais.
os relacionamentos tornam-se bidirecionais; isso é mostrado na Figura 10.28. Observe que

todos os relacionamentos o fizeram pelo pacote 30.
Quando o DIS é eleito O primeiro pacote transmitido após a eleição do DIS é o pacote 29,
transmitido no segundo 3.2. Este pacote é um Nonpseudonode LSP onde R3 descreve a si
mesmo e sua interface com o link compartilhado (pseudo node). O identificador de link
compartilhado (R3.01) está incluído no IS Neighbours TLV do tipo 2 do Nonpseudonode-LSP.
Note que este LSP só poderia ter sido gerado após a eleição do DIS porque a interface com o
link compartilhado é descrita através do identificador do link compartilhado, e este identificador
é baseado no SID do DIS.
A especificação IS-IS [1] diz que deve haver um período de espera de 2×iSISHelloTimer
(padrão de 20 segundos) antes que o DIS seja eleito. A julgar pelo tempo de transmissão do
LSP, o tempo de espera desta implementação é de aproximadamente 3 segundos, muito
menos do que o sugerido pela especificação.
Os LSPs restantes são os Nonpseudonode-LSPs enviados por R1 e R2 (pacotes 34 e 38)

e o Pseudonode-LSP enviado por R3 (pacote 33). O último LSP é enviado por volta do
segundo 4.5. Quando os roteadores recebem todos os LSPs, seus LSDBs ficam completamente
sincronizados. No IS-IS, esse processo é mais rápido que no OSPF.
Pacotes HELLO após a eleição do DIS O pacote 36 é o primeiro HELLO onde o novo DIS é
reconhecido; o pacote é enviado pelo próprio DIS. O que nos diz que o R3 se reconheceu
como DIS é o valor do Hold Timer, que agora é de 10 segundos. Todos os pacotes HELLO
subseqüentes indicam que o DIS é R3 no campo LAN ID (que tem o valor R3.01). Os pacotes
37 e 39 são HELLOs imediatos enviados em reação ao pacote 36. Os pacotes HELLO
restantes são HELLOs periódicos. Observe que a frequência dos HELLOs enviados pelo DIS
é maior (e o Holding Timer é menor) do que a dos pacotes restantes.
Primeiro CSNP O pacote 41 é o primeiro CSNP. Ele contém o resumo LSDB, com três
Nonpseudonode-LSPs descrevendo cada roteador e suas interfaces (R1.00-00, R2.00-00 e
R3.00-00) e o Pseudonode-LSP descrevendo o link compartilhado (R3. 01-00). O CSNP é
transmitido próximo ao segundo 10, o que está de acordo com a periodicidade das
transmissões CSNP. Lembre-se que o tempo dis

tocada no Wireshark é relativa ao primeiro pacote capturado e que o primeiro pacote é

enviado algum tempo depois que o roteador foi ligado. A especificação IS-IS [1] não
indica um comportamento específico para o primeiro CSNP. A partir desta experiência,
supomos que este pacote é transmitido após a expiração do primeiro completeSNPInterval
(que tem um valor padrão de 10 segundos).
10.2.2.2 Mudança de DIS
Este experimento analisa o comportamento do IS-IS quando o DIS é alterado por meio
de uma ação de configuração. O DIS é inicialmente o roteador R3 (devido ao seu
endereço MAC de interface maior), e vamos mudar a prioridade da interface f0/0 do
roteador R1, para que ele se torne o DIS.
Procedimento experimental O procedimento é o seguinte: (i) iniciar todos os roteadores
ao mesmo tempo e aguardar a convergência da rede, (ii) instalar uma sonda Wireshark
no link compartilhado com um filtro isis configurado, (iii) inserir o comando isis priority
100 na interface f0/0 do roteador R1. O experimento pode ser interrompido quando a
rede convergir novamente, ou seja, quando o novo DIS for eleito e os LSDBs forem
atualizados.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.29. Nenhum
pacote foi removido da captura original. Começamos descrevendo as principais partes
da captura do Wireshark:
• Pacotes 21, 23, 24, 28, 29 - pacotes HELLO enviados antes da alteração da prioridade
da interface.
• Pacote 22 - CSNP enviado por R3 antes de alterar a prioridade da interface.
• Pacote 30, 32, 36, 39, 43, 45 a 48 - pacotes HELLO enviados após alteração da
prioridade da interface.
• Pacote 31 - Novo Pseudonode-LSP enviado por R1.
• Pacotes 33 e 34 - Exclusão do antigo Pseudonode-LSP.
• Pacotes 35, 37, 38 - Novas instâncias Nonpseudonode-LSPs enviadas por R1, R2,
e R3.
• Pacote 40 - CSNP enviado por R1 após alteração da prioridade da interface.
Pacotes HELLO iniciais Os pacotes HELLO iniciais mostram que as interfaces

concordam que o roteador R3 é o DIS (já que o valor de LAN ID é R3.01). Além disso,
o CSNP inicial (pacote 22) indica que o Pseudonode-LSP que descreve o link
compartilhado é originado por R3 (já que o ID do LSP é R3.01-00). O valor de Prioridade
indicado em todos esses pacotes HELLO é 64, ou seja, o valor padrão do Cisco IOS.
A periodicidade e o Hold Timer diferem nos pacotes HELLO enviados pelo DIS e pelos
demais roteadores: o DIS usa uma periodicidade de 3 segundos e um Hold Timer de
10 segundos; os roteadores restantes usam uma periodicidade de 10 segundos e um
Hold Timer de 30 segundos.

FIGURA 10.29: Reeleição do DIS após alteração da prioridade do roteador - Captura do

Wireshark.
A prioridade da interface é alterada Quando a nova prioridade é configurada no roteador

R1, o roteador envia imediatamente um pacote HELLO (pacote 30). Nesse pacote, R1
indica uma Prioridade de 100 e se anuncia como sendo o DIS, já que o ID da LAN é
R1.01 e o Temporizador de Retenção é de 10 segundos. A partir de então, todos os
pacotes HELLO anunciam este DIS. Observe que este HELLO foi enviado com menos de
10 segundos de intervalo do HELLO anterior do roteador R1 (pacote 23): o pacote 23 foi
enviado no segundo 19,4 e o pacote 30 no segundo 25,4. Isso mostra que o pacote 30 é
um HELLO imediato acionado pela mudança na prioridade do roteador.
LSPs enviados após a nova eleição DIS Imediatamente após o HELLO

pacote, R1 envia o novo Pseudonode-LSP que descreve o link, com LSP ID igual a R1.01-00
(pacote 31). Também envia uma indicação para deletar o antigo Pseudonode-LSP, originado pelo
DIS anterior, com LSP ID igual a R3.01-00 (pacote 33). A indicação para excluir é facilmente
reconhecida por ter um Remaining Lifetime igual a 0. Esse comportamento é marcadamente
diferente do OSPF: no IS-IS, é o novo DIS que deve excluir o antigo Pseudonode-LSP; no OSPF,
os LSAs só podem ser excluídos por seus roteadores de origem. Observe que a indicação de
exclusão inclui apenas o cabeçalho LSP e não seu conteúdo completo.
O pacote 34 merece alguma atenção, pois parece corresponder a um comportamento fora do

padrão. Este pacote é novamente uma indicação de exclusão do antigo Pseudonode-LSP,
transmitido em reação ao pacote 33. Quando o pacote 33 chega em R2, R2 substitui a instância
LSP armazenada pela que está chegando, pois a instância que está chegando é considerada mais
recente; lembre-se de que instâncias com tempo de vida restante zero são consideradas mais
recentes do que aquelas com o mesmo SN e tempo de vida restante diferente de zero. De acordo
com a Seção 7.3.16.4 da especificação IS IS [1], esta instância agora deve ser inundada, ou seja,
deve ser transmitida em todas as interfaces, exceto aquela em que o pacote foi recebido.
Porém, conforme observamos neste experimento, o pacote também é transmitido pela interface
receptora. Isso não prejudica a correção do protocolo, mas parece desnecessário.
Observe que o antigo DIS (ou seja, R3) não transmitiu uma indicação para excluir seu (antigo)
Pseudonó-LSP. Isso foi por acaso: se você executar o experimento várias vezes, poderá ver essa
indicação, possivelmente antes da indicação enviada pelo novo DIS. De fato, quando R3 descobre
que deve deixar de ser o DIS, ele zera o Remaining Lifetime de seu Pseudonode-LSP e programa
a inundação desse LSP por todas as suas interfaces. Porém, se nesse meio tempo ele receber a
mesma instância do LSP em alguma interface, ele cancela sua transmissão por aquela interface.
Foi o que aconteceu neste caso: a recepção em R3 da indicação de deletar enviada por R1
cancelou a transmissão da mesma indicação já agendada em R3.
Os LSPs restantes (pacotes 35, 37 e 38) são as novas instâncias dos três Nonpseudonode-
LSPs. Essas instâncias tiveram que ser criadas e inundadas por seus roteadores de origem, pois
o identificador de link compartilhado mudou para R1.01 (anteriormente era R3.01). Observe que o
IS Neighbors TLV desses LSPs inclui R1.01 como vizinho. Observe também que cada um desses
LSPs é visto apenas uma vez no link. Isso porque, diferentemente do caso do pacote 34, esses
LSPs seguem o procedimento usual de flooding e, portanto, não são retransmitidos nas interfaces
receptoras.
CSNP enviado após a nova eleição do DIS O CSNP enviado após a alteração do DIS (pacote 40)
já lista o novo Pseudonode-LSP, que possui LSP ID igual a R1.01-00. Pode parecer estranho que
ele também liste o antigo Pseudonode LSP (com LSP ID R3.01-00). No entanto, os LSPs
expirados devem ser mantidos no LSDB por um minuto adicional (ZeroAgeLifetime*) antes de
serem eliminados (consulte a Seção 6.5.7). Você pode continuar verificando o conteúdo dos
CSNPs para confirmar que a referência ao antigo Pseudonode-LSP desaparece após 1 minuto.

Mudança na periodicidade das transmissões HELLO Note que a forma de transmissão dos pacotes
HELLO mudou com a escolha do novo DIS. Os pacotes HELLO enviados por R1 agora têm o
mesmo comportamento dos pacotes HELLO enviados por R3 antes da mudança de prioridade: são
enviados a cada 3 segundos e possuem um Hold Timer de 10 segundos.
Tempo de convergência Destacamos que a reação da rede à mudança de DIS foi muito rápida:
demorou pouco mais de 100 ms desde o primeiro pacote sinalizando a mudança de DIS (pacote 30)
até o último LSP necessário para a sincronização LSDB (pacote 38) .
EXPERIMENTOS ADICIONAIS - Repita este experimento várias vezes, mas agora apenas
concentrado nas indicações de exclusão. Sugerimos que você use um filtro isis.lsp no Wireshark, e
fique alternando os comandos isis priority 100 e no isis priority 100 na interface f0/0 do roteador R1.
O filtro mantém apenas os LSPs, que são transmitidos apenas no período transiente após as
mudanças de prioridade. Você pode reconhecer facilmente as indicações de exclusão observando o
valor de tempo de vida restante de cada pacote. Você observará que as indicações de exclusão
podem ser enviadas por R1 e R2 (como acima), por R1 e R3 ou por R3 e R2.
10.2.2.3 Falha DIS
Este experimento analisa o comportamento do IS-IS quando o DIS falha. O DIS é inicialmente o
roteador R3 (por causa de seu endereço MAC de interface mais alto). Após a convergência da rede,
desligamos o DIS para simular sua falha e o novo DIS se tornará o roteador R2.
Procedimento experimental O procedimento é semelhante ao experimento de falha OSPF DR

(consulte a Seção 10.2.1.5), exceto que o recurso de depuração não é usado desta vez. O
procedimento é o seguinte: (i) iniciar todos os roteadores ao mesmo tempo e aguardar a convergência
da rede, (ii) instalar uma sonda Wireshark no link compartilhado e (iii) desligar o roteador R3 (para
simular sua falha). O experimento pode ser interrompido quando a rede convergir novamente, ou
seja, quando o novo DIS for eleito e os LSDBs forem atualizados.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.30. Nenhum pacote foi
removido da captura original. Começamos descrevendo as principais partes da captura do Wireshark:
• Pacote 53 - Último HELLO enviado por R3, antes de sua falha.
• Pacotes 54, 58 - pacotes HELLO enviados antes da detecção da falha DIS.
• Pacotes 59, 60, 66, 68 - pacotes HELLO enviados após a nova eleição do DIS.
• Pacote 61 - Novo Pseudonode-LSP enviado após a nova eleição do DIS.
• Pacotes 63 e 64 - Exclusão do antigo Pseudonode-LSP.

FIGURA 10.30: Reação à falha do DIS - Captura do Wireshark.
• Pacotes 62, 65 - Novas instâncias Nonpseudonode-LSP enviadas por R1 e R2.
• Pacote 67 - CSNP enviado pelo R2 após a nova eleição do DIS.
Pacotes HELLO iniciais O último HELLO enviado por R3 (pacote 53) é visto no segundo
52.7. Nos dois HELLOs subseqüentes (pacotes 54 e 58) R1 e R2 ainda reconhecem
R3 como vizinho.
Detecção de falha em R1 Pacote 59 (enviado no segundo 62.7) é o HELLO imediato
enviado por R1 após detectar a falha. Sabemos disso porque R3 não está mais listado
como vizinho e o pacote foi enviado com menos de 10 segundos de intervalo do último
HELLO periódico de R1 (que era o pacote 58, enviado no segundo 58,1). Como o Hold
Timer do DIS é de 10 segundos, supomos que o DIS falhou aproximadamente no
segundo 52,7 (logo após enviar o último OLÁ). Observe que, neste HELLO, o valor de
LAN ID ainda é R3.01, apesar do fato de R3 não ser mais reconhecido como vizinho.
Isso ocorre porque R2, o novo DIS, ainda não forneceu o novo identificador de link
compartilhado: R1 sabe que R2 é o novo DIS e conhece seu SID, mas ainda não
conhece o Pseudonode ID que R2 atribuiu ao link compartilhado.
R2 se reconhece como DIS O roteador R2 se reconhece como DIS, pela primeira vez,
no pacote 60; ele não lista mais R3 como vizinho e anuncia um Temporizador de espera
de 10 segundos e um ID de LAN de R2.01. A partir de então, todos os pacotes HELLO
anunciam o mesmo LAN ID.

LSPs enviados após a nova eleição de DIS O comportamento referente às

transmissões de LSP é o mesmo do experimento de mudança de DIS (Seção 10.2.2.2).
Após a eleição do novo DIS, R2 inunda um novo Pseudonode-LSP (pacote 61) e uma
nova instância de seu Nonpseudonode-LSP com SN igual a 3 (pacote 65). R1 também
inunda uma nova instância de seu Nonpseudonode-LSP (pacote 62) com SN igual a
3. Além disso, R2 toma a iniciativa de deletar o antigo Pseudonode-LSP (pacote 63),
e este pacote também é inundado por R1 (pacote 64 ).
CSNP enviado após a nova eleição DIS Finalmente, o pacote 67 é o primeiro CSNP
enviado após a nova eleição DIS. Ele lista todos os novos LSPs, bem como o antigo
Pseudonode-LSP, que permanece no LSDB (com um Remaining Lifetime de 0) por
um minuto adicional (ZeroAgeLifetime*).
Tempo de convergência O resultado deste experimento não é muito diferente daquele
do experimento de mudança DIS (Seção 10.2.2.2). A principal diferença é o tempo de
espera até que a falha do DIS seja detectada (aproximadamente 10 segundos).
Uma vez detectada a falha, a escolha do novo DIS e atualização do LSDB é muito
rápida: leva apenas um pouco mais de 100 ms desde o primeiro pacote sinalizando a
falha (pacote 59) até o último pacote necessário para atualizar totalmente o LSDB
(pacote 65).
10.3 Procedimento de inundação

Esta seção apresenta vários experimentos que ilustram o processo de inundação em
OSPF e IS-IS. Esta questão foi discutida na Seção 6.4.
Configuração experimental Os experimentos usam a topologia de rede da Figura
10.31. A rede inclui quatro roteadores e três links. R4 está conectado a R1 e R2 por
meio de links ponto a ponto; R1, R2 e R3 são conectados por meio de um link Fast
Ethernet. Os roteadores devem ser configurados inicialmente com as configurações
básicas de roteamento. Os experimentos usam o Wireshark.
Objetivo principal dos experimentos O objetivo principal desses experimentos é
analisar a reação a uma mudança no custo da interface. Especificamente, alteraremos
o custo da interface s0/0 do roteador R4. Isso certamente acionará a origem e
inundação de novas instâncias LSA (OSPF) ou LSP (IS-IS).
10.3.1 Links compartilhados OSPF
Procedimento experimental O procedimento é o seguinte: (i) iniciar todos os roteadores

ao mesmo tempo e aguardar a convergência da rede; (ii) instalar uma sonda
Wireshark no link compartilhado e iniciar uma captura com um filtro ospf; (iii) continuar
alternando o custo da interface s0/0 do roteador R4 entre 100 e 64 (o valor padrão).
A alternância do custo da interface pode ser obtida alternando

FIGURA 10.31: Experimentos de inundação - topologia de rede.
os comandos ip ospf custam 100 e nenhum ip ospf custa. O primeiro comando define
o custo da interface para 100 e o segundo retorna ao seu valor padrão, ou seja, 64.
O objetivo dessas alterações é observar diferentes sequências de pacotes no link
compartilhado. Concentre-se no primeiro pacote LS UPDATE transmitido no link
compartilhado: às vezes esse pacote é transmitido por R1 e outras vezes por R2.
Você pode parar o experimento quando tiver observado os dois casos.
Como todos os roteadores são ligados ao mesmo tempo, R3 se tornará o DR e

R2 o BDR. Verifique se isso é verdade antes da etapa (ii) do experimento, por
exemplo, usando o comando show ip ospf vizinho.
Resultado do experimento Alterar o custo OSPF da interface s0/0 do roteador R4
força a geração de uma nova instância do roteador-LSA. Especificamente, o valor da
métrica associado às descrições de link tipo 1 e tipo 3 da interface s0/0 é alterado
de 64 para 100 e vice-versa. Quando uma nova instância é gerada, o SN é
incrementado em um, e R4 transmite a instância em todas as suas interfaces,
encapsuladas em pacotes LS UPDATE. As duas instâncias do roteador-LSA são
recebidas por R1 e R2 e retransmitidas por esses roteadores no link compartilhado
usando novamente pacotes LS UPDATE. Qualquer um deles pode ser o primeiro a
transmitir um pacote LS UPDATE no link; isso depende da carga relativa dos
roteadores e links no caminho de R4 para o link compartilhado.
O comportamento é diferente em cada caso, já que em um caso o LS UPDATE é
transmitido pelo BDR e em outro por um roteador não DR.
Também pode acontecer que uma das transmissões iniciadas por R4 esteja tão
atrasada que R1 ou R2 receba primeiro a nova instância LSA por meio do link
compartilhado (ou seja, na interface f0/0 e não na interface s0/0). Nesse caso, o
roteador que recebe o LSA atrasado não o transmitirá no link compartilhado. Não
pudemos observar esse comportamento em nossos experimentos OSPF.

FIGURA 10.32: Inundação OSPF em links compartilhados - Captura Wireshark.
No entanto, vimos isso nos experimentos IS-IS relacionados a links compartilhados (consulte
a Seção 10.3.3).
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.32.
Em relação à captura original, mantivemos apenas dois grupos de interações de
confirmação de atualização, um referente a um LS UPDATE enviado por R1 e outro
referente a um LS UPDATE enviado por R2.
R1 transmite primeiro no link compartilhado Na primeira interação atualização-confirmação
(pacotes 9 a 15), é R1 que transmite o primeiro LS UPDATE no link compartilhado (pacote
9). Como R1 é um roteador não DR, o pacote é enviado para o DR usando o endereço
multicast AllDRouters (224.0.0.6). O roteador LSA é então retransmitido pelo DR para
todos os outros roteadores encapsulados em outro pacote LS UPDATE (pacote 11), mas
agora usando o endereço multicast AllSPFRouters (224.0.0.5). Enquanto isso, R2 também
transmite o roteador LSA recebido de R4 encapsulado em um pacote LS UPDATE (pacote
10); como R2 é o BDR, ele transmite o pacote usando o endereço AllSPFRouters.
O pacote final deste grupo é o LS ACKNOWLEDGMENT enviado por R2 (pacote 15).

Observe que R1 não precisa reconhecer o Router-LSA enviado pelo DR, pois o LSA é uma
duplicata (já está no LSDB de R1) e é um reconhecimento implícito ao LSA enviado
anteriormente por R1 (pacote 9).
R2 transmite primeiro no link compartilhado No segundo grupo de confirmação de
atualização (pacotes 150 a 153), o primeiro pacote LS UPDATE (pacote 150) é enviado por
R2, que é o BDR. O DR não retransmite os LSAs enviados pelo DR, mas deve confirmá-
los, o que faz no pacote 153. R1 também transmite o Router-LSA enviado por R4 (pacote
151). Porém, quando esse LSA chega ao DR, ele é tratado como duplicado, pois o DR já
recebeu a mesma instância de R2; portanto, o LSA não é mais inundado. R2 não reconhece
o LSA enviado por R1, pois o LSA é uma duplicata (já está no LSDB de R2) e é uma
confirmação implícita para o LSA enviado anteriormente por R2 (pacote 150).

FIGURA 10.33: Inundação OSPF em links ponto a ponto - Captura Wireshark.
10.3.2 Enlaces ponto a ponto OSPF
Procedimento experimental Neste experimento, repetimos o procedimento do

experimento de link compartilhado OSPF, mas agora colocando a sonda Wireshark
no link ponto-a-ponto entre R4 e R2. Além disso, apenas fazemos duas alterações
de custo de interface.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.33. Em
relação à captura original, mantivemos apenas os dois primeiros LS UPDATEs e os
correspondentes LS ACKNOWLEDGMENTs.
Resultado do experimento O processo de flooding é semelhante ao dos links
compartilhados. Quando o custo da interface é alterado na interface s0/0 de R4, R4
gera uma nova instância Router-LSA e a transmite em ambas as interfaces,
encapsulada em pacotes LS UPDATE. Os pacotes 17 e 25 são dois pacotes LS
UPDATE transmitidos de R4 para R2 em reação a uma mudança de custo de
interface. Quando estes pacotes são recebidos em R2, R2 responde confirmando
sua correta recepção, utilizando pacotes LS ACKNOWLEDGMENT (pacotes 20 e
28). Para correlacionar as atualizações com as confirmações, os pacotes LS
ACKNOWLEDGMENT carregam o cabeçalho do LSA que está sendo confirmado. O
pacote 28 é mostrado na Figura 10.34. Observe que o pacote carrega apenas o
cabeçalho LSA, indicando que a instância do roteador-LSA que está sendo
reconhecida foi originada pelo roteador R4 (o campo Advertising Router é 4.4.4.4) e
tinha um SN igual a 0 × 80000003. Observe também que a instância é realmente nova (seu LS Ag
10.3.3 links compartilhados IS-IS
Procedimento experimental Neste experimento, queremos ter certeza de que R3 é o

DIS. Para isso, digite inicialmente o comando isis priority 100 na interface f0/0 do
roteador R3. Além disso, o procedimento deste experimento é semelhante ao da
Seção 10.3.1: (i) iniciar todos os roteadores ao mesmo tempo e aguardar a
convergência da rede; (ii) instalar uma sonda Wireshark no link compartilhado e
iniciar uma captura com um filtro isis; (iii) continuar alternando o custo da interface
s0/0 do roteador R4, entre 30 e 10 (o valor padrão).
A alternância dos custos de interface pode ser obtida alternando os comandos isis
metric 30 e no ip ospf cost. O primeiro comando define o custo da interface para 30
e o segundo retorna para o valor padrão, ou seja, 10.

FIGURA 10.34: Inundação de OSPF em enlaces ponto a ponto - LSA ACKNOWL

EDGMENT enviado pelo roteador R2, confirmando a recepção de um Roteador-LSA
de R4.
O resultado do experimento R4 gera uma nova instância Nonpseudonode-LSP

sempre que o custo de uma interface muda. Neste experimento, o que será alterado
é o valor da Default Metric referente à interface com R2 (identificado como R2.00-00).
Este campo aparece tanto no IS Neighbors TLV quanto no IP Internal Reachability
Information TLV do Nonpseudonode-LSP. Uma vez gerada, esta instância LSP é
transmitida nas interfaces s0/0 e s0/1 de R4.
Quando R1 e R2 recebem esta instância LSP, eles podem (ou não) retransmiti-la no
link compartilhado.
Dependendo das cargas relativas dos roteadores e links no caminho percorrido
pelos Nonpseudonode-LSPs de R4 para o link compartilhado, pelo menos um roteador
irá retransmitir o LSP no link compartilhado, mas ambos os roteadores podem fazê-
lo. O resultado específico é imprevisível e é por isso que continuamos alternando os
custos de interface neste experimento. O experimento pode ser interrompido quando
ambos os padrões forem observados (um LSP ou dois LSPs).
relação à captura original, mantivemos apenas os pacotes CSNP e LSP do período
de tempo que queremos analisar.
Os CSNPs Primeiro observe que os CSNPs são transmitidos regularmente, com
intervalos de tempo entre 8 e 10 segundos. De fato, a periodicidade das transmissões
CSNP não é afetada pela chegada dos LSPs; ao contrário dos pacotes HELLO, não
existe um CSNP imediato.
Os LSPs Na captura, existem dois grupos de LSPs: o primeiro grupo com um único
LSP (pacote 37), e o segundo grupo com dois LSPs (pacotes 62 e 63). Esses dois
padrões foram observados em sucessivas alterações de custo de interface: o primeiro
grupo quando o custo foi alterado pela primeira vez para 30 e o segundo grupo
quando o custo foi alterado de volta para o valor padrão. O fato de esses padrões
terem sido observados em sucessivas mudanças de custo foi mera sorte; os padrões ocorrem

aleatoriamente e, como será explicado mais adiante, o segundo padrão é mais provável
que o primeiro.
Antes da primeira mudança de custo O pacote 37 é o CSNP transmitido imediatamente
antes da primeira mudança de custo. O CSNP anuncia quatro Nonpseudonode LSPs,
cada um representando um roteador (R1.00-00, R2.00-00, R3.00-00 e R4.00-00), e um
Pseudonode-LSP, representando o link compartilhado e originado pelo roteador R3
(R3.01-00). Observe que o SN dos Nonpseudonode-LSPs de R4 (R4.00-00) é 3 (ou
seja, 0×00000003).
Reação à primeira mudança de custo O pacote 41 é o LSP anunciando o novo custo
da interface s0/0 do roteador R4. É transmitido no link compartilhado pelo roteador R2.
Observe que o SN aumentou para 4. Você também pode analisar o conteúdo do pacote
para verificar se, no IS Neighbours TLV, o valor da Default Metric referente à interface
com R2 mudou para 30.
Antes da segunda mudança de custo Os pacotes 46 e 52 são dois CSNPs enviados
após a primeira transmissão LSP e antes da próxima mudança de custo de interface.
Observe que o SN de R4.00-00 agora é 4. Esses CSNPs confirmam para R2 que o
LSP enviado anteriormente (pacote 41) foi recebido por R3. É assim que as
confirmações são realizadas nos links compartilhados IS-IS (consulte a Seção 6.4.2).
Reação à segunda mudança de custo Quando a segunda mudança de custo da
interface é feita (agora de volta ao valor padrão), R4 origina outra instância
Nonpseudonode-LSP, agora com SN igual a 5. Desta vez, o LSP é transmitido no link
compartilhado por ambos R1 e R2 (pacotes 62 e 63).
O CSNP que segue as transmissões LSP anteriores no link compartilhado (Pacote
66) já anuncia o Nonpseudonode-LSP de R4 com um SN de 5.
Como no caso do pacote 41, este CSNP reconhece que os LSPs transmitidos
anteriormente por R1 e R2 foram recebidos corretamente.
Explicação para ter um ou dois LSPs transmitidos no link compartilhado A Figura 10.36
ilustra o processo de inundação no link compartilhado quando dois LSPs ou um LSP
são transmitidos no link compartilhado. No primeiro caso (Figura 10.36.a), os dois LSPs
chegam aproximadamente ao mesmo tempo em R2 e R1.
Então R2 e R1 substituem a instância armazenada (com SN=3) pela de entrada (com
SN=4), e ambos os roteadores transmitem a nova instância LSP no link compartilhado.
Quando cada roteador recebe (em sua interface f0/0) o LSP transmitido pelo outro no
link compartilhado, ambos os roteadores descartam o pacote de entrada, pois a
instância armazenada tem atualização igual.
No segundo caso (Figura 10.36.b), há um grande atraso na recepção do LSP
transmitido pela interface s0/1 de R4. Enquanto isso, R2 recebe o LSP, substitui a
instância armazenada pela que está chegando e transmite a nova instância do LSP no
link compartilhado. Quando R1 recebe este LSP (em sua interface f0/0), ele substitui a
instância armazenada pela que está chegando, assim como R2 fez. Quando o LSP
transmitido pela interface s0/1 de R4 finalmente chega em R4, ele é descartado pois já
existe uma instância armazenada com igual frescor. Neste caso, também pode
acontecer que R1 transmita o

FIGURA 10.35: Inundação IS-IS em links compartilhados - Captura Wireshark.
nova instância LSP por meio de sua interface s0/0, caso em que R4 receberia uma
instância LSP auto-originada.
EXPERIMENTO ADICIONAL - Repita este experimento, mas certificando-se de que,

inicialmente, o DIS seja R1 ou R2. Basta aumentar a prioridade associada à interface
f0/0 de um desses roteadores para um valor superior a 100. O objetivo é garantir que,
pelo menos algumas vezes, o primeiro Nonpseudonode-LSP transmitido no link
compartilhado seja transmitido por o DIS. Você notará um comportamento semelhante.
Às vezes, ambos os roteadores transmitem a instância Nonpseudonode-LSP gerada por
R4 quando o custo da interface é alterado; outras vezes apenas um LSP é transmitido e,
neste caso, algumas vezes é transmitido por R1 e outras vezes por R2. Os CSNPs
continuam sendo transmitidos periodicamente no link compartilhado e são atualizados
sempre que uma nova instância Nonpseudonode-LSP do R4 é recebida.
10.3.4 Enlaces ponto a ponto IS-IS
Procedimento experimental Neste experimento, repetimos o procedimento do experimento

de link compartilhado IS-IS, mas agora colocando a sonda Wireshark no link ponto a
ponto entre R4 e R2. Além disso, fazemos apenas uma alteração no custo da interface.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.37. Em relação à

captura original, mantivemos apenas os pacotes LSP e PSNP. A captura do Wireshark
não reconhece os endereços de origem e destino

FIGURA 10.36: Inundação IS-IS em enlaces compartilhados - Reação à origem de um novo LSP por R4
quando (a) dois LSPs são retransmitidos no enlace compartilhado e (b) apenas um LSP é retransmitido.
(afinal, este é um link ponto a ponto); no entanto, isso pode ser facilmente inferido a partir de outras
informações contidas nos pacotes.
Resultado do experimento A mudança no custo da interface resulta apenas na troca de dois pacotes.
Quando o custo é alterado no roteador R4, R4 gera uma nova instância Nonpseudonode-LSP e a inunda
por todas as suas interfaces. O LSP transmitido pela interface s0/0 (em direção a R2) é o pacote 5.
Observe que o SN deste LSP é 3. Quando R2 recebe este pacote, ele confirma sua recepção através de
um PSNP, que identifica o LSP reconhecido através das LSP Entries TLV (pacote 6). Observe que este
TLV tem um LSP ID de R4.00-00 e um SN de 3, o que indica que ele está de fato reconhecendo o LSP
anterior.

FIGURA 10.37: Inundação IS-IS em links ponto a ponto - Captura Wireshark.
10.4 Procedimento de exclusão

É instrutivo pensar em eventos que acionam a exclusão de LSAs e LSPs. Considerando
a rede da Figura 10.31, uma dessas situações é quando o roteador designado (DR ou
DIS) é R1 ou R2 e é substituído no link compartilhado sem falhar. Nesse caso, o
roteador designado ainda tem a oportunidade de excluir seu Network-LSA ou
Pseudonode LSP originado anteriormente.
10.4.1 OSPF
Procedimento experimental Neste experimento, a configuração de R1 deve ser primeiro

modificada de modo que R1 se torne inicialmente o DR no link compartilhado.
Para fazer isso, você deve inserir o comando ip ospf priority 2 na interface f0/0. Você
pode modificar diretamente o arquivo de configuração de inicialização ou (i) ligar o
roteador, (ii) fazer e salvar a configuração e (iii) desligar o roteador novamente. Feita
esta configuração preliminar, execute os seguintes passos: (i) ligue todos os roteadores
ao mesmo tempo e aguarde a convergência da rede; (ii) confirmar que R1 é de fato o
DR no link compartilhado (por exemplo, usando o comando show ip ospf vizinho em
R3) e anotar o SN do Network-LSA armazenado no LSDB (usando o comando show ip
ospf database) ; (iii) instalar uma sonda Wireshark no link compartilhado e iniciar uma
captura com um filtro ospf; (iv) interface de desligamento f0/0 de R1 (inserindo o
comando shutdown na interface f0/0).
Resultado do experimento Inicialmente, R1 é o DR no link compartilhado, e R3 é o BDR

(já que seu RID é maior que o de R2). Quando a interface f0/0 de R1 é desligada, o
roteador imediatamente entende que deixou de ser o DR e inunda uma nova instância
de seu Roteador-LSA e uma indicação para deletar a Rede-LSA que representa o link
compartilhado. Esses LSAs são primeiro transmitidos para o roteador R4 e depois
retransmitidos de R4 para R2, que os injeta no link compartilhado. Muitos pacotes LS
UPDATE e LS ACKNOWLEDGMENT aparecem no link compartilhado, mas queremos
apenas nos concentrar na indicação de deletar o Network-LSA. Mostramos isso na
Figura 10.38. Observe que o campo LS Age é igual a 3600 segundos, que é a
característica distintiva de uma indicação de exclusão. Também é verdade que o
Número de Sequência carregado no

10.4 Procedimento de exclusão 357
FIGURA 10.38: Procedimento de exclusão do OSPF - Indicação para excluir o Network LSA originado
por R1.
pacote (0×80000002) é o mesmo que a instância armazenada. Observe também que o Network-LSA
ainda lista três roteadores como sendo anexados ao link compartilhado; o novo Network-LSA, originado
por R3 (o novo DR), listará apenas dois roteadores (R2 e R3).
EXPERIMENTO ADICIONAL - Um experimento muito fácil de realizar e que aciona a transmissão de

indicações de exclusão é a liberação do processo ospf em um roteador sem desligá-lo. Novamente na
rede da Figura 10.31, (i) inicie todos os roteadores ao mesmo tempo, (ii) instale uma sonda Wireshark
no link compartilhado com um filtro ospf e (iii) insira o comando clear ip ospf process no EXEC
privilegiado nível.
10.4.2 IS-IS
Procedimento experimental Este experimento é mais fácil de ser feito em IS-IS do que em OSPF, pois
o DIS é mais fácil de mudar do que o DR. O procedimento é o seguinte: (i) ligar todos os roteadores
ao mesmo tempo e aguardar a convergência da rede; (ii) verificar qual roteador é o DIS e anotar o SN
do Pseudonode-LSP armazenado no LSDB (utilizando o comando show isis database); (iii) instalar
uma sonda Wireshark no link compartilhado e iniciar uma captura com um filtro isis; (iv) diminuir a
prioridade da interface f0/0 do DIS.
A maneira mais fácil de saber quem é o DIS é verificar no LSDB qual roteador está anunciando o
Pseudonode-LSP, ou seja, o LSP com Pseudonode diferente de zero

FIGURA 10.39: Procedimento de deleção do IS-IS - Indicação para deletar o

Pseudonode-LSP originado por R3.
ID (usando o comando show isis database). O valor de prioridade padrão é 64, e você
terá que alterá-lo para um valor menor usando o comando isis priority na interface
f0/0 do DIS.
Resultado do experimento Em nosso caso, o DIS era inicialmente R3 e mudamos a
prioridade de sua interface f0/0 para 63. Feito isso, o roteador imediatamente
transmitiu uma indicação para deletar o Pseudonode-LSP que possuía. Esse LSP é
mostrado na Figura 10.39. Observe que o Remaining Lifetime é igual a zero, que é
uma característica distintiva das indicações de exclusão. O LSP ID identifica o LSP
que está sendo excluído: R3-01.00 indica que este LSP é originado por R3 e que o
LSP é um Pseudonode-LSP, pois o Pseudonode ID é 1 (diferente de zero). Observe
também que, ao contrário do OSPF, a indicação de exclusão não carrega todo o
conteúdo do LSP que está sendo excluído; ele carrega apenas o ID do LSP, o
Número de Sequência e o Tempo de Vida Remanescente.
10.5 Sincronização LSDB inicial

Esta seção apresenta vários experimentos que ilustram o processo inicial de
sincronização LSDB de OSPF e IS-IS. Esta questão foi discutida na Seção 6.6.
Configuração experimental Os experimentos usam a topologia de rede da Figura

10.40, com três roteadores e dois links; os links são um link compartilhado entre R1
e R2 e um link ponto a ponto entre R2 e R3. Eles são realizados com as versões IPv4
de ambos os protocolos, pois o comportamento das versões IPv6 é semelhante. Os
roteadores devem ser configurados inicialmente com as configurações básicas de
roteamento. Tanto o Wireshark quanto o recurso de depuração do Cisco IOS são
usados nesses experimentos.

FIGURA 10.40: Experimentos relacionados ao processo inicial de sincronização

LSDB - Topologia de rede.
10.5.1 OSPF
O objetivo deste experimento é analisar as diversas fases do processo de sincronização
LSDB do OSPF, descritas na Seção 6.6.1. Nós nos concentramos na sincronização
no link compartilhado (entre R1 e R2). O procedimento experimental é projetado de
forma que, quando um roteador é ligado, ele encontra no vizinho LSAs auto-originados
com maior frescor.
Procedimento experimental O procedimento é o seguinte: (i) ligar todos os roteadores
ao mesmo tempo e aguardar a convergência da rede; (ii) desligue o roteador R1 e
espere até que a rede converja novamente; (iii) instalar uma sonda Wireshark no link
compartilhado e iniciar uma captura com um filtro ospf; (iv) execute o comando debug
ip ospf adj no roteador R2; (v) ligue o roteador R1 novamente.
Resultado experimental Quando R1 é ligado pela primeira vez, o SN de seu Roteador-
LSA é incrementado várias vezes durante o processo de convergência devido à
mudança de estado da interface (a interface é eleita BDR) e da mudança de estado
vizinho (quando seu relacionamento com R2 atinge o estado Cheio).
Na verdade, após a convergência da rede, o Roteador-LSA terá um SN de 3.
Isso garante que, quando R1 for ligado novamente, ele encontrará no vizinho uma
instância de seu Roteador-LSA autogerado com SN mais alto.
Depois que R1 é desligado, o link compartilhado muda de um link compartilhado
de trânsito para um link compartilhado de stub. Isso solicita a exclusão do Network-
LSA anteriormente originado por R2 e a atualização do Roteador-LSA de R2. O
Roteador-LSA de R2 deve ser atualizado, pois as interfaces com links compartilhados
de trânsito e stub são descritas de maneira diferente (com diferentes tipos de descrição de link).
Quando R1 é religado o link compartilhado volta a ser um link compartilhado de
trânsito, e R2 origina um novo Network-LSA e uma nova instância de seu Roteador-
LSA.
Observe que o resultado desse experimento é muito próximo ao exemplo da Seção
6.6.1.
Captura do Wireshark e saída de depuração de R2 A Figura 10.41 mostra a captura
do Wireshark e a Figura 10.42 mostra a saída de depuração do roteador R2. Em
relação à captura inicial do Wireshark, removemos todos os pacotes HELLO; em
relação à saída de depuração original, removemos todas as mensagens relacionadas
à eleição do roteador designado, exceto as mensagens relacionadas à primeira eleição.
Começamos descrevendo as principais partes da captura do Wireshark:

• Pacotes 27 a 32, 34 - DB DESCRIÇÃO pacotes que trocam os resumos LSDB.
• Pacote 33 - LS REQUEST enviado por R1 solicitando os LSAs completos pertencentes

por R2.
• Pacote 35 - LS UPDATE enviado por R2 em resposta LS REQUEST (pacote

33).
• Pacotes 36, 37, 42 - LS UPDATE divulgando a nova Rede-LSA, e as novas instâncias de

Roteador-LSA de R1 e R2.
• Pacotes 40, 44 - LS ACKNOWLEDGMENTs confirmando o recebimento de

os LSAs enviados em LS UPDATEs anteriores.
Primeiros pacotes DB DESCRIPTION Os pacotes 27 e 28 são os primeiros pacotes DB DE

SCRIPTION enviados por R1 e R2. R1 escolhe um ddSN de 5384 e R2 escolhe um ddSN de
1397, e ambos assumem ser o mestre (conjunto de bits MS).
De acordo com a saída de depuração, R2 recebeu a primeira DESCRIÇÃO do banco de dados
de R1 (mensagem 1) antes de atingir o estado 2-Way com este vizinho (mensagem 2). Isso
significa que R1 atingiu esse estado antes de R2, pois os pacotes DB DESCRIÇÃO só podem
ser enviados para um vizinho após a verificação da comunicação bidirecional com esse vizinho.
Esses dois pacotes não carregam cabeçalhos LSA.
R2 executa o algoritmo de eleição do roteador designado Quando R2 atinge o estado 2-Way
com R1, ele imediatamente executa o algoritmo de eleição do roteador designado (mensagens
3 a 7 da saída de depuração), concluindo que continua sendo o DR e que R1 é o novo BDR.
Envia então o seu primeiro pacote DB DESCRIPTION que, como referido acima, é o pacote
28; este evento também é sinalizado nas mensagens 8 e 9 da saída de depuração.
R1 abandona o estado ExStart Na próxima DESCRIÇÃO DB enviada por R1 (pacote 29), R1

já entendeu que não é o mestre, pois o bit MS está limpo e o ddSN é o mesmo do pacote 28
enviado por R2 (ou seja, 1397 ).
O bit I também é zerado, pois R1 entendeu que é o escravo e, portanto, abandonou o estado
ExStart. Neste pacote, R1 anuncia seu recém-criado Roteador-LSA com SN=1 (na verdade
0×80000001).
R2 abandona o estado ExStart Quando o pacote 29 é recebido em R2 (mensagem 10 da saída
de depuração), R2 também muda para o estado Exchange (mensagem 11), pois recebeu uma
DESCRIÇÃO DB com o bit I e o bit MS limpo e seu RID é maior que o do vizinho.
R2 descreve seus LSAs R2 então envia um pacote DB DESCRIPTION (pacote 30 e mensagem

12 da saída de depuração), onde descreve todos os seus LSAs, ou seja, o Roteador-LSA de
R1 (com SN=3), o Roteador-LSA de R2 (com SN=4), e o Roteador-LSA de R3 (com SN=1).
Por se tratar de um novo pacote DB DESCRIPTION enviado pelo mestre, o ddSN é
incrementado em 1 em relação ao anterior; agora é 1398.
R1 e R2 abandonam a fase de troca Neste ponto, R1 e R2 já

FIGURA 10.41: Sincronização LSDB inicial de captura OSPF - Wireshark.
concluíram a troca de seus resumos LSDB. No entanto, o recebimento dessas informações

ainda deve ser confirmado antes que ambos os roteadores possam concluir a fase de
descrição do banco de dados e abandonar o estado Exchange. O pacote 31 é o primeiro
pacote DB DESCRIPTION enviado por R1 onde o bit M é limpo, indicando que R1 tem
sua lista de resumo do banco de dados vazia; a lista está vazia pois a recepção do pacote
29 (enviado por R1) foi confirmada pelo pacote 30 (enviado por R2). A recepção deste
pacote em R2 é sinalizada na mensagem 13 da saída de depuração.
O pacote 31 (enviado por R1) também é uma confirmação de que o pacote 30

(enviado por R2) foi recebido corretamente. Assim, a lista de resumo do banco de dados de R2 é

FIGURA 10.42: Sincronização LSDB inicial de OSPF - Mensagens de saída de

depuração de R2.
esvaziado e R2 envia um pacote DB DESCRIPTION com o bit M limpo (pacote 32 e

mensagem 14 da saída de depuração). O roteador R1 deve responder a esta
mensagem (já que é o escravo), o que ele faz no pacote 34.
R2 vai para o estado Full Quando R2 recebe o pacote 34, ele abandona o

Troca o estado e muda diretamente para o estado Completo (mensagens 17 a 19 da

saída de depuração). R2 não passa pela fase de Carregamento, pois não tem
interesse nos LSAs que R1 possui: R1 anunciou um Roteador-LSA, mas R2 tem uma
instância desse LSA com SN maior.
R2 inunda uma nova instância do Router-LSA Como R2 ficou totalmente adjacente a
R1, ele agora tem que gerar uma nova instância do Router-LSA, com um SN
incrementado em um em relação ao anterior (mensagem 20 da saída de depuração).
Isso é necessário, pois o link compartilhado mudou de um link compartilhado de stub
para um link compartilhado de trânsito. Assim, a descrição do link correspondente
deve ser alterada do tipo 3 (link para rede stub) para o tipo 2 (link para rede de
trânsito). A nova instância do roteador-LSA é anunciada no pacote LS UPDATE
(pacote 36) enviado para o endereço multicast AllSPFRouters (224.0.0.5).
R2 inunda um novo Network-LSA Da mesma forma, como R2 é o DR e ficou adjacente
a um novo roteador (neste caso, a adjacência é a primeira no link compartilhado), ele
deve originar um novo Network-LSA (mensagens 21 e 22 da saída de depuração).
Como no caso do novo Router-LSA, o Network-LSA é anunciado em um pacote LS
UPDATE (pacote 37) enviado para o endereço multicast AllSPFRouters (224.0.0.5).
R1 solicita vários LSAs Quando R1 recebe o pacote 32, ele muda do estado Exchange
para o estado Loading. Com base nas informações fornecidas por R2 no pacote 30,
R1 descobre que estão faltando vários LSAs (completos) que R2 possui e os solicita
em um pacote LS REQUEST (pacote 33). Observe que R1 também solicita o conteúdo
completo de seu Roteador-LSA autogerado.
Porém, essa requisição específica é desnecessária, pois R1 já sabe (pelo pacote 30)
que o SN do LSA é 3, e que terá que inundar uma nova instância deste LSA com um
SN incrementado em um em relação ao vizinho um.
R2 envia os LSAs completos Quando R2 recebe esta requisição (mensagem 15 da

saída de depuração), ele responde com um LS UPDATE unicast para R1, incluindo
o conteúdo completo dos Router-LSAs que R2 possui (pacote 35 e mensagem 16 da
depuração saída).
R1 inunda uma nova instância do Roteador-LSA auto-originado R1 enviará um LS
UPDATE final, pois notou que R2 tinha uma instância de seu Roteador-LSA auto-
originado com um SN maior que o seu. Assim, cria uma nova instância deste Roteador-
LSA com o SN incrementado em um em relação ao vizinho, ou seja, com um SN de
4. A recepção desta mensagem em R2 é sinalizada pela mensagem 33 da saída
debug.
Confirmando a recepção dos LSAs Finalmente, os pacotes 40 e 44 são LS
ACKNOWLEDGMENTs que confirmam a recepção dos LSAs enviados nos pacotes
LS UPDATE anteriores. Observe que o LS ACKNOWLEDGMENT enviado por R1
reconhece os LSAs que foram transmitidos em diferentes pacotes LS UPDATE. Isso
dá um exemplo de confirmações atrasadas.
EXPERIÊNCIA ADICIONAL - Repita esta experiência, mas agora com

o local da sonda Wireshark no link ponto a ponto; além disso, inicie a sonda Wire shark antes de
desligar R1. Desta forma, você poderá observar a reação de R2 quando R1 é desligado e quando
é ligado novamente.
Quando R1 é desligado nada acontecerá por aproximadamente 40 segundos, que é o tempo que
R2 leva para detectar a falha de R1. Em seguida, R2 envia uma nova instância de seu roteador-
LSA e uma indicação para excluir o Network-LSA do link compartilhado de trânsito nos pacotes LS
UPDATE. Você notará que Network-LSA é uma indicação de exclusão porque o valor do campo
LS Age é 3600 segundos. R2 envia essas instâncias LSA porque quando o roteador R1 falha, o
link compartilhado muda de um link de trânsito para um link de stub. Você também observará um
pacote LS ACKNOWLEDGMENT enviado por R3 confirmando a recepção dos dois LSAs enviados
por R2.
Mais tarde, quando R1 é ligado novamente, R2 envia para R3 uma nova instância de seu
Roteador-LSA, uma nova Rede-LSA representando o link compartilhado de trânsito (já que o link
compartilhado tornou-se novamente um link de trânsito) e o novo Roteador-LSA de R1 , e R3 envia
as confirmações correspondentes.
10.5.2 IS-IS
A sincronização LSDB inicial do IS-IS foi descrita na Seção 6.6.2 e é analisada nesta seção.
10.5.2.1 Links compartilhados
O objetivo deste experimento é analisar as diversas fases do processo de sincronização IS-IS em

enlaces compartilhados.
Configuração e procedimento experimental A configuração e procedimento experimental são
semelhantes aos da Seção 10.5.1, exceto que um filtro isis deve ser configurado no Wireshark;
além disso, o recurso de depuração não é usado neste experimento. Observe que o DIS do link
compartilhado é R2 porque sua interface possui um endereço MAC maior.
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.43. Em relação à captura

original, removemos os pacotes HELLO e os pacotes CSNP fora da janela de tempo do
experimento. Começamos descrevendo as principais partes da captura do Wireshark:
• Pacote 8 - Último CSNP enviado por R2 antes de R1 ser ligado.
• Pacote 23, 24, 27 - LSPs iniciais enviados por R1 e R2.
• Pacote 28 - Nonpseudonode-LSP de R1 enviado por R2 porque recebeu um

instância deste LSP com um SN menor que o armazenado.
• Pacote 29 - Nonpseudonode-LSP de R1 enviado por R1 porque recebeu um

instância deste LSP com um SN maior que o armazenado.
• Pacote 35 - Primeiro CSNP recebido por R1.

FIGURA 10.43: Sincronização LSDB inicial em links compartilhados IS-IS - Captura

Wire shark.
• Pacote 36 e 37 - PSNP enviado por R1 para solicitar LSP ausente e resposta

enviado por R2.
Último CSNP antes de ligar R1 O pacote 8 é o último CSNP transmitido antes de R1

ser ligado. Observe que o Nonpseudonode-LSP de R1 ainda está no LSDB de R2,
apesar de R1 estar desligado. Isso ocorre porque a idade desse LSP ainda está em
contagem regressiva até zero. Observe também que o Pseudonode-LSP que descreve
o link compartilhado (R2.01-00) ainda está no LSDB. Quando R1 foi desligado, o link
compartilhado mudou de um link compartilhado de trânsito para um link compartilhado
stub e, portanto, o Pseudonode-LSP que descreve o link compartilhado deve ter sido
removido. Porém, nesta implementação, ele permanece no LSDB por 20 minutos
(MaxAge*).
LSPs iniciais enviados por R1 e R2 Quando R1 é ligado, R1 e R2 tornam-se adjacentes
e enviam um ao outro seus próprios LSPs. No pacote 23, R2 transmite no link seu
Nonpseudonode-LSP (R2.00-00 com SN=9) e, no pacote 24, transmite o Pseudonode-
LSP descrevendo o link compartilhado de trânsito (R2.01-00 com SN=6 ), pois R2 é o
link DIS. Observe que os SNs desses LSPs são maiores que os anunciados pelo CSNP
anterior (pacote 8); isso ocorre porque o link compartilhado mudou de um link
compartilhado stub para um link compartilhado de trânsito. No pacote 27, R1 anuncia
seu Nonpseudonode-LSP recém-criado (R1.00-00 com SN=2).
Reação a LSPs auto-originados desatualizados Quando R2 recebe o Nonpseudonode-

LSP de R1 (pacote 27), ele verifica se sua instância armazenada possui SN maior (a
instância armazenada possui SN=6 e a enviada por R1 possui SN=2). Assim, R2 inunda
no link sua instância armazenada de R1.00-00 (pacote

28). Quando R1 recebe este LSP, ele verifica que é um LSP auto-originado com SN
maior, e inunda uma nova instância do LSP com o SN incrementado em um em
relação ao SN recebido de R2 (pacote 29).
CSNP de R2 e requisição de informações faltantes por R1 O pacote 35 é um CSNP
enviado por R2 (o link DIS), onde ele anuncia todos os LSPs contidos em seu LSDB.
Este é o primeiro CSNP recebido pelo R1. Quando R1 examina este pacote, conclui
que ainda falta o Nonpseudonode-LSP de R3 (R3.00-00). Assim, ele transmite um
PSNP solicitando este LSP (pacote 36), e R2 o envia imediatamente (pacote 37).
10.5.2.2 Enlaces ponto a ponto
O objetivo deste experimento é analisar as diversas fases do processo de

sincronização IS-IS LSDB em enlaces ponto a ponto.
Configuração e procedimento experimental A configuração e procedimento
experimental são semelhantes aos da Seção 10.5.2.1, exceto que a sonda Wireshark
agora deve ser colocada no link ponto a ponto e o roteador que é ligado e desligado
é o roteador R3.
Além disso, queremos ter certeza de que a instância Nonpseudonode-LSP de R3
que permanece no LSDB de R1 e R2 após R3 ser desligado tem SN maior do que a
primeira instância Nonpseudonode-LSP inundada por R3 quando ele é ligado
novamente. Para impor isso, devemos aumentar o SN do Nonpseudonode-LSP
durante o período em que o R3 estiver ligado. Uma maneira fácil de fazer isso é
alterar o custo da interface (por exemplo, usando o comando isis metric 30 na
interface f0/0 de R3).
O procedimento é então o seguinte: (i) ligar todos os roteadores ao mesmo tempo
e aguardar a convergência da rede; (ii) alterar o custo da interface f0/0 do roteador
R3 (pelo menos uma vez); (iii) desligue o roteador R3 e espere até que a rede
converja novamente; (iii) instalar uma sonda Wireshark no link ponto-a-ponto e iniciar
uma captura com um filtro isis; (v) ligue o roteador R3 novamente.
relação à captura inicial do Wireshark, removemos todos os pacotes HELLO.
Começamos descrevendo as principais partes da captura do Wireshark:
• Pacotes 24 e 25 - Nonpseudonode-LSPs de R2 e R3, enviados inicialmente.
• Pacote 26 e 27 - CSNPs descrevendo os resumos LSDB de R2 e R3.
• Pacote 29 a 31 LSPs completos enviados por R2 e R3.
• Pacotes 32 e 33 - PSNPs confirmando o recebimento de

LSPs enviados.
Nonpseudonode-LSPs iniciais Os roteadores R2 e R3 enviam inicialmente entre si

seus Nonpseudonode-LSPs auto-originados. R2 envia o LSP com LSP ID R2.00-00 e
SN=9 (pacote 25), e R3 envia o LSP com LSP ID R3.00-00 e SN=2 (pacote 24).

FIGURA 10.44: Sincronização LSDB inicial em links ponto-a-ponto IS-IS (1º

experimento) - Captura Wireshark.
Troca de resumos LSDB R2 e R3 então trocam CSNPs com os resumos de seus

LSDBs. Neste ponto, R3 tem apenas seu próprio Nonpseudonode LSP (R3.00-00
com SN=2) e o Nonpseudonode-LSP recebido de R2 no pacote 25 (R2.00-00 com
SN=9). R2 anuncia todos os LSPs que descrevem a rede, incluindo um
Nonpseudonode-LSP de R3 com um SN maior que o recém-gerado por R3 (pacote
24), mas que agora está desatualizado.
R3 inunda nova instância de Nonpseudonode-LSP auto-originado A partir do CSNP
enviado por R2 (pacote 27) R3 entende que R2 tem uma instância de seu
Nonpseudonode-LSP auto-originado com um SN maior que o seu. Assim, inunda, no
pacote 29, uma nova instância com o SN incrementado em um em relação à instância
mantida por R2: aumenta o SN de 6 para 7.
R2 inunda LSPs que faltam em R3 Com base nas informações fornecidas por R3, R2
entende que R3 ainda está faltando R1.00-00 e R2.01.00 e envia esses LSPs nos
pacotes 30 e 31, respectivamente.
Reconhecimento dos LSPs Os pacotes 32 e 33 são os PSNPs que reconhecem os
LSPs recebidos por cada roteador. No pacote 32, R3 confirma a recepção de R1.00
com SN=3, R2.00 com SN=9 e R2.01 com SN=2. No pacote 33, R2 confirma a
recepção de R3.00-00 com SN=7. Observe que, embora R2 tenha recebido duas
instâncias de R3.00-00, uma com SN=2 (pacote 24) e outra com SN=7 (pacote 29),
ele só reconhece a última.
Uma pequena variação do experimento anterior Suponha agora que queremos
garantir que, exceto para os Nonpseudonode-LSPs de R2 e R3, as outras instâncias
de LSP sejam as mesmas quando R2 e R3 sincronizam pela segunda vez. Para isso,
repetimos o procedimento do experimento anterior, mas ao invés de desligar e ligar
o roteador R3, apenas desligamos e ligamos sua interface s0/0 (através dos
comandos shutdown e no shutdown).
Captura do Wireshark A captura do Wireshark é mostrada na Figura 10.45. Como em

FIGURA 10.45: Sincronização LSDB inicial em links ponto-a-ponto IS-IS (2º

experimento) - Captura Wireshark.
No experimento anterior, os roteadores R2 e R3 primeiro trocam seus Nonpseudonode-

LSPs auto-originados (pacotes 22 e 23). Esses LSPs são os únicos que mudam
quando a interface s0/0 de R3 é desligada e ligada. Os roteadores então trocam seus
resumos LSDB (pacotes 24 e 25). Os resumos indicam que o LSDB é o mesmo em
ambos os roteadores. Portanto, nenhum roteador precisa solicitar mais LSPs ao seu
vizinho. Finalmente, os dois últimos PSNPs reconhecem os dois Nonpseudonode-
LSPs enviados inicialmente: o pacote 27 reconhece o LSP enviado no pacote 22 e o
pacote 28 reconhece o LSP enviado no pacote 23.
10.5.2.3 Lidando com LSPs desatualizados de origem própria
Nesta seção, comparamos o resultado de dois experimentos, projetados para analisar

o papel do checksum durante o processo inicial de sincronização do LSDB, quando
uma encarnação anterior de um LSP auto-criado tem o mesmo SN do recém-criado.
Usamos um procedimento semelhante à Seção 10.5.2.2. Após a convergência da

rede, R3 é desligado e ligado novamente, de modo que, quando ligado, encontra uma
encarnação anterior de seu Nonpseudonode-LSP auto-originado (R3.00-00) em R2.
Realizamos dois experimentos nos quais queremos garantir que: (i) os SNs das
instâncias antiga e nova sejam os mesmos em ambos os experimentos e, (ii) em um
experimento as somas de verificação das instâncias antiga e nova sejam as mesmas,
mas em no outro experimento, as somas de verificação são diferentes.
Procedimento experimental (experimento 1) O primeiro experimento leva a instâncias
LSP com SNs e checksums iguais. O procedimento é o seguinte: (i) ligar todos os
roteadores ao mesmo tempo e aguardar a convergência da rede; (ii) desligue o
roteador R3 e espere até que a rede converja novamente; (iii) instalar uma sonda
Wireshark no link ponto-a-ponto e iniciar uma captura com um filtro isis; (iv) ligue o
roteador R3 novamente.
Procedimento experimental (experimento 2) O segundo experimento é mais complexo
e envolve alterar a configuração de inicialização enquanto o roteador R3 está
desligado. O objetivo é garantir que, quando o R3 for ligado pela segunda vez, ele

FIGURA 10.46: Função do checksum no processo de sincronização LSDB inicial IS-

IS (experimento 1) - Captura Wireshark.
gera um Nonpseudonode-LSP com o mesmo SN do antigo LSP, mas com um

checksum diferente. Uma maneira de conseguir isso é modificar o endereço IP
atribuído à interface s0/0. O procedimento é então o seguinte: (i) ligar todos os
roteadores ao mesmo tempo e aguardar a convergência da rede; (ii) desligue o
roteador R3 e espere até que a rede converja novamente; (iii) no arquivo de
configuração de inicialização do R3, modifique o endereço IP da interface s0/0 de
222.222.10.3 para 222.222.10.4; (iv) instalar uma sonda Wireshark no link ponto-a-
ponto e iniciar uma captura com um filtro isis; (v) ligue o roteador R3 novamente.
Capturas do Wireshark As capturas do Wireshark dos dois experimentos são
mostradas nas Figuras 10.46 e 10.47. Em relação às capturas originais, removemos
todos os pacotes HELLO. Nas figuras, incluímos informações relativas ao Remaining
Lifetime e Checksum dos vários LSP Entries TLVs, uma vez que esta informação é
relevante para a interpretação dos experimentos.
Resultado do experimento 1 Começamos discutindo o experimento 1. Os primeiros
dois pacotes (pacotes 19 e 20) são os Nonpseudonode-LSPs auto-originados de R2
e R3. Os próximos dois pacotes (pacotes 21 e 22) são os CSNPs que anunciam os
resumos LSDB de R2 e R3. R3 anuncia o LSP que acabou de criar (R3.00-00) e o
recém-recebido de R2 no pacote 19 (R2.00-00); R2 anuncia quatro LSPs (R1.00-00,
R2.00-00, R2.01-00 e R3-00.00). Com base nas informações fornecidas no CSNP do
pacote 21 (enviado por R3), R2 descobre que R3 ainda está faltando R1.00-00 e
R2.01-00 e envia para R3 esses LSPs nos pacotes 25 e 26. Pacotes 27 e 28 são os
PSNPs que confirmam a recepção dos LSPs anteriores.
Analisando em detalhes R3.00-00 Vamos nos concentrar agora em R3.00-00. Em

FIGURA 10.47: Papel do checksum no processo de sincronização LSDB inicial IS-IS

(experimento 2) - Captura Wireshark.
pacote 20, R3 envia a instância de R3.00-00 que acabou de criar, com SN=2, Remaining
Lifetime = 1200s e Checksum = 0×1450; o Remaining Lifetime desta instância é o mais
alto possível. Em seguida, no CSNP enviado por R2 (pacote 22), R2 anuncia uma
instância de R3.00-00 com o mesmo SN e checksum, mas com um tempo de vida
restante significativamente menor (922 segundos).
Esta foi a instância deixada em R2 quando R3 foi desligado. Observe que, no CSNP
do pacote 22, o Remaining Lifetime de R2.00-00 é apenas 1 segundo mais antigo que
o do pacote 19, mas o Remaining Lifetime de R3.00-00 é 188 segundos mais antigo
que o do pacote 20. Além disso, nos pacotes subseqüentes, R3 não inunda uma
instância de R3 com o SN incrementado em um.
De fato, ao receber o pacote 20, R2 entende, com base no SN e no Checksum de
R3.00-00, que o conteúdo das instâncias armazenadas e recebidas de R3.00-00 é
exatamente o mesmo (têm o mesmo frescor ) e decide não substituir a instância
armazenada. Além disso, quando R3 recebe o CSNP de R2 (pacote 22), ele descobre,
com base novamente no SN e no Checksum, que a instância de R3.00 armazenada
em R2 está totalmente atualizada (as instâncias armazenadas e recebidas são
igualmente novas), e decide que não há necessidade de inundar uma instância adicional.
Resultado do experimento 2 O resultado do experimento 2 não é o mesmo.

O ponto inicial do experimento 2 é o mesmo do experimento 1. Assim, R3 cria
inicialmente uma instância de R3.00-00 com SN=2 e Checksum = 0×1450, e esta é a
instância que resta em R2 e R1 quando R3 está desligado.
Quando R3 é ligado novamente, ele cria imediatamente uma instância de R3.00-00
com SN=2 (como no experimento 1), mas com uma soma de verificação diferente, devido a

a alteração feita na configuração do R3 enquanto ele estava desligado; o pacote

18 revela que o Checksum agora é 0 × 283b. Quando R2 recebe o pacote 18,
ele entende, com base no Checksum, que as instâncias armazenadas e
recebidas de R3.00 não são iguais: o Checksum da instância armazenada é
0×1450 e o da instância recebida é 0×283b . Conforme mostrado no CSNP do
pacote 20, R2 então decide expirar esta instância definindo seu Remaining
Lifetime como 0; ele também modifica seu Checksum para 0×e415. Quando R3
recebe o pacote 20, ele descobre que a instância de R3.00 armazenada em R2
expirou e inunda uma nova instância desse LSP com SN=3 (pacote 23); como
o SN é diferente do pacote 18, o Checksum também é diferente (mudou para 0×263c).


11
Experimentos em Redes Hierárquicas
As redes OSPF e IS-IS podem ser estruturadas em uma hierarquia de dois níveis de
áreas, onde o nível superior pode ter apenas uma área e as áreas de nível inferior se
conectam diretamente à superior e não podem se conectar umas às outras. Essa
questão foi abordada no Capítulo 7. Neste capítulo, apresentamos vários experimentos
que ilustram os vários recursos das redes hierárquicas OSPF e IS-IS.
A Seção 11.1 explica as configurações do roteador e a estrutura LSDB. A Seção
11.2 mostra como as restrições impostas ao processo de seleção do caminho mais
curto podem levar a um roteamento não ótimo. Os experimentos são realizados
apenas com as versões IPv4 dos protocolos, pois as versões IPv6 possuem
comportamento semelhante.
11.1 Estrutura LSDB

Analisamos aqui a estrutura LSDB de redes hierárquicas OSPF e IS-IS, contendo
informações de endereçamento de área interna, área externa e domínio externo. Os
experimentos serão baseados na topologia de rede da Figura 11.1. A rede inclui dois
ASes conectados por meio de BGP (AS 100 e AS 200) e o AS 200 inclui duas áreas
executando OSPF hierárquico ou IS-IS.
A área de nível inferior é a área 1 tanto no OSPF quanto no IS-IS; o backbone é a
área 0 no OSPF e a área 2 no IS-IS. Lembre-se que no OSPF o backbone é
necessariamente a área 0. O roteador R1 é interno à área 1; os roteadores R2 e R3
são os ABRs entre a área 1 e o backbone; o roteador R4 é interno ao backbone e, ao
mesmo tempo, é o DBR que se comunica com o roteador R5 (o DBR da área 100). O
AS 100 inclui o prefixo 150.150.0.0/16 que deve ser injetado no AS 200. Os prefixos
do AS 200 pertencem ao intervalo 222.222.0.0/16. Os custos da interface OSPF são
todos 10 (o valor padrão), exceto os da interface f0/0 de R1 (com custo 15) e interface
f0/1 de R3 (com custo 30).
11.1.1 Configurações do roteador

As configurações necessárias para o suporte de roteamento hierárquico em OSPF e
IS-IS não são muito diferentes das configurações básicas de roteamento (consulte a
Seção 8.4). A Figura 11.2 mostra as configurações completas do roteador R2.
373

374 11 Experimentos em Redes Hierárquicas
FIGURA 11.1: Experimentos relacionados à estrutura LSDB de redes hierárquicas -

topologia de rede.
OSPF As configurações de roteador do OSPF são muito semelhantes às de área

única. As únicas modificações são nos ABRs onde, no comando network do modo
ospf do roteador, cada sub-rede deve ser declarada na área a que pertence. Por
exemplo, na configuração de R2 (Figura 11.2.a) a sub-rede 222.222.10.0/24 é
declarada na área 1 e a sub-rede 222.222.30.0/24 é declarada na área 0.
IS-IS As configurações do roteador IS-IS são um pouco mais complexas que as do

OSPF. Os roteadores de área interna devem ser configurados como roteadores L1
ou L2, dependendo do tipo de área a que pertencem. Declarar um roteador como L1
ou L2 no modo isis do roteador força todas as interfaces do roteador a se tornarem
somente L1 ou somente L2, que é exatamente o que desejamos. No nosso caso, R1
deve ser configurado como roteador L1 (através do comando is-type level-1) e R2
como roteador L2 (através do comando is-type level-2-only). Os ABRs devem ser
configurados como roteadores L1/L2. O Cisco IOS assume essa configuração por
padrão, portanto, nenhuma configuração específica é necessária no modo isis do
roteador. No entanto, um roteador L1/L2 tem suas interfaces configuradas como interfaces L1/L2 po

11.1 Estrutura LSDB 375
FIGURA 11.2: Configurações do roteador para roteamento hierárquico em (a) OSPF

e (b) IS-IS (roteador R2).
precisamos configurar as interfaces conectadas às áreas L1 como interfaces somente

L1, e as conectadas à área L2 como interfaces somente L2. Isso é mostrado na Figura
11.2.b para o caso do roteador R2: a interface f0/0 é configurada como somente L1
através do comando isis circuit-type level-1, e a interface f0/1 é configurada como
somente L2 usando o comando comando isis tipo circuito apenas nível 2.
Além das configurações acima, os roteadores L1/L2 devem ser informados
explicitamente para redistribuir os prefixos do L2 LSDB no L1 LSDB. Isso é feito
através do comando redistribuir isis ip level-2 into level-1 distribui

FIGURA 11.3: Estrutura LSDB do OSPF hierárquico - LSDB da área 1.
list 100 inserido no modo isis do roteador (consulte a Figura 11.2.b). Isso requer ainda a
configuração de uma lista de acesso para definir quais prefixos serão redistribuídos. Com o
comando access-list 100 permit ip any any, permitimos a redistribuição de todos os prefixos IPv4.
11.1.2 Estrutura OSPF LSDB

A estrutura LSDB das redes hierárquicas OSPF foi abordada na Seção 7.3.1. O experimento desta
seção é baseado na topologia de rede da Figura 11.1. As Figuras 11.3 e 11.4 mostram os resumos
do LSDB da área 1 e da área 0. Esses LSDBs podem ser obtidos nos ABRs usando o comando
show ip ospf database.
Informações topológicas e de endereçamento interno de área Vamos primeiro

FIGURA 11.4: Estrutura LSDB de OSPF hierárquico - LSDB de área 0.
concentre-se nas informações de endereçamento topológicas e de área interna que, no OSPFv2,

são fornecidas pelo Roteador-LSAs e pela Rede-LSAs.
O LSDB de cada área descreve apenas os elementos topológicos dessa área. Os Network-LSAs
da área 1 descrevem apenas as sub-redes 222.222.10.0/24 e 222.222.20.0/24, e os Network-LSAs
da área 0 descrevem apenas 222.222.30.0/24 e 222.222.40.0/24. R4 não possui Router-LSA na
área 1, e R1 não possui Router-LSA na área 0. Além disso, os Router-LSAs originados em uma
área descrevem apenas as interfaces pertencentes a essa área. Por exemplo, R2 origina um
Roteador-LSA na área 1 descrevendo sua interface f0/0, e origina outro Roteador-LSA na área 0
descrevendo sua interface f0/1. A Figura 11.5.a mostra o conteúdo completo do Roteador-LSA
originado por R2 na área 0. Possui apenas uma descrição de link caracterizando a interface com
o link compartilhado de prefixo 222.222.10.0/24 (identificado como Link conectado a: uma Rede
de Trânsito ).
Informações de endereçamento de área externa Os prefixos de área externa são anunciados

usando Network-Summary-LSAs. Eles podem ser vistos na parte Summary Net Link States da tela
(Figuras 11.3 e 11.4). Existem quatro LSAs deste tipo em cada LSDB, dois deles originados por
R2 e os outros dois

FIGURA 11.5: Estrutura LSDB do OSPF hierárquico; (a) Router-LSA originado por
R2 na área 1, (b) Network-Summary-LSA originado por R3 na área 1, e (c) ASBR-
Summary-LSA originado por R3 na área 1.
por R3. Os LSAs da área 1 descrevem os prefixos da área 0 e vice-versa. Os LSAs

também incluem o custo do caminho intra-área mais curto desde o ABR de origem
até o prefixo anunciado. A Figura 11.5.b mostra o Network-Summary-LSA originado
por R3 na área 0 para anunciar o prefixo 222.222.30.0/24. O prefixo é descrito nos
campos Link State ID e Network Mask, e o custo do caminho é incluído no campo
Metric. Neste caso, o custo do caminho é a soma dos

FIGURA 11.6: Estrutura LSDB do OSPF hierárquico - Tabela de encaminhamento do

roteador R1.
custos de interface da interface f0/1 de R3 (que é 30) e da interface f0/0 de R4 (que é 10).
Informações de roteamento externo de domínio O anúncio de um prefixo externo de

domínio em redes hierárquicas OSPF requer dois tipos de LSA, um para anunciar o
prefixo e outro para anunciar o ASBR que injetou o prefixo no domínio. O prefixo é
anunciado por meio de AS-External-LSAs, que são inundados com escopo de inundação
de domínio. Isso significa que os LSAs não são modificados pelos ABRs e alcançam
todos os roteadores conforme injetados pelo ASBR de origem. Isso pode ser confirmado
pelas ILDs das duas áreas. O AS-External-LSA pode ser visto na parte do tipo 5 AS
External Link States da tela. Observe que ambos os LSDBs incluem o mesmo AS-External-
LSA, originado por R4 e prefixo de anúncio 150.150.0.0/16.
Conforme explicado na Seção 7.3.1, este LSA não fornece nenhuma indicação sobre
como rotear para o ASBR fora da área do ASBR. Esta informação é fornecida pelo ASBR-
Summary-LSA, que é disseminado como um vetor de distância dentro da sobreposição
ABR. Assim, tanto R2 quanto R3 injetam um LSA desse tipo na área 1.
Esses LSAs podem ser vistos na parte Summary ASB Link States da tela (Figura 11.3).
A Figura 11.5.c mostra o ASBR-Summary-LSA originado pelo roteador R3. O identificador
ASBR está incluído no campo Link State ID, e o custo do caminho do ABR de origem
para o ASBR (que neste caso é 30) está incluído no campo Metric.
Tabela de encaminhamento de R1 Finalmente, a Figura 11.6 mostra a tabela de

encaminhamento do roteador R1. As entradas relativas aos prefixos área-externa são
identificadas através da palavra-chave “IA” (para inter-área). Observe que o roteador R1
seleciona R2 como o ABR de saída para alcançar todos os destinos externos, pois o
próximo salto é 222.222.10.2 para todas as entradas correspondentes. O custo do
caminho mais curto é 15+10=25 para 222.222.30.0/24 e para o ASBR, e é 15+10+10=35 para 222.222.4
O custo do caminho para os mesmos destinos via roteador R3 é 10+30=40 para
222.222.40.0/24 e para o ASBR, e é 10+30+10=50 para 222.222.30.0/24.
A entrada relativa ao prefixo externo ao domínio (150.150.0.0/16) é identificada pela
palavra-chave “E2”, como no caso de redes unilaterais.

FIGURA 11.7: Estrutura LSDB do IS-IS hierárquico - L1 LSDB.
11.1.3 Estrutura IS-IS LSDB

A estrutura LSDB das redes hierárquicas IS-IS foi abordada na Seção 7.3.2. O experimento desta
seção é baseado na topologia de rede da Figura 11.1. As Figuras 11.7 e 11.8 mostram o L1 e L2
LSDB do roteador R2. Pode ser obtido através do comando show isis database detail.
O L1 LSDB inclui os LSPs que descrevem a área de nível inferior, que são os Nonpseudonode-
LSPs R1.00-00, R2.00-00 e R3.00-00, e os Pseudonode-LSPs R2.01-00 e R3.01-00. Da mesma
forma, o L2 LSDB inclui

!"#
!"#
$
!"# !"# $$ %
!"# !"#
!"# !"#
FIGURA 11.8: Estrutura LSDB do IS-IS hierárquico - L2 LSDB.
os LSPs que descrevem o backbone, ou seja, os Nonpseudonode-LSPs R2.00-00, R3.00-00 e

R4.00-00, e os Pseudonode-LSPs R4.01-00 e R4.02-00.
Informação topológica Primeiro nos concentramos na informação topológica, que é fornecida
pelos TLVs Extended IS Reachability (identificados no display através da palavra-chave “IS-
Extended” que segue o valor Metric).
Os IDs LSP dos Pseudonode-LSPs revelam que o DIS em cada link compartilhado é sempre o
roteador com SID mais alto, ou seja, R2 no link R2-R1 (o ID do LSP é R2.01-00), R3 no link R3-R1
(ID LSP é R3.01-00), R4 no link R4-R2 (ID LSP é R4.01-00) e R4 no link R4-R3 (ID LSP é
R4.02-00).
A informação topológica descreve apenas a área a que se refere. Observe que

o L1 LSDB não inclui as descrições do roteador R4 (R4.00-00) e dos links R4-R2 (R4.01-00) e R4-R3
(R4.02-00). Da mesma forma, o L2 LSDB não inclui as descrições do roteador R1 (R1.00-00) e dos
links R2-R1 (R2.01-00) e R3-R1 (R3.01-00). R3 e R2, uma vez que são roteadores L1/L2, possuem
Nonpseudonode-LSPs tanto no L1 quanto no L2 LSDB. Porém, no L1 LSDB são representadas
apenas as interfaces com área de nível inferior, e no L2 LSDB são representadas apenas as
interfaces com backbone. No L1 LSDB, R2.00-00 descreve apenas a interface com R2.01-00 e
R3.00-00 descreve apenas a interface com R3.01-00. Da mesma forma, no L2 LSDB, R2.00-00
descreve apenas a interface com R4.01-00 e R3.00-00 descreve apenas a interface com R4.02-00.
Assim, como no caso do OSPF, as informações topológicas são mantidas dentro de áreas.
O bit ATT é usado para indicar, dentro de uma área de nível inferior, se um roteador é um
roteador L1/L2. Observe que este bit é definido nos Nonpseudonode-LSPs originados por R2
(R2.00-00) e R3 (R3.00-00) na área 1 (Figura 11.7).
Informações de endereçamento As informações de endereçamento são identificadas através das
palavras-chave “IP” e “IP-Interarea” que seguem o valor da Métrica. Embora isso não esteja claro
no visor, todos os prefixos são anunciados por meio de TLVs de alcance de IP estendido (tipo 135),
sejam eles de área interna, área externa ou domínio externo; você pode verificar isso usando Wire
shark. A palavra-chave “IP-Interarea” é atribuída a prefixos redistribuídos do L2 LSDB para o L1
LSDB. Esses prefixos são o prefixo externo de domínio 150.150.0.0/16 e os prefixos externos de
área 222.222.30.0/24 e 222.222.40.0/24. Os TLVs que os anunciam têm o bit Up/Down definido
como 1. O valor Metric é o custo do caminho do roteador L1/L2 de origem até o destino. Por exemplo,
R3 anuncia um custo de 40 para 222.222.30.0/24, que é o custo do caminho R3 ÿ R4 ÿ
222.222.30.0/24 (custo de interface f0/1 de R3 + custo de interface f0/0 de R4) . R2 anuncia um
custo de caminho de 10 para a mesma sub-rede, pois o caminho inclui apenas a interface f0/1 de R2,
que tem um custo de 10.
Os prefixos redistribuídos na direção oposta, ou seja, do L1 LSDB para o L2 LSDB, são

indistinguíveis dos prefixos internos da área. Por exemplo, no L2 LSDB o Nonpseudonode-LSP de
R3 (Figura 11.8), anuncia da mesma forma os prefixos de área externa 222.222.10.0/24 e
222.222.20.0/24, com custos de caminho 25 e 10, respectivamente, e o prefixo de área interna
222.222.40.0/24, com custo de caminho 30 (este custo de caminho coincide com o custo da interface
f0/1 de R3). Observe também que, como já apontado para o caso de redes de área única, um prefixo
atribuído a um link compartilhado é anunciado por todos os roteadores conectados a ele. Por
exemplo, o prefixo 222.222.40.0/24 é anunciado no Nonpseudonode-LSP de R3 (com custo 30) e no
Nonpseudonode LSP de R4 (com custo 10).
No L1 LSDB (Figura 11.7), os prefixos interno e externo da área são diferenciados pelo bit Up/
Down. Os prefixos internos da área de publicidade dos TLVs (ou seja, 222.222.10.0/24 e
222.222.20.0/24) têm o bit Up/Down apagado.
Tabela de encaminhamento do roteador R1 A tabela de encaminhamento do roteador R1 é mostrada

FIGURA 11.9: Estrutura LSDB do IS-IS hierárquico - Tabela de encaminhamento do

roteador R1.
na Figura 11.9. As rotas para os vários destinos são as mesmas do OSPF (consulte a
Seção 11.1.2). O roteador R2 é novamente o ABR usado para alcançar todos os destinos
externos. A palavra-chave “ia” indica que a entrada correspondente é um caminho entre
áreas. Observe que não há distinção entre os prefixos externo de área e externo de
domínio. A última entrada é uma rota padrão (0.0.0.0/0), que o IS-IS sempre inclui na
tabela de encaminhamento dos roteadores internos das áreas L1 quando a área inclui
roteadores L1/L2. A entrada aponta para o roteador L1/L2 mais próximo (no sentido do
caminho mais curto), que neste caso é R3.
11.2 Restrições na seleção do caminho mais curto

Nesta seção, ilustramos as consequências de restringir o processo de seleção do
caminho mais curto. As restrições são semelhantes em OSPF e IS-IS, e vamos mostrá-
las usando o OSPFv2 como exemplo. Conforme discutido na Seção 7.4, os vetores de
distância originados pelos ABRs não podem anunciar dentro de uma área (i) rotas para
destinos internos à área e (ii) rotas para destinos externos à área que cruzam aquela
área. Além disso, (iii) ao construir as tabelas de encaminhamento, os roteadores preferem
as rotas intra-área sobre as inter-área. Essas restrições às vezes podem levar à seleção
de caminho não ideal.
Configuração experimental O experimento é baseado na topologia de rede da Figura
11.10. A rede tem duas áreas. Os roteadores R1 e R2 são internos à área 1 e os
roteadores R3 e R4 são ABRs. As sub-redes 222.222.10.0/24, 222.222.20.0/24 e
222.222.30.0/24 pertencem à área 1 e a sub-rede 222.222.40.0/24 pertence à área 0.
Todas as interfaces têm custo 10, exceto a interface s0/0 do roteador R2 , que deve ser
configurado com um custo de 100.
Resultado experimental A tabela de encaminhamento de R2 (Figura 11.11.a) mostra que
R2 não está usando o caminho mais curto para 222.222.20.0/24. O caminho selecionado
é via R1 (o próximo salto é 222.222.10.1) com um custo de 110, mas o caminho mais
curto é via R4 com um custo de 30. Na verdade, os ABRs (R3 e R4) não podem anunciar
222.222. 20.0/24 na área 1 usando Network-Summary-LSAs, mesmo que tenham
informações sobre isso. A Figura 11.11.b mostra o conteúdo completo

FIGURA 11.10: Experimentos relacionados às restrições na seleção do caminho

mais curto - topologia de rede.
do Network-Summary-LSAs de área 0 referente a 222.222.20.0/24. Esses LSAs são

armazenados em R3 e R4. O primeiro LSA é originado por R3 e indica que R3
fornece um custo de 10 a 222.222.20.0/24. O segundo LSA indica que R4 fornece
um custo de 120 para o mesmo prefixo. Assim, R4 sabe que pode fornecer um custo
de 10+10=20 para 222.222.20.0/24, mas não tem permissão para injetar essa
informação na área 1. Isso pode ser confirmado na Figura 11.11.c, que mostra
informações resumidas sobre o Network-Summary-LSAs da área 1 (obtido através
do comando show ip ospf database summary). Pode-se ver que apenas o prefixo
externo de área (222.222.40.0/24) é anunciado por meio desses LSAs.
Observe também a decisão tomada pelo R4. Como já mencionado, o R4 tem

acesso às duas rotas de si mesmo para 222.222.20.0/24. De um lado, ele está
diretamente ligado à área 1 e sabe, pelo LSDB dessa área, que o custo do caminho
intra-área de si para 222.222.20.0/24 é 120. Por outro lado, R4 recebeu um Network
-Resumo-LSA do R3 anunciando um custo de 10 para 222.222.20.0/24 e, a partir
dessa informação, determina que existe um caminho interárea para o prefixo com
custo 20. Porém, conforme tabela de encaminhamento da Figura 11.11.d, R4
seleciona o caminho de maior custo (via R2).
Isso porque, ao construir sua tabela de encaminhamento, o roteador considera
primeiro as rotas intra-área e, somente se não houver, considera as rotas inter-área.
Consequências do desligamento da interface s0/0 de R2 Agora, vamos desligar a
interface s0/0 de R2. Podemos fazer isso digitando o comando desligar na interface
s0/0. A Figura 11.12 mostra as tabelas de encaminhamento resultantes

FIGURA 11.11: Restrições na seleção do caminho mais curto - (a) Tabela de

encaminhamento de R2, (b) Network-Summary-LSAs de área 0 relativa a 222.222.20.0/24,
(c) Informações resumidas sobre os Network-Summary-LSAs de área 1, (d)
Tabela de encaminhamento de R4.
dos roteadores R2 e R4, e o conteúdo completo do Network-Summary LSA relativo a

222.222.20.0/24 incluído no LSDB de R2. Quando a interface é desligada, a área 1 torna-
se particionada e o roteador R4 deixa de receber informações de roteamento relativas a
222.222.20.0/24 via R2. R4 tem acesso apenas ao caminho entre áreas (via R3) e,
conforme mostra a Figura 11.12.b, armazena esse caminho em sua tabela de
encaminhamento. Além disso, da perspectiva de R4, 222.222.20.0/24 não pertence mais
a uma área diretamente anexada. Assim, R4 pode anunciar o prefixo para R2 (através
de sua interface s0/0). O Network-Summary-LSA correspondente é mostrado na Figura
11.12.c. Baseia-se

FIGURA 11.12: Restrições na seleção do caminho mais curto, após o desligamento da

interface s0/0 de R2 - (a) Tabela de encaminhamento de R2, (b) Tabela de
encaminhamento de R4, (c) Network-Summary-LSA de R2 relativo a 222.222.20.0 /24.
neste LSA que o R2 instala em sua tabela de encaminhamento um caminho entre áreas
para 222.222.20.0/24 com custo 30, conforme Figura 11.12.a. Assim, o caminho mais
curto de R2 para 222.222.20.0/24 foi finalmente instalado quando o caminho intra-área
quebrou!

Glossário
ABR (Area Border Router): roteador OSPF localizado na fronteira entre áreas; chamado L1/
L2 em IS-IS (página 20).
ABR overlay: rede lógica de ABRs usada para a troca de informações de roteamento entre
áreas (página 116).
Proteção ACK: protege a transmissão de um pacote forçando o receptor a confirmar a

recepção correta do pacote (página 36).
bloco de endereços: grupo de endereços contíguos caracterizados por um prefixo comum

(página 8).
ACK (DELETE): designação genérica de mensagem de controle que reconhece o recebimento

de indicações de exclusão de NR; consulte a Figura 6.1 para correspondência com OSPF
e IS-IS (página 101).
ACK (UPDATE): designação genérica de mensagem de controle que reconhece a recepção

de instâncias NR; consulte a Figura 6.1 para correspondência com OSPF e IS-IS (página
101).
informações de endereçamento: informações sobre prefixos de endereço, ou seja, prefixos

IPv4 ou IPv6 (página 43).
vizinhos adjacentes: vizinhos cuja conexão preencheu todas as condições para fazer parte do
mapa da rede (página 188).
aep-NR (area-external-prefix-NR): designação genérica de NR que descreve um prefixo de

endereço externo a uma área; consulte a Figura 5.2 para correspondência com OSPF e
IS-IS (página 122).
aip-NR (area-internal-prefix-NR): designação genérica de NR que descreve um prefixo de

endereço interno a uma área; consulte a Figura 5.2 para correspondência com OSPF e
IS-IS (página 70).
AR (Advertising Router): roteador que origina um LSA/LSP, e inicia

sua inundação; igual ao roteador de origem (página 148).
Endereços de área TLV: IS-IS TLV que lista todos os IDs de área atribuídos ao roteador de
origem (página 168).
Area ID (AID): identificador de uma área (pág. 151).
387

388 Glossário
abrangência de alagamento de área: refere-se ao alagamento de um NR/LSA/LSP somente dentro

de uma área (pág. 120).
constantes arquitetônicas: parâmetros de protocolo que são fixados pela especificação e não
podem ser alterados pelo gerenciador de rede (página 145).
AS (Autonomous System): domínio administrativo da Internet, geralmente sob responsabilidade

de uma única administração (por exemplo, um ISP) e possuindo política de roteamento
própria; pode incluir um ou mais domínios de roteamento (página 19).
ASBR (Autonomous System Border Router): roteador localizado no

fronteira entre Sistemas Autônomos (página 19).
ASBR-Summary-LSA: OSPFv2 LSA que descreve um ASBR externo ao

uma área; equivalente a dbr-NR (página 242).
AS-External-LSA: OSPFv2 e OSPFv3 LSA que descreve um prefixo de endereço externo a um

domínio de roteamento; equivalente a dep-NR (página 175).
backbone: área de nível superior de redes hierárquicas (página 143).
BDR (Backup Designated Router): roteador que substitui o DR em caso de falha do DR, em OSPF
(página 152).
inicialização a frio: iniciando um algoritmo distribuído ligando todos os seus elementos

simultaneamente (página 35).
gráfico de conectividade: gráfico da conectividade expressa pelo mapa da rede (página 58).
rede convergente: uma rede em um estado estável (página 250).
CSNP (COMPLETE SEQUENCE NUMBER PDU): pacote de controle IS-IS que transmite os resumos
de todos os LSPs contidos em um LSDB para um roteador vizinho; equivalente a LSDB
SUMMARY (página 181).
DB DESCRIÇÃO: Pacote de controle OSPF que transmite os resumos de todos os LSAs contidos
em um LSDB para um roteador vizinho; equivalente a LSDB SUMMARY (página 181).
DBR (Domain Border Router): roteador localizado na fronteira entre domínios de roteamento
(página 19).
dbr-NR (domain-border-router-NR): designação genérica de NR que descreve um roteador de

borda de domínio externo a uma área; consulte a Figura 5.2 para correspondência com OSPF
e IS-IS (página 138).
DELETE: designação genérica de mensagem de controle que transporta indicações de exclusão

de NR para roteadores vizinhos; consulte a Figura 6.1 para correspondência com OSPF e IS-
IS (página 101).

Glossário 389
dep-NR (domain-external-prefix-NR): designação genérica de NR que descreve um prefixo de

endereço externo a um domínio de roteamento; consulte a Figura 5.2 para correspondência
com OSPF e IS-IS (página 82).
DIS (Designated Intermediate System): roteador eleito em um link compartilhado

para representar o link (designação IS-IS) (página 152).
escopo de inundação de domínio: refere-se à inundação de um NR/LSA/LSP através

todo o domínio de roteamento (página 120).
DR (Designated Router): roteador eleito em um link compartilhado para representar o link

(designação genérica e OSPF) (pág. 56).
DVR (Distance Vector Routing): abordagem de roteamento em que os roteadores calculam

seus caminhos com base nas informações fornecidas por seus vizinhos e no conhecimento
do estado dos links com esses vizinhos (página 129).
Dynamic Hostname TLV: IS-IS TLV que associa o SID a um nome codificado em ASCII
(página 169).
Extended IP Reachability TLV: IPv4 IS-IS TLV com métricas estendidas que representam
prefixos de endereços internos a uma área (equivalente a aip-NR), prefixos de endereços
externos a uma área (equivalente a aep-NR) ou prefixos de endereços externos a um
roteamento domínio (equivalente a dep-NR) (página 163).
Extended IS Reachability TLV: IS-IS (IPv4 e IPv6) TLV com métricas estendidas que
descrevem os vizinhos de um roteador ou link de trânsito compartilhado (pseudonó);
equivalente a router-NR quando incluído em um Nonpseudonode-LSP e a um slink-NR
quando incluído em um Pseudonode LSP (página 163).
escopo flooding: zona da rede onde uma mensagem de controle é disseminada

(página 99).
tabela de encaminhamento (camada-3): tabela que indica em um roteador como encaminhar

pacotes para a próxima interface do roteador ou interface do host (página 5).
vizinhos totalmente adjacentes: vizinhos que sincronizaram seus LSDBs

(página 188).
HELLO: designação genérica (página 45), OSPF (página 180) e IS-IS (página 180) de
mensagem de controle transmitida periodicamente para roteadores vizinhos, para
estabelecer e manter relacionamentos de vizinhança; IS-IS tem diferentes tipos de
pacotes HELLO: POINT-TO-POINT IS-IS HELLO (página 180), LAN IS-IS HELLO (página
180), L1 HELLO (página 189) e L2 HELLO (página 189); veja a Figura 6.1 para
correspondência com OSPF e IS-IS.
rede hierárquica: rede estruturada em áreas, onde as áreas são organizadas em níveis com
relação hierárquica entre si (pág. 143).

390 Glossário
hosts: dispositivos finais que são as fontes e sumidouros de informações (por exemplo, lap
tops, tablets, servidores, sensores, atuadores) (página 3).
interface de entrada: parte de uma interface que recebe pacotes (do link para o equipamento)
(página 3).
Inter-Area-Prefix-LSA: OSPFv3 LSA que descreve um prefixo de endereço ex

externo a uma área; equivalente a aep-NR (página 241).
Intra-Area-Prefix-LSA: OSPFv3 LSA que descreve um prefixo de endereço em

externo a uma área; equivalente a aip-NR (página 171).
caminho entre áreas: um caminho que cruza mais de uma área (página 134).
Inter-Area-Router-LSA: OSPFv3 LSA que descreve um ASBR externo

para uma área; equivalente a dbr-NR (página 242).
protocolo de roteamento entre áreas: protocolo de roteamento que é executado na borda da área
roteadores para determinar caminhos entre áreas (página 20).
protocolo de roteamento inter-AS: protocolo de roteamento que é executado em ASBRs para

determinar caminhos de mineração entre ASes (o BGP é o padrão de fato para esse tipo de
protocolo) (página 19).
protocolo de roteamento entre domínios: protocolo de roteamento executado em roteadores de

borda de domínio para determinar caminhos entre domínios de roteamento (página 19).
regras de aceitação de interface: regras que definem se um pacote de controle pode ser aceito
por uma interface receptora (página 184).
caminho intra-área: um caminho que cruza apenas elementos de rede de uma área (página
134).
protocolo de roteamento intradomínio: protocolo de roteamento executado dentro de um domínio

de roteamento para determinar caminhos dentro do domínio (por exemplo, OSPF e IS-IS)
(página 19).
IOS (Internetwork Operating System): sistema operacional dos roteadores Cisco

(página 253).
IP Interface Address TLV: IS-IS TLV que lista os endereços IPv4 como
assinado para as interfaces IS-IS do roteador de origem (página 169).
IPv6 Interface Address TLV: IS-IS TLV que lista os endereços IPv6 como
assinado para as interfaces IS-IS do roteador de origem (página 169).
IP External Reachability Information TLV: IPv4 IS-IS TLV que descreve um prefixo de endereço
externo a um domínio de roteamento; equivalente a dep NR (página 175).

Glossário 391
IP Internal Reachability Information TLV: IPv4 IS-IS TLV que representa prefixos de endereços
internos a uma área (equivalente a aip-NR) ou prefixos de endereços externos a uma área
(equivalente a aep-NR) (página 163).
IPv6 Reachability TLV: IPv6 IS-IS TLV que representa prefixos de endereços internos a uma área
(equivalente a aip-NR), prefixos de endereços externos a uma área (equivalente a aep-NR)
ou prefixos de endereços externos a um domínio de roteamento (equivalente a dep-NR)
(página 163).
IS Neighbors TLV (tipo 2): IS-IS (IPv4 e IPv6) TLV que descreve os vizinhos de um roteador ou
link compartilhado de trânsito (pseudonó); equivalente a router-NR quando incluído em um
Nonpseudonode-LSP e a um slink-NR quando incluído em um Pseudonode-LSP (página 163).
IS Neighbours TLV (tipo 6): IS-IS TLV que descreve interfaces vizinhas em links compartilhados,
usando seus endereços MAC (página 186).
Roteador L1/L2: roteador IS-IS que suporta interfaces somente L1, somente L2 e L1/L2 e está
localizado na borda entre as áreas; chamado ABR em OSPF (página 145).
Interface somente L1: interface do roteador IS-IS que apenas transmite/recebe pacotes de controle
L1 (página 144).
Interface somente L2: interface do roteador IS-IS que apenas transmite/recebe pacotes de controle
L2 (página 144).
Interface L1/L2: interface do roteador IS-IS que transmite/recebe pacotes de controle L1 e L2

(página 144).
Roteador L1: roteador IS-IS que suporta apenas interfaces somente L1 (página 145).
Subdomínio L2: área de nível superior do IS-IS, também chamada de backbone (página 143).
Roteador L2: roteador IS-IS que suporta apenas interfaces somente L2 (página 145).
LAN ID: campo de pacotes IS-IS LAN HELLO que identifica o DIS, usando
seu SID e Pseudonode ID (página 201).
la-NR (link-address-NR): designação genérica de NR que descreve os endereços fornecidos pelo

roteador do próximo salto para comunicações dentro do link; consulte a Figura 5.2 para
correspondência com OSPF e IS-IS (página 77).
link da camada 2: link lógico entre os dispositivos da camada 3 (hosts ou roteadores); pode
corresponder a um link ponto a ponto ou a uma rede de camada 2 relativamente complexa
(página 13).
switch de camada 2: equipamento de comutação que encaminha pacotes de acordo com

endereços da camada 2 (por exemplo, endereços MAC) (página 14).

392 Glossário
informações de link: informações sobre os endereços usados para transportar pacotes

entre roteadores vizinhos (página 43).
escopo de inundação de link: refere-se à inundação de um NR/LSA/LSP somente dentro de

um link (página 77).
Link-LSA: OSPFv3 LSA que descreve endereços fornecidos pelo roteador de próximo salto
para comunicações dentro do link; equivalente a la-NR (página 177).
LINK STATE PDU (pacote LSP): pacote de controle IS-IS que transmite uma instância LSP
para um roteador vizinho; equivalente a UPDATE e não deve ser confundido com
registro LSP (página 181).
LSA (Link State Advertisement): elemento de um OSPF LSDB, que contém informações de
roteamento elementares e é indivisível do ponto de vista do flooding; equivalente a NR
(página 148).
LS ACKNOWLEDGMENT: pacote de controle OSPF que reconhece o recebimento de

instâncias LSA; equivalente a ACK (UPDATE) (página 181).
LSA ID: identificador do LSA (página 155).
LSDB (Link State Database): banco de dados que armazena as informações de roteamento
(página 43).
LSDB SUMMARY: designação genérica de mensagem de controle que transmite os resumos

de todos os NRs contidos em um LSDB para roteadores vizinhos; consulte a Figura 6.1
para correspondência com OSPF e IS-IS (página 108).
LSDB SUMMARY REQUEST: designação genérica de mensagem de controle que solicita

NRs de roteadores vizinhos; consulte a Figura 6.1 para correspondência com OSPF e
LSP (Link State PDU): elemento do IS-IS LSDB, que é um container de TLVs, e é indivisível
do ponto de vista do flooding; não deve ser confundido com pacote LSP (página 148).
LSP Entries TLV: IS-IS TLV que anuncia resumos LSP em pacotes de controle PSNPs e
CSNPs (página 183).
LSP ID: identificador do LSP, consistindo em SID, Pseudonode ID e LSP Number (página
156).
LSP Number: campo que identifica exclusivamente um fragmento LSP, parte do LSP ID
(página 156).
LSR (Link State Routing): abordagem de roteamento onde os roteadores trocam informações
para construir e manter um mapa da rede completa e nos prefixos de endereços
disponíveis (página 21).

Glossário 393
LS REQUEST: pacote de controle OSPF que solicita LSAs de roteadores vizinhos; equivalente
a PARTIAL LSDB REQUEST (página 181).
LS UPDATE: pacote de controle OSPF que transmite instâncias LSA para neigh
roteadores chatos; equivalente a UPDATE (página 181).
NET (Network Entity Title): identificador completo de um roteador IS-IS, que inclui seu
identificador de área (página 151).
mapa de rede: parte do LSDB que representa a topologia da rede (página

43).
Network-LSA: OSPFv2 e OSPFv3 LSA que descreve um link compartilhado de trânsito; em

OSPFv2 também descreve o prefixo atribuído a um link compartilhado de trânsito;
equivalente a slink-NR e, em OSPFv2, também equivalente a aip-NR (página 160).
Network-Summary-LSA: OSPFv2 LSA que descreve um prefixo de endereço externo a uma

área; equivalente a aep-NR (página 240).
Node ID: identificador de um vizinho no IS-IS, composto pelo SID e pelo

ID do pseudonó (página 164).
Nonpseudonode-LSP: LSP que descreve um roteador, seus links e os prefixos de endereços

atribuídos ao roteador e seus links (página 148).
NR (Network Record): designação genérica de um pedaço do LSDB; equivalente a LSA em

OSPF e TLV em IS-IS, de uma perspectiva de informações de roteamento (página 50).
roteador de origem: roteador responsável por criar, atualizar, excluir e

divulgar uma NR/LSA/LSP (página 50).
interface de saída: parte de uma interface que transmite pacotes (do equip
mento para link) (página 3).
PARTIAL LSDB REQUEST: designação genérica de mensagem de controle que solicita

instâncias NR de um roteador vizinho; consulte a Figura 6.1 para correspondência com
OSPF e IS-IS (página 108).
prefixo: bits de ordem superior (mais à esquerda) de um endereço (página 8).
Protocolos suportados TLV: IS-IS TLV que identifica os protocolos da camada de rede
suportados pelo roteador de origem (página 168).
link ponto a ponto: link que conecta dois, e apenas dois, dispositivos da camada 3
(página 31).
TLV de adjacência de três vias ponto a ponto: IS-IS TLV que anuncia o estado de uma
interface de link ponto a ponto, como Down, Initializing ou Up (página 192).

394 Glossário
Pseudonode ID: tag local atribuído pelo DIS para diferenciar entre enlaces compartilhados de trânsito,
que faz parte do identificador de enlace compartilhado e do LSP ID (página 152).
Pseudonode-LSP: LSP que descreve um link compartilhado de trânsito, topologicamente

(página 148).
PSNP (PARTIAL SEQUENCE NUMBER PDU): Pacote de controle IS-IS utilizado no reconhecimento
(enlaces ponto a ponto) e na requisição de instâncias LSP (enlaces compartilhados); equivalente
a ACK (UPDATE) e PARTIAL LSDB REQUEST (página 181).
RID (Router ID): identificador do roteador OSPF (página 149).
roteador: equipamento de comutação que encaminha pacotes de acordo com o anúncio da camada 3
vestidos (por exemplo, endereços IPv4 e IPv6) (página 3).
Router-LSA: OSPFv2 e OSPFv3 LSA que descreve um roteador e seus links anexados; no OSPFv2
também descreve os prefixos atribuídos ao roteador e seus links; equivalente a router-NR e, em
OSPFv2, também equivalente a aip-NR (página 157).
roteador-NR: designação genérica de NR que descreve um roteador e seus enlaces; consulte a Figura
5.2 para correspondência com OSPF e IS-IS (página 64).
domínio de roteamento: um domínio pertencente a uma única administração e executando um único

protocolo de roteamento (página 19).
informações de roteamento: informações necessárias para construir as tabelas de encaminhamento

do roteador (página 43).
protocolo de roteamento: algoritmo distribuído que é executado em equipamentos de comutação e

coopera por meio da troca de mensagens de controle para determinar caminhos dentro de uma
rede (página 7).
princípio de separação: separação entre os vários tipos de roteamento em formação presentes no

LSDB — uma boa prática de projeto (página 68).
link compartilhado: link que abstrai uma rede de camada 2 e pode potencialmente
conecte muitos dispositivos de camada 3 (página 31).
SID (System ID): identificador do roteador IS-IS de área específica (página 151).
slink-NR (shared-link-NR): designação genérica de NR que descreve um link compartilhado; consulte

a Figura 5.2 para correspondência com OSPF e IS-IS (página 64).
SN (Sequence Number): número inteiro que é incrementado sequencialmente para expressar a

atualização de NRs/LSAs/LSPs (página 96).
link compartilhado stub: link compartilhado com apenas um roteador conectado (página 32).

Glossário 395
sub-rede: rede lógica reunindo um bloco de endereços IP contíguos que compartilham um prefixo
comum e atribuídos a interfaces que podem se comunicar entre si sem a intervenção de um
roteador (página 15).
Protocolo Stop-and-Wait (SW): protocolo de controle de erros onde a recepção de uma mensagem
deve ser confirmada, sendo que a transmissão da próxima mensagem só é possível após o
recebimento da confirmação da anterior (página 36).
equipamento de comutação: equipamento que transfere pacotes de interfaces de entrada para

interfaces de saída de acordo com as tabelas de encaminhamento (por exemplo, roteadores e
switches de camada 2) (página 3).
TLV (Type-Length-Value): registro de comprimento variável que inclui informações sobre seu tipo e
comprimento além do conteúdo real (página 156).
elementos topológicos: os elementos que definem a topologia da rede, ou seja, os roteadores e os

links (página 51).
identificadores topológicos: identificadores de roteadores e links (página 68).
informações topológicas: informações sobre a topologia da rede, ou seja, sobre os roteadores e links
entre roteadores (página 43).
link compartilhado de trânsito: link compartilhado com mais de um roteador conectado (página
32).
UPDATE: designação genérica de mensagem de controle que transporta NR em instâncias (conteúdo

completo) para roteadores vizinhos; consulte a Figura 6.1 para correspondência com OSPF e


Referências
[1] Tecnologia da informação Telecomunicações e troca de informações entre

sistemas Intermediate System protocolo de troca de informações de roteamento
intra-domínio para uso em conjunto com o protocolo para fornecer o serviço de
rede no modo sem conexão (ISO 8473). ISO/IEC 10589, novembro de 2002.
[2] Roteamento IP: Guia de configuração ISIS, Cisco IOS XE Release 3SE (Cat
alyst 3650 Switches). Sistemas Cisco, 2013.
[3] P. Albitz e C. Liu. DNS e BIND. O'Reilly Media, 5ª edição, 2009.
[4] R. Albrightson, J. Garcia-Luna-Aceves e J. Boyle. EIGRP-Um protocolo de

roteamento rápido baseado em vetores de distância. Em Interop 94, 1994.
[5] D. Allan e N. Bragg. 802.1aq Projeto de ponte de caminho mais curto e Evo
solução: A Perspectiva do Arquiteto. Wiley, 2012.
[6] D. Bertsekas e R. Gallager. Redes de Dados. Prentice-Hall, 2ª edição,

1992.
[7] R. Callon. Uso de OSI IS-IS para roteamento em TCP/IP e ambientes duplos.
RFC 1195, dezembro de 1990.
[8] R. Coltun, D. Ferguson, J. Moy e A. Lindem. OSPF para IPv6. RFC 5340, julho
de 2008.
[9] D. Comer. Internetworking com TCP/IP: Princípios, Protocolos e Arquiteturas.

Prentice Hall, 4ª edição, 2000.
[10] J. Day. Padrões na arquitetura de rede: um retorno aos fundamentos.

PrenticeHall, 2008.
[11] J. Doyle. OSPF e IS-IS: Escolhendo um IGP para Redes de Grande Escala.
Addison Wesley, 2006.
[12] B. Edgeworth, A. Foss e R. Garza Rios. Roteamento IP no Cisco IOS, IOS XE

e IOS XR: um guia essencial para entender e implementar protocolos de
roteamento IP. Cisco Press, 2005.
[13] J. Garcia-Lunes-Aceves. Roteamento sem loop usando cálculos difusos.

IEEE/ACM Transactions on Networking, 1(1):130–141, fevereiro de 1993.
397

398 Referências
[14] R. Graziani. Fundamentos do IPv6: uma abordagem direta para entender o IPv6.
Cisco Press, 2013.
[15] H. Gredler e W. Goralski. O Protocolo de Roteamento IS-IS Completo.

Springer, 2005.
[16] A. Gurtov. Host Identity Protocol (HIP): Rumo ao Mobile Seguro

Internet. Wiley, 2008.
[17] S. Hagen. IPv6 Essentials. O'Reilly, 2ª edição, 2006.
[18] S. Halabi. Arquiteturas de roteamento da Internet. Cisco Press, 2ª edição, 2001.
[19] J. Harrison, J. Berger e M. Bartlett. Engenharia de Tráfego IPv6 em IS-IS.

RFC 6119, fevereiro de 2011.
[20] C. Hopps. Roteamento IPv6 com IS-IS. RFC 5308, outubro de 2008.
[21] K. Ishiguro, V. Manral, A. Davey e A. Lindem. Engenharia de Tráfego

Extensões para OSPF Versão 3, setembro de 2008.
[22] A. Johnston. SIP: Entendendo o Protocolo de Iniciação de Sessão. artech

Câmara, 3ª edição, 2009.
[23] D. Katz, K. Kompella e D. Yeung. Extensões de Engenharia de Tráfego (TE) para

OSPF Versão 2. RFC 3630, setembro de 2003.
[24] D. Katz e R. Saluja. Handshake de três vias para adjacências ponto a ponto de
sistema intermediário a sistema intermediário (IS-IS). RFC 3373, setembro de 2002.
[25] D. Katz, R. Saluja e D. Eastlake 3º. Handshake de três vias para adjacências ponto
a ponto IS-IS. RFC 5303, outubro de 2008.
[26] Z. Kou, F. Yang e H. Ma. Atualize para o procedimento OSPF Hello. Internet
rascunho, dezembro de 2006.
[27] J. Kurose e K. Ross. Redes de computadores: uma abordagem de cima para baixo.
Addison Wesley, 6ª edição, 2013.
[28] T. Li, T. Przygienda e H. Smit. Distribuição de prefixo em todo o domínio com IS-IS
de dois níveis. RFC 2966, fevereiro de 2000.
[29] T. Li e H. Smit. Extensões IS-IS para Engenharia de Tráfego. RFC 5305, outubro
de 2008.
[30] G. Malkin. RIP Versão 2. RFC 2453, novembro de 1998.
[31] A. Martey. Soluções de design de rede IS-IS. Cisco Press, 2002.

Referências 399
[32] J. McQuillan, I. Richer e E. Rosen. O novo algoritmo de roteamento para a ARPANET.

IEEE Transactions on Communications, 28(5), maio de 1980.
[33] D. Medhi e K. Ramasamy. Algoritmos, protocolos e arquiteturas de roteamento de

rede. Morgan Kaufmann, 2007.
[34] J. Moy. Extensões Multicast para OSPF. RFC 1584, março de 1994.
[35] J. Moy. Anatomia de um protocolo de roteamento da Internet. Addison Wesley, 1998.
[36] J. Moy. OSPF versão 2. RFC 2328, abril de 1998.
[37] J. Moy. Implementação completa do OSPF. Addison Wesley, 2001.
[38] C. Murthy e B. Manoj. Arquiteturas e protocolos de redes sem fio ad hoc. Prentice-
Hall, 2004.
[39] T. Narten, E. Nordmark e W. Simpson. Descoberta de vizinhos para IP versão 6

(IPv6). RFC 2461, dezembro de 1998.
[40] R. Perlman. Transmissão tolerante a falhas de informações de roteamento. Computer

Networks, 7:395–405, 1983.
[41] R. Perlman. Interconexões - Bridges, Roteadores, Switches e Internet

protocolos de trabalho. Addison Wesley, 2000.
[42] L. Peterson e B. Davie. Redes de Computadores: uma Abordagem de Sistemas.

Morgan Kaufmann, 5ª edição, 2012.
[43] D. Plummer. Um protocolo de resolução de endereços Ethernet. RFC 826, RFC

Editor, novembro de 1982.
[44] T. Przygienda, N. Shen e N. Sheth. M-ISIS: Multi Topologia (MT)

Roteamento em Sistema Intermediário para Sistemas Intermediários (IS-ISs). RFC
5120, fevereiro de 2008.
[45] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen e P. Pillay-Esnault. Roteamento Multi

Topologia (MT) em OSPF. RFC 4915, junho de 2007.
[46] Y. Rekhter, T. Li e S. Hares. Um protocolo de gateway de borda 4 (BGP-4).

RFC 4271, janeiro de 2006.
[47] J. Saltzer. Sobre a nomenclatura e vinculação de destinos de rede. RFC 1498,

agosto de 1993.
[48] N. Shen e H. Smit. Mecanismo dinâmico de troca de nomes de host para IS-IS.
RFC 2763, fevereiro de 2000.
[49] J. Shoch. Nomenclatura, endereçamento e roteamento entre redes. Em IEEE Pro

ceedings COMPCON, páginas 72–79, 1978.

400 Referências
[50] T. Tomás. Soluções de design de rede OSPF. Cisco Press, 2ª edição,

2003.
[51] R. Valadas. Extensão OSPF para suporte a redes multiárea com

topologias arbitrárias. arXiv 1704.08916, abril de 2017.
[52] I. van Beijnum. BGP. O'Reilly, 2002.

Índice
ABR ( Area Border Router ) _ _ _ _ _ _ _ _ Roteador), 19, 79, 144,

______ 174–176, 242, 295, 300, 302,
310, 379
ASBR-Resumo-LSA, 242, 379
Sobreposição ABR, 116, 119, 125, 127, 131,
134, 135 Espinha dorsal, 143–145, 235, 237, 238,
ACK (EXCLUIR), 101, 113 243, 373, 381
ACK (ATUALIZAÇÃO), 101, 112 BDR (roteador designado de backup),
Proteção ACK, 36, 98, 108, 203, 206, 152, 191, 195–200, 203, 204,
220, consulte também 218, 221, 250, 314, 315 , 327,
Inundação confiável 328 , 331–336 , 338, 339, 349,
Informações de endereçamento, 43, 68, 350, 356 , 359, 360
70, 75, 79, 80 , 84, 94, 117, 121, BGP (Border Gateway Protocol), 11, 14, 15,
122, 137, 142, 144 , 147 , 157 , 19, 79–82 , 262, 295 , 297, 298,
163, 169 , 174 , 240 , 241, 243, 304, 306, 373
244
Partida a frio, 35, 51, 106, 191, 198 , 250,
Vizinho adjacente, 188, 189, 217, 225–
227, 236, 271, 292, 323, 324, 259, 271, 327, 332, 340
331, 341, 365 SEQUÊNCIA COMPLETA
Distância administrativa, 25, 268, 272, NÚMERO PDU, consulte CSNP
273, 308 aep- Gráfico de conectividade, 58, 60, 62, 63,
NR, 122, 128, 133, 240, 243 aip-NR, 65, 68, 109
70, 83–85, 122, 157, 163, 171 Rede convergente, 250
CSNP, 181, 183, 206, 226, 227, 250 , 342,
AR (Roteador de Publicidade), 148, 155
Constantes arquitetônicas, 145 343 , 348, 352, 365, 367, 369
Endereços de área TLV, 168, 186, 190,
237, 289, 324, 325
DESCRIÇÃO DO BD, 181, 219, 221, 328,
ID de área (AID), 151, 168, 184–186,
360
189, 235, 236, 289, 323, 324
DBR (Domain Border Router), 19, 78, 80–
area-external-prefix-NR, consulte aep-NR
82, 84 , 94, 117, 122, 127, 133,
area-internal-prefix-NR, consulte aip-NR
135, 244 dbr-NR,
AS (Sistema Autônomo), 11, 19, 79, 82,
138, 241
144, 175, 295, 296, 298, 300–
Gateway padrão, 27
302, 373
Rota padrão, 81, 94, 175, 176, 300, 301
AS-Externo-LSA, 175, 176, 231, 232, 242,
297, 301, 304, 312, 379
APAGAR, 101, 112, 180, 208
ASBR (Borda do Sistema Autônomo
401

402 Índice
dep-NR, 82, 84, 122, 128, 133, 137, 175, IPv4, 267, 268, 270, 273 , 274 , 297,
241, 244 300, 301, 304, 306, 308–310,
Rota diretamente conectada, 24, 91, 268, 272, 379, 382–384
273 IPv6, 267, 271, 285
DIS (Intermediário Designado Vizinho totalmente adjacente, 188, 221,
Sistema ) _ _ _ _ _ _ _ _ _ _ _ _ _ 232, 237, 363
_ _ _ _ _ _ _ _ _ , 357, 358, 364, 381
Gateway de último recurso, consulte Rota
padrão
HELLO pacote
genérico, 45, 48, 56, 112
domínio-border-router-NR, consulte
dbr-NR IS-IS, 177, 180, 186, 187, 189,
192, 195, 200, 250, 314, 340, 343,
domínio-externo-prefixo-NR, consulte
347
dep-NR
imediato, 194, 340, 344, 347
DR (roteador designado)
L1 OLÁ, 186, 189, 325
genérico, 56–58, 62–65, 72, 100, 106,
L2 OLÁ, 186, 189
112
LAN IS-IS HELLO, 180, 186
OSPF, 152, 157, 160 , 171, 172 , 177,
PONTO A PONTO IS-IS
187, 191, 195–200, 203–205,
OLÁ, 180, 186, 192, 322
218, 221, 231, 232, 250, 277 , 280,
OSPF, 180, 185–187, 189, 191,
282, 287, 293, 314 , 315, 327, 328,
195, 196, 250, 314, 318, 320, 328,
331–339, 349, 356, 360
333–336
imediato, 194, 320, 328
DVR (roteamento de vetor de distância),
Hello protocol, 45, 48–50, 54, 56–58, 60, 65,
129, 131, 235, 238
77, 112, 151, 180, 185, 195,
Nome de host dinâmico TLV, 169, 288, 290
313 comunicação
bidirecional, 47
Acessibilidade de IP estendida TLV, 163, 165, Rede hierárquica, 143, 236, 238, 376, 379,
175, 243, 244, 298, 301, 382 380
Acessibilidade IS estendida TLV, 163, 243, Caminho entre áreas, 134, 246, 383–385
298, 381 Protocolo de roteamento entre áreas,
20, 115–117, 119, 120, 122, 127,
Escopo de inundação, 136, 137, 144, 242
99 área, 120, 122, 128, 129, 133, Inter-Area-Prefixo-LSA, 241
241, 242 Inter-Area-Router-LSA, 242
domínio, 120, 127, 129, 133, 137, 242 Protocolo de roteamento entre AS, 19
link, Protocolo de roteamento entre domínios,
77, 177 19, 20, 78–80, 122, 232
Tabela de Regras de aceitação de interface, 184,
encaminhamento genérica, 5, 7, 14–17, 187–189
22, 24, 27 , 28, 35, 43, 50, 68, Caminho intra-área, 134, 135, 245, 246, 378,
69, 77, 81, 85, 91, 94, 147, 384, 386
239, 246, 267

Índice 403
Intra-Área-Prefixo-LSA, 169, 171, 177, Interface somente L1, 144, 184–186, 189,
231, 232, 240, 282, 287 262, 322, 324, 325, 374
Protocolo de roteamento intradomínio, 19, Interface
79, 80, 144, 295 L1/L2, 144, 184, 186, 189, 262,
Bloco de 316, 324–326, roteador 374,
endereço de endereçamento 145, 236, 237, 243, 244,
IP, 8, 9, 15 configuração de endereço, 262, 313, 374, 375, 382, 383
16, 255 representação de L2
endereço, 7 estrutura de adjacência, 144, 145, 189, 190, 200,
endereço, 15 endereços 236, 237, 325, 326
classful, 16 famílias, 7 LSDB, 144, 145, 162, 189, 236, 299,
Endereços IPv6 globais e de link 375, 380, 382
local, 10, 16 multicast LSP, 156, 162, 180, 243
e broadcast roteador, 145, 236, 262, 298, 374
endereços, 9 subdomínio, 143
endereços públicos e privados, 10 Interface somente L2, 144, 184–186, 189,
Acessibilidade externa de IP 262, 324, 326, 374 la-
Informações TLV, 175, 244 NR, 77, 84, 92, 177
Endereço de interface IP TLV, 169, 177, 290 Enlace da camada 2, 13, 16, 17, 19, 31, 117,
153
Informações de acessibilidade interna de IP Informações de link, 43, 76, 92, 142, 147,
TLV, 163, 165, 243, 290, 352 177
endereço de link-NR, consulte la-NR
Endereço de interface IPv6 TLV, 169, 178, Link-LSA, 177, 231, 232, 284, 286, 287
291
Endereço local de link IPv6, 10, 16, 27, LS RECONHECIMENTO, 181, 203, 218,
169, 177, 178, 232, 254, 273, 285, 339, 350, 351, 356, 363
286, 291 , 293, 315
Acessibilidade IPv6 TLV, 163, 165, 169, LS PEDIDO, 181, 220, 221, 363
175, 243, 244, 291 LS ATUALIZAÇÃO, 181, 203, 220, 253,
IS Neighbors TLV (tipo 2), 163, 195, 243, 290, 339, 349, 351, 356, 363
291, 294, 341, 345, 352 LSA (Link State Advertisement), 148, 155,
203, 208 confirmação,
IS Neighbors TLV (tipo 6), 186, 189, 195, 317 203, 220, 351 expiração de idade, 216,
231 confirmação atrasada,
203, 363
L1
adjacência, 144, 145, 189, 190, 200, exclusão, 212, 356, 359
236, 237, 325, 326 atualização, 155, 208, 210, 359
LSDB, 144, 145, 162, 189, 236, cabeçalho, 155, 203, 219
237, 243, 268, 299, 375, 380, 382 confirmação implícita, 204, 350
LSP, 156, 162, 180, 243, 245 instância, 210, 349

roteador, 145, 236, 262, 374 ID LSA, 155
origem de, 230, 242, 348

404 Índice
recepção de, 213 Nomes, 4

pedido, 220, 363 auto- endereços, 5
originado, 214, 221, 359 escopos,
SN wrap around, 216 4 espaços, 4, 68
geração não solicitada, 215, 230 NET, 151, 235, 237, 260
LSDB (Link State Database), 43, 50, 85, 104 , Mapa de rede, 43, 45, 47, 50, 57, 60 , 64 , 71 ,
148, 155, 157, 162, 169, 174 , 81 , 82, 85, 103, 116, 121, consulte
177 , 202, 208 , 217 , 236, 239, também Informações topológicas
274 , 295, 300, 302, 309 , 348 , 356,
358, 373, 376, 380 área, 121 Rede-LSA, 157, 160, 169, 171, 172, 200,
231, 232, 240, 278, 282, 286, 297,
304, 310, 356, 377
sobreposição, 127
RESUMO DA LSDB, 108, 113, 181, Rede-Resumo-LSA, 240, 377, 384
221
PEDIDO DE RESUMO DA LSDB, 108, 113 Nonpseudonode-LSP, 148, 163, 166, 174,
175, 201, 206, 225, 233, 243, 288,
LSP (Link State PDU), 148, 155, 163, 181, 292, 294 , 299 , 342, 345, 348 , 352,
206, 208 confirmação, 355, 365, 366 , 368 , 3 80
206, 207, 226, 367 expiração de idade,
NR (Registro de rede), 50, 122, 147, 148, 155
216 , 231 corpo, 156 exclusão,
212, 345, confirmação, 99, 112 exclusão,
356, 358 fragmentação, 156 100, 102 atualização,
atualização, 156, 208, 57, 96, 97, 102 identificador, 83
210, 227 cabeçalho, 156, 345 instância, 57
identificador, 156 identificador
indivisibilidade, de instância, 96, 98, 112 solicitação,
148 instância, 210 108 auto-
originado, 108
L1 e L2, 156, 162, 243 SN volta, 102
ID LSP, 156, 183, 206, 288
Número LSP, 156 Roteador de origem, 50, 77, 81, 83, 94, 97, 100,
origem de, 230, 245, 348 recepção 122, 148, 156, 166, 168, 169 ,
de, 213 solicitação, 202 , 216 , 231, 232, 240, veja
206, 226, 366 auto- também AR
originada, 214, 225–227, 365, 366,

PEDIDO PARCIAL DE LSDB, 108, 113,
368
182, 221
SN wrap around, 216
NÚMERO DE SEQUÊNCIA PARCIAL
geração não solicitada, 215, 230
PDU, consulte PSNP
Entradas LSP TLV, 183, 206, 225, 355, 369
Link ponto a ponto, 14, 27, 31, 32, 47, 48, 51,
61, 83, 93, 104, 106 representação
pacote LSP, 181, 206, 225
gráfica, 86 identificador, 33,
54, 55 prefixo atribuído
Roteamento multiárea, 20
a, 72, 75

Índice 405
Adjacência de três vias ponto a ponto caminho,

TLV, 180, 186, 192, 322, 323 5 custos de caminho,
23 seleção de caminho, 23
Protocolos suportados TLV, 168, 169, 289, 291 Informações de roteamento, 43, 50, 79, 91, 95,
116, 119, 134 , 144, 147, 148, 180,
Pseudonó, 33 202, 208, 230, 240
ID do pseudonó, 152, 156, 164, 165, 288, 290, Protocolos de roteamento, 7
340, 347, 358
Pseudonode-LSP, 148, 163, 166, 201, 206 , 212, Princípio da separação, 68, 71, 147,
233, 243, 288, 292, 294 , 342 , 343, 148, 169, 177, 284
348 , 353, 356, 357, 365, 380 Link compartilhado, 26, 28, 31, 48, 51, 61, 64,
77, 104
PSNP, 181, 182, 185, 206, 226, 355, 366, 367, capacidade de transmissão, 31
369 grau de conectividade, 31 falha,
38
Inundação confiável, 44, 98, 100, 202, 203 representação gráfica, 86
identificador, 33, 56–58, 63, 64
RID (ID do roteador), 149, 152, 157, 159, 160, 170, particionamento, 38 , 58
171, 186, 191, 195 , 197, 219, 242 , prefixo atribuído a, 72, 75
256 , 260 , 280 , 294, 314, 315, 328, transmissão confiável, 37 stub, 32, 71,
332 , 334, 356, 360 93 trânsito, 32 NR
de link
Roteador, 51 compartilhado, consulte slink-NR
representações gráficas, 86 SID (ID do sistema), 151, 152, 164, 165, 169, 186,
identificadores, 195, 201 , 233 , 260, 288, 290, 322,
33 prefixos atribuídos a, 72, 75 340 , 342, 347 slink-NR, 64, 75, 83–
Roteador-LSA, 157, 169, 170 , 172, 177, 200, 231, 85, 121 , 153, 154, 157, 163, 171
233, 240, 276, 286, 293 , 297 , 304,
310, 349 , 351, 356, 359, 377 descrição SN (número de sequência), 96–100, 102, 109, 111,
do link, 158, 170, 155, 156, 208–212, 214–216, 221,
177, 222, 227 , 345 , 348, 349 , 351, 353,
200, 276, 280, 293 , 339, 349, 359, 355, 359, 360, 363–370
363, 377 roteador-
NR, 64, 75, 81, 82 , 84, 85, 104, 121, 127, Protocolo Stop-and-Wait, 36, 219
157, 163, 170 Sub-rede, 11, 15, 19
Domínio de roteamento, 19, 20, 22, 69, 70, 78–
80, 82, 84, 94 , 117 , 122, 127, 133 , Arquitetura TCP/IP, resolução de
135 , 137, 142 , 144, 145 , 147 , 149, 11 endereços, 25
152 , 174, 175 , 232, 235, 274, 295, Protocolo IP, 13, 14
297, 310, 312 endereço de camada 2,
14 camada de
Função de roteamento, 5 link, 13 camada de
e arquitetura TCP/IP, 14 roteamento de rede, 12 hierarquia de roteamento de dois níveis, 12

ponta a ponta, 25 Registro TLV, 148, 156, 163, 168
encaminhamento, 6 estendido, 156, 165

406 Índice
estrutura vizinha, 164 estrutura

de prefixo, 165
Elemento topológico, 51, 68, 70, 74, 75, 171
Identificador topológico, 68, 70, 75, 77, 157,

163, 169, 178
Informações topológicas, 43, 68, 75, 84, 117,
120, 122, 127, 142, 147 , 157, 163,
165 , 169, 172, 240, 243
ATUALIZAÇÃO, 101, 108, 112, 180, 221

Ospf and Is Is em Portugues

Enviado por

Direitos autorais:

Formatos disponíveis

Ospf and Is Is em Portugues

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

Ospf and Is Is em Portugues

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

Grupo Taylor & Francis

© 2019 por Taylor & Francis Group, LLC

Nenhuma reivindicação de obras originais do governo dos EUA

Impresso em papel sem ácido

Livro padrão internacional número 13: 978-1-138-50455-4 (capa dura)

Visite o site da Taylor & Francis em http://

e o site da CRC Press em

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

2.2.1.4 Identificadores dinâmicos de links compartilhados e designados

Canal do Telegram: @IRFaraExam

3 princípios de roteamento de estado de link multiárea 115 .

3.1.2 Determinando caminhos mais curtos fim-a-fim. . . . . . . . 118 . 120

III Tecnologias 139

É ................................................. ......................................... 162 5.6.1 IS Vizinhos

Canal do Telegram: @IRFaraExam

5.6.2 TLVs de acessibilidade de IP. . . . . . . . . . . . . . . . . . 165 .

6 Mecanismos de Sincronização OSPF e IS-IS 179

Canal do Telegram: @IRFaraExam

6.4.1 Inundação em OSPF ....................................... .......... 203 6.4.2 Inundações

7 Redes Hierárquicas OSPF e IS-IS

IV Estudos de caso 247

8 Ferramentas e Configurações 249

Canal do Telegram: @IRFaraExam

8.3.3 Recursos adicionais do IOS . . . . . . . . . . . . . . . . . 257 .

9 Experimentos em tabelas de encaminhamento e LSDB 9.1

10 Experimentos sobre Mecanismos de Sincronização 10.1 313

Canal do Telegram: @IRFaraExam

10.2.1.1 Partida a frio .............................. ......... 327 10.2.1.2 Partida a

10.2.1.4 Apenas um roteador iniciado no link. . . . . . . 334 . 335

11 Experimentos em Redes Hierárquicas 373

Canal do Telegram: @IRFaraExam

Canal do Telegram: @IRFaraExam

Compreender os princípios por trás das tecnologias torna o processo de aprendizagem

Curiosamente, a Área de Roteamento da Força-Tarefa de Engenharia da Internet

Canal do Telegram: @IRFaraExam

Visão geral do roteamento de estado de link Nos

A necessidade de armazenar a visualização completa da rede aumenta as preocupações

Canal do Telegram: @IRFaraExam

• Introdução - A Introdução inclui o Capítulo 1, que revisa as noções básicas de

• Princípios - A parte Princípios inclui dois capítulos abordando os princípios da

• Technologies - A parte Technologies descreve as versões IPv4 e IPv6 de OSPF

• Estudos de caso - A parte de Estudos de caso apresenta e discute vários

Incluímos no final do livro um glossário explicando os principais conceitos e as

Como ler o livro

Canal do Telegram: @IRFaraExam

Uma palavra sobre nomenclatura

Os arquivos contendo as configurações dos experimentos e as capturas do Wire

Nós gostaríamos de ouvir de você

Primeiramente, gostaria de agradecer ao meu amigo e colega José Br´azio, do

Canal do Telegram: @IRFaraExam

Universidade de Lisboa (minha Universidade) e Instituto de Telecomunicações (meu

Canal do Telegram: @IRFaraExam