1.

Introduo

Roteamento o mecanismo atravs do qual duas mquinas em comunicao acham e

usam um caminho timo (o melhor) atravs de uma rede. O processo envolve:
Determinar que caminhos esto disponveis;
Selecionar o melhor caminho para uma finalidade particular;
Usar o caminho para chegar aos outros sistemas;
Ajustar o formato dos dados (datagramas) s tecnologias de
transporte disponveis (MTU, MSS, etc.).
! Na arquitetura TCP/IP, o roteamento baseado no endereamento IP, particularmente, na
parte de identificao de rede de um endereo IP. Toda a tarefa desenvolvida na camada
Inter-rede da pilha de protocolos TCP/IP.
A ARPANET foi a rede que iniciou o backbone da Internet. Nessa poca cada
participante administrava suas tabelas de roteamento e suas atualizaes eram feitas
manualmente. Dessa forma, a topologia da Internet em seus primrdios poderia ser descrita
como um conjunto de roteadores bsicos, conhecidos tambm por core routers ou tambm
por roteadores de borda. Estes roteadores eram controlados pelo INOC (Internet Network
Operations Center). Adicionalmente, existia tambm um conjunto de roteadores,
conhecidos como secundrios que eram administrados por grupos isolados e eram
conectados aos core routers, fornecendo acesso s redes locais de cada instituio. Em
seguida, surgiu a NFSNET que inicialmente estabeleceu um nico ponto de conexo com a
ARPANET, posteriormente aumentando o nmero dessas conexes.
Essa situao aumentou a complexidade do roteamento global, impossibilitando a
forma manual de atualizao das tabelas de rotas. Por esse motivo o esquema de diviso por
hierarquias foi sendo substitudo pelo modelo distribudo que o modelo utilizado at os
dias de hoje. Assim sendo, o roteamento no fica mais centralizado em alguns roteadores,
como nos roteadores bsicos da NFSNET, mas cada roteador responsvel pelas suas redes
e pela comunicao com os demais roteadores da Internet.
Para acompanhar tais mudanas, foi criado o conceito de sistema autnomo
(Autonomous System, ou simplesmente AS), que faz com que as redes e roteadores que
esto sob uma mesma poltica sejam administradas pela prpria entidade que os possui.
Assim, o que ocorre internamente a um AS no ser conhecido por outros sistemas
autnomos, diminuindo a complexidade da Internet global. Para a comunicao com o
mundo externo, ou seja, com os demais sistemas autnomos, deve ser utilizado pelo menos
um dos roteadores do AS para trocar informaes com os demais ASs e garantir a
alcanabilidade entre suas redes. Para cada AS atribudo um AS number, que uma
identificao nica que o identifica para os demais sistemas autnomos. Dessa forma, a
Internet global deixou de ser vista como um grande grupo de redes locais interligadas, mas
agora como um conjunto de Sistemas Autnomos que trocam anncios de rotas para suas
redes entre si. Um exemplo prtico de Sistema Autnomo seria a rede da UFRGS. Uma
analogia a sistemas autnomos seria imaginar que a Internet hoje formada por um

conjunto de "nuvens", interligados entre si, garantindo que sempre exista algum caminho
para qualquer ponto da Internet.
Diante de tais inovaes e a distribuio desta nova arquitetura, surgiu a
necessidade de protocolos de roteamento capazes de manter a consistncia e as informaes
entre os sistemas autnomos da Internet, incluindo tambm suas redes internas. Assim
surgiram diversos protocolos de roteamento com o intuito de atender a estas necessidades e
funcionalidades.
Os protocolos de roteamento dividem-se em dois grupos, explicados a seguir:

EGP (Exterior Gateway Protocol): Grupo de protocolos utilizados para a

comunicao inter AS, ou seja, usado para a comunicao entre roteadores que se
encontram em diferentes sistemas autnomos. Os protocolos deste tipo garantem
que todos os sistemas autnomos pela Internet mantenham informaes consistentes
para garantir o funcionamento do roteamento global. Exemplo de protocolo deste
grupo seria o BGP.

IGP (Interior Gateway Protocol): Grupo de protocolos utilizados na comunicao

intra AS, ou seja, usados para comunicao entre roteadores em um mesmo sistema
autnomo. Hoje este grupo representado por vrios protocolos, como RIP, OSPF,
IGRP, entre outros.

Atravs da Figura abaixo so apresentados exemplos de utilizao dos dois grupos

de protocolos. Entre o AS 1 e AS 2 utilizado o grupo de protocolos EGP, utilizando o
grupo IGP para propagao das rotas aos demais roteadores de cada sistema autnomo.

Exemplos de utilizao de protocolos IGP e EGP em sistemas autnomos.

O processo de configurao do roteamento interno a um AS pode ser feito de duas
formas. A primeira delas esttica, ou seja, baseada na configurao manual de rotas j
que em geral no existe mais que um caminho para chegar a determinada rede ou roteador
do AS. A desvantagem desta forma de configurao que, na ocorrncia de alguma
mudana na rede ou falha em alguma das conexes, o administrador deve fazer todas as

alteraes necessrias para restabelecimento da comunicao manualmente. Tambm se

torna bvio que a confiabilidade e o tempo de resposta a problemas podem no ser
satisfatrios. J a forma dinmica, baseia-se na utilizao de protocolos de roteamento que
automatizam tal tarefa, ou seja, que fazem o anncio de rotas e deteco do melhor
caminho de forma automtica, sem a interveno do administrador da rede. Caso a deciso
seja de utilizar um protocolo dinmico em um AS, dever ser utilizado um protocolo tipo
IGP para tal tarefa. J para a configurao externa de um AS dever obrigatoriamente ser
utilizado um protocolo tipo EGP, visto que no existe outra forma de propagao das redes
pertencentes a ele.
Os protocolos dinmicos podem implementar diversos algoritmos de roteamento.
Os algoritmos principais so apresentados abaixo:
a) Vetor distncia: Tambm definido como algoritmo de Bellman-Ford, este algoritmo
trabalha baseado na idia que cada roteador propaga periodicamente uma tabela com todas
as redes conhecidas e a distncia para alcan-las. Geralmente, a distncia calculada pelo
nmero de next hops necessrios para alcanar uma determinada rede. O termo HOP
caracteriza-se pela passagem entre um roteador e outro. Esse termo poderia ser equivalente
a palavra salto. Sendo assim, cada roteador, ao receber os anncios de todos os demais,
calcula o caminho timo baseado no menor nmero de HOPs para chegar a determinada
rede. Vale lembrar tambm, que cada roteador ao receber as informaes de outras redes
incrementa o nmero de HOPs e anuncia as rotas divulgadas para os demais roteadores.
b) Estado de enlace: Tambm definido como algoritmo Link State, este algoritmo trabalha
baseado na idia de que cada roteador possui informaes sobre as redes que esto
conectadas a ele e, periodicamente, testa para determinar se cada enlace est ativo. Com
estas informaes cada roteador divulga uma lista sobre o status de cada conexo, dizendo
se estas esto ativas ou inativas. Baseado nessas informaes, quando um roteador recebe
um conjunto de mensagens sobre o estado dos enlaces das redes prximas a ele, aplicado
o algoritmo SPF de Dijskstra. Este algoritmo aplicado baseado nas informaes de cada
roteador e feito localmente a cada um destes, para o clculo das melhores rotas para todos
os destinos a partir de uma mesma origem. Em termos de expanso, este algoritmo tem
vantagem sobre o Vetor Distncia, pois o clculo do melhor caminho feito localmente e
no depende do clculo de roteadores intermedirios. Outra vantagem que devido a suas
caractersticas, este algoritmo converge mais rapidamente devido a utilizao de flooding
para divulgao do estado de seus enlaces, ou seja, divulga de forma mais eficaz os
melhores caminhos para suas redes a todos os roteadores conectados.

3.

Introduo BGP

O BGP um protocolo de roteamento dinmico utilizado para comunicao entre

sistemas autnomos (ASs). Baseados nestas informaes, os sistemas autnomos
conseguem trocar informaes e determinar o melhor caminho para as redes que formam a
Internet. Tal papel muito importante sabendo que a todo momento as redes podem sofrer
alteraes, podem ocorrer quedas de suas conexes, receber anncios invlidos, aplicar

polticas, manter a conectividade por outros caminhos, adaptando-se rapidamente e

mantendo a consistncia de seus anncios de forma eficiente.
O BGP foi projetado para evitar loops de roteamento em topologias arbitrarias, o
mais serio problema de seu antecessor, o EGP (Exterior Gateway Protocol). Outro
problema que o EGP no resolve - e abordado pelo BGP - o do Roteamento Baseado em
Poltica (policy-based routing), um roteamento com base em um conjunto de regras notcnicas, definidas pelos Sistemas Autnomos.
A divulgao das informaes de roteamento BGP feita entre roteadores que
estabelecem uma relao de vizinhana, sempre na forma de pares. Tendo essa relao,
so trocadas as informaes contidas nas tabelas de roteamento BGP de cada um destes.
Para estabelecer uma relao de vizinhana necessrio que dois roteadores tenham uma
conexo direta entre eles, ou que algum protocolo IGP trate de garantir a alcanabilidade.
Essa relao de vizinhana pode definir aos roteadores uma relao de speakers ou peers.
Tratando-se de um protocolo importante que requer confiabilidade em sua
comunicao para garantir a alcanabilidade entre todas as redes da Internet, necessrio
que seja utilizada uma forma confivel de troca de informaes deste protocolo. Isso
obtido pela utilizao do protocolo TCP entre dois roteadores que trocam informaes do
protocolo BGP. A porta utilizada para a comunicao 179.
Para diferir e identificar univocamente cada sistema autnomo, cada AS possui um
nmero que o identifica mediante os demais ASs da Internet. Este nmero varia entre 1 e
65535, sendo que a faixa entre 64512 e 65535 destinada a uso privado.
A ultima verso do BGP, o BGP4, foi projetado para suportar os problemas
causados pelo grande crescimento da Internet.

3.1

Algoritmo BGP

O algoritmo que sustenta o BGP definido como PATH VECTOR, assemelhandose ao algoritmo de vetor distncia, pois a partir de informaes recebidas de outros sistemas
autnomos formado um vetor que armazena os ASs que formam um caminho para se
chegar a determinada rede. Uma vez que os roteadores divulguem tal informao,
possvel calcular o menor caminho para determinada rede. Nem sempre esse menor
caminho o escolhido, pois o BGP utiliza tambm diversos outros parmetros para
determinao do melhor caminho para determinada rede, que sero estudados a seguir.
Por tratar-se de tabelas de rotas de toda a Internet e a dinamicidade em que as
alteraes ocorrem, constantemente so trocadas mensagens de atualizaes da tabela de
roteamento. Para se ter uma idia, a tabela de roteamento BGP completa da Internet no
incio do ano de 2002 possua aproximadamente 107.000 rotas. J o nmero em Novembro
de 2002 de 116.000 rotas. A atualizao de tabelas de rotas entre roteadores vizinhos no
ocorre em intervalos de tempo pr-definidos, mas sim quando a tabela BGP sobre alguma

mudana. Isso torna a divulgao mais leve, visto que ao nvel do BGP o nmero total de
rotas da Internet muito grande e o anncio de todas as rotas seria invivel. Esta forma de
anncio pode ser definida como incremental, ou seja, sendo enviadas apenas as
atualizaes. Este modo de atualizaes incremental diminui consideravelmente o
overhead e a banda utilizada para anncios.
Para comunicao entre roteadores BGP existem alguns tipos de mensagens onde
cada um deles tem um papel importante na comunicao BGP.

Mensagens tipo OPEN so utilizadas para o estabelecimento de uma conexo BGP;

Mensagens tipo NOTIFICATION reportam erros e serve para representar possveis
problemas nas conexes BGP.
Mensagens tipo UPDATE so utilizadas para os anncios propriamente ditos,
incluindo rotas que devem ser includas na tabela e tambm rotas que devem ser
removidos da tabela BGP.
Mensagens tipo KEEPALIVE so utilizadas para manter a conexo entre roteadores
BGP caso no existam atualizaes atravs de mensagens UPDATE.

Uma expresso utilizada para definir rotas que devem ser removidas da tabela BGP
withdrawn, que devido a dinamicidade da Internet ocorrem com muita freqncia.
Outra questo importante em roteadores BGP a questo do chamado Full Routing.
Este termo usado em roteadores que recebem todos os anncios de rotas da Internet. Esta
caracterstica desejvel em core routers que possuam mltiplos pontos de interconexo
com outros backbones. Nesses casos com a tabela de rotas completa ser possvel explorar
e descobrir melhores rotas para uma determinada rede. Como efeito colateral, este recurso
exige que os roteadores tenham bons recursos de CPU e memria.
Na maioria dos casos o recurso de full routing no utilizado, pois os roteadores
possuem geralmente apenas um ou dois pontos de interconexo com outros backbones, no
permitindo nenhuma melhora significativa no roteamento caso fosse usado full routing. A
tabela de roteamento BGP possui um nmero que identifica sua verso, sendo incrementado
cada vez que esta sofrer alguma modificao. Um exemplo de verso de tabela pode ser
visto na Figura 1.
BGP
table
version
is
1660291,
local
router
ID
is
200.10.20.30
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
*>i12.0.48.0/20
198.32.252.254
100
0
11537 10578 1742 i
*>i12.6.208.0/20
198.32.252.254
100
0
11537 10578 1742 i
*>i12.6.252.0/24
198.32.252.254
100
0
11537 10578 14325 ?
*>i12.16.126.192/26
198.32.252.254
100
0
11537 10578 14325 ?
*>i12.144.59.0/24
198.32.252.254
100
0
11537 10466 13778 i
......
Figura 1: Exemplo de tabela de roteamento BGP e seus atributos

No tpico Mensagens do protocolo estes tipos de mensagens sero detalhados e estudados

mais profundamente.

3.2

Estados de uma conexo BGP

A negociao de uma sesso BGP passa por diversos estados at o momento que
propriamente estabelecida e iniciada a troca de anncios de prefixos de cada vizinho BGP.
Para demonstrar os estados possveis na negociao, apresentamos a Figura 2 que ilustra a
mquina de estados finitos:

Figura 2: Mquina de estados finitos para sesses BGP

A seguir so apresentados a discutidos os 6 estados possveis desta mquina de estados
finitos:

IDLE: Este estado identifica o primeiro estgio de uma conexo BGP, onde o
protocolo est aguardando por uma conexo de um peer remoto. Esta conexo deve
ter sido previamente configurada pelo administrador do sistema. O prximo estado
o de CONNECT e no caso da tentativa ser mal sucedida, volta ao estado IDLE.
CONNECT: Nesta estado o BGP aguarda pela conexo no nvel de transporte, com
destino na porta 179. Quando a conexo a este nvel estiver estabelecida, ou seja,
com o recebimento da mensagem de OPEN, passa-se ao estado de OPENSENT. Se
a conexo nvel de transporte no for bem sucedida, o estado vai para ACTIVE. No
caso do tempo de espera ter sido ultrapassado, o estado volta para CONNECT. Em
qualquer outro evento, retorna-se para IDLE.

ACTIVE: O BGP tenta estabelecer comunicao com um peer inicializando uma

conexo no nvel de transporte. Caso esta seja bem sucedida, passa-se ao estado
OPENSENT. Se esta tentativa no for bem sucedida, pelo motivo de expirao do
tempo, por exemplo, o estado passa para CONNECT. Em cada de interrupo pelo
sistema ou pelo administrador, volta ao estado IDLE. Geralmente as transies entre
o estado de CONNECT e ACTIVE refletem problemas com a camada de transporte
TCP.
OPENSENT: Neste estado o BGP aguarda pela mensagem de OPEN e faz uma
checagem de seu contedo. Caso seja encontrado algum erro como nmero de AS
incoerente ao esperado ou a prpria verso do BGP, envia-se uma mensagem tipo
NOTIFICATION e volta ao estado de IDLE. Caso no ocorram erros na checagem,
inicia-se o envio de mensagens KEEPALIVE. Em seguida, acerta-se o tempo de
Hold Time, sendo optado o menor tempo entre os dois peers. Depois deste acerto,
compara-se o nmero AS local e o nmero AS enviado pelo peer, com o intuito de
detectar se trata-se de uma conexo iBGP (nmeros de AS iguais) ou eBGP
(nmeros de AS diferentes). Em caso de desconexo a nvel de protocolo de
transporte, o estado passa para ACTIVE. Para as demais situaes de erro, como
expirao do Hold Time, envia-se uma mensagem de NOTIFICATION com o
cdigo de erro correspondente e retorna-se ao estado de IDLE. No caso de
interveno do administrador ou o prprio sistema, tambm retorna-se o estado
IDLE.
OPENCONFIRM: Neste estado o BGP aguarda pela mensagem de KEEPALIVE e
quando esta for recebida, o estado segue para ESTABLISHED e a negociao do
peer finalmente completa. Com o recebimento da mensagem de KEEPALIVE,
acertado o valor negociado de Hold Time entre os peers. Se o sistema receber uma
mensagem tipo NOTIFICATION, retorna-se ao estado de IDLE. O sistema tambm
envia periodicamente, segundo o tempo negociado, mensagens de KEEPALIVE. No
caso da ocorrncia de eventos como desconexo ou interveno do operador,
retorna-se ao estado de IDLE tambm. Por fim, na ocorrncia de eventos diferentes
aos citados, envia-se uma mensagem NOTIFICATION, retornando ao estado de
IDLE.
ESTABLISHED: Neste estado, o BGP inicia a troca de mensagens de UPDATE ou
KEEPALIVE, de acordo com o Hold Time negociado. Caso seja recebida alguma
mensagem tipo NOTIFICATION, retorna-se ao estado IDLE. No recebimento de
cada mensagem tipo UPDATE, aplica-se uma checagem por atributos incorretos ou
em falta, atributos duplicados e caso algum erro seja detectado, envia-se uma
mensagem de NOTIFICATION, retornando ao estado IDLE. Por fim, se o Hold
Time expirar ou for detectada desconexo ou interveno do administrador, tambm
retorna-se ao estado de IDLE.

A partir da mquina de estados apresentada anteriormente, possvel saber qual o

status de uma sesso BGP entre dois roteadores, podendo tambm iniciar uma investigao
sobre qual problema pode estar ocorrendo em alguma sesso. O objetivo esperado que
todas as sesses BGP de um roteador mantenham-se no estado ESTABLISHED, visto que
somente neste estado ocorre a troca de anncios com o roteador vizinho.

3.3

Funcionamento do algoritmo de deciso

O processo de deciso do BGP baseia-se nos valores dos atributos de cada anncio.
Para reforar a importncia do algoritmo de deciso, em sistemas autnomos multihomed conexo com mais de um AS, tendo mais de um caminho de sada para a Internet - normal
a ocorrncia de mltiplas rotas para a mesma rede e nestes casos o algoritmo de deciso do
BGP que toma a deciso da melhor rota a ser utilizada. Para esse clculo, so
apresentados os 9 critrios de deciso, apresentados por ordem de precedncia:

Se o next hop no for alcanvel, a rota ignorada;

Ser preferida a rota que tiver maior valor de Weight, que se trata de um parmetro
proprietrio da Cisco, utilizado localmente em um roteador. Caso o equipamento
no seja Cisco, este passo do algoritmo no ser efetuado;
Caso o parmetro anterior seja o mesmo, ser preferida a rota que tiver o maior
valor de Local Preference (LOCAL_PREF);
Caso o valor de Local Preference seja o mesmo, ser preferida a rota com menor
AS_PATH.
Caso o AS_PATH tenha o mesmo tamanho, ser preferida a rota com menor tipo
ORIGIN, ou seja, sero priorizados os anncios tipo IGP (i), seguido pelos EGP (e)
e INCOMPLETE (?).
Caso o tipo ORIGIN seja o mesmo, ser preferida a rota o atributo MED mais baixo
caso as rotas tenham sido aprendidas a partir do mesmo AS.
Caso as rotas tenham o mesmo valor de MED, ser preferida a rota por eBGP a
iBGP.
Se o valor de MED for o mesmo, ser preferido o anncio vindo do roteador
conectado via IGP mais prximo deste.
Se o caminho interno for o mesmo, o atributo BGP ROUTER_ID ser o responsvel
pela deciso (tiebreaker). Neste caso, ser preferido o caminho cujo roteador
possuir o menor ROUTER_ID, que nas implementaes Cisco definido como IP
da interface loopback se esta estiver configurada. No caso do roteador no possuir
interface loopback configurada, ser escolhido o IP mais alto do roteador. Vale
lembrar que para cada fabricante o ROUTER_ID pode ser baseado em outras
informaes.

Dessa forma, os anncios so includos na tabela BGP e baseado nestes critrios,

escolhido o melhor caminho. Este melhor caminho, por sua vez, ser incluindo na
forwarding table, que utilizada de fato par o encaminhamento de pacotes pelo roteador.

3.4

Utilizao de polticas

O protocolo tambm fornece diversos mecanismos para utilizao de polticas de

roteamento. Muitas das polticas aplicadas so relacionadas ao ato de troca de trfego que
tem relao direta com seus anncios. O fato de um sistema autnomo ser trnsito define-se
por este AS anunciar-se como caminho no somente para suas redes, mas para todas as
demais que ele conhece. Outros que no desejam fornecer trnsito apenas anunciam suas
prprias redes. Tambm podem existir casos que o AS anuncia suas rotas recebidas a
apenas um conjunto restrito de ASs. Esta troca de trfego chamada de peering e feita

geralmente mediante acordos entre ASs, como o caso dos NAPs ou PTTs ou em conexes
particulares entre ASs. Para esclarecer melhor o assunto, apresentamos a Figura 3 que
ilustra a situao de uma instituio X que compra acesso de dois provedores de acesso IP.
Ambos provedores, Embratel e BrasilTelecom, entre tantos outros que poderiam ser
citados, possuem seu prprio AS. Com clientes que so multihomed, como o caso a
instituio X, que caracteriza-se por ter conectividade com mais um provedor de upstream,
o protocolo BGP o mais aconselhvel j que prov formas de aplicao de polticas de
anncios e formas eficientes de balanceamento de carga.

Figura 3: Exemplo de situao de trnsito BGP com clientes multihomed.

Nesta situao a instituio X pretende utilizar tais conexes para acesso a redes da
Internet e no para ser o elo de ligao entre a Embratel e BrasilTelecom (servir de
trnsito). Para evitar que o AS 1945 se torne trnsito, a poltica que ser aplicada ser que
todos os anncios recebidos de um provedor nunca sero repassados ao outro provedor, ou
seja, todos anncios de redes da Embratel no sero divulgados a BrasilTelecom e viceversa. Isso garantir que ambas conexes sejam utilizadas para trfego provenientes ou
destinados apenas s redes do AS 1945 da instituio X. Essa postura de no servir como
trnsito um tanto bvia j que o acesso a provedores como Embratel e BrasilTelecom
pago e por isso no faz sentido que algum pague para servir de trnsito para outros
backbones. Problemas como este j foram registrados nas operaes com instituies
conectadas ao POP-RS e a backbones comerciais.
O ato de servir de trnsito, se pelo lado dos clientes evitado, pelos provedores de
upstream como os citados so praticamente uma lei, pois estes devem propagar os anncios
de seus clientes para garantir que tais redes sejam alcanveis por toda a Internet.
Em PTTs existem algumas restries e pontos importantes sobre este tpico que
sero explicados e aprofundados nos prximos captulos.
Outro recurso importante o Route Dampening, ou seja, uma espcie de punio
que determinado AS pode levar caso seus anncios sofram instabilidades na tabela de
roteamento (FLAPs) constantes. Isso faz com que determinado AS no seja ouvido pelos
demais ASs por um tempo determinado, mantendo a estabilidade at que aquele anncio
estabilize. Isso evita que isso seja propagado por toda a Internet, consumindo banda e CPU
de milhares de roteadores na incluso/excluso em suas tabelas de rotas BGP. Alguns
backbones implementam tal funcionalidade, estabelecendo seus tempos de punio.

Outros recursos de polticas podem ser aplicados de acordo com a necessidade de

administrador do AS, podendo filtrar tipos determinados de anncios, baseado em algum
parmetro do protocolo BGP, aceitando ou filtrando tais anncios. Esses procedimentos so
muito utilizados e merecem cuidado ao manipula-los.
A utilizao de polticas em um sistema autnomo uma das tarefas mais
importantes de um administrador, visto que sua configurao pode refletir em uma melhora
no acesso a outras redes, at efeitos negativos, como problemas de alcanabilidade para
outras redes, ou involuntariamente servir de trnsito para outros sistemas autnomos.

3.5

Mensagens do protocolo

O BGP possui basicamente 4 tipos de mensagens. Nestas mensagens existe um

header que comum a todos eles, apresentado na Figura 4 explicado a seguir:
As mensagens trocadas em sesses BGP tm o comprimento mximo de 4.096
bytes, e mnimo de 19 bytes. Todas as mensagens so compostas de, no mnimo, um
cabealho e, opcionalmente, uma parte de dados. O formato do cabealho das mensagens
BGP :

Figura 4 - Formato do Cabealho das Mensagens BGP.

Pode haver, ou no, uma seqncia dados aps o cabealho.Seus campos so:
- Campo Marcador (Marker)
Serve para verificar a autenticidade da mensagem recebida e se houve perda de
sincronizao entre os roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem
seja do tipo OPEN (abrir), ou se a mensagem tipo OPEN no possuir informao de
autenticao, o campo deve estar todo preenchido com nmeros um (1); seno, o campo
marker ter o seu contedo baseado em parte do mecanismo de autenticao usado.
- Campo Comprimento (Lenght)
Deve conter um nmero que representa o comprimento total da mensagem,
incluindo o cabealho. Como pode haver mensagens que no possuem dados aps o
cabealho, a menor mensagem BGP enviada de 19 bytes (16 + 2 + 1 bytes).
- Campo Tipo (Type)

Deve conter um nmero que representa o cdigo de um tipo de mensagem

(KEEPALIVE, NOTIFICATION, OPEN e UPDATE).

3.5.1 Mensagens do protocolo : Mensagem tipo OPEN

A mensagem do tipo OPEN enviada para se iniciar a abertura de uma
sesso BGP entre neighbors ou peers BGP. O formato desta mensagem pode ser
visto na figura abaixo:

Figura 5 - Formato da Mensagem OPEN.

Seus campos so:

- Verso (Version) - caractersticas: [1 byte, inteiro, positivo].
Identifica a verso do BGP (3 ou 4). Este um dos parmetros negociados
pelos roteadores que, normalmente, tentam entrar em acordo para usar a maior
verso suportada. No havendo possibilidade de consenso (ex.: um dos
roteadores no suporta o BGP4), eles tentam usar verses anteriores, at que
coincidam. Nos roteadores Cisco, h como configurar a verso a ser usada pelos
roteadores (se previamente se sabe qual verso ambos suportam), eliminando
esta fase de negociao do processo de abertura da sesso BGP, implicando
numa conseqente economia de tempo.

- Nmero do AS (AS Number) - caractersticas: [2 bytes, inteiro, positivo].

Deve conter o nmero do AS a qual o roteador (remetente da mensagem
tipo OPEN) pertence.
- Tempo de espera (Hold Time) - caractersticas: [2 bytes, inteiro, positivo].
Deve conter o valor, em segundos, do maior tempo de espera (hold time)
permitido entre mensagens do tipo UPDATE ou KEEPALIVE. O BGP mantm um
contador do hold time, que reiniciado (zerado) a cada vez que uma mensagem
do tipo KEEPALIVE ou UPDATE recebida. Caso nenhuma das duas seja
recebida no prazo mximo, o BGP considera que a comunicao com o outro
roteador foi perdida e a sesso encerrada, tendo que ser reiniciada novamente.
Os roteadores tentam usar o menor hold time entre os dois. Caso o valor seja
estabelecido como zero, a sesso ser considerada como sempre "viva" (ativa) e
mensagens de KEEPALIVE no sero transmitidas, pois os contadores do hold
time e do KEEPALIVE no sero zerados nunca. O valor mnimo recomendado
para este parmetro de trs segundos.
- Comprimento dos Parmetros Opcionais (Optional Parameters Lenght) caractersticas: [1 byte, inteiro, positivo].
Indica o comprimento total do campo de Parmetros Opcionais (Optional
Parameters). No caso de ausncia de parmetros opcionais, este campo ser
preenchido com zero.
- Parmetros Opcionais (Optional Parameters) - caractersticas: [comprimento
varivel].
Pode conter vrios parmetros opcionais para a negociao de abertura de uma
sesso BGP. Este campo deve ser preenchido com conjuntos formados por 3
valores: [Tipo do parmetro (1 byte), Comprimento do Parmetro (1 byte), Valor do
parmetro (comprimento varivel) ]. Um exemplo de parmetro o de informao
de autenticao (tipo 1), usado para autenticar a sesso com o vizinho BGP.

3.5.2 Mensagens do protocolo : Mensagem tipo NOTIFICATION

Este tipo de mensagem enviada no caso de deteco de erros durante ou
aps o estabelecimento de uma sesso BGP. O formato da mensagem
NOTIFICATION :

Figura 6 - Formato da Mensagem Tipo NOTIFICATION.

Seus campos so:
- Campo Erro (Error)
Deve conter o tipo da notificao
- Campo Sub Cdigo de Erro (Error subcode)
Deve conter um valor que fornece maiores informaes sobre o erro.
- Campo de Dados (Data)
Pode conter dados referentes ao erro, como por exemplo, um cabealho
mal formado (invlido), um nmero de AS invlido, etc. Os trs tipos de erros
principais so: erro de cabealho, erro de OPEN e erro de UPDATE.

3.5.3 Mensagens do protocolo : Mensagem tipo KEEPALIVE

So mensagens trocadas periodicamente com o propsito de verificar se a
comunicao entre os vizinhos est ativa. A mensagem do tipo KEEPALIVE
composta apenas do cabealho padro das mensagens BGP, sem dados
transmitidos aps o cabealho. O tempo mximo permitido para o recebimento de
mensagens KEEPALIVE ou UPDATE definido pelo hold time, como foi visto na
descrio do tipo de mensagem OPEN.
Para manter aberta a sesso, a mensagem de KEEPALIVE deve ser
enviada antes que o prazo definido no hold time expire; caso contrrio a sesso
ser encerrada. A recomendao que a mensagem seja enviada em at 1/3 do

tempo definido no hold time. Se o seu valor for igual a zero, ento as mensagens
do tipo KEEPALIVE no sero enviadas.

3.5.4 Mensagens do protocolo : Mensagem tipo UPDATE

As mensagens UPDATE, trocadas entre os peers ou vizinhos BGP, so de
extrema importncia, pois so elas que levam as informaes para a atualizao
da tabela de rotas mantida pelo BGP.
A estrutura bsica das mensagens do tipo UPDATE composta de 3 itens:

Rotas Inalcanveis (Unreachable Routes);

Atributos de Caminhos (PATH Attributes);
Informao de alcance da camada de rede - (NLRI - Network Layer
Reachability Information);

O formato da mensagem do tipo UPDATE pode ser visto na figura abaixo:

Figura 7 - O Formato da Mensagem UPDATE.

Seus campos so:
- Comprimento das Rotas Removidas ou Inalcanveis (Unfeasible Routes
Length) - caractersticas: [2 bytes, inteiro, positivo].

Neste campo, indicado o comprimento total, em bytes, do total de rotas

removidas (Withdrawn Routes).

- Rotas Removidas (Withdrawn Routes) - caractersticas [comprimento varivel].

Este campo inclui uma lista de prefixos de endereos para rotas que devem
ser removidas da tabela de rotas BGP. composto por endereos IP mais o
comprimento do nmero de bits contados a partir da esquerda no endereo IP,
como mostrado na figura abaixo:

Figura 8 - O formato do Campo de Withrawn Routes.

Esses subcampos so:

Prefixo
(Prefix)
caractersticas
[comprimento
varivel]
Contm prefixos de endereos IP seguidos de bits suficientes para fazer o
final deste campo terminar "arredondado" em bytes completos. O valor dos
bits complementares no possui importncia.
Comprimento (Lenght) - caractersticas [1 byte, inteiro, positivo]
Deve indicar o comprimento total, em bits, do total de rotas removidas. Um
comprimento igual a 0 (zero), indica que, nesta mensagem UPDATE, no
h rotas a serem removidas.

- Comprimento Total do Atributo PATH (Total Path Attribute Length) caractersticas [2 bytes, inteiro, positivo]
Deve indicar o comprimento total, em bits, do campo Atributos PATH. O
valor contido neste campo deve permitir a determinao do comprimento do
campo NLRI. Se o valor deste campo for 0 (zero), significa que no h informao
NLRI presente na mensagem UPDATE.
- Atributos do PATH (PATH Attributes) - caractersticas [comprimento varivel]
So um conjunto de parmetros associados a uma determinada rota que
influenciam no processo de deciso, feito pelo BGP, para escolha da melhor rota.
- Informaes NLRI (NLRI Information) - caractersticas [comprimento varivel]

So prefixos de endereos IP de informaes no formato igual ao do campo

de rotas removidas (Withdrawn Routes). Este campo preenchido por vrias
entradas:

Figura 9 - O Formato das Informaes NLRI.

Um exemplo de entrada seria: <18,192. 213.134.0>, que indica uma rota
para 192.213.134.0 255.255.192.0 (ou 192.213.134.0/18, na notao CIDR).

3.5.6 Utilizao de BGP em sistemas autnomos

O protocolo BGP utilizado para propagar rotas entre sistemas autnomos. Esse
seu principal propsito, mas diante de grandes sistemas autnomos, os IGPs nem sempre
conseguem sustentar o roteamento interno e seu crescimento. Nessas situaes, o BGP
tambm pode ser usado dentro de um mesmo AS. Supondo que determinado AS tenha
apenas um de seus roteadores com sesses BGP com outros ASs, outros roteadores deste
mesmo sistema autnomo podem receber os anncios do roteador de borda via BGP e no
exclusivamente por algum protocolo tipo IGP. Nesses casos existe o iBGP, que se trata de
uma extenso do protocolo BGP para ser utilizado entre roteadores de um mesmo AS.
Como justificativa para o surgimento do iBGP, pode-se dizer que os protocolos tipo IGP
no so escalonveis a ponto de fazerem a comunicao entre roteadores em grandes
backbones de forma satisfatria. Por isso, utiliza-se iBGP por permitir uma escalabilidade
mais poderosa e tambm pelas funcionalidades que o protocolo fornece muito superiores
aos do tipo IGP. Um exemplo de utilizao de iBGP e eBGP mostrado na Figura 11.

Figura 11: Exemplo de uso de eBGP e iBGP.

De acordo com a figura, o roteador A o border router e responsvel pela

comunicao com o mundo externo, que no caso feita com o AS 2. O roteador A mantm
com B e C uma sesso iBGP. Os roteadores B e C poderiam trocar informaes via IGP
com A, utilizando OSPF por exemplo, mas em grandes backbones isso no seria
escalonvel. Por isso, utilizado iBGP para esta comunicao. Isso fica mais evidente em
backbones a nvel nacional, como o caso da RNP que utiliza iBGP em seu AS em
conjunto com OSPF.

3.6

O Futuro do BGP

A fim de acompanhar o crescimento da Internet e para atender s novas tecnologias

como Multicast e o surgimento do Ipv6, foram propostas tambm funcionalidades
adicionais ao protocolo BGP. Segundo [CIS00] essas funcionalidades formam o MBGP
(Multiprotocol BGP), que surge com o intuito de permitir a troca de informaes de
roteamento por mltiplos protocolos em nvel de rede. Tais protocolos so identificados por
uma famlia de endereo (Address Family), como definido na RFC 1700. Algumas famlias
de endereos que poderiam ser citadas seriam: IPv4, IPv6, IPX. Tambm o MBGP permite
sub-famlias, a citar unicast e multicast por exemplo.
Outro recurso que provavelmente no futuro ser mais utilizado ser a assinatura das
mensagens de sesses BGP, pois tem sido registrados alguns casos de ataques de hackers a
roteadores, enviando pacotes falsificados, tentando incluir anncios a roteadores com BGP.
Neste caso, a utilizao do mtodo de assinatura TCP MD5 j est prevista, segundo a RFC
2385, utilizando para tanto o campo MARKER do header do pacote BGP.
Software Zebra
O software Zebra uma implementao freeware destinada a sistemas
operacionais Unix como FreeBSD, Linux, NetBSD e OpenBSD. Suporta diversos
protocolos de roteamento como RIP, OSPF, BGP e alguns destes para IP verso 6
tambm como RIP6 e OSPF6. No caso do BGP o protocolo verso 6 tambm
suportado, mas isso feito pelo mesmo daemon que suporta IP verso 4. Para cada
protocolo destes apresentados a ferramenta possui um daemon que pode ser ativado e
configurado. Para cada protocolo existe um arquivo de configurao independente.
Tambm existe um daemon chamado zebra que permite configurao global da
ferramenta e as possveis distribuies das informaes entre um protocolo e outro. Os
comandos utilizados por cada protocolo so semelhantes aos comandos de roteadores
Cisco. Um recurso importante presente nesta ferramenta o acesso via telnet a cada
um dos daemons que estiverem ativos, semelhante a um terminal virtual. As portas
associadas a cada daemon so exibida na Tabela 1.
Porta Protocolo Associado
2601

Zebra

2602

RIP

2603

RIP6 (IP verso 6)

2604

OSPF

2605

BGP (IP verso 4 e verso 6)

2606

OSPF v3 (IP verso 6)

Tabela 1 Portas Zebra

A partir destes terminais virtuais a configurao de cada protocolo pode ser alterada,
podendo ser salva no arquivo de configurao correspondente. No caso da
configurao do protocolo BGP, cujo daemon o bgpd, um exemplo bsico de possvel
configurao deste protocolo mostrado na Figura 7.
hostname
password
enable
!
router
bgp
network
neighbor
!
log
!
log stdout

exemplo
zebra
bgpsecret

password
bgp
router-id
10.0.0.2

remote-as
file

65000
10.0.0.1
192.168.10.0/24
65001
bgpd.log

Figura 7 Configurao BGP no Zebra

A configurao exibida na Figura 7 trata de uma sesso BGP entre o roteador cujo
router-id 10.0.01 e o roteador 10.0.0.2. O AS que cada um pertence
respectivamente 65000 e 65001. A rede anunciada pelo AS 65000 , neste caso,
192.168.10.0/24. Outras coisas que so configuradas neste daemon so as senhas de
primeiro e segundo nvel. As senhas de primeiro nvel so acesso a consultas de
sesses BGP e dados das interfaces e as senhas de segundo nvel do acesso
configurao completa do sistema com permisses para alterao.