Redes e Roteamentos PDF

OUTROS TRABALHOS EM:
www.projetoderedes.com.br
Roteamento em redes de
computadores
Autor: Valter Roesler

Universidades: UNISINOS e UFRGS
Data: maio de 2001
Roteamento em redes de computadores
pg. 2
Valter Roesler
SUMRIO
1
2
3
4
6
7
Sistemas Autnomos ..........................................................................................................3

Algoritmos de roteamento ..................................................................................................4
2.1
Roteamento por Vetor de Distncia............................................................................4
2.1.1
Exemplo de funcionamento cidades ................................................................4
2.1.2
Exemplo de funcionamento real ......................................................................5
2.1.3
Problemas da contagem ao infinito ....................................................................6
2.1.4
Solues para a contagem ao infinito .................................................................7
2.2
Estado de Enlace.........................................................................................................8
2.2.1
Descobrir seus vizinhos e aprender seus endereos de rede...............................9
2.2.2
Medir o retardo para cada um dos vizinhos........................................................9
2.2.3
O pacote LSP (Link State Packet) ......................................................................9
2.2.4
Enviar esse pacote a todos outros roteadores (Flooding) .................................10
2.2.5
Calcular o caminho mais curto para cada um dos roteadores...........................11
2.3
Estado de Enlace x Vetor de Distncia.....................................................................11
RIP V1 (Routing Information Protocol Version 1) ..........................................................12
RIP V2 (Routing Information Protocol Version 2) ..........................................................13
4.1
Autenticao .............................................................................................................14
4.2
Route Tag .................................................................................................................14
4.3
Subnet Mask .............................................................................................................14
4.4
Next Hop...................................................................................................................14
4.5
Multicasting ..............................................................................................................15
4.6
RIP com IPv6............................................................................................................15
OSPF (Open Shortest Path First)......................................................................................15
5.1
O banco de dados OSPF ...........................................................................................15
5.1.1
O custo das rotas (mtricas)..............................................................................17
5.2
Os protocolos OSPF .................................................................................................18
5.2.1
O protocolo Hello .............................................................................................18
5.2.2
O protocolo Exchange ......................................................................................19
5.2.3
O protocolo Flooding........................................................................................19
5.3
Mltiplas reas no OSPF ..........................................................................................19
5.4
OSPF para IPv6 ........................................................................................................20
Comparao RIP-1, RIP-2 e OSPF...................................................................................20
BGP-4 (Border Gateway Protocol 4)................................................................................20
7.1
Sesso BGP...............................................................................................................21
7.2
Mensagens BGP .......................................................................................................21
7.2.1
Mensagens de cabealho ..................................................................................22
7.2.2
Mensagens de Open ......................................................................................22
7.2.3
Mensagem de KeepAlive..................................................................................23
7.2.4
Mensagens de Notification............................................................................23
7.2.5
Mensagens de Update ...................................................................................24
7.3
ATRIBUTOS BGP ...................................................................................................25
7.3.1
ORIGIN ............................................................................................................26
7.3.2
AS_PATH.........................................................................................................26
7.3.3
NEXT_HOP......................................................................................................27
7.3.4
MULTI_EXIT_DISC .......................................................................................27
7.3.5
LOCAL_PREF .................................................................................................27
7.3.6
AGGREGATOR...............................................................................................27
Constraint Based Routing.................................................................................................27

9
pg. 3
Valter Roesler
Bibliografia.......................................................................................................................27
1 Sistemas Autnomos
Internet um conjunto de sistemas autnomos interligados, ou seja, uma interligao de
vrios domnios. Domnio a rede interna de uma organizao, ou seja, uma coleo de
estaes e roteadores administrados por uma nica entidade.
Cada domnio ou rea possui um nmero de identificao AS (Autonomous System),
que identifica todos os roteadores de uma rea. O espao de nmeros de AS finito, sendo
definido atualmente como um inteiro de 16 bits (65536 nmeros). O IANA reservou o bloco
de 64512 a 65535 para uso privado (no podem ser anunciados na Internet) [RFC 1930].
Existem duas classes principais de protocolos de roteamento, os IGP (Interior Gateway
Protocols), e os EGP (Exterior Gateway Protocols), como mostra a figura a seguir.
Os protocolos IGP mantm a comunicao entre os roteadores limitada ao domnio, ou

seja, o flooding e a comunicao entre vizinhos ficam contidos na rea. Exemplos de
protocolos IGP so o RIP (Routing Information Protocol) e o OSPF (Open Shortest Path
First), que utilizam, respectivamente, algoritmos de vetor de distncia e estado de enlace
para descobrir a topologia da rede.
Os protocolos EGP so necessrios para que exista comunicao entre domnios, ou
seja, deve haver um roteador de borda entre as reas. Exemplos de protocolos EGP so o BGP
(Border Gateway Protocol) e IDRP (Interdomain Routing Protocol).
necessria uma diferenciao entre protocolos IGP e EGP, pois os objetivos no so
os mesmos. Um protocolo IGP se preocupa com a melhor rota at a rede de destino, sem
pensar em poltica. J um protocolo EGP assume que empresas diferentes, organizaes
diferentes e at pases diferentes precisam se comunicar, e existem certas polticas que devem
ser respeitadas, at mesmo por questes econmicas e de segurana, como, por exemplo
[TAN 96, pg 489].
pg. 4
Valter Roesler
No utilizar determinado AS;

Nunca colocar o Iraque numa rota que comea no pentgono;
Trfego que comea ou termina numa empresa no deve passar pela concorrente.
2 Algoritmos de roteamento
Existem duas formas de um roteador ser configurado: atravs de roteamento esttico e
roteamento dinmico. No roteamento esttico, um administrador configura manualmente a
rota. Uma delas configurada sempre a rota default. Como provocam um trabalho
considervel, o roteamento esttico adequado para rotas que no mudam com muita
freqncia.
O roteamento dinmico depende de algoritmos para descobrir o melhor caminho.
Basicamente, existem dois tipos de algoritmos para roteamento dinmico em redes IGP: o
roteamento por Vetor de Distncia e o roteamento por Estado de Enlace.
Estes algoritmos aprendem como alcanar outras redes atravs da troca de informaes
com outros roteadores, sabendo assim para onde encaminhar pacotes de uma rede para outra.
2.1 Roteamento por Vetor de Distncia

No roteamento com vetor de distncia, cada roteador possui uma tabela com a melhor
distncia conhecida aos diversos destinos alcanveis, bem como a sada a ser usada para
chegar l. Essa tabela atualizada a partir de troca de informaes com os vizinhos, que
informam sobre seus vizinhos, e assim por diante.
Esse algoritmo tambm conhecido pelo nome de seus desenvolvedores, ou BellmanFord (1957) e Ford-Fulkerson (1962), e foi usado originalmente na Internet com o nome de
RIP [TAN 96, pg 406].
A mtrica permitida pelo algoritmo pode ser nmero de hops (usado no RIP), retardo de
tempo em milisegundos, nmero de pacotes na fila ou algo semelhante. A seguir ser feito um
exemplo ilustrativo de funcionamento do protocolo e em seguida um exemplo mais real.
2.1.1 Exemplo de funcionamento cidades

Imagine pessoas em cidades diferentes com a responsabilidade de saber como chegar
em outras cidades e qual o melhor caminho a seguir. Para isso, supondo que a mtrica para
chegar ao destino seja a distncia mais curta (poderia ser a melhor estrada, por exemplo), eles
tm que saber a distncia em quilmetros at cada um dos destinos.
Imagine tambm que existe um sistema de comunicao somente entre cidades
vizinhas, ou seja, cada uma dessas pessoas s consegue falar com seus vizinhos, e atravs
deles que vai circular a informao de como chegar a todas as cidades existentes.
No exemplo a seguir, tudo que a pessoa sabe inicialmente que ela se encontra em So
Leopoldo (custo 0 local) e a cidade possui duas sadas, uma a BR-116 e outra a RS-x.
Assim, constri uma tabela com essa informao.
Tabela SL
Destino
Custo
Rota
SL
0
-
BR-116N
So
Leopoldo
BR-116S
pg. 5
Valter Roesler
Em seguida, as duas cidades vizinhas enviam suas tabelas. Suponha que seja possvel
medir a distncia entre os vizinhos atravs de mensagens especiais. Assim, a tabela de So
Leopoldo incrementada com Novo Hamburgo, a 10 km e Canoas, a 15 km.
BR-116N
10Km
Destino
SL
NH
CAN
Tabela SL
Custo
Rota
0
10
BR-116N
15
BR-116S
Novo
Hamburgo
So
Leopoldo
BR-116S
15Km
CANOAS
Conforme o tempo passa, as outras cidades vo aprendendo rotas novas atravs da troca
de informaes com os vizinhos. Por exemplo, So Leopoldo agora informa a Novo
Hamburgo que pode chegar em Canoas. Na figura a seguir, SL recebeu de NH distncias para
chegar em Porto Alegre e Taquara, e tambm recebeu de Canoas as distncias para chegar em
Porto Alegre. Como a distncia mais curta para Porto Alegre via Canoas, a tabela fica de
acordo com a rota mais curta.
Taquara
35Km
BR-116N
10Km
Tabela SL
Destino
Custo
SL
0
NH
10
CAN
15
TAQ
45
POA
30
Rota
BR-116N
BR-116S
BR-116N
BR-116S
Novo
Hamburgo
55Km
So
Leopoldo
BR-116S
15Km
CANOAS
15Km
Porto
Alegre
Cada roteador tem um ID e conhece o custo com seus vizinhos. De tempos em tempos,
recebe de todos os vizinhos tudo que os vizinhos conhecem. Com essas informaes, ele
atualiza sua tabela com a menor distncia e a rota de sada para chegar num destino.
2.1.2 Exemplo de funcionamento real

Imagine a topologia de rede ilustrada na figura a seguir, onde a mtrica o retardo, e
cada roteador mediu previamente o retardo atravs de pacotes de Echo, por exemplo.
pg. 6
Valter Roesler
O roteador A, quando iniciado, monta uma tabela das rotas conhecidas. Esta tabela
enviada para todos os links do roteador.
Roteador A
Destino
Custo
A
0
B
2
G
6
Cada roteador troca suas tabelas com os roteadores vizinhos de tempos em tempos. As
novas rotas recebidas so calculadas e adicionadas. No exemplo abaixo, o roteador A recebe a
tabela de G, gerando a nova tabela de A. Note que as rotas E e H foram adicionadas e um
custo de 6 foi adicionado a cada rota recebida por causa do custo do link entre A e G.
Roteador G
Destino
Custo
G
0
A
6
E
1
H
4
Destino
A
B
G
Roteador A
Custo
Rota
0
2
B
6
G
Nova tabela de A com o que

aprendeu de G
Roteador A
Destino
Custo
Rota
A
0
B
2
B
G
6
G
E
6+1 = 7
G
H
6+4 = 10
G
Quando o roteador A receber a atualizao de B, sua tabela fica da seguinte forma:
Roteador B
Destino
Custo
A
2
B
0
C
7
E
2
Roteador A
Destino Custo Rota
A
0
B
2
B
E
7
G
G
6
G
H
10
G
Nova tabela de A com o que

aprendeu de G e B
Roteador A
Destino Custo Rota
A
0
B
2
B
C
2+7=9
B
E
2+2=4
B
G
6
G
H
10
G
A nova rota C foi encontrada. Note que a rota para E tambm foi modificada, pois existe
um caminho com custo menor por B.
2.1.3 Problemas da contagem ao infinito

O algoritmo de vetor de distncia tem um problema na velocidade de convergncia
quando ocorrem problemas na rede. Pode-se dizer que as boas notcias convergem rpido,
mas as ms notcias demoram a convergir. Para exemplificar, a figura a seguir (item a)
pg. 7
Valter Roesler
mostra as distncias de todos os roteadores recm ligados para A. Pode-se ver que, em 3
atualizaes da tabela, todos ficaram sabendo da sua existncia.
Por outro lado, na figura a seguir item b, pode-se ver que falhas na rede demoram a
ser eliminadas, podendo ocasionar loops, que so pacotes que ficam sendo repassados de um
roteador para outro durante certo tempo. Para o pacote no ficar em loop infinito em uma
rede, todo o pacote possui um contador TTL.
O contador TTL (Time to Live) de cada pacote comea com um valor padro de 15 e vai
sendo diminudo medida que passa por um roteador. Assim, se uma rede estive em loop, o
TTL chegar 0 e o roteador ir descartar o pacote.
No exemplo a seguir (item b), quando A sai do ar, B atualiza a distncia para 16,
entretanto, recebe em seguida a atualizao de C dizendo que sabe chegar em A com 2 hops.
A B atualiza sua tabela para 2+1 = 3. Quando B atualizar C, C vai passar sua distncia
at A para 3+1=4, e assim por diante. Vai levar em torno de 7 ciclos de atualizaes para
que todos saibam que A est fora, e isso d mais de 3 minutos (considerando 30 segundos
para cada ciclo de atualizao).
Neste instante C
ainda acha que chega
em A com 2 hops,
informando para B e
para D
a)
No existe A
1
1
1
2
2
Aps 1 troca
Aps 2 trocas
Aps 3 trocas
A sai do ar. B
detecta e atualiza
tabela (16 para
chegar em A)
B recebe tabela de C
antes de enviar para
C. Pensa que chega
em A via B com 3
hops (2 informados
por C mais um para
chegar em C)
Inicialmente
16
3
3
5
5
C atualiza B
B atualiza C
C atualiza B e D
5
5
7
...
...
16
16
16
B atualiza C
C atualiza B e D
Aps algumas
trocas
b)
2.1.4 Solues para a contagem ao infinito
Hold Down Se um link falhar, o roteador ignora todas atualizaes para aquela
rede por um tempo de, por exemplo, 180s. Assim, todos roteadores esquecem o
caminho at C, e um link quebrado no ser propagado. Este tempo pode ser um
problema para os pacotes sendo transmitidos para aquela rede caso exista outra rota
alternativa.
Poison Reverse and Triggered Updates Se um link falhar, modifica a informao
da rota para uma distncia infinita (16) e propaga imediatamente essa informao
adiante (no d tempo de receber a atualizao de outro n). Assim, se houver alguma
outra rota para C, essa rota ser utilizada, pois ser melhor que uma distncia infinita.
pg. 8
Valter Roesler
Dividir o Horizonte O roteador sempre propaga todas as rotas conhecidas, menos as

rotas que foram recebidas pela mesma porta. Baseando-se na figura anterior, quando C
anunciar as suas rotas, ele no anunciar para B o que ele recebeu de B. Veja o
exemplo baseado no problema do loop.
a) B nota uma falha em A, atualizando sua tabela para 16.
b) Quando C envia sua tabela, no informa a rota de A, pois a havia recebido de B.
Assim, no vai criar falsas expectativas de rotas, e quando B enviar sua
atualizao, C automaticamente passa para 16 o custo para chegar em A.
2.2 Estado de Enlace

O algoritmo de estado de enlace elimina alguns problemas crticos do vetor de distncia,
como a lenta convergncia no caso de problemas. A idia bsica do algoritmo de estado de
enlace que cada roteador faa o seguinte [TAN 96]:
1. Descobrir seus vizinhos e aprender seus endereos de rede
2. Medir o retardo para cada um dos vizinhos
3. Criar um pacote que diga tudo o que acaba de ser aprendido. Cada roteador constri
um pacote chamado de Link State Packet ou LSP, que contm o seu nome, o nome
de seus vizinhos e o custo necessrio para chegar at eles.
4. Enviar esse pacote a todos outros roteadores
5. Calcular o caminho mais curto para cada um dos roteadores.
Estes itens sero analisados com mais detalhes a seguir, com base na seguinte topologia:
O objetivo que cada roteador envolvido tenha um banco de dados completo de toda a
topologia da rede, para conseguir traar o caminho mais curto atravs de um algoritmo, como
o de Dijkstra, por exemplo. Assim, para a topologia acima, cada roteador deve ter um banco
de dados semelhante ao mostrado na tabela a seguir [HUI 99, pg 120]. Este banco de dados
deve ser o mesmo em todos os roteadores, a fim de que todos tomem as mesmas decises.

Origem
A
A
B
B
B
C
C
C
D
D
E
E
E
F
F
F
G
G
pg. 9
Valter Roesler
Destino
B
D
A
C
E
B
F
G
A
E
B
D
F
C
E
G
C
F
Custo
6
2
6
2
1
2
2
5
2
2
1
2
4
2
4
1
5
1
2.2.1 Descobrir seus vizinhos e aprender seus endereos de rede

Para o roteador saber quem so seus vizinhos, pacotes Hello (multicast para 224.0.0.5 =
todos roteadores SPF) so enviados para as portas de tempos em tempos. Se um roteador
recebe um pacote Hello ele responde com outro pacote contendo seu nome. Os nomes dos
roteadores no podem ser duplicados [TAN 96, pg 411]. Os pacotes Hello tambm so
utilizados para saber se um link est operacional [HUI 99, pg. 145]. Maiores detalhes no
estudo do OSPF.
2.2.2 Medir o retardo para cada um dos vizinhos

A forma mais simples de medir o retardo enviar pacotes de ECHO para o vizinho e
esperar resposta. A mdia de vrios tempos de resposta dividida por dois uma estimativa do
retardo [TAN 96, pg 411]. O tamanho da fila e a carga na rede tambm podem ser levados em
considerao.
No algoritmo de estado de enlace, outras mtricas podem ser medidas e levadas em
considerao, como a velocidade das linhas, sua segurana, e assim por diante. No item de
comparao entre os algoritmos de estado de enlace e vetor de distncia isso ser mais
detalhado.
2.2.3 O pacote LSP (Link State Packet)

Os roteadores utilizam o pacote LSP (Link State Packet) para trocar as informaes de
rotas com os outros roteadores. Seu formato mostrado na tabela a seguir (para roteador B).
Identidade do Transmissor
Nmero de seqncia
Idade (Tempo)
Destino
Custo
A
6
C
2
E
1
A identidade do transmissor deve identificar o mesmo univocamente na rea em que ele

se encontra, para evitar conflitos de informaes (e.g. nmero IP). O nmero de seqncia e a
pg. 10
Valter Roesler
idade ficaro mais claros no prximo item, que trata da problemtica de enviar este pacote a
todos os outros roteadores da rede.
2.2.4 Enviar esse pacote a todos outros roteadores (Flooding)

Um pacote mandado quando um roteador descobre um novo vizinho, o custo de um
link muda, um link cai ou passa determinado tempo (30minutos no caso do OSPF).
Como cada LSP deve ser enviado a todos os outros roteadores na rede, utiliza-se
flooding (inundao), onde cada pacote recebido mandado para todas as portas, exceto a
porta em que veio.
Para o flooding no se propagar ao infinito, gerando uma exploso de pacotes, pode ser
usado um contador TTL com um limite de hops que decrementado a cada roteador, e
quando chega a zero, descartado. O ideal que o TTL seja inicializado com o comprimento
do caminho da origem ao destino [TAN 96, pg. 400]. No caso do OSPF, utiliza-se um
nmero de seqncia ao invs do TTL, pois mais eficiente, conforme descrito a seguir.
Um pacote flooding pode ser recebido mais de uma vez em um roteador. Uma vez que
cada pacote LSP enviado possui um nmero de seqncia diferente do anterior, o roteador
sabe se o mesmo pacote foi recebido mais de uma vez, ento, ele no repassa os pacotes
repetidos. Caso receba um pacote mais antigo que o que tm no banco de dados, envia o
pacote mais atual (do banco de dados) de volta para a porta pela qual recebeu, a fim de
atualizar o roteador que est propagando rotas mais antigas. Caso receba um pacote com um
nmero de seqncia maior do que o existente no banco de dados, atualiza o banco de dados
com o pacote mais novo e envia o pacote para todas suas portas, menos pela qual o pacote
foi recebido [HUI 99, pg 121].
Por exemplo, suponha que o link entre A e B tenha cado. A deve enviar essa mudana a
todos os roteadores, e B deve fazer o mesmo. Supondo que o nmero de seqncia inicial
tenha sido 1, A vai enviar a seguinte informao para D (nica porta ativa).
Origem
A
Destino
B
Custo
infinito
Seqncia
2
O roteador D vai enviar esta informao para todas as portas menos A, ou seja, para E,
que vai enviar para B e F. B envia a informao para C (nica porta que sobrou em B que no
a que o pacote chegou). F envia a informao para G e C (que recebe duas vezes a mesma
informao, descartando uma). Dependendo por onde C recebe primeiro o pacote, ele envia
para as outras portas. Supondo que ele receba primeiro via B, ele envia a informao para F e
G. F tambm pode receber o pacote por portas diferentes, enviando para as outras portas da
primeira vez e descartando quando receber duplicado. G envia a informao para a porta pela
qual o pacote no chegou.
Caso o link entre D e E caia tambm, o mesmo acontece, mas existiro duas redes
separadas se atualizando independentemente. Caso um link volte ao ar, haver a necessidade
pg. 11
Valter Roesler
de uma troca completa de informaes, pois as tabelas estaro inconsistentes. No OSPF, isso
chamado bringing up adjacencies [HUI 99, pg 122].
Alm de manter a consistncia, o banco de dados deve ser protegido contra corrupo
acidental. Por exemplo, caso ocorra um erro de memria ou de transmisso, levando o nmero
de seqncia para um nmero elevado, todas as atualizaes de rota sero descartadas, pois
sero sempre mais antigas que o nmero corrupto. Para evitar isso, o algoritmo do OSPF
utiliza alguns mecanismos de proteo, como os seguintes [HUI 99, pg 124]:
O procedimento de flooding inclui um reconhecimento (ACK) de cada mensagem

enviada;
Cada LSP protegido por um timer, e removido do banco de dados caso este timer
expire;
Todas transmisses so protegidas por checksum;
As mensagens podem ser autenticadas por senhas.
2.2.5 Calcular o caminho mais curto para cada um dos roteadores.

Aps as informaes serem distribudas por flooding, o algoritmo de Dijkstra pode ser
usado para encontrar o caminho mais curto para cada um dos outros roteadores.
Cada roteador, tendo posse dos LSPs de todos os outros roteadores de sua rea, deve
construir uma rvore lgica para chegar a qualquer outro roteador pelo caminho com menor
custo. A figura a seguir mostra os caminhos mais curtos (onde a mtrica a distncia) para os
roteadores C e E.
2.3 Estado de Enlace x Vetor de Distncia
Suporte a mltiplos caminhos possvel no Estado de Enlace, e o roteador pode

utilizar mais de um caminho simultaneamente (o que pode ocasionar entrega de
pacotes fora de ordem, mas isso consertado no nvel TCP), deixando o fluxo mais
rpido. O vetor de distncia suporta apenas um caminho, o de menor custo;
Suporte a mltiplas mtricas Como cada roteador tem conscincia de toda a rede,
basta a medio de outras mtricas para que o algoritmo consiga decidir pelo menor
custo dependendo da necessidade da aplicao. Por exemplo, suponha que na figura a
seguir exista uma aplicao de voz e outra de dados partindo de A com destino a D. O
melhor caminho para a aplicao de voz seria o de menor atraso (A-E-D), enquanto
que para a de dados seria o de maior vazo (A-B-C-D). O OSPF verso 2 suporta os 4
mecanismos definidos no campo IP TOS (Type Of Service), que so: maior vazo,
menor atraso, menor custo e maior segurana [HUI 99, pg 127];
pg. 12
Valter Roesler
Link de satlite
C
1,5Mbit/s
275 ms
1,5Mbit/s
20 ms
B
64 Kbit/s
20 ms
1,5Mbit/s
20 ms
64 Kbit/s
20 ms
Banda Consumida O algoritmo de Estado de Enlace melhor, pois as atualizaes

ocorrem somente quando algo muda na rede, e no a cada 30 segundos, por exemplo.
Alm disso, o Estado de Enlace necessita enviar somente as informaes dos vizinhos,
e no toda sua tabela;
CPU O Estado de Enlace gasta mais, pois deve calcular a rvore de menor custo;
Velocidade de Convergncia O Estado de Enlace melhor, pois a cada alterao na
rede, essa informao se propaga imediatamente a todos os ns. Isso d uma vantagem
adicional, ou seja, evita loops na rede.
3 RIP V1 (Routing Information Protocol Version 1)

O RIP um protocolo do tipo IGP destinado a redes de tamanho limitado. Foi criado
inicialmente pela Xerox e baseado no algoritmo de vetor de distncia visto anteriormente.
Est definido na RFC 1058 e implementado no Unix Berkeley como routed. Quando
implementado em hosts, eles utilizam o modo passivo (somente ouvem as rotas e no enviam
atualizaes). Suas caractersticas so:
Utiliza o nmero de hops como mtrica;

Comunica-se com seus vizinhos a cada 30s. Se uma rota no re-anunciada em 180s,
ela considerada como infinita e removida da tabela;
Transmite toda tabela de rotas para vizinhos sempre (e no s alteraes da tabela), o
que gera bastante trfego;
Distncia mxima de 15 hops. Acima disso o destino considerado inalcanvel;
Utiliza protocolo UDP (porta 520) com pacotes de 576 bytes, o que demanda
mltiplos pacotes para enviar a tabela inteira. Por exemplo, uma tabela com 300
entradas necessita de 12 pacotes;
Utiliza sempre o caminho mais curto, impossibilitando engenharia de trfego ou
roteamento baseado em QoS;
Possui uma convergncia lenta, pois uma nova rota vai sendo enviada a cada 30
segundos de vizinho em vizinho, demorando a atingir um destino distante;
O formato do pacote RIPv1 pode ser visto na figura a seguir. A parte do cabealho do
identificador da famlia do endereo at a mtrica pode se repetir at 25 vezes [RFC 1058].
pg. 13
Valter Roesler
0
1
2
3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1)
| version (1)
|
must be zero (2)
|
+---------------+---------------+-------------------------------+
| address family identifier (2) |
must be zero (2)
|
+-------------------------------+-------------------------------+
|
IP address (4)
|
+---------------------------------------------------------------+
|
must be zero (4)
|
+---------------------------------------------------------------+
|
must be zero (4)
|
+---------------------------------------------------------------+
|
metric (4)
|
+---------------------------------------------------------------+
...
...
Os comandos mais comuns so Comando 1: requisio de tabela de roteamento e

Comando 2: resposta contendo tabela. A famlia da rede o nmero do protocolo, pois o RIP
no foi feito somente para IP (A famlia do IP a de nmero 2). O endereo informando a
rede pode ter at 14 bytes (IP usa apenas 4). A mtrica da rede pode conter nmeros de 1 a 16,
sendo que 16 igual a infinito (destino inalcanvel). Os campos reservados devem ser zero.
4 RIP V2 (Routing Information Protocol Version 2)

O RIP verso 2 est definido na RFC 1723, e possui compatibilidade com o RIP v1,
porm, adiciona uma srie de melhorias, como as descritas a seguir:
Autenticao: Se uma famlia de rede 0xFFFF, a primeira rota uma senha;

Mscara de subrede: til para classless;
Rtulo de rota: permite rotas aprendidas externamente, como, por exemplo, com
BGP;
Next Hop: endereo do prximo roteador para cada entrada de rota. til para redes
locais com mltiplos roteadores;
Multicast: RIPv2 usa o IP multicast 224.0.0.9, que equivale ao MAC 01-00-5E-0000-09. O RIP v1 utiliza broadcast.
O formato do pacote RIPv2 pode ser visto na figura a seguir:
0
1
2
3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1)
| Version (1)
|
unused
|
+---------------+---------------+-------------------------------+
| Address Family Identifier (2) |
Route Tag (2)
|
+-------------------------------+-------------------------------+
|
IP Address (4)
|
+---------------------------------------------------------------+
|
Subnet Mask (4)
|
+---------------------------------------------------------------+
|
Next Hop (4)
|
+---------------------------------------------------------------+
|
Metric (4)
|
+---------------------------------------------------------------+
pg. 14
Valter Roesler
Os campos command, Address Family Identifier, IP address e metric possuem

o mesmo significado da RFC 1058. O campo verso deve ser 2 nas mensagens que usam
autenticao ou informaes sobre os campos novos.
4.1 Autenticao
Para que o cabealho seja de autenticao, o campo Address Family Identifier deve
ser 0xFFFF, e o restante do cabealho contm a autenticao, conforme mostrado na figura a
seguir.
0
1
2
3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1)
| Version (1)
|
unused
|
+---------------+---------------+-------------------------------+
|
0xFFFF
|
Authentication Type (2)
|
+-------------------------------+-------------------------------+
~
Authentication (16)
~
+---------------------------------------------------------------+
O nico tipo de autenticao definida na RFC 1723 a senha simples (tipo 2). Os 16
bytes seguintes contm a senha em texto aberto.
4.2 Route Tag

O atributo Route Tag (RT) tem como objetivo separar rotas internas ao RIP de rotas
externas ao RIP (anunciadas de outro IGP ou EGP) [RFC 1723].
4.3 Subnet Mask

A mscara de subrede permite adaptar o esquema classfull de endereos IP para o uso
de classless, ou seja, baseado em mscara. Se for zero, no existe mscara de subrede
associada a este endereo IP.
4.4 Next Hop

O campo Next Hop indica o prximo endereo IP para o qual determinado pacote
deve ser redirecionado para chegar no destino informado no cabealho. Os endereos do next
hop devem, obrigatoriamente, ser alcanados diretamente atravs da subrede pela qual o
anncio feito.
No exemplo a seguir, IR1 at IR3 so roteadores internos. XR1 at XR3 so roteadores
de outra rea, com outra administrao. Configurando corretamente, o roteador XR3 seria o
next hop para chegar nas redes N6 e N7, XR2 para as redes N3, N4 e N5, e XR1 para as
redes N1 e N2. Caso um dos roteadores externos no enviasse o campo next hop, seriam
necessrios pacotes adicionais com IR1, IR2 e IR3 informando que ele seria o responsvel
para chegar em N1 e N2 [RFC 1723, apndice A].
pg. 15
Valter Roesler
N4
N2
N3
N6
N5
N1
N7
XR1
XR2
XR3
Subrede nica
IR1
IR2
IR3
4.5 Multicasting
A fim de reduzir carga desnecessria de CPU para hosts que no querem receber
mensagens de roteamento, foi definido o grupo multicast 224.0.0.9 (roteadores RIP2 [RFC
1700]). Observe que IGMP no necessrio, pois essas mensagens no so redirecionadas,
ficando na rede local.
4.6 RIP com IPv6

/**/ [HUI 99] pg 109.
5 OSPF (Open Shortest Path First)

O OSPF utiliza como base o algoritmo de estado de enlace, est definido na RFC 2178,
e possui as seguintes caractersticas:
Usa outras mtricas alm da contagem de hops;

Permite mscara de subrede;
Permite balanceamento de carga em caminhos de igual custo;
Suporta Type of Service do IPv4;
Autentica troca de rotas;
Aprende de rotas externas (vindas de outros sistemas autnomos);
Possui rpida convergncia (que um dos problemas do RIP);
Roda sobre TCP. Todos LSAs enviados (via flooding) possuem reconhecimento com
ACK. Se no veio ACK, o LSA enviado novamente (via flooding).
A informao enviada novamente (flooding) toda vez que um roteador descobre um

novo vizinho, o custo de um link muda, um link cai ou passa determinado tempo (30
minutos no caso do OSPF).
5.1 O banco de dados OSPF

Cada roteador OSPF de mesma rea utiliza um banco de dados representando a
topologia da rede (de acordo com o algoritmo de estado de enlace), e esses dados so
pg. 16
Valter Roesler
utilizados para encontrar o melhor caminho dependendo da mtrica necessria para a

aplicao [HUI 99, pg 138].
A troca de informaes entre os roteadores para a atualizao da base de dados se d
atravs da troca de pacotes de estado de enlace, ou LSPs (Link-State Packets). O cabealho
comum a todos, e mostrado na figura a seguir.
0
1
8
Link-State age
(2 bytes)
16
Options
(1 byte)
Link State ID (4 bytes)
Advertising router (4 bytes)
LS sequence number (4 bytes)
LS Checksum
(2 bytes)
31
24
LS type
(1 byte)
Length
(2 bytes)
Os campos vistos na figura tm o seguinte significado [HUI 99, pg138]:
Link-State age: serve para eliminar rotas velhas da base de dados, e indica o tempo
em segundos desde que aquela rota foi anunciada pela primeira vez. O roteador envia
a rota com idade zero. Durante o flooding, cada roteador por onde a mensagem passa
incrementa de um esse valor, e depois vai incrementando de segundo em segundo.
Quando ele atinge MaxAge (uma hora), o registro considerado obsoleto e
descartado. Entretanto, como todos os roteadores devem ter a mesma cpia do banco
de dados, esse processo deve ser sncrono, portanto, anunciado via flooding [HUI
99, pg 151]. Para garantir que os registros no fiquem velhos, os roteadores devem
reenvia-los a intervalos regulares, no mnimo a cada 30 minutos. Este novo registro
deve possuir o mesmo contedo, mas com o nmero de seqncia incrementado e a
idade em zero.
Options: a verso 2 do OSPF define somente dois bits deste campo:
o T bit 0: indica que o roteador suporta o uso do campo type of service
definido na RFC 1349. Isso ser detalhado a seguir.
o E bit 1: indica que o roteador capaz de enviar ou receber rotas externas,
ou seja, este um roteador de borda.
LS type: determina o tipo do registro que est sendo trocado entre roteadores. Pode
assumir um dos 5 valores a seguir:
1. router link: enviados pelos roteadores a fim de definir os custos dos links que
comeam no prprio roteador ( o tipo mais comum);
2. network link: so enviados pelos roteadores designados com destino a
roteadores de redes trnsito;
3. summary link (rede IP): anunciado pelos roteadores de borda destinado aos
roteadores de dentro de uma rea, e a diferena para o router link que envia
um anncio separado para cada destino;
4. summary link (border router): o mesmo que acima s que para o roteador de
borda da rea;
5. external link: registros enviados por roteadores de borda e destinados a
roteadores externos ao AS.
pg. 17
Valter Roesler
Link-State ID: a identificao do link escolhida pelo roteador (normalmente um

nmero IP). Pela definio, os campos Link-State ID mais o Advertising router mais o
LS type devem identificar univocamente o registro.
Advertising router: a identificao do roteador, ou seja, seu nmero IP.
LS sequence number: o nmero de seqncia necessrio para que o roteador saiba
se o pacote que est chegando mais atual ou mais antigo que o existente no banco de
dados. A utilidade deste campo foi explicada em maiores detalhes anteriormente, na
explicao do flooding do algoritmo de estado de enlace.
LS Checksum: usado para proteger os dados e o cabealho (menos o campo LS
Age, a fim de que o checksum no tenha que ser modificado toda vez que o registro
passa por um roteador).
Length: o tamanho total do registro em bytes, incluindo os cabealhos.
5.1.1 O custo das rotas (mtricas)

O caminho mais curto do OSPF pode ser baseado no tipo de servio (campo TOS da
RFC 1349). Caso o roteador tenha suporte a TOS, ele deve obter uma tabela de custo separada
para cada mtrica, e dependendo da aplicao, utilizar a mtrica correspondente. A definio
do tipo de mtrica feita de acordo com a tabela a seguir [HUI 99, pg 143]:
Cdigo OSPF
0
2
4
8
16
Cdigo RFC 1349

0000
0001
0010
0100
1000
Definio
Servio normal
Minimiza custo
Maximiza segurana
Maximiza vazo
Minimiza atraso
Assim, caso um pacote IP possua o campo TOS de 1000, a mtrica a ser utilizada pelo
roteador deve ser a de menor atraso, ou de nmero 16. Caso o roteador no tenha suporte a
TOS, deve zerar o bit 0 do campo options. Esses campos so codificados no anncio das
rotas, em tabelas definidas atravs do tipo do registro (LS Type). Maiores detalhes na RFC
2178 pg 176 ou em [HUI 99, pg 140].
Os valores de mtrica devem ser inteiros, sendo que os valores menores correspondem
s melhores rotas.
A mtrica de maximizar a vazo utiliza a frmula 10^8/ifspeed [RFC 1850, pg 39]. A
tabela a seguir especifica alguns valores para a mtrica 8.
Velocidade
9,6 Kbit/s
56 Kbit/s
2.048 Mbit/s
10 Mbit/s
100 Mbit/s e acima
Mtrica
10.416
1.785
48
10
1
Isso cria um problema para redes de alta velocidade, pois no tem como diferenciar um
link de 100 Mbit/s de outro de 2,4 Gbit/s.
A mtrica para atraso pode ser definida como o nmero de unidades de 10s necessrio
para encaminhar uma mensagem de 1000 bits [HUI 99, pg 143]. Assim, um link de satlite
com atraso de 275ms iria gerar um valor de 27.500 para a mtrica de nmero 16.
pg. 18
Valter Roesler
5.2 Os protocolos OSPF

O OSPF composto de trs subprotocolos bsicos: Hello, Exchange e Flooding. Todos
eles utilizam um formato nico de cabealho, visto na figura a seguir [RFC 2178, pg 164].
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version #
|
Type
|
Packet length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Area ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
AuType
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: nmero da verso. A RFC 2178 especifica o nmero 2;

Type: O tipo do pacote. Os seguintes esto definidos:
1. Hello: Serve para descobrir quem so seus vizinhos;
2. Database Description: Fornece o nmero de seqncia de todas as entradas de
estado de enlace mantidas atualmente pelo transmissor. Comparando com seus
prprios valores, o receptor sabe quem tem os valores mais atuais. Essas
mensagens so usadas quando uma linha interrompida (bringing up
adjacencies);
3. Link State Request: Solicitao de atualizao por parte de um roteador a seu
vizinho;
4. Link State Update: Mensagens emitidas periodicamente para seus vizinhos,
informando seu estado e custo de acesso aos outros vizinhos. Cada mensagem
incrementa o nmero de seqncia;
5. Link State Acknowledgment: Todas as mensagens so reconhecidas para
aumentar a segurana.
Packet Length: nmero de bytes do pacote;
Router ID: nmero IP definido para identificar o roteador;
Area ID: Identificao da rea. A de nmero 0 (0.0.0.0) reservada para o backbone.
usual a escolha de um nmero IP para identificar uma rea [HUI 99, pg 144];
Checksum: feito para todo pacote OSPF, menos o campo de autenticao;
AuType: define o tipo de algoritmo de autenticao a ser utilizado. As definies so:
0. Sem autenticao;
1. Autenticao simples (senha aberta);
2. Criptografia (usa checksum MD5).
5.2.1 O protocolo Hello

O protocolo Hello trocado entre vizinhos para descobrir os vizinhos, ver se eles esto
operacionais e eleger o roteador designado (para representar a LAN, por exemplo). Os pacotes
devem ser trocados a cada hello-interval segundos (o default de 10 segundos) [RFC 1850,
pg 44]. Caso eles no cheguem em dead-interval, o link considerado falho (o default 60
segundos) [RFC 1850, pg 44].
pg. 19
Valter Roesler
5.2.2 O protocolo Exchange

Quando dois roteadores estabeleceram uma conexo, eles devem sincronizar seus
bancos de dados. Para isso, eles utilizam o protocolo Exchange. A primeira sincronizao
feita atravs deste protocolo, e as seguintes atravs de flooding.
5.2.3 O protocolo Flooding

Cada mudana de estado do roteador (ou aps 30 minutos), ele responsvel por enviar
essa informao aos outros roteadores da mesma rea, atravs de flooding, com o nmero de
seqncia incrementado em relao ao anterior e a idade (LS Age) igual a zero.
Cada roteador que recebe um pacote de flooding (tipo = 4, update), deve retornar um
pacote de reconhecimento (tipo = 5, ack). Isso serve como garantia que o banco de dados
fique consistente entre todos os roteadores da rea.
5.3 Mltiplas reas no OSPF

Muitos Sistemas Autnomos na Internet so grandes e difceis de gerenciar. O OSPF
permite que eles sejam divididos em reas, a fim de diminuir o trfego de roteamento.
Grandes reas so divididas em reas menores, e cada rea tem uma identificao de 32 bits.
A rea de backbone a rea 0 (0.0.0.0), e as outras podem ser 0.0.0.1, 0.0.0.2, e assim
por diante. As reas se comunicam entre si via backbone, ou seja, todas as reas devem estar
ligadas ao backbone central, conforme mostra a figura a seguir.
rea de Backbone
(0.0.0.0)
ABR
rea 1
(0.0.0.1)
ABR
rea 2
(0.0.0.2)
ABR
rea 3
(0.0.0.3)
Os roteadores de borda de rea (ABR Area Border Routers) sumarizam a topologia e

a transmitem para a rea de backbone que, por sua vez, retransmitem essa informao para as
outras reas. Esses roteadores rodam algoritmos OSPF para as duas reas a que pertencem.
Durante a operao normal, podem ser necessrios trs tipos de rotas: na mesma rea
(usam algoritmo completo entre eles), entre reas (usam o ABR para ir e voltar ao backbone)
e entre sistemas autnomos (necessitam de protocolo de roteamento externo). Para suportar
isso, o OSPF define quatro classes de roteadores [TAN 96, pg 487]:
Roteadores internos: ficam inteiramente dentro de uma rea;

Roteadores de borda de rea (ABRs): conectam uma rea com o backbone;
Roteadores de backbone: redirecionam pacotes dentro do backbone;
Roteadores de fronteira do AS: interagem com roteadores de outros sistemas
autnomos.
pg. 20
Valter Roesler
5.4 OSPF para IPv6

/**/ [HUI 99], pg. 152
6 Comparao RIP-1, RIP-2 e OSPF

A tabela a seguir resume as diferenas entre RIP-1, RIP-2 e OSPF.
RIP-1
RFC 1058
Vetor de distncia
RIP-2
RFC 1723
Vetor de distncia
OSPF
RFC 2178
Estado de enlace
No (hops)
No (hops)
Sim
No
Sim
Sim
No (o mais curto)
No (o mais curto)
Sim
15 Hops
15 Hops
Intervalo de Atualizao
30 segundos
30 segundos
Atualizaes
Intervalo para eliminao
Autenticao
Velocidade de
Convergncia
Suporta AS#
Toda a tabela de rotas

180s
No
Toda a tabela de rotas

180s
Sim (senha aberta)1
65.535
A cada mudana ou
30min
Somente vizinhos (LSP)
?
Sim (senha MD5)
Devagar
Devagar ??/**/
Rpido
No
Sim ?? /**/
Sim
RFC
Algoritmo
Suporte a mltiplas
mtricas
Suporte a CIDR
Suporte a mltiplos
caminhos
Mximo dimetro da rede
1. A RFC 2082 define um esquema para encriptar a senha via MD5 para evitar a transmisso
de senhas abertas [HUI 99, pg 106].
7 BGP-4 (Border Gateway Protocol 4)

O BGP um protocolo entre sistemas autnomos, definido na RFC 1761 e usado desde
1989, entretanto, seu uso cresceu mesmo nos ltimos anos. Sua funo principal trocar
informaes de acessibilidade com outros sistemas BGP com o objetivo de traar um grafo da
conectividade do AS, visando eliminar problemas de laos e reforar decises de polticas do
sistema (como, por exemplo, a poltica de anunciar para os AS vizinhos somente as rotas que
ele usa, refletindo o paradigma hop-by-hop usado na Internet).
A verso 4 do BGP possui um novo conjunto de mecanismos para suportar CIDR
(Classless Interdomain Routing), como suporte para anunciar um prefixo IP (extended
network prefix e.g. /24) e eliminar o conceito de classes. Alm disso, inclui mecanismos
para agregao de rotas [RFC 1761].
O BGP um dos protocolos destinados a efetuar as polticas tratadas no item de
Sistemas Autnomos. Ele fundamentalmente um protocolo de vetor de distncia, porm, ao
contrrio do RIP, cada roteador mantm o controle total de cada caminho (da origem ao
destino) utilizado por cada roteador envolvido na rede [TAN 96, pg 490].
Para exemplificar, considere os roteadores mostrados na figura a seguir [TAN 96, pg
491]. Considere o roteador F. Suponha que ele esteja utilizando o caminho FGCD para chegar
a D. Os seus vizinhos devem informar a rota completa, como mostra a figura (B, G, I e E).
Depois de receber todas as rotas dos vizinhos, F procura o melhor. Ele descarta as rotas
de I e F, pois usam ele mesmo como passagem. Assim, sobra analisar as distncias para B e
pg. 21
Valter Roesler
G. Qualquer rota que passe por alguma rede politicamente restrita deve ser evitada (distncia
marcada como infinito). Aps essas eliminaes, o roteador usa a rota com distncia mais
curta.
C
B
A
G
Informao sobre D que F

recebe dos vizinhos
De B: rota BCD
De G: rota GCD
De I: rota IFGCD
De E: rota EFGCD
E
I
O problema da contagem ao infinito no existe no BGP. Suponha que G falhe ou que a

linha FG seja desativada. Rapidamente ele descobre que o nico caminho via FBCD [TAN
96, pg 491].
7.1 Sesso BGP

O BGP roda sobre TCP, porta 179, sendo, portanto, confivel (a aplicao no precisa
se preocupar com a confiabilidade). Dois sistemas BGP vizinhos abrem uma sesso atravs
de uma conexo de transporte entre eles, trocando mensagens para receber e confirmar os
parmetros da sesso (e.g. tempo mximo de espera de mensagens hold time). No havendo
concordncia nos parmetros, a sesso no aberta.
O primeiro fluxo enviado a tabela de roteamento completa, e depois disso, somente
atualizaes incrementais (mensagens de update) so feitas medida que as tabelas mudam
(e.g. uma rota se tornou invlida ou surgiu uma nova). Isso elimina a necessidade de
atualizaes peridicas na tabela de roteamento inteira, diminuindo a carga na rede. Portanto,
um roteador BGP mantm a verso atual da tabela de todos os seus vizinhos durante toda a
durao da conexo.
Cada atualizao das tabelas no BGP (mensagens update) provoca um incremento no
nmero de verso, permitindo verificar inconsistncias nas informaes de roteamento. O
exemplo a seguir mostra a verificao da verso da tabela de roteamento [MOU 99].
roteador> sh ip bgp
BGP table version is 72076, local router ID is 192.168.4.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
(...)
7.2 Mensagens BGP

Existem diversas mensagens padronizadas no BGP. Cada mensagem composta de
uma mensagem de cabealho mais a mensagem desejada. Mensagens de KeepAlive so
enviadas periodicamente para assegurar que a conexo est ativa. Mensagens de notificao
so enviadas em resposta a erros ou condies especiais. Se der erro numa conexo, uma
mensagem de notificao enviada e a conexo fechada. As rotas so atualizadas atravs de
pg. 22
Valter Roesler
mensagens do tipo update. Os itens a seguir descrevem algumas dessas mensagens. Maiores
detalhes na RFC 1761.
7.2.1 Mensagens de cabealho

As mensagens de cabealho so enviadas sempre no incio de qualquer outra
mensagem, ou seja, estas mensagens servem como cabealho para as outras. O formato
mostrado na figura a seguir [RFC 1761, pg 7].
Marker
16 bytes
Length
2 bytes
Type
1 byte
Marker: pode ser usado para detectar perda de sincronizao entre um par BGP ou
para autenticar mensagens BGP entrantes, possuindo dois formatos: Caso o campo
Type informe que a mensagem de Open ento todos os bits deste campo devem
ser preenchidos com o valor 1. Caso contrrio, o valor deste campo pode ser
previsto como parte de informao de autenticao.
Length: indica o tamanho total da mensagem (em bytes), incluindo o cabealho. A
maior mensagem existente 4096 bytes, e a menor de 19 bytes (KeepAlive).
Type: indica o cdigo da mensagem. Os cdigos definidos so:
o OPEN
o UPDATE
o NOTIFICATION
o KEEPALIVE
7.2.2 Mensagens de Open

Aps a conexo TCP estabelecida, a primeira mensagem enviada de Open. Para
confirmar, enviado uma mensagem de KeepAlive como confirmao, e a partir deste
momento mensagens de Notification podem ser trocadas.
Alm do cabealho, as mensagens de Open possuem o seguinte formato [RFC 1761,
pg 8]:
pg. 23
Valter Roesler
Version
1 byte
My Autonomous
System
2 bytes
Hold Time
2 bytes
BGP Identifier
4 bytes
Opt Parm
Len
1 byte
Optional Parameters
4 bytes
Version: atualmente, verso 4 (BGP-4).

My Autonomous System: informa o AS do transmissor.
Hold Time: indica o nmero mximo de segundos entre sucessivas mensagens
KeepAlive. Quando recebe uma mensagem de Open, o receptor deve usar como
hold time o menor valor entre o seu valor configurado e o proposto na mensagem.
Este tempo deve ser zero ou, no mnimo, 3 segundos. Caso seja zero, no so enviadas
mensagens de KeepAlive, caso contrrio, elas devem ser enviadas a
aproximadamente 1/3 do valor do hold time.
BGP Identifier: nmero IP do transmissor da mensagem. Este nmero determinado
no incio e o mesmo para toda interface local e todo para BGP.
Optional Parameters Length: indica o comprimento total (em bytes) do campo de
parmetros. Se for zero, no existem parmetros opcionais.
Optional Parameters: cada parmetro codificado atravs da tripla <Parameter Type,
Parameter Length, Parameter Value>. Os parmetros definidos na RFC 1761 so:
Informao de autenticao; Cdigo de autenticao; Dados de autenticao.
7.2.3 Mensagem de KeepAlive

As mensagens de KeepAlive so enviadas para manter a conexo viva entre os pares
BGP. Elas tm que ser enviadas numa freqncia tal que no excedam o tempo hold time,
configurado durante a mensagem de Open. O valor sugerido enviar uma mensagem
KeepAlive num tempo de 1/3 do tempo de hold time.
Caso o tempo de hold time tenha sido configurado como zero, a conexo
considerada sempre ativa, e no necessrio enviar mensagens de KeepAlive.
7.2.4 Mensagens de Notification

Uma mensagem de Notification enviada quando uma condio de erro detectada.
Como conseqncia, a conexo BGP encerrada logo aps seu envio. Uma mensagem
Notification consiste dos seguintes campos:

Error Code
(1 byte)
pg. 24
Valter Roesler
Error Subcode
1 byte
Data
Varivel
Os bytes de Error Code e Error subcode representam o cdigo e subcdigo da

mensagem de erro. Os seguintes erros foram definidos [MOU 99], [RFC 1761]:
Cdigo de erro
1. Erro no cabealho da mensagem
2. Erro na mensagem Open
3. Erro na mensagem Update
4. Hold Time expirou

5. Erro na mquina de estados finitos
6. Cease encerra conexo
Sub cdigos de erro

1. Conexo no sincronizada
2. Comprimento da mensagem invlido
3. Tipo de mensagem invlido
1. Nmero de verso no suportado
2. Nmero de AS vizinho invlido
3. Identificador BGP invlido
4. Parmetro opcional no suportado
5. Falha na autenticao
6. Tempo de espera inaceitvel
1. Lista de atributos mal formada
2. Atributo Well-known desconhecido
3. Atributo Well-known faltando
4. Erro nas flags de atributos
5. Erro no comprimento do atributo
6. Atributo de origem invlido
7. Loop de roteamento em AS
8. Atributo next-hop invlido
9. Erro no atributo opcional
10. Campo de rede invlido
11. AS-path mal formado
Qualquer erro detectado na mquina de
estados do BGP gera esta notificao de erro.
Na ausncia de erros a conexo pode ser
desfeita por qualquer parte, e este tipo no
deve ser considerado erro, mas encerramento
de conexo.
7.2.5 Mensagens de Update

As mensagens de Update so usadas para transferir informaes de rotas entre pares
BGP, e essas informaes podem ser usadas para construir um grafo com os relacionamentos
dos vrios AS envolvidos. Aplicando certas regras, loops e outras anomalias podem ser
detectadas e removidas do roteamento.
Uma mensagem de Update usada para anunciar uma rota com o par BGP ou para
eliminar rotas inviveis. Este tipo de mensagem sempre contm um cabealho e outros
campos, conforme mostra a figura a seguir [RFC 1761, pg. 11], [MOU 99].
pg. 25
Valter Roesler
Unfeasible Routes Length

2 bytes
Withdrawn Routes
varivel
Total Path Attribute Length
2 bytes
Path Attributes
varivel
Network Layer Reachability Information
varivel
Unfeasible Routes Length: indica o tamanho total do campo Withdrawn Routes.

Um valor de zero indica que nenhuma rota est sendo removida e o campo seguinte
no est presente na mensagem.
Withdrawn Routes (Rotas Removidas): contm uma lista de nmeros IP para as
rotas que esto sendo eliminadas do servio. Cada endereo codificado na tupla
<length, prefix>. Maiores detalhes na RFC 1761.
Total Path Attribute Length: indica o tamanho total do campo Path Attributes e
permite saber o comprimento do campo Network Layer Reachability. Um valor de
zero indica que no existe campo de Network Layer Reachability nesta mensagem.
Path Attributes: este campo varivel est presente em toda mensagem de Update e
representa um conjunto de atributos associados a uma determinada rota que
influenciam no processo de deciso para o BGP escolher a melhor rota. Tais
atributos so compostos pela tripla <attribute type, attribute length, attribute value>.
Network Layer Reachability Information (NLRI): contm uma lista de prefixos IP
no formato <length, prefix> com informaes de alcance da rede. Por exemplo, uma
entrada do tipo <20, 200.248.168.0> indica uma rota para a subrede 200.248.168.0
com mscara 255.255.240.0, ou 200.248.168.0/20 (na notao CIDR).
7.3 ATRIBUTOS BGP

Como visto acima, as mensagens de Update incluem o campo Path Attributes, que
possui informaes dos atributos BGP para as rotas anunciadas no campo NLRI. As
categorias de atributos so:
Well Known Mandatory (WKM): atributos conhecidos (por todas verses de BGP) e
obrigatrios (devem estar presentes em todas mensagens BGP)
Well Known Discretionary (WKD): atributos conhecidos (por todas verses de BGP)
mas no precisam estar presentes em todas mensagens
Optional Transitive (OT): atributos opcionais (no precisam ser conhecidos por todas
verses BGP) que so retransmitidos para os vizinhos caso a flag transitive esteja
ativada.
Optional NonTransitive (ONT): atributos opcionais (no precisam ser conhecidos por
todas verses BGP) que so ignorados caso a implementao BGP no o reconhea.
A tabela a seguir resume rapidamente as categorias de atributos BGP. Maiores detalhes

em [MOU 99] e na RFC 1761. O campo cdigo de atributo possui valores padronizados
pg. 26
Valter Roesler
pelo IANA, e podem ser encontrados em http://www.isi.edu/in-notes/iana/assignments/bgpparameters.
Tipo
1
2
3
4
5
6
7
255
Atributo
ORIGIN
AS_PATH
NEXT_HOP
MULTI_EXIT_DISC
LOCAL_PREF
ATOMIC_AGGREGATE
AGGREGATOR
Referncia:
RFC 1771
RFC 1771
RFC 1771
RFC 1771
RFC 1771
RFC 1771
RFC 1771
Categoria
WKM
WKM
WKM
ONT
WKD
WKD
OT
Reservado para
desenvolvimento
7.3.1 ORIGIN
O atributo ORIGIN indica a origem do anncio da rota. Pode ser originado de um IGP
(de dentro do mesmo AS identificado por i na tabela de rotas), um EGP (origem um AS
externo identificado por e) ou incompleto (origem desconhecida ou configurada por rota
esttica identificado por ?). O exemplo a seguir mostra o resultado de uma consulta
(observe que os identificadores i, e e ? aparecem na direita da tabela de rotas do BGP [MOU
99].
roteador>show ip bgp
* i0.0.0.0 204.189.152.169 100 0 3561 i
* i 204.189.152.153 100 0 3561 i
*> 204.189.152.141 0 3561 i
*> 12.128.70.48/28 200.255.125.4 0 4230 8031 i
* i 200.230.6.4 100 0 4230 8031 i
*> 32.96.204.0/24 200.255.125.4 0 4230 2685 ?
* i 200.230.6.4 100 0 4230 2685
7.3.2 AS_PATH
O AS_PATH representa a seqncia de ASN (AS Numbers) que uma rota cruza para
alcanar determinada rede destino. medida que a mensagem passa pelos ASs, cada um
acrescenta seu ASN no incio da seqncia de ASNs, repassando a informao para seus pares
(que iro repetir o processo). No final, a lista conter todos os ASs que a mensagem passou
naquele caminho (AS sequence). Caso um AS receba uma lista com seu prprio AS nela,
sinal que pode haver loop de roteamento, e, para evitar isso, este anncio ser rejeitado e
descartado.
Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informao contida
no AS_PATH no alterada.
A informao contida no AS_PATH uma das usadas no processo de escolha da
melhor rota para um destino. Ao comparar duas rotas para o mesmo destino, o BGP vai
preferir a de menor AS_PATH.
pg. 27
Valter Roesler
7.3.3 NEXT_HOP
O atributo NEXT_HOP possui o endereo IP da interface do prximo roteador para
chegar a determinado destino. O exemplo a seguir mostra informaes de NEXT_HOP
aprendidas atravs de mensagens Update [MOU 99].
roteador> show ip bgp
*> 139.82.0.0 200.159.255.253 20 0 2715 i
*>i143.54.0.0 200.132.0.16 1 100 0 i
7.3.4 MULTI_EXIT_DISC
O atributo MULTI_EXIT_DISCRIMINATOR (MED) informa aos vizinhos BGP
externos qual o melhor caminho para uma determinada rota dentro do prprio AS,
influenciando-os no caso do AS possuir diversos pontos de entrada.
Somente o AS origem pode fazer anncios MED a outros ASs vizinhos, entretanto, os
outros AS no podem repassar este valor a outros ASs, e somente usa este atributo para
tomada de decises internas.
7.3.5 LOCAL_PREF
O atributo LOCAL_PREF serve para anunciar o caminho preferencial de sada (de
pacotes) para uma determinada rota, destinada a uma rede externa ao AS.
7.3.6 AGGREGATOR
O atributo AGGREGATOR pode ser includo em mensagens Update que sejam
formadas por agregao. Este atributo contm o ASN do ltimo roteador que formou uma rota
agregada, seguido do seu ASN e endereo IP.
8 Constraint Based Routing

/**/ ver apostila de QoS est explicado superficialmente l.
9 Bibliografia
[HUI 99]
HUITEMA, Christian. Routing in the Internet. Second edition. Ed. Prentice

Hall, New Jersey, 1999. 384 p.
[MOU 99] MOURA, Alex Soares. O protocolo BGP partes 1, 2 e 3. RNP: News
Generation. 1999.
[RFC 1058] HEDRICK, C. Routing Information Protocol. IETF: California. Jun 1988.
[RFC 1723] MALKIN, G. RIP Version 2. Carrying Additional Information. IETF:
California. Nov 1994.
[RFC 1850] BAKER, F. COLTUN, R. OSPF Version 2 Management Information Base.
IETF: California. Nov 1995.
[RFC 1930] HAWKINSON, J. BATES, T. Guidelines for creation, selection and
resgistration of an Autonomous System (AS) (Best Current Practice). IETF:
California. Mar 1996.
pg. 28
Valter Roesler
[RFC 1761] REKHTER Y. LI, T. A Border Gateway Protocol 4 (BGP-4) (Standards Track).
IETF: California. Mar 1995.
[RFC 2178] MOY, J. OSPF Version 2. IETF: California. Jul 1997.
[TAN 96]
TANENBAUM, Andrew C. Redes de Computadores. 3a edio. Ed. Campus,

Rio de Janeiro, 1996. 923p.
OUTROS TRABALHOS EM:

www.projetoderedes.com.br

Redes e Roteamentos PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Redes e Roteamentos PDF

Загружено:

Авторское право:

Доступные форматы

OUTROS TRABALHOS EM:

Autor: Valter Roesler

Roteamento em redes de computadores

Sistemas Autnomos ..........................................................................................................3

Roteamento em redes de computadores

Os protocolos IGP mantm a comunicao entre os roteadores limitada ao domnio, ou

Roteamento em redes de computadores

No utilizar determinado AS;

2.1 Roteamento por Vetor de Distncia

2.1.1 Exemplo de funcionamento cidades

Roteamento em redes de computadores

2.1.2 Exemplo de funcionamento real

Roteamento em redes de computadores

Nova tabela de A com o que

Quando o roteador A receber a atualizao de B, sua tabela fica da seguinte forma:

Nova tabela de A com o que

2.1.3 Problemas da contagem ao infinito

Roteamento em redes de computadores

2.1.4 Solues para a contagem ao infinito

Roteamento em redes de computadores

Dividir o Horizonte O roteador sempre propaga todas as rotas conhecidas, menos as

2.2 Estado de Enlace

Roteamento em redes de computadores

2.2.1 Descobrir seus vizinhos e aprender seus endereos de rede

2.2.2 Medir o retardo para cada um dos vizinhos

2.2.3 O pacote LSP (Link State Packet)

A identidade do transmissor deve identificar o mesmo univocamente na rea em que ele

Roteamento em redes de computadores

2.2.4 Enviar esse pacote a todos outros roteadores (Flooding)

Roteamento em redes de computadores

O procedimento de flooding inclui um reconhecimento (ACK) de cada mensagem

2.2.5 Calcular o caminho mais curto para cada um dos roteadores.

2.3 Estado de Enlace x Vetor de Distncia

Suporte a mltiplos caminhos possvel no Estado de Enlace, e o roteador pode

Roteamento em redes de computadores

Banda Consumida O algoritmo de Estado de Enlace melhor, pois as atualizaes

3 RIP V1 (Routing Information Protocol Version 1)

Utiliza o nmero de hops como mtrica;

Roteamento em redes de computadores

Os comandos mais comuns so Comando 1: requisio de tabela de roteamento e

4 RIP V2 (Routing Information Protocol Version 2)

Autenticao: Se uma famlia de rede 0xFFFF, a primeira rota uma senha;

Roteamento em redes de computadores

Os campos command, Address Family Identifier, IP address e metric possuem

4.2 Route Tag

4.3 Subnet Mask

4.4 Next Hop

Roteamento em redes de computadores

4.6 RIP com IPv6

5 OSPF (Open Shortest Path First)

Usa outras mtricas alm da contagem de hops;

A informao enviada novamente (flooding) toda vez que um roteador descobre um

5.1 O banco de dados OSPF

Roteamento em redes de computadores

utilizados para encontrar o melhor caminho dependendo da mtrica necessria para a

Link State ID (4 bytes)

Advertising router (4 bytes)

LS sequence number (4 bytes)

Os campos vistos na figura tm o seguinte significado [HUI 99, pg138]:

Roteamento em redes de computadores

Link-State ID: a identificao do link escolhida pelo roteador (normalmente um

5.1.1 O custo das rotas (mtricas)

Cdigo RFC 1349