552_redes_roteamento

8/6/2019 552_redes_roteamento

1/28

Roteamento em redes decomputadores

Autor: Valter RoeslerUniversidades: UNISINOS e UFRGS

Data: maio de 2001


2/28

Roteamento em redes de computadores pg. 2Valter Roesler

SUMRIO1 Sistemas Autnomos ..........................................................................................................32 Algoritmos de roteamento ..................................................................................................4

2.1 Roteamento por Vetor de Distncia............................................................................42.1.1 Exemplo de funcionamento cidades................................................................4

2.1.2 Exemplo de funcionamento real ......................................................................52.1.3 Problemas da contagem ao infinito ....................................................................62.1.4 Solues para a contagem ao infinito .................................................................7

2.2 Estado de Enlace.........................................................................................................82.2.1 Descobrir seus vizinhos e aprender seus endereos de rede...............................92.2.2 Medir o retardo para cada um dos vizinhos........................................................92.2.3 O pacote LSP (Link State Packet) ......................................................................92.2.4 Enviar esse pacote a todos outros roteadores (Flooding).................................102.2.5 Calcular o caminho mais curto para cada um dos roteadores...........................11

2.3 Estado de Enlace x Vetor de Distncia.....................................................................113 RIP V1 (Routing Information Protocol Version 1) ..........................................................124 RIP V2 (Routing Information Protocol Version 2) ..........................................................13

4.1 Autenticao .............................................................................................................144.2 Route Tag .................................................................................................................144.3 Subnet Mask .............................................................................................................144.4 Next Hop...................................................................................................................144.5 Multicasting..............................................................................................................154.6 RIP com IPv6............................................................................................................15

5 OSPF (Open Shortest Path First)......................................................................................155.1 O banco de dados OSPF ...........................................................................................15

5.1.1 O custo das rotas (mtricas)..............................................................................17

5.2 Os protocolos OSPF .................................................................................................185.2.1 O protocolo Hello .............................................................................................185.2.2 O protocolo Exchange ......................................................................................195.2.3 O protocolo Flooding........................................................................................19

5.3 Mltiplas reas no OSPF ..........................................................................................195.4 OSPF para IPv6 ........................................................................................................20

6 Comparao RIP-1, RIP-2 e OSPF...................................................................................207 BGP-4 (Border Gateway Protocol 4)................................................................................20

7.1 Sesso BGP...............................................................................................................217.2 Mensagens BGP .......................................................................................................21

7.2.1 Mensagens de cabealho ..................................................................................22

7.2.2 Mensagens de Open ......................................................................................227.2.3 Mensagem de KeepAlive..................................................................................237.2.4 Mensagens de Notification............................................................................237.2.5 Mensagens de Update ...................................................................................24

7.3 ATRIBUTOS BGP...................................................................................................257.3.1 ORIGIN ............................................................................................................267.3.2 AS_PATH.........................................................................................................267.3.3 NEXT_HOP......................................................................................................277.3.4 MULTI_EXIT_DISC .......................................................................................277.3.5 LOCAL_PREF .................................................................................................277.3.6 AGGREGATOR...............................................................................................27

8 Constraint Based Routing.................................................................................................27


3/28


9 Bibliografia.......................................................................................................................27

1 Sistemas Autnomos

Internet um conjunto de sistemas autnomos interligados, ou seja, uma interligao devrios domnios. Domnio a rede interna de uma organizao, ou seja, uma coleo deestaes 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, sendodefinido atualmente como um inteiro de 16 bits (65536 nmeros). O IANA reservou o blocode 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 GatewayProtocols), e os EGP (Exterior Gateway Protocols), como mostra a figura a seguir.

Os protocolos IGP mantm a comunicao entre os roteadores limitada ao domnio, ouseja, 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 PathFirst), que utilizam, respectivamente, algoritmos de vetor de distncia e estado de enlacepara descobrir a topologia da rede.

Os protocolos EGP so necessrios para que exista comunicao entre domnios, ouseja, 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 soos 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, organizaesdiferentes e at pases diferentes precisam se comunicar, e existem certas polticas que devemser respeitadas, at mesmo por questes econmicas e de segurana, como, por exemplo[TAN 96, pg 489].


4/28


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 roteamentoExistem duas formas de um roteador ser configurado: atravs de roteamento esttico eroteamento dinmico. No roteamento esttico, um administrador configura manualmente arota. Uma delas configurada sempre a rota default. Como provocam um trabalhoconsidervel, o roteamento esttico adequado para rotas que no mudam com muitafreqncia.

O roteamento dinmico depende de algoritmos para descobrir o melhor caminho.Basicamente, existem dois tipos de algoritmos para roteamento dinmico em redes IGP: oroteamento porVetor de Distncia e o roteamento porEstado 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 melhordistncia conhecida aos diversos destinos alcanveis, bem como a sada a ser usada parachegar l. Essa tabela atualizada a partir de troca de informaes com os vizinhos, queinformam sobre seus vizinhos, e assim por diante.

Esse algoritmo tambm conhecido pelo nome de seus desenvolvedores, ou Bellman-Ford (1957) e Ford-Fulkerson (1962), e foi usado originalmente na Internet com o nome deRIP [TAN 96, pg 406].

A mtrica permitida pelo algoritmo pode ser nmero de hops (usado no RIP), retardo detempo em milisegundos, nmero de pacotes na fila ou algo semelhante. A seguir ser feito umexemplo ilustrativo de funcionamento do protocolo e em seguida um exemplo mais real.

2.1.1 Exemplo de funcionamento cidadesImagine 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 parachegar ao destino seja a distncia mais curta (poderia ser a melhor estrada, por exemplo), elestm 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 atravsdeles 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 SoLeopoldo (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.

SoLeopoldo

BR-116S

BR-116NTabela SL

Destino Custo RotaSL 0 -


5/28


Em seguida, as duas cidades vizinhas enviam suas tabelas. Suponha que seja possvelmedir a distncia entre os vizinhos atravs de mensagens especiais. Assim, a tabela de SoLeopoldo incrementada com Novo Hamburgo, a 10 km e Canoas, a 15 km.

SoLeopoldo

CANOAS

NovoHamburgo

BR-116S15Km

BR-116N10KmTabela SL

Destino Custo RotaSL 0 - NH 10 BR-116NCAN 15 BR-116S

Conforme o tempo passa, as outras cidades vo aprendendo rotas novas atravs da trocade 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 parachegar em Porto Alegre e Taquara, e tambm recebeu de Canoas as distncias para chegar emPorto Alegre. Como a distncia mais curta para Porto Alegre via Canoas, a tabela fica deacordo com a rota mais curta.

SoLeopoldo

CANOAS

NovoHamburgo

BR-116S15Km

BR-116N10Km

Tabela SLDestino Custo Rota

SL 0 - NH 10 BR-116NCAN 15 BR-116STAQ 45 BR-116NPOA 30 BR-116S

Taquara

PortoAlegre

15Km

35Km

55Km

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, eleatualiza sua tabela com a menor distncia e a rota de sada para chegar num destino.

2.1.2 Exemplo de funcionamento realImagine 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.


6/28


O roteador A, quando iniciado, monta uma tabela das rotas conhecidas. Esta tabela enviada para todos os links do roteador.

Roteador ADestino Custo

A 0B 2G 6

Cada roteador troca suas tabelas com os roteadores vizinhos de tempos em tempos. Asnovas rotas recebidas so calculadas e adicionadas. No exemplo abaixo, o roteador A recebe atabela de G, gerando a nova tabela de A. Note que as rotas E e H foram adicionadas e umcusto de 6 foi adicionado a cada rota recebida por causa do custo do link entre A e G.

Roteador GDestino Custo

G 0

A 6E 1H 4

Roteador ADestino Custo Rota

A 0 -B 2 BG 6 GE 6+1 = 7 GH 6+4 = 10 G

Nova tabela de A com o queaprendeu de G


A 0 -B 2 BG 6 G

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


A 0 -B 2 B

C 2+7=9 BE 2+2=4 BG 6 GH 10 G

Roteador BDestino Custo

A 2B 0C 7E 2


A 0 -B 2 BE 7 GG 6 GH 10 G

Nova tabela de A com o queaprendeu de G e B

A nova rota C foi encontrada. Note que a rota para E tambm foi modificada, pois existeum caminho com custo menor por B.

2.1.3 Problemas da contagem ao infinitoO 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)


7/28


mostra as distncias de todos os roteadores recm ligados para A. Pode-se ver que, em 3atualizaes 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 aser eliminadas, podendo ocasionar loops, que so pacotes que ficam sendo repassados de umroteador para outro durante certo tempo. Para o pacote no ficar em loop infinito em umarede, todo o pacote possui um contador TTL.

O contador TTL (Time to Live) de cada pacote comea com um valor padro de 15 e vaisendo diminudo medida que passa por um roteador. Assim, se uma rede estive em loop, oTTL 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 distnciaat A para 3+1=4, e assim por diante. Vai levar em torno de 7 ciclos de atualizaes paraque todos saibam que A est fora, e isso d mais de 3 minutos (considerando 30 segundos

para cada ciclo de atualizao).

A B C D

- - -

1 - -

21

1 2

-

No existe A

Aps 1 troca

Aps 2 trocas

Aps 3 trocas3

A B C D

1 2 3

2 3

4

3

5

6

3

Inicialmente

C atualiza B

B atualiza C

C atualiza B e D5B recebe tabela de Cantes de enviar paraC. Pensa que chegaem A via B com 3hops (2 informados

por C mais um parachegar em C)

B atualiza C

C atualiza B e D

Aps algumastrocas

A sai do ar. Bdetecta e atualizatabela (16 parachegar em A)

Neste instante Cainda acha que chega

em A com 2 hops,informando para B e

para D

5

...

77

...

1616 16a)

b)

16

5

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 ocaminho 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 rotaalternativa.

Poison Reverse and Triggered Updates Se um link falhar, modifica a informaoda rota para uma distncia infinita (16) e propaga imediatamente essa informaoadiante (no d tempo de receber a atualizao de outro n). Assim, se houver algumaoutra rota para C, essa rota ser utilizada, pois ser melhor que uma distncia infinita.


8/28


Dividir o Horizonte O roteador sempre propaga todas as rotas conhecidas, menos asrotas que foram recebidas pela mesma porta. Baseando-se na figura anterior, quando Canunciar as suas rotas, ele no anunciar para B o que ele recebeu de B. Veja oexemplo 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 suaatualizao, 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 deenlace que cada roteador faa o seguinte [TAN 96]:

1. Descobrir seus vizinhos e aprender seus endereos de rede2. Medir o retardo para cada um dos vizinhos

3. Criar um pacote que diga tudo o que acaba de ser aprendido. Cada roteador constrium pacote chamado de Link State Packet ou LSP, que contm o seu nome, o nomede seus vizinhos e o custo necessrio para chegar at eles.

4. Enviar esse pacote a todos outros roteadores5. 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 atopologia da rede, para conseguir traar o caminho mais curto atravs de um algoritmo, comoo de Dijkstra, por exemplo. Assim, para a topologia acima, cada roteador deve ter um bancode dados semelhante ao mostrado na tabela a seguir [HUI 99, pg 120]. Este banco de dadosdeve ser o mesmo em todos os roteadores, a fim de que todos tomem as mesmas decises.


9/28


Origem Destino CustoA B 6A D 2B A 6B C 2B E 1

C B 2C F 2C G 5D A 2D E 2E B 1E D 2E F 4F C 2F E 4F G 1G C 5

G F 1

2.2.1 Descobrir seus vizinhos e aprender seus endereos de redePara 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 roteadorrecebe um pacote Hello ele responde com outro pacote contendo seu nome. Os nomes dosroteadores no podem ser duplicados [TAN 96, pg 411]. Os pacotes Hello tambm soutilizados para saber se um link est operacional [HUI 99, pg. 145]. Maiores detalhes noestudo 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 eesperar resposta. A mdia de vrios tempos de resposta dividida por dois uma estimativa doretardo [TAN 96, pg 411]. O tamanho da fila e a carga na rede tambm podem ser levados emconsiderao.

No algoritmo de estado de enlace, outras mtricas podem ser medidas e levadas emconsiderao, como a velocidade das linhas, sua segurana, e assim por diante. No item decomparao entre os algoritmos de estado de enlace e vetor de distncia isso ser maisdetalhado.

2.2.3 O pacote LSP (Link State Packet)

Os roteadores utilizam o pacote LSP (Link State Packet) para trocar as informaes derotas com os outros roteadores. Seu formato mostrado na tabela a seguir (para roteador B).

Identidade do TransmissorNmero de seqncia

Idade (Tempo)Destino Custo

A 6C 2E 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


10/28


idade ficaro mais claros no prximo item, que trata da problemtica de enviar este pacote atodos os outros roteadores da rede.

2.2.4 Enviar esse pacote a todos outros roteadores (Flooding)Um pacote mandado quando um roteadordescobre 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 aporta em que veio.

Para o flooding no se propagar ao infinito, gerando uma exploso de pacotes, pode serusado um contador TTL com um limite de hops que decrementado a cada roteador, equando chega a zero, descartado. O ideal que o TTL seja inicializado com o comprimentodo caminho da origem ao destino [TAN 96, pg. 400]. No caso do OSPF, utiliza-se umnmero 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 quecada pacote LSP enviado possui um nmero de seqncia diferente do anterior, o roteadorsabe se o mesmo pacote foi recebido mais de uma vez, ento, ele no repassa os pacotesrepetidos. 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 deatualizar o roteador que est propagando rotas mais antigas. Caso receba um pacote com umnmero de seqncia maior do que o existente no banco de dados, atualiza o banco de dadoscom o pacote mais novo e envia o pacote para todas suas portas, menos pela qual o pacotefoi recebido [HUI 99, pg 121].

Por exemplo, suponha que o link entre A e B tenha cado. A deve enviar essa mudana atodos os roteadores, e B deve fazer o mesmo. Supondo que o nmero de seqncia inicialtenha sido 1, A vai enviar a seguinte informao para D (nica porta ativa).

Origem Destino Custo SeqnciaA B infinito 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 mesmainformao, 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 eG. 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 pelaqual o pacote no chegou.

Caso o link entre D e E caia tambm, o mesmo acontece, mas existiro duas redesseparadas se atualizando independentemente. Caso um link volte ao ar, haver a necessidade


11/28


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 corrupoacidental. Por exemplo, caso ocorra um erro de memria ou de transmisso, levando o nmerode seqncia para um nmero elevado, todas as atualizaes de rota sero descartadas, poissero sempre mais antigas que o nmero corrupto. Para evitar isso, o algoritmo do OSPFutiliza alguns mecanismos de proteo, como os seguintes [HUI 99, pg 124]:

O procedimento de flooding inclui um reconhecimento (ACK) de cada mensagemenviada;

Cada LSP protegido por um timer, e removido do banco de dados caso este timerexpire;

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, deveconstruir uma rvore lgica para chegar a qualquer outro roteador pelo caminho com menorcusto. A figura a seguir mostra os caminhos mais curtos (onde a mtrica a distncia) para osroteadores 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 depacotes fora de ordem, mas isso consertado no nvel TCP), deixando o fluxo maisrpido. 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 menorcusto dependendo da necessidade da aplicao. Por exemplo, suponha que na figura aseguir exista uma aplicao de voz e outra de dados partindo de A com destino a D. Omelhor caminho para a aplicao de voz seria o de menor atraso (A-E-D), enquantoque para a de dados seria o de maior vazo (A-B-C-D). O OSPF verso 2 suporta os 4mecanismos definidos no campo IP TOS (Type Of Service), que so: maior vazo,menor atraso, menor custo e maior segurana [HUI 99, pg 127];


12/28


1,5Mbit/s20 ms

1,5Mbit/s20 ms

64 Kbit/s20 ms

64 Kbit/s20 ms

1,5Mbit/s275 ms

Link de satlite

C

EB A

D

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 vantagemadicional, 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. Quandoimplementado em hosts, eles utilizam o modo passivo (somente ouvem as rotas e no enviamatualizaes). 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 300entradas necessita de 12 pacotes;

Utiliza sempre o caminho mais curto, impossibilitando engenharia de trfego ouroteamento baseado em QoS;

Possui uma convergncia lenta, pois uma nova rota vai sendo enviada a cada 30segundos 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 doidentificador da famlia do endereo at a mtrica pode se repetir at 25 vezes [RFC 1058].


13/28


0 1 2 3 30 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 eComando 2: resposta contendo tabela. A famlia da rede o nmero do protocolo, pois o RIPno 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-00-

00-09. O RIP v1 utiliza broadcast.

O formato do pacote RIPv2 pode ser visto na figura a seguir:

0 1 2 3 30 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) |+---------------------------------------------------------------+


14/28


Os campos command, Address Family Identifier, IP address e metric possuemo mesmo significado da RFC 1058. O campo verso deve ser 2 nas mensagens que usamautenticao ou informaes sobre os campos novos.

4.1 Autenticao

Para que o cabealho seja de autenticao, o campo Address Family Identifier deveser 0xFFFF, e o restante do cabealho contm a autenticao, conforme mostrado na figura aseguir.

0 1 2 3 30 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 16bytes 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 rotasexternas ao RIP (anunciadas de outro IGP ou EGP) [RFC 1723].

4.3 Subnet Mask

A mscara de subrede permite adaptar o esquema classfullde endereos IP para o usode 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 pacotedeve ser redirecionado para chegar no destino informado no cabealho. Os endereos do nexthop devem, obrigatoriamente, ser alcanados diretamente atravs da subrede pela qual oanncio feito.

No exemplo a seguir, IR1 at IR3 so roteadores internos. XR1 at XR3 so roteadoresde outra rea, com outra administrao. Configurando corretamente, o roteador XR3 seria onext 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, seriamnecessrios pacotes adicionais com IR1, IR2 e IR3 informando que ele seria o responsvelpara chegar em N1 e N2 [RFC 1723, apndice A].


15/28


Subrede nica

IR2

XR3

IR3IR1

XR1 XR2

N1

N2

N3

N4

N5N6

N7

4.5 Multicasting

A fim de reduzir carga desnecessria de CPU para hosts que no querem recebermensagens de roteamento, foi definido o grupo multicast 224.0.0.9 (roteadores RIP2 [RFC1700]). 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 roteadordescobre umnovo vizinho, o custo de um link muda, um link cai ou passa determinado tempo (30minutos no caso do OSPF).

5.1 O banco de dados OSPF

Cada roteador OSPF de mesma rea utiliza um banco de dados representando atopologia da rede (de acordo com o algoritmo de estado de enlace), e esses dados so


16/28


utilizados para encontrar o melhor caminho dependendo da mtrica necessria para aaplicao [HUI 99, pg 138].

A troca de informaes entre os roteadores para a atualizao da base de dados se datravs da troca de pacotes de estado de enlace, ou LSPs ( Link-State Packets). O cabealho comum a todos, e mostrado na figura a seguir.

Link-State age(2 bytes)

Options(1 byte)

24168

1

2

3

310LS type(1 byte)

LS Checksum

(2 bytes)

Length

(2 bytes)

LS sequence number (4 bytes)4

5

Link State ID (4 bytes)

Advertising router (4 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 tempoem segundos desde que aquela rota foi anunciada pela primeira vez. O roteador enviaa rota com idade zero. Durante o flooding, cada roteador por onde a mensagem passaincrementa de um esse valor, e depois vai incrementando de segundo em segundo.Quando ele atinge MaxAge (uma hora), o registro considerado obsoleto edescartado. Entretanto, como todos os roteadores devem ter a mesma cpia do bancode dados, esse processo deve ser sncrono, portanto, anunciado via flooding [HUI

99, pg 151]. Para garantir que os registros no fiquem velhos, os roteadores devemreenvia-los a intervalos regulares, no mnimo a cada 30 minutos. Este novo registrodeve possuir o mesmo contedo, mas com o nmero de seqncia incrementado e aidade 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 quecomeam no prprio roteador ( o tipo mais comum);

2. network link: so enviados pelos roteadores designados com destino aroteadores de redes trnsito;

3. summary link (rede IP): anunciado pelos roteadores de borda destinado aosroteadores de dentro de uma rea, e a diferena para o router link que enviaum anncio separado para cada destino;

4. summary link (border router): o mesmo que acima s que para o roteador deborda da rea;

5. external link: registros enviados por roteadores de borda e destinados aroteadores externos ao AS.


17/28


Link-State ID: a identificao do link escolhida pelo roteador (normalmente umnmero IP). Pela definio, os camposLink-State ID mais oAdvertising routermais 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 dedados. A utilidade deste campo foi explicada em maiores detalhes anteriormente, naexplicao do flooding do algoritmo de estado de enlace.

LS Checksum: usado para proteger os dados e o cabealho (menos o campo LSAge, 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 daRFC 1349). Caso o roteador tenha suporte a TOS, ele deve obter uma tabela de custo separadapara cada mtrica, e dependendo da aplicao, utilizar a mtrica correspondente. A definiodo tipo de mtrica feita de acordo com a tabela a seguir [HUI 99, pg 143]:

Cdigo OSPF Cdigo RFC 1349 Definio0 0000 Servio normal2 0001 Minimiza custo4 0010 Maximiza segurana8 0100 Maximiza vazo16 1000 Minimiza atraso

Assim, caso um pacote IP possua o campo TOS de 1000, a mtrica a ser utilizada peloroteador deve ser a de menor atraso, ou de nmero 16. Caso o roteador no tenha suporte aTOS, deve zerar o bit 0 do campo options. Esses campos so codificados no anncio dasrotas, em tabelas definidas atravs do tipo do registro (LS Type). Maiores detalhes na RFC2178 pg 176 ou em [HUI 99, pg 140].

Os valores de mtrica devem ser inteiros, sendo que os valores menores correspondems melhores rotas.

A mtrica de maximizar a vazo utiliza a frmula 10^8/ifspeed [RFC 1850, pg 39]. Atabela a seguir especifica alguns valores para a mtrica 8.

Velocidade Mtrica9,6 Kbit/s 10.41656 Kbit/s 1.785

2.048 Mbit/s 4810 Mbit/s 10

100 Mbit/s e acima 1

Isso cria um problema para redes de alta velocidade, pois no tem como diferenciar umlink 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 necessriopara 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.


18/28


5.2 Os protocolos OSPF

O OSPF composto de trs subprotocolos bsicos: Hello, Exchange e Flooding. Todoseles utilizam um formato nico de cabealho, visto na figura a seguir [RFC 2178, pg 164].

0 1 2 30 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. Essasmensagens so usadas quando uma linha interrompida (bringing upadjacencies);

3. Link State Request: Solicitao de atualizao por parte de um roteador a seuvizinho;

4. Link State Update: Mensagens emitidas periodicamente para seus vizinhos,

informando seu estado e custo de acesso aos outros vizinhos. Cada mensagemincrementa o nmero de seqncia;

5. Link State Acknowledgment: Todas as mensagens so reconhecidas paraaumentar 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 HelloO 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 pacotesdevem 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 60segundos) [RFC 1850, pg 44].


19/28


5.2.2 O protocolo ExchangeQuando 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 FloodingCada 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 deseqncia 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 dadosfique 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 estarligadas ao backbone central, conforme mostra a figura a seguir.

rea de Backbone(0.0.0.0)

ABR ABR ABR

rea 1(0.0.0.1)

rea 2(0.0.0.2)

rea 3(0.0.0.3)

Os roteadores de borda de rea (ABR Area Border Routers) sumarizam a topologia ea transmitem para a rea de backbone que, por sua vez, retransmitem essa informao para asoutras 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 suportarisso, 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.


20/28


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 RIP-2 OSPF

RFC RFC 1058 RFC 1723 RFC 2178Algoritmo Vetor de distncia Vetor de distncia Estado de enlaceSuporte a mltiplasmtricas

No (hops) No (hops) Sim

Suporte a CIDR No Sim SimSuporte a mltiploscaminhos

No (o mais curto) No (o mais curto) Sim

Mximo dimetro da rede 15 Hops 15 Hops 65.535

Intervalo de Atualizao 30 segundos 30 segundosA cada mudana ou30min

Atualizaes Toda a tabela de rotas Toda a tabela de rotas Somente vizinhos (LSP)Intervalo para eliminao 180s 180s ?Autenticao No Sim (senha aberta)1 Sim (senha MD5)Velocidade deConvergncia

Devagar Devagar ??/**/ Rpido

Suporta AS# No Sim ?? /**/ Sim

1. A RFC 2082 define um esquema para encriptar a senha via MD5 para evitar a transmissode 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 trocarinformaes de acessibilidade com outros sistemas BGP com o objetivo de traar um grafo daconectividade do AS, visando eliminar problemas de laos e reforar decises de polticas dosistema (como, por exemplo, a poltica de anunciar para os AS vizinhos somente as rotas queele 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 (extendednetwork 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, aocontrrio do RIP, cada roteador mantm o controle total de cada caminho (da origem aodestino) utilizado por cada roteador envolvido na rede [TAN 96, pg 490].

Para exemplificar, considere os roteadores mostrados na figura a seguir [TAN 96, pg491]. Considere o roteador F. Suponha que ele esteja utilizando o caminho FGCD para chegara 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 rotasde I e F, pois usam ele mesmo como passagem. Assim, sobra analisar as distncias para B e


21/28


G. Qualquer rota que passe por alguma rede politicamente restrita deve ser evitada (distnciamarcada como infinito). Aps essas eliminaes, o roteador usa a rota com distncia maiscurta.

A

E

B

I

F

G

C

D

H

J

Informao sobre D que Frecebe dos vizinhos

De B: rota BCDDe G: rota GCDDe I: rota IFGCDDe E: rota EFGCD

O problema da contagem ao infinito no existe no BGP. Suponha que G falhe ou que alinha FG seja desativada. Rapidamente ele descobre que o nico caminho via FBCD [TAN96, pg 491].

7.1 Sesso BGP

O BGP roda sobre TCP, porta 179, sendo, portanto, confivel (a aplicao no precisase preocupar com a confiabilidade). Dois sistemas BGP vizinhos abrem uma sesso atravsde 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 havendoconcordncia nos parmetros, a sesso no aberta.

O primeiro fluxo enviado a tabela de roteamento completa, e depois disso, somenteatualizaes 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 deatualizaes 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 adurao da conexo.

Cada atualizao das tabelas no BGP (mensagens update) provoca um incremento nonmero de verso, permitindo verificar inconsistncias nas informaes de roteamento. Oexemplo a seguir mostra a verificao da verso da tabela de roteamento [MOU 99].

roteador> sh ip bgpBGP table version is 72076, local router ID is 192.168.4.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path

(...)

7.2 Mensagens BGP

Existem diversas mensagens padronizadas no BGP. Cada mensagem composta deuma mensagem de cabealho mais a mensagem desejada. Mensagens de KeepAlive soenviadas periodicamente para assegurar que a conexo est ativa. Mensagens de notificaoso enviadas em resposta a erros ou condies especiais. Se der erro numa conexo, umamensagem de notificao enviada e a conexo fechada. As rotas so atualizadas atravs de


22/28


mensagens do tipo update. Os itens a seguir descrevem algumas dessas mensagens. Maioresdetalhes na RFC 1761.

7.2.1 Mensagens de cabealhoAs 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].

Marker16 bytes

Length2 bytes

Type1 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 campoType informe que a mensagem de Open ento todos os bits deste campo devemser 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 OPENo UPDATEo NOTIFICATIONo KEEPALIVE

7.2.2 Mensagens de OpenAps 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]:


23/28


BGP Identifier4 bytes

My AutonomousSystem2 bytes

Opt ParmLen1 byte

Version1 byte

Hold Time2 bytes

Optional Parameters4 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 comohold 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 enviadasmensagens de KeepAlive, caso contrrio, elas devem ser enviadas aaproximadamente 1/3 do valor do hold time.

BGP Identifier: nmero IP do transmissor da mensagem. Este nmero determinadono incio e o mesmo para toda interface local e todo para BGP.

Optional Parameters Length: indica o comprimento total (em bytes) do campo deparmetros. Se for zero, no existem parmetros opcionais.

Optional Parameters: cada parmetro codificado atravs da tripla . Os parmetros definidos na RFC 1761 so:Informao de autenticao; Cdigo de autenticao; Dados de autenticao.

7.2.3 Mensagem de KeepAliveAs 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 mensagemKeepAlive 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 NotificationUma mensagem de Notification enviada quando uma condio de erro detectada.

Como conseqncia, a conexo BGP encerrada logo aps seu envio. Uma mensagemNotification consiste dos seguintes campos:


24/28


DataVarivel

Error Subcode1 byte

Error Code(1 byte)

Os bytes de Error Code e Error subcode representam o cdigo e subcdigo damensagem de erro. Os seguintes erros foram definidos [MOU 99], [RFC 1761]:

Cdigo de erro Sub cdigos de erro

1. Erro no cabealho da mensagem1. Conexo no sincronizada2. Comprimento da mensagem invlido3. Tipo de mensagem invlido

2. Erro na mensagem Open

1. Nmero de verso no suportado2. Nmero de AS vizinho invlido3. Identificador BGP invlido4. Parmetro opcional no suportado5. Falha na autenticao6. Tempo de espera inaceitvel

3. Erro na mensagem Update 1. Lista de atributos mal formada2. Atributo Well-known desconhecido3. Atributo Well-known faltando4. Erro nas flags de atributos5. Erro no comprimento do atributo6. Atributo de origem invlido7. Loop de roteamento em AS8. Atributo next-hop invlido

9. Erro no atributo opcional10. Campo de rede invlido11.AS-path mal formado

4. Hold Time expirou5. Erro na mquina de estados finitos Qualquer erro detectado na mquina de

estados do BGP gera esta notificao de erro.

6. Cease encerra conexoNa ausncia de erros a conexo pode serdesfeita por qualquer parte, e este tipo nodeve ser considerado erro, mas encerramentode conexo.

7.2.5 Mensagens de UpdateAs 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 relacionamentosdos vrios AS envolvidos. Aplicando certas regras, loops e outras anomalias podem serdetectadas e removidas do roteamento.

Uma mensagem de Update usada para anunciar uma rota com o par BGP ou paraeliminar rotas inviveis. Este tipo de mensagem sempre contm um cabealho e outroscampos, conforme mostra a figura a seguir [RFC 1761, pg. 11], [MOU 99].


25/28


Unfeasible Routes Length2 bytes

Withdrawn Routesvarivel

Network Layer Reachability Informationvarivel

Total Path Attribute Length2 bytes

Path Attributesvarivel

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 seguinteno est presente na mensagem.

Withdrawn Routes (Rotas Removidas): contm uma lista de nmeros IP para asrotas que esto sendo eliminadas do servio. Cada endereo codificado na tupla. Maiores detalhes na RFC 1761.

Total Path Attribute Length: indica o tamanho total do campo Path Attributes epermite saber o comprimento do campo Network Layer Reachability. Um valor dezero indica que no existe campo de Network Layer Reachability nesta mensagem.

Path Attributes: este campo varivel est presente em toda mensagem de Update erepresenta um conjunto de atributos associados a uma determinada rota queinfluenciam no processo de deciso para o BGP escolher a melhor rota. Taisatributos so compostos pela tripla .

Network Layer Reachability Information (NLRI): contm uma lista de prefixos IPno formato com informaes de alcance da rede. Por exemplo, umaentrada do tipo indica uma rota para a subrede 200.248.168.0com 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. Ascategorias 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 todasverses BGP) que so retransmitidos para os vizinhos caso a flag transitive estejaativada.

Optional NonTransitive (ONT): atributos opcionais (no precisam ser conhecidos portodas verses BGP) que so ignorados caso a implementao BGP no o reconhea.

A tabela a seguir resume rapidamente as categorias de atributos BGP. Maiores detalhesem [MOU 99] e na RFC 1761. O campo cdigo de atributo possui valores padronizados


26/28


pelo IANA, e podem ser encontrados em http://www.isi.edu/in-notes/iana/assignments/bgp-parameters.

Tipo Atributo Referncia: Categoria1 ORIGIN RFC 1771 WKM2 AS_PATH RFC 1771 WKM3 NEXT_HOP RFC 1771 WKM4 MULTI_EXIT_DISC RFC 1771 ONT5 LOCAL_PREF RFC 1771 WKD6 ATOMIC_AGGREGATE RFC 1771 WKD7 AGGREGATOR RFC 1771 OT255 Reservado para

desenvolvimento- -

7.3.1 ORIGINO 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 ASexterno identificado por e) ou incompleto (origem desconhecida ou configurada por rotaesttica 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 [MOU99].

roteador>show ip bgp

BGP table version is 117080, local router ID is 200.180.1.142Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path* 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_PATHO 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 umacrescenta 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 passounaquele 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 edescartado.

Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informao contidano AS_PATH no alterada.

A informao contida no AS_PATH uma das usadas no processo de escolha damelhor rota para um destino. Ao comparar duas rotas para o mesmo destino, o BGP vai

preferir a de menor AS_PATH.


27/28


7.3.3 NEXT_HOPO 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_HOPaprendidas atravs de mensagens Update [MOU 99].

roteador> show ip bgp

BGP table version is 117080, local router ID is 204.189.152.142Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path

*> 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_DISCO 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, osoutros AS no podem repassar este valor a outros ASs, e somente usa este atributo paratomada de decises internas.

7.3.5 LOCAL_PREFO 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 AGGREGATORO 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: NewsGeneration. 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 andresgistration of an Autonomous System (AS) (Best Current Practice). IETF:

California. Mar 1996.


28/28


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

552_redes_roteamento

Documents