Este artigo descreve o protocolo de roteamento de borda BGP. Será descrito suas características, aplicações, funcionamento e configurações. Definiremos vários termos que complementarão a abordagem realizada.
Ele foi escrito durante a cadeira de TCP Avançado durante o curso de Pós-Graduação em Segurança de Redes na Universidade AESO.
A versão em PDF do artigo você encontra aqui:

Introdução

O Border Gateway Protocol (Protocolo de Roteamento de Borda – BGP) é um sistema de roteamento entre sistemas autônomos1 (Autonomous Systems - AS). Sistemas Autônomos são grupos de redes que compartilham uma mesma administração e a mesma política de roteamento. BGP é o protocolo usado para troca de informações sobre roteamento da internet e ele é usado por ISP's (Internet Service Providers). A versão usada atualmente é o BGP-42. Comumente, as empresas e universidades usam em suas redes, protocolos de roteamentos internos IGP3. Vários clientes, compartilham o mesmo AS de um ISP, dessa forma, na borda do AS do ISP é usado o BGP para trocar informações de rotas com a internet para seus clientes
O BGP Pode ser usado de duas Maneiras:
EBGP – External BGP: Usado na troca de rotas entre Sistemas Autônomos;
IBGP – Internal BGP: Usado dentro de um Sistema Autônomo.


Figura 1. Uso do IBGP e do EBGP
Observe que na figura 1, o EBGP é usado na troca de informações entre o AS4230, AS1916 e AS6505, já o IBGP é usado internamente no AS6505 para levar informações de roteamento vindos dos dois nós do AS6505 em um sistema autônomo de trânsito. Um IGP é usado para rotear os pacotes do IBGP para suas localizações remotas dentro do AS (é necessário que a rede de destino esteja na tabela de roteamento IGP).
O BGP é um protocolo extremamente complexo e robusto. Como ele é usado na interent, ele gerencia atualizações de rota em uma tabela com 184062 rotas4. Para garantir performance e escalabilidade, o BGP usa muitos parâmetros de rota, chamados de atributos, dessa forma,ele consegue definir a política de roteamento e garantir um ambiente de roteamento estável.
Adicionalmente aos atributos usados pelo BGP, é implementado o classless inter-domain routing (CIDR) com o objetivo de reduzir o tamanho das tabelas de roteamento da internet. Isso significa que caso um provedor possua o bloco de endereços classe C 200.199.x.x. Esse bloco significa que o ISP possui 256 redes classe C disponíveis, 200.199.0.x até 200__.199.255.x. Assumindo que o provedor entregue cada um das 256 redes para clientes, o ISP deveria publicar na internet, 256 rotas. Com o CIDR, o BGP vê o endereço 200.199.x.x com um bloco Classe B e publicará apenas a supernet 200.199.x.x, sumarizando as 256 rotas desse ISP.

Características

Detalhamos em alguns pontos abaixo as principais características do BGP.
É um protocolo de vetor caminho;
As atualizações completas de roteamento são enviadas no início da sessão e as atualizações adicionais incrementais são enviadas em seguida;
Cria e mantém conexões na porta 179 do TCP1;
É um protocolo orientado a Conexão, dessa forma é tido como confiváel;
A conexão é mantida por keepalives periódicos;
O uso de atributos como métrica na escolha do melhor caminho lhe permite ótima granularidade2;
O uso de endereçamento hierárquico e a capacidade de manipular o fluxo de tráfego resultam em uma rede projetada para crescer;
Ele possui sua própria tabela de roteamento, apesar de ser capaz de compartilhar e pesquisar a tabela de roteamento IP Interno.

Funcionamento

O algoritmo que sustenta o BGP é definido como PATH VECTOR, assemelhando-se ao algoritmo de vetor distância, pois a partir de informações recebidas de outros sistemas autônomos é formado um vetor que armazena os ASs que formam um caminho para se chegar a determinada rede. Uma vez que os roteadores divulguem tal informação, é possível calcular o menor caminho para determinada rede. Nem sempre esse menor caminho é o escolhido, pois o BGP utiliza também diversos outros parâmetros para determinação do melhor caminho para determinada rede,
O BGP troca informações completas de roteamento quando uma conexão TCP for estabelecido com seu neighbor1. Quando uma rota é modificada, ele envia para seus vizinhos apenas as alterações. Ele não envia atualizações periódicas de rotas, e ele só informa o melhor caminho para a rede de destino, isso torna a divulgação mais leve, visto que ao nível do BGP o número total de rotas da Internet é muito grande e o anúncio de todas as rotas seria inviável. Esta forma de anúncio é conhecida como incremental.
Par a comunicação entre roteadores BGP existem alguns tipos de mensagens onde cada um deles tem um papel importante na comunicação BGP.
Mensagens tipo OPEN são utilizadas para o estabelecimento de uma conexão BGP;
Mensagens tipo NOTIFICATION reportam erros e servem para representar possíveis problemas nas conexões BGP.
Mensagens tipo UPDATE são utilizadas para os anúncios propriamente ditos, incluindo rotas que devem ser incluídas na tabela e também rotas que devem ser removidos da tabela BGP.
Mensagens tipo KEEPALIVE são utilizadas para manter a conexão entre roteadores BGP caso não existam atualizações através de mensagens UPDATE.
Uma expressão utilizada para definir rotas que devem ser removidas da tabela BGP é withdrawn, que devido a dinamicidade da Internet ocorrem com muita freqüência.
Outra questão importante em roteadores BGP é a questão do chamado Full Routing. Este termo é usado em roteadores que recebem todos os anúncios de rotas da Internet. Esta característica é desejável em core routers que possuam múltiplos pontos de interconexão com outros backbones. Nesses casos com a tabela de rotas completa será possível explorar e descobrir melhores rotas para uma determinada rede. Como efeito colateral, este recurso exige que os roteadores tenham bons recursos de CPU e memória.
Na maioria dos casos o recurso de full routing não é utilizado, pois os roteadores possuem geralmente apenas um ou dois pontos de interconexão com outros backbones, não permitindo nenhuma melhora significativa no roteamento caso fosse usado full routing. A tabela de roteamento BGP possui um número que identifica sua versão, sendo incrementado cada vez que esta sofrer alguma modificação. Um exemplo de versão de tabela pode ser visto na Figura 2.
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 2. Exemplo de tabela de roteamento BGP e seus atributos



__Figura 3. Exemplo de uma inicialização de sessão com um vizinho
__

Estados de uma conexão BGP

A negociação de uma sessão BGP passa por diversos estados até o momento que é propriamente estabelecida e é iniciada a troca de anúncios de prefixos de cada vizinho BGP. Para demonstrar os estados possíveis na negociação, apresentamos a Figura 4 que ilustra a máquina de estados finitos:


Figura 4. Máquina de estados finitos para sessões BGP
A seguir são apresentados a discutidos os 6 estados possíveis desta máquina de estados finitos:
IDLE: Este estado identifica o primeiro estágio de uma conexão BGP, onde o protocolo está aguardando por uma conexão de um peer remoto. Esta conexão deve ter sido previamente configurada pelo administrador do sistema. O próximo estado é o de CONNECT e no caso da tentativa ser mal sucedida, volta ao estado IDLE.
CONNECT: Nesta estado o BGP aguarda pela conexão no nível de transporte, com destino na porta 179. Quando a conexão a este nível estiver estabelecida, ou seja, com o recebimento da mensagem de OPEN, passa-se ao estado de OPENSENT. Se a conexão nível de transporte não 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 comunicação com um peer inicializando uma conexão no nível de transporte. Caso esta seja bem sucedida, passa-se ao estado OPENSENT. Se esta tentativa não for bem sucedida, pelo motivo de expiração do tempo, por exemplo, o estado passa para CONNECT. Em caso de interrupção pelo sistema ou pelo administrador, volta ao estado IDLE. Geralmente as transições 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 conteúdo. Caso seja encontrado algum erro como número de AS incoerente ao esperado ou a própria versão do BGP, envia-se uma mensagem tipo NOTIFICATION e volta ao estado de IDLE. Caso não 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 número AS local e o número AS enviado pelo peer, com o intuito de detectar se trata-se de uma conexão IBGP (números de AS iguais) ou EBGP (números de AS diferentes). Em caso de desconexão a nível de protocolo de transporte, o estado passa para ACTIVE. Para as demais situações de erro, como expiração do Hold Time, envia-se uma mensagem de NOTIFICATION com o código de erro correspondente e retorna-se ao estado de IDLE. No caso de intervenção do administrador ou o próprio sistema, também 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 negociação 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 também envia periodicamente, segundo o tempo negociado, mensagens de KEEPALIVE. No caso da ocorrência de eventos como desconexão ou intervenção do operador, retorna-se ao estado de IDLE também. Por fim, na ocorrência 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 desconexão ou intervenção do administrador, também retorna-se ao estado de IDLE.
A partir da máquina de estados apresentada anteriormente, é possível saber qual o status de uma sessão BGP entre dois roteadores, podendo também iniciar uma investigação sobre qual problema pode estar ocorrendo em alguma sessão. O objetivo esperado é que todas as sessões BGP de um roteador mantenham-se no estado ESTABLISHED, visto que somente neste estado ocorre a troca de anúncios com o roteador vizinho.

Sincronização

Um regra simples estabelece que, para que o IBGP possa propagar uma rota para outro sistema autônomo, passando pelo EBGP, a rota deve ser totalmente conhecida dentro do sistema autônomo. Isso quer dizer que o IGP, deve ser sincronizado com o BGP.
Por default, essa regra é ativa. Pode ser desativada nas seguintes circunstâncias:
Se todos os roteadores do sistema autônomo estiverem rodando o BGP;
Se todos os roteadores do sistema autônomo estiverem em rede;
Quando um sistema autônomo, não for um domínio de transito1.
Vantagens da Sincronização:
Impede que o tráfego seja enviado a destinos inatingíveis;
Reduz o táfego desnecessário;
Garante consistência dentro do Sistema Autônomo.

Funcionamento do algoritmo de decisão

O processo de decisão do BGP baseia-se nos valores dos atributos de cada anúncio. Para reforçar a importância do algoritmo de decisão, em sistemas autônomos multihomed - conexão com mais de um AS, tendo mais de um caminho de saída para a Internet - é normal a ocorrência de múltiplas rotas para a mesma rede e nestes casos o algoritmo de decisão do BGP é que toma a decisão da melhor rota a ser utilizada. Para esse cálculo, são apresentados os 9 critérios de decisão, apresentados por ordem de precedência:
Se o next hop não for alcançável, a rota é ignorada;
Será preferida a rota que tiver maior valor de Weight, que se trata de um parâmetro proprietário da Cisco, utilizado localmente em um roteador. Caso o equipamento não seja Cisco, este passo do algoritmo não será efetuado;
Caso o parâmetro 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, serão priorizados os anúncios tipo IGP (i), seguido pelos EGP (e) e INCOMPLETE (?).
Caso o tipo ORIGIN seja o mesmo, será preferida a rota com 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 anúncio vindo do roteador conectado via IGP mais próximo deste.
Se o caminho interno for o mesmo, o atributo BGP ROUTER_ID será o responsável pela decisão (tiebreaker). Neste caso, será preferido o caminho cujo roteador possuir o menor ROUTER_ID, que nas implementações Cisco é definido como IP da interface loopback se esta estiver configurada. No caso do roteador não 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 informações.
Dessa forma, os anúncios são incluídos na tabela BGP e baseado nestes critérios, é escolhido o melhor caminho. Este melhor caminho, por sua vez, será incluído na forwarding table, que é utilizada de fato par o encaminhamento de pacotes pelo roteador.

Utilização de políticas

O protocolo também fornece diversos mecanismos para utilização de políticas de roteamento. Muitas das políticas aplicadas são relacionadas ao ato de troca de tráfego que tem relação direta com seus anúncios. O fato de um sistema autônomo ser trânsito define-se por este AS anunciar-se como caminho não somente para suas redes, mas para todas as demais que ele conhece. Outros que não desejam fornecer trânsito apenas anunciam suas próprias redes. Também podem existir casos que o AS anuncia suas rotas recebidas a apenas um conjunto restrito de ASs. Esta troca de tráfego é chamada de peering e é feita geralmente mediante acordos entre ASs, como é o caso dos NAPs ou PTTs ou em conexões particulares entre ASs. Para esclarecer melhor o assunto, apresentamos a Figura 5 que ilustra a situação de uma instituição X que compra acesso de dois provedores de acesso IP.
Ambos provedores, Embratel e BrasilTelecom, entre tantos outros que poderiam ser citados, possuem seu próprio AS. Com clientes que são multihomed, como é o caso a instituição X, que caracteriza-se por ter conectividade com mais um provedor de upstream, o protocolo BGP é o mais aconselhável já que provê formas de aplicação de políticas de anúncios e formas eficientes de balanceamento de carga.


Figura 5. Exemplo de situação de trânsito BGP com clientes multihomed.
Nesta situação a instituição X pretende utilizar tais conexões para acesso a redes da Internet e não para ser o elo de ligação entre a Embratel e BrasilTelecom (servir de trânsito). Para evitar que o AS 1945 se torne trânsito, a política que será aplicada será que todos os anúncios recebidos de um provedor nunca serão repassados ao outro provedor, ou seja, todos anúncios de redes da Embratel não serão divulgados a BrasilTelecom e vice-versa. Isso garantirá que ambas conexões sejam utilizadas para tráfego provenientes ou destinados apenas às redes do AS 1945 da instituição X. Essa postura de não servir como trânsito é um tanto óbvia já que o acesso a provedores como Embratel e BrasilTelecom é pago e por isso não faz sentido que alguém pague para servir de trânsito para outros backbones. Problemas como este já foram registrados nas operações com instituições conectadas a backbones comerciais.
O ato de servir de trânsito, se pelo lado dos clientes é evitado, pelos provedores de upstream como os citados são praticamente uma lei, pois estes devem propagar os anúncios de seus clientes para garantir que tais redes sejam alcançáveis por toda a Internet.
Outro recurso importante é o Route Dampening, ou seja, uma espécie de “punição” que determinado AS pode levar caso seus anúncios sofram instabilidades na tabela de roteamento (FLAPs) constantes. Isso faz com que determinado AS não seja “ouvido” pelos demais ASs por um tempo determinado, mantendo a estabilidade até que aquele anúncio estabilize. Isso evita que isso seja propagado por toda a Internet, consumindo banda e CPU de milhares de roteadores na inclusão/exclusão em suas tabelas de rotas BGP. Alguns backbones implementam tal funcionalidade, estabelecendo seus tempos de punição.
Outros recursos de políticas podem ser aplicados de acordo com a necessidade de administrador do AS, podendo filtrar tipos determinados de anúncios, baseado em algum parâmetro do protocolo BGP, aceitando ou filtrando tais anúncios. Esses procedimentos são muito utilizados e merecem cuidado ao manipula-los.
A utilização de políticas em um sistema autônomo é uma das tarefas mais importantes de um administrador, visto que sua configuração pode refletir em uma melhora no acesso a outras redes, até efeitos negativos, como problemas de alcançabilidade para outras redes, ou involuntariamente servir de trânsito para outros sistemas autônomos.

Atributos do BGP

Conforme discutido anteriormente, o BGP utiliza atributos como base para escolha do melhor caminho para chegar a uma determinada rede. Caracterizamos abaixo os atributos do BGP que apresentaremos adiante:

Classificação
Significado
Conhecido obrigatório
(Well-know mandatory)
Atributo que deve ser reconhecido em todas as implementações BGP de qualquer fabricante. Caso algum atributo deste tipo não esteja em uma mensagem UPDATE, será gerada uma mensagem tipo NOTIFICATION par reportar o erro.
Conhecido arbitrário (Well-known discretionary)
Atributo que deve ser reconhecido em todas as implementações de BGP, mas pode ou não estar presente em mensagens UPDATE. Um exemplo de atributo deste tipo é LOCAL_PREF.
Opcional e transitivo (Optional transitive)
Atributo que pode não ser reconhecido em todas as implementações. Sendo transitivo, significa que o atributo deve ser aceito e repassado aos demais peers1 BGP.
Opcional intransitivo (Optional nontrasitive)
Atributo também opcional. Sendo intransitivo, ele não é repassado a outros peers BGP.
Tabela 1: Classificação dos atributos utilizados no BGP.
Através da Tabela 2 apresentamos alguns atributos, juntamente com sua categoria e RFC que os descreve:

No	Nome do atributo	Categoria / Tipo
1	ORIGIN	Conhecido obrigatório RFC 1771
2	AS_PATH	Conhecido obrigatório RFC 1771
3	NEXT_HOP	Conhecido obrigatório RFC 1771
4	MULTI_EXIT_DISC (MED)	Opcional intransitivo RFC 1771
5	LOCAL_PREF	Conhecido arbitrário RFC 1771}
6	ATOMIC_AGGREGATE	Conhecido arbitrário RFC 1771
7	AGGREGATOR	Opcional transitivo RFC 1771
8	COMMUNITY	Opcional transitivo RFC 1997
9	ORIGINATOR_ID	Opcional intransitivo RFC 1966
10	Cluster List	Opcional intransitivo RFC 1966
14	Multiprotocol Reachable NLRI	Opcional intransitive RFC 2283
15	Multiprotocol Unreachable NLRI	Opcional intransitive RFC 2283
16	Extended Communities	Draft-remachandra-bgp-ext-communities-00,txt “work in progress”
256	Reservada	Reservado para desenvolvimento

Tabela 2: Apresentação de atributos utilizados no BGP.
Usaremos a Tabela 3 para definir os atributos que são mais usados.

Atributo	Definição
ORIGIN	Define a origem do anúncio, classificando-o em 3 grupos: 0 : IGP (i) - Significa que a origem do anúncio é interna ao referido AS. 1 : EGP (e) – significa que a origem do anúncio é externa ao referido AS, aprendida via EGP. 2 : INCOMPLETE (?) – A origem do anúncio foi feita por algum mecanismo de redistribuição ou por meios desconhecidos. A ordem de preferência deste atributo é a própria ordem em que os grupos foram apresentados, visto que os anúncios do grupo 0 têm maior confiabilidade que os grupos 1 e 2.
AS_PATH	Atributo que representa a seqüência de ASs que uma rota segue para atingir determinado destino. Esses dados são incluídos na passagem ao anúncio em cada peer, que inclui seu número de AS juntamente ao anúncio da rota. Uma operação possível sobre este atributo é o chamado “prepend”, que se caracteriza por “piorar” o AS_PATH para determinada rota, forçando com que outros caminhos possam ser escolhidos. Um exemplo de prepend seria transformar o AS_PATH 1916 4230 para 1916 1916 4230. O menor AS_PATH é escolhido.
NEXT_HOP	Refere-se ao IP do próximo roteador para atingir determinada rede. Geralmente o roteador que anuncia determinado prefixo repassa como nexthop o seu próprio IP, exceto em sessões iBGP ou em route servers2.
LOCAL_PREF	Usado para selecionar o caminho preferencial de saída a partir de um determinado AS. Seu escopo é interno ao AS, não sendo repassado a seus vizinhos (peers). Quanto mais alto seu valor, maior será a preferência.
COMMUNITY	Atributo que pode ser repassado a outros peers. Trata-se de uma espécie de “carimbo” que acompanha anúncios para que estes possam ser tratados de forma diferenciada.
WEIGHT	Atributo proprietário da CISCO, muito semelhante ao LOCA_PREF, embora não seja repassado para outros roteadores, mesmo dentro do mesmo AS. Quanto maior seu valor, maior será a preferência.

Tabela 3: Definição dos atributos mais utilizados no BGP.

Através da tabela de rotas BGP representada pela Figura 6, são apresentados alguns dos atributos vistos anteriormente. Depois da versão e identificador do roteador, é apresentado o início da listagem de prefixos seus atributos. Cada linha a seguir representa um prefixo e seus respectivos atributos.

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 6: Exemplo de tabela BGP parcial.
A partir do início de cada linha, o símbolo * (asterisco) apresentado ao lado dos prefixos mostra que estes estão definidos como melhores caminhos para as redes em questão. Ao lado é apresentada a rede anunciada na forma de bloco CIDR, em seguida o Next Hop que define-se como próximo roteador que os pacotes para esta rede deverão ser enviados. Também todas as rotas possuem o atributo Local Preference com valor 100, o atributo Weight (proprietário da Cisco) com valor 0. Outro atributo é o AS_PATH que mostra a seqüência de sistemas autônomos até a chegada a rede destino e por fim, o atributo ORIGIN, que define a procedência do anúncio pelo AS que anunciou e é representado por i (IGP), e (EGP) ou “?” (indefinido ou incompleto).

Glossário

AS - Autonomous System
ASN - Autonomous System Number
BGP-4 - Border Gateway Protocol versão 4
IANA - Internet Assigned Numbers Authority
IDC - Internet Data Center
ISP - Internet Service Provider
NAP - Network Access Point
PIR - Ponto de Interconexão de Redes

Referências

Gought, Clare (2002) “CCNP Routing: Guia de Certificação do Exame”, Alta Books p 338-361.
Dooley, Jevin and Brown, Ian (2003) “Cisco Cookbook”, O'REILLY p 307 - 363
Cisco Systems, “Border Gateway Protocol”, 2003 Cisco.com
Artigo Publicado em : http://www.pop-rs.rnp.br/ovni/roteamento2/bgp.html
Artigo Publicado na RNP nos links abaixo:
[http://www.rnp.br/newsgen/9903/bgp4.html http://www.rnp.br/newsgen/9905/bgp4p2.html https://www.rnp.br/newsgen/9907/bgp4p3.shtml
Website: www.cidr-report.org