Alex Soares de Moura
Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Tipos de mensagem BGP (cont.)
Atributos BGP
Redistribuição
Mapas de rotas (Route Maps)
Sincronização
Filtragem no BGP
Configurações em roteamento Cisco
Dicas e erros de configuração
Conclusão
Referências
Sites relacionados
Referências bibliográficas

Esta é a terceira e última parte do artigo de introdução ao Protocolo BGP-4. A parte 1 e a parte 2 foram publicadas nas duas edições anteriores do RNP NewsGeneration.

É importante lembrar que este artigo procura oferecer uma introdução a essa tecnologia e também facilitar a leitura e compreensão das diversas referências técnicas disponíveis, como as RFCs que especificam o protocolo e suas funcionalidades – basicamente [RFC 1771] e [RFC 1772] – além dos excelentes livros que abordam o tema em profundidade.

A principal diretriz da narrativa foi mantê-la o mais didática possível, e seguindo esta visão, alguns termos técnicos foram traduzidos de forma livre pelo autor, a fim de facilitar a compreensão dos assuntos abordados, não sendo obrigatoriamente a tradução técnica oficial para a língua portuguesa.

Este artigo também não se propôs a oferecer em profundidade todos os conceitos e técnicas avançados sobre o protocolo BGP-4, mas sim oferecer uma introdução, com clareza, para que o leitor tenha um primeiro contato ameno com o assunto e se sinta à vontade ao iniciar estudos aprofundados sobre o tema.

^

Introdução

Na parte 2 do artigo, foi iniciada a descrição de quais são as mensagens trocadas entre roteadores configurados com BGP, que tipo de informações elas transportam e sua finalidade.

Dando continuidade a esta descrição, neste artigo, será apresentado o último tipo de mensagem BGP, a de atualização de rotas, conhecida por UPDATE. Dessa forma, serão descritos os atributos que as mensagens UPDATE possuem, com suas características e finalidades. Em seguida, serão apresentados mais alguns importantes conceitos como redistribuição e sincronização. Por fim, serão dadas algumas dicas, exemplos de problemas comuns enfrentados pelos provedores e de erros corriqueiros de configuração deste protocolo.

^

Tipos de mensagem BGP (cont.)

UPDATE

As mensagens UPDATE, trocadas entre os peers ou neighbors BGP, são de extrema importância, pois são elas que levam as informações para a atualização da tabela de rotas mantida pelo BGP.

A estrutura básica das mensagens do tipo UPDATE é composta de 3 itens:

• Rotas Inalcançáveis (Unreachable Routes);
• Atributos de Caminhos (PATH Attributes);
• Informação de alcance da camada de rede – (NLRI – Network Layer Reachability Information);

O formato da mensagem do tipo UPDATE é:

Figura 1 – O Formato da Mensagem UPDATE

Comprimento das Rotas Removidas ou Inalcançáveis (Unfeasible Routes Length) – características: [2 bytes, inteiro, positivo].

Neste campo, é indicado o comprimento total, em bytes, do total de rotas removidas (Withdrawn Routes).

Rotas Removidas (Withdrawn Routes) – características [comprimento variável].

Este campo inclui uma lista de prefixos de endereços para rotas que devem ser removidas da tabela de rotas BGP. É composto por endereços IP mais o comprimento do número de bits contados a partir da esquerda no endereço IP, como mostrado abaixo.

Figura 2 – O formato do Campo de Withrawn Routes

• Prefixo – (Prefix) – características [comprimento variável]
  Contém prefixos de endereços IP seguidos de bits suficientes para fazer o final deste campo terminar “arredondado” em bytes completos. O valor dos bits complementares não têm importância.
• Comprimento (Lenght) – características [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, não há rotas a serem removidas.

Comprimento Total do Atributo PATH (Total Path Attribute Length) – características [2 bytes, inteiro, positivo]

Deve indicar o comprimento total, em bits, do campo Atributos PATH. O valor contido neste campo deve permitir a determinação do comprimento do campo NLRI. Se o valor deste campo for 0 (zero), significa que não há informação NLRI presente na mensagem UPDATE.

Atributos do PATH (PATH Attributes) – características [comprimento variável]

São um conjunto de parâmetros associados a uma determinada rota que influenciam no processo de decisão, feito pelo BGP, para escolha da melhor rota. Mais adiante, estes atributos serão vistos com mais detalhes.

Informações NLRI (NLRI Information) – características [comprimento variável]

São prefixos de endereços IP de informações no formato igual ao do campo de rotas removidas (Withdrawn Routes). Este campo é preenchido por várias entradas:

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 notação CIDR).

^

Atributos BGP

Como foi visto, as mensagens UPDATE incluem o campo PATH Attributes que carrega as informações dos atributos BGP para as rotas anunciadas no campo NLRI. São dadas, a seguir, breves descrições de alguns dos atributos do BGP. Atributos definidos para uso em implementações específicas e uso restrito estão além do alcance deste artigo introdutório.

Existem as seguintes categorias de atributos:

• Conhecido Obrigatório (Well-Known Mandatory)
  Trata-se de um atributo definido na especificação original do protocolo BGP. Deve estar sempre presente em todas as mensagens do tipo UPDATE e deve ser obrigatoriamente reconhecido em todas as implementações do protocolo. Caso não esteja presente na mensagem UPDATE, será enviada uma mensagem do tipo NOTIFICATION informando o erro.
• Conhecido Arbitrário (Well-Known Discretionary)
  É o tipo do atributo reconhecido por todas as implementações do protocolo BGP mas que não precisa estar obrigatoriamente presente em todas as mensagens UPDATE enviadas.

Além dos atributos well-known acima, existem os opcionais, que podem ser transitivos ou não (Optional Transitive e Optional Non-transitive) e que não são obrigatoriamente suportados por todas as implementações do BGP.

• Opcional Transitivo (Optional Transitive)
  Ao receber uma mensagem UPDATE, se um atributo opcional não for reconhecido por determinada implementação do BGP, a mesma procura verificar se a flag transitive (ver explicação abaixo) está ativada, ou não, para aquele atributo. Em caso positivo, este atributo é repassado nas mensagens UPDATE seguintes, enviadas pelo roteador para seus vizinhos.
• Opcional Não Transitivo (Optional Non-transitive)
  Inverso do Opcional Transitivo, se a implementação do BGP não reconhecer o atributo opcional e não encontrar a flag transitiveativada, o atributo é ignorado e não é repassado para os vizinhos BGP nas mensagens UPDATE subseqüentes.

Uma vez descritas as categorias de Atributos, veremos agora eles aparecem na mensagem UPDATE. Os PATH Attributes são uma seqüencia de comprimento variável, que deve estar presente em todas as mensagens do tipo UPDATE. Cada atributo é um trio de dados, de comprimento variável, composto por:

.

O tipo do atributo é um campo de 2 bytes que contém: Flags de Atributos (1 byte) e Código do Tipo de Atributo (1 byte).

Figura 4 – O Formato dos Tipos de PATH Attributes

O primeiro bit das Flags de Atributos chama-se Opcional (Optional), que determina se o atributo é Optional ou Well-known [ 1 | 0 ].

O segundo bit é chamado de Transitivo (Transitive). Ele determina se um atributo opcional é transitivo ou não [ 1 | 0 ]. No caso de atributos Well-Known, o bit Transitive deve ter sempre seu valor igual a 1.

O terceiro bit é chamado de Parcial (Partial). Determina se a informação do atributo opcional Transitive é parcial ou completa [ 1 | 0 ]. Atributos Well-Known e atributos opcionais Non-Transitive o bit Partial deve ser 0 (zero).

O quarto bit é o de Comprimento Estendido. Ele diz se o Attribute Length tem 1 ou 2 bytes [ 0 | 1 ] e deve ser usado somente se o comprimento do valor Atributo for maior que 255 bytes.

Os outros 4 bits restantes não são usados e devem ser todos zerados. Devem também ser ignorados pelo destinatário da mensagem UPDATE.

O campo Código do Tipo de Atributo deve conter os valores numéricos correspondentes a cada tipo de atributo. Estes valores numéricos atualmente são mantidos pela Internet Assigned Numbers Authority – IANA e podem ser encontrados em:

http://www.isi.edu/in-notes/iana/assignments/bgp-parameters .

A lista atual dos Tipos de Atributos BGP (e seus respectivos valores identificadores) é a seguinte:

Código de Tipo	Atributo	Referência	Categoria	Definido por:
1	ORIGIN	[RFC1771]	Well-known mandatory	–
2	AS_PATH	[RFC1771]	Well-known mandatory	–
3	NEXT_HOP	[RFC1771]	Well-known mandatory	–
4	MULTI_EXIT_DISC	[RFC1771]	Optional Non-transitive	–
5	LOCAL_PREF	[RFC1771]	Well-known discretionary	–
6	ATOMIC_AGGREGATE	[RFC1771]	Well-known discretionary	–
7	AGGREGATOR	[RFC1771]	Optional transitive	–
8	COMMUNITY	[RFC1771]	Optional transitive	Cisco
9	ORIGINATOR_ID	[RFC1998]	Optional non-transitive	Cisco
10	CLUSTER_LIST	[RFC1998]	Optional non-transitive	Cisco
11	DPA	[Chen]	–	MCI
12	ADVERTISER	[RFC1863]	–	Baynet
13	RCID_PATH/CLUSTER_ID	[RFC1863]	–	Baynet
14	MP_REACH_NLRI	[RFC2283]	–	–
15	MP_UNREACH_NLRI	[RFC2283]	–	–
16	EXTENDED COMMUNITIES	[Rosen]	–	–
…	–	–	–	–
255	Reservado para desenvolvimento	–	–	–

ATRIBUTO ORIGIN [TYPE CODE 1]

Indica a origem do anúncio de rota, ou NLRI (que indica o prefixo e a máscara de bits), com relação ao AS que o originou. Pode conter um dos valores:

As indicações “i”, “e” e “?” aparecem na extremidade direita da tabela de rotas do BGP como podemos ver no exemplo abaixo.

roteador>show ip bgp BGP table version is 117080, local router ID is 200.180.1.142 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 * 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

Exemplo de Tabela de Rotas com Diferentes Origens

ATRIBUTO AS_PATH [TYPE CODE 2]

É uma seqüência de ASNs que uma rota cruza para alcançar uma determinada rede de destino. O AS que origina uma rota acrescenta seu ASN ao anunciar uma rota sua para seus vizinhos BGP externos. Daí pra frente, cada AS que receber a rota, acrescenta seu próprio ASN no início da seqüencia de ASNs e repassa a rota para outros peers seus que irão fazer o mesmo. A lista final vai representar todos os ASNs que uma rota atravessou com o ASN do AS de origem da rota no final da seqüencia, também conhecida como AS_Sequence.

Caso um AS receba um anúncio de rota que contenha seu próprio ASN na seqüencia inclusa no AS_PATH, este anúncio será rejeitado e descartado, garantindo assim, que não haverá loop de roteamento na tabela BGP desse AS.

Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informação contida no AS_PATH não é alterada.

A informação contida no AS_PATH é uma das usadas no processo de seleção da melhor rota para determinado destino. Ao comparar duas rotas para um mesmo destino (considerando que os outros atributos sejam idênticos), o BGP vai preferir a que possuir o AS_PATH menor. Caso o caminho (path) seja do mesmo tamanho, o BGP vai usar outros atributos para fazer a sua escolha da melhor rota.

ATRIBUTO NEXT_HOP [TYPE CODE 3]

Basicamente, este atributo recebe o endereço IP da interface do próximo roteador – próximo salto (next hop) a ser dado – para se chegar a determinado destino. No caso, para alcançar as redes de destino incluídas na mensagem UPDATE.

Existem três situações diferentes que determinam o NEXT_HOP:

• Em sessões eBGP, onde o NEXT_HOP será sempre o IP de um roteador de borda (peer BGP) de um AS vizinho que originou a rota.
• Em sessões iBGP onde a rota foi originada dentro do AS, o NEXT_HOP será o endereço IP do vizinho que anunciou a rota originalmente. O NEXT_HOP aprendido pelo eBGP não é alterado pelo iBGP, permanecendo o endereço IP do peer eBGP que originou o anúncio da rota.
• Quando a rota é anunciada em mídias de multiacesso (como Ethernet e Frame Relay), o NEXT_HOP geralmente é o endereço IP da interface do roteador conectada à mídia que originou a rota.

Existem, entretanto, outras regras definidas pela [RFC 1771]:

• Um roteador que “fala” BGP só pode anunciar como NEXT_HOP um roteador de borda de seu próprio AS caso uma interface com endereço IP de cada um faça parte de uma mesma sub-rede.
• O roteador pode anunciar como NEXT_HOP qualquer roteador de borda externo (AS vizinho), desde que o IP dele tenha sido aprendido de um dos seus pares (peers) BGP e que uma interface com endereço IP de ambos façam parte de uma mesma sub-rede.
• Ao anunciar uma rota para um vizinho do mesmo AS, o valor do NEXT_HOP associado à rota não deve ser alterado.
• Um roteador não pode anunciar como NEXT_HOP para um vizinho (peer) o endereço IP do mesmo.
• Um roteador não pode anunciar como NEXT_HOP o seu próprio endereço IP.

roteador> show ip bgp BGP table version is 117080, local router ID is 204.189.152.142 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 *> 139.82.0.0 200.159.255.253 20 0 2715 i *>i143.54.0.0 200.132.0.16 1 100 0 i

Exemplo de Informações NEXT_HOP Aprendidas Através de Mensagens UPDATE

ATRIBUTO MÉTRICA (MED – MULTI_EXIT_DISCRIMINATOR) [TYPE CODE 4]

Este atributo tem como finalidade informar para os vizinhos BGP externos (peers) qual o melhor caminho (path) para uma determinada rota do próprio AS; influenciando-os, assim, em relação a qual caminho deve ser seguido no caso do AS possuir diversos pontos de entrada.

BGP table version is 117080, local router ID is 204.189.152.142 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 *> 139.82.0.0 200.159.255.253 20 0 2715 i *>i143.54.0.0 200.132.0.16 1 100 0 i *>i143.106.0.0 200.136.34.1 0 100 0 1251 i *> 146.134.0.0 200.159.255.32 1200 32768 i *> 146.164.0.0 200.159.255.253 20 0 2715 i *> 147.65.0.0 0.0.0.0 0 32768 i *>i150.165.0.0 200.130.255.70 1112000 100 0 i

Exemplo de Tabela de Rotas com Diferentes Métricas

ATRIBUTO LOCAL_PREF [TYPE CODE 5]

Este atributo serve para anunciar qual é o caminho preferencial de saída (de pacotes) para uma determinada rota, destinada a uma rede externa ao AS. Como o próprio nome do atributo sugere, o LOCAL_PREF somente é anunciado (repassado) entre os roteadores vizinhos BGP (iBGP)do mesmo AS e não é repassado aos roteadores vizinhos externos (eBGP). Caminhos (paths) que possuem o LOCAL_PREF com maior valor são preferidos pelo BGP. O valor padrão do LOCAL_PREF é 100.

ATRIBUTO ATOMIC_AGGREGATE [TYPE CODE 6]

Este atributo é usado por um roteador que, ao ter que selecionar uma rota dentre outras – recebidas de seu peer – que se sobrepõem, escolhe uma, ignorando a mais específica. Então, ele deve incluir o atributo ATOMIC_AGGREGATE à rota quando for propagá-la a seus vizinhos (caso o atributo ainda não esteja presente na rota menos específica recebida).

Um roteador que receba uma rota com o atributo ATOMIC_AGGREGATE não deve removê-lo e não deve fazer nenhum NLRI da rota mais específica quando for propagar a rota aos vizinhos BGP. Ele precisa também reconhecer que o caminho atual para os destinos (como especificado no campo NLRI da rota), respeitando a ausência de loops de roteamento, pode cruzar ASs que não estejam listados no AS_PATH.

Uma outra observação importante: não é possível agregar um endereço sem ter uma rota mais específica daquele endereço na tabela de roteamento. Por exemplo: um roteador não pode gerar uma rota agregada para 160.0.0.0 sem possuir previamente uma rota de 160.0.0.0 em sua tabela de roteamento.

ATRIBUTO AGGREGATOR [TYPE CODE 7]

Este atributo pode ser incluído em mensagens UPDATE que sejam formadas por agregação. O atributo AGGREGATOR contém o ASN do último roteador que formou uma rota agregada, seguido de seu próprio ASN e endereço IP.

ATRIBUTO COMMUNITY [TYPE CODE 8]

Este atributo é usado para representar um agrupamento de destinos que compartilhem uma ou mais características, não sendo estas restritas a um mesmo AS, rede ou conjunto de redes. As delimitações do agrupamento são políticas, podendo envolver mais de um AS, inclusive. As comunidades (communities) podem ser compostas de diversas redes pertencentes a qualquer AS, usadas para simplificar políticas de roteamento identificando rotas por algum parâmetro lógico ao invés de prefixos CIDR ou ASNs. Usando esses atributos, um roteador pode combiná-los com outros para determinar, para cada comunidade, quais rotas devem ser aceitas, descartadas, preferidas ou repassadas para outros vizinhos.

O valor deste atributo pode estar entre 0 (zero) e 4.294.967.200 e consiste de conjuntos de valores de 4 bytes.

“ATRIBUTO” WEIGHT

Definido pela Cisco Systems, o WEIGHT não é propriamente um atributo BGP. Ele influencia no processo de seleção da melhor rota do roteador onde for definido e, como é um atributo local ao roteador, não é repassado e nem propagado aos seus vizinhos nas mensagens UPDATE. O WEIGHT é um valor decimal entre 0 e 65535, sendo o valor padrão igual a 32768, assumido para rotas originadas pelo roteador. Outras rotas possuem o WEIGHT igual a 0 (zero), por padrão. Havendo mais de uma possível rota para um mesmo destino, o BGP-4 seleciona a que possuir o atributo WEIGHT com maior valor.

Este atributo é comumente usado pelos operadores de redes para influenciar o processo de escolha de rotas do BGP.

O MED é anunciado somente entre ASs. Porém, só o AS de origem pode fazer anúncios com valores neste atributo, enquanto um AS vizinho que receba o atributo via mensagem UPDATE não pode repassar o valor deste atributo a outros ASs, fazendo uso dos mesmos apenas para tomadas de decisão internas ao AS.

Quando repassado o anúncio da rota a um terceiro AS, por exemplo, o atributo MED recebe o valor 0 (zero). O BGP seleciona a rota que possuir o atributo MED com menor valor. Havendo contato com mais de um vizinho BGP pertecentes a um mesmo AS que façam anúncios com métrica, o roteador (do AS vizinho) que receber os UPDATEs vai comparar as métricas para os caminhos oferecidos por estes roteadores, se ele não for configurado para o contrário. Para um roteador comparar métricas anunciadas por vizinhos BGP de ASs diferentes, é necessário usar um comando especial de configuração no roteador.

Valor	Descrição
0	IGP – a origem é interna ao AS originário da mensagem (indicado por um “i” na tabela de rotas), seja ela recebida através da redistribuição das rotas do IGP para o BGP (daquele AS) ou pela simples configuração do BGP naquele roteador.
1	EGP – a origem é de um AS externo e foi recebida por um anúncio de um EGP. É identificada por um “e” na tabela de rotas. Este tipo de entrada dificilmente será visto nas tabelas de rotas atualmente.
2	INCOMPLETE – a NLRI é desconhecida ou aprendida por outros meios (além dos acima). Geralmente acontece quando uma rota estática (configurada manualmente por um operador) é redistribuída no BGP e a origem da rota fica incompleta. É indicada por um “?” na tabela de rotas.

^

Redistribuição

Num roteador, cada protocolo de roteamento mantém a sua tabela de rotas individual na memória, enquanto o próprio roteador mantém uma outra tabela montada com rotas fornecidas por todos os protocolos de roteamento que estiverem sendo executados no mesmo. Esta é a tabela utilizada pelo roteador para executar sua função de rotear pacotes de dados.

A redistribuição acontece quando, em um roteador, um protocolo de roteamento repassa as rotas de sua tabela para outro protocolo de roteamento. O outro protocolo pode aceitá-las (ou não) todas ou apenas algumas e incluí-las em sua tabela de rotas. Posteriormente, estas rotas serão anunciadas por este outro protocolo para os roteadores vizinhos que “falam” este mesmo protocolo.

O comando network é uma das formas de anunciar as redes de um AS no protocolo BGP. Outra forma é redistribuir as rotas conhecidas pelo IGP para o BGP. Isso pode ser muito perigoso, pois pode-se injetar todas rotas internas do AS no BGP desnecessariamente. Se, por exemplo, uma das rotas podem ter sido aprendidas através do próprio BGP, então não há necessidade de repassá-las novamente. Uma filtragem cuidadosa deve ser aplicada para garantir que só serão anunciadas para a Internet rotas que, realmente, se deseja anunciar e não anunciar todas indiscriminadamente.

^

Mapas de rotas (Route Maps)

São uma forma de controlar e modificar informações de roteamento. Os route-maps possibilitam a definição de condições para, por exemplo, redistribuição de rotas entre protocolos de roteamento – BGP e algum IGP – ou o controle das rotas injetadas (ou removidas) no BGP.

A sintaxe do comando para criação de um route-map é:

route-map [[permit | deny] | [ número seqüencial ]]

O pode ser qualquer nome escolhido para indentificá-lo. Múltiplas instâncias do mesmo route-map podem ser configuradas (com o mesmo nome), e o é um indicativo da posição que o novo route-map deve ter dentro da lista daqueles já configurados com o mesmo nome. Exemplo:

# route-map MAPA permit 10 # route-map MAPA permit 20

Aplicando as condições para rotas de entrada ou de saída, o primeiro conjunto de condições será aplicado e, caso nenhuma das condições seja atendida, o segundo conjunto seré aplicado. As condições são configuradas através dos comandos match e set.

match ip address 1.1.1.1 set metric 5

A partir daí, podem ocorrer duas situações: o envio da atualização (envio do UPDATE) ser permitido ou negado. Se as condições forem encontradas na mensagem, então será permitida a redistribuição ou o controle (pelo comando set) da atualização de rotas.

Caso as condições não sejam encontradas, será negada a redistribuição ou controle da atualização de rotas feitos por este route-map. Neste caso, a próxima instância do route-map (route map MEU-MAPA permit 20) será verificado e assim por diante, até a última instância deste ser processada. Se a lista de route-maps for toda processada e nenhuma condição satisfeita, então a rota não será aceita ou redistribuída, ou seja, as rota será descartada.

A lista de comandos relacionados ao comando match são:

match as-path match community match clns match interface match ip address match ip next-hop match ip route-source match metric match route-type match tag

A lista de comandos relacionados ao set são:

set as-path set automatic-tag set community set clns set interface set default interface set ip next-hop set ip default next-hop set ip precedence èaÉ set level set local-preference set metric set metric-type set next-hop set origin set tag set weight

No exemplo abaixo, deseja-se definir um route-map que verifique nas mensagens UPDATE de saída se foi encontrado o IP 1.1.1.1. Neste caso, o atributo METRIC (ou MED) deste UPDATE deve ser alterado para 5:

^

Sincronização

No caso de um AS servir de trânsito entre outros dois ASs, o BGP não deverá anunciar uma rota antes que todos os roteadores do AS tenham aprendido a rota através do IGP. Assim, ele deverá aguardar até que o IGP tenha propagado a rota por todo o AS e somente após faça o anúncio para os vizinhos BGP externos. Daí, o termo sincronização.

Isso é importante para evitar “buracos negros” de roteamento, ou seja, situações em que algum roteador do AS anuncie para um vizinho externo que tem rota para um determinado destino em um terceiro AS, porém os roteadores internos do mesmo AS deste roteador anunciante não têm a menor idéia da existência deste destino, pois não receberam informações sobre a rota para a rede do terceiro AS através do IGP (que a deve receber por redistribuição do BGP). Assim que pacotes enviados para este destino alcançarem algum destes roteadores internos do AS de trânsito, os mesmos serão simplesmente descartados.

É possível, entretanto, “desligar” a sincronização, caso ela não seja necessária. Por exemplo, se o AS não serve de trânsito entre outros ASs ou se todos os roteadores estiverem usando BGP sem rodar nenhum IGP. Assim, há a vantagem de se ter menos entradas na tabela de rotas e uma maior rapidez de convergência do BGP.

^

Filtragem no BGP

O envio e aceitação de atualizações de rotas (mensagens UPDATE) pode ser controlado através de filtros. Existem diferentes métodos que levam aos mesmos resultados, sendo que a escolha por um deles depende da configuração da rede. As atualizações podem ser filtradas baseado em rotas, caminhos (paths) ou em comunidades (communities).

^

Configurações em roteamento Cisco

Nesta sessão, é mostrado como fazer a inicial do protocolo BGP em um roteador Cisco. Para tal, assume-se que o ASN ao qual o roteador pertence é 100. Assim, o comando de configuração será:

router bgp 100

Com este comando, o BGP já está ativado no roteador. Os mesmos comando deve ser incluído na configuração de outros roteadores para ativar neles o BGP com seus respectivos ASNs.

O próximo passo é o estabelecimento das vizinhanças BGP com roteadores de outro AS (peer) ou do mesmo AS (para configurar iBGP), através do comando neighbor:

neighbor remote-as

Exemplo: (retirado de [Halabi-2])

roteador-a#
router bgp 100
neighbor 129.213.1.1 remote-as 200

roteador-b#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200

roteador-c#
router bgp 200
neighbor 175.220.212.1 remote-as 200

Olhando a saída do comando show ip bgp como no exemplo abaixo (ainda de [Halabi-2] ):

# show ip bgp neighbors

BGP neighbor is 129.213.1.1, remote AS 200, external link
BGP version 4, remote router ID 175.220.212.1
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10

pode-se confirmar o estabelecimento da sessão BGP entre os neighbors, observando-se a informação BGP state = Established.

Para reiniciar uma sessão BGP no caso de alterações na configuração, deve-se usar o comando:

clear ip bgp

ou

clear ip bgp *

Este comando reinicializa TODAS as sessões BGP com todos os vizinhos, portanto o seu uso requer cuidados.

^

Dicas e erros de configuração

A seguir são dadas algumas dicas em relação a configuração e mesmo manutenção do protocolo BGP.

• Sempre filtrar as redes reservadas! A [RFC1918] especifica alocação de endereços para redes privadas, cujas rotas nunca deverão ser anunciadas para a Internet.A IANA reservou os três blocos de endereços IP abaixo para uso em redes internet privadas:

  10.0.0.0 – 10.255.255.255 (prefixo: 10/8 )
  172.16.0.0 – 172.31.255.255 (prefixo: 172.16/12 )
  192.168.0.0 – 192.168.255.255 (prefixo: 192.168/16 )

  Na notação CIDR, o primeiro bloco é de 24 bits, o segundo de 20 bits e o terceiro de 16 bits. Na notação pré-CIDR, o primeiro bloco corresponde a uma Classe A, o segundo, um conjunto de 16 Classes B contíguas; e o terceiro a um conjunto de 256 Classes C contíguas.

  Toda esta faixa de endereços reservados tem que ser devidamente filtrada e não pode ser redistribuída do IGP (RIP, OSPF, IGRP, EIGRP etc.) para o BGP.

• Evitar, a todo custo, fazer redistribuição entre diferentes protocolos de roteamento. Se não for possível abrir mão deste recurso, faça-o com a maior atenção.
• Um erro comum e freqüente é o de não se filtrar os anúncios do protocolo RIP (que em geral roda livremente nas redes locais) que acabam sendo redistribuídos no IGP (IGRP, EIGRP, OSPF) se não houver o devido route-map para filtrá-los.
• Sempre anunciar as redes de seu AS através do comando network, cuja sintaxe é:

  network

  Para ISPs que desejam pedir seu próprio AS e tornar-se multi-homed (ter mais de uma saída para diferentes provedores), é preciso se tomar algumas decisões, como por exemplo:

  • Qual deverá ser a “rota default” (0.0.0.0) de saída do seu AS ?
  • Caso seu AS vizinho (e, possivelmente, o upstream provider do seu AS) anuncie a “rota default” 0.0.0.0, seu AS deve aceitá-la ou não?
  • Estas são algumas questões que surgem ao se tornar um Sistema Autônomo; as quais deve-se refletir com cuidado antes de decidir qual será a política de roteamento a ser adotada no seu AS.

^

Conclusão

Nesta parte final do artigo O Protocolo BGP-4, foi descrita a mensagem tipo UPDATE do BGP-4, responsável por divulgar todas as mudanças ocorridas nas redes interconectadas e que permite a construção das tabelas de roteamento utilizadas pelo protocolo BGP.

Também foram descritos os Atributos BGP, que são características associadas às rotas que compõem a tabela de roteamento do BGP e permitem um controle arbitrário do tráfego e dos caminhos utilizados para entrada e saída de tráfego nos ASs.
Por fim, foram dados alguns exemplos de configuração básica do BGP em roteadores da plataforma Cisco e, por fim, algumas recomendações gerais, dicas e exemplos do que não se deve ou não fazer em termos de configuração de roteamento.

Alex Soares de Moura <alex@nc-rj.rnp.br>
Rede Nacional de Ensino e Pesquisa (RNP)

Introdução

Este artigo procura apresentar uma introdução ao protocolo de roteamento Border Gateway Protocol Version 4, BGP-4, que podemos considerar, parafraseando o Dr. Douglas E. Comer, “a cola que mantém a Internet unida e permite a interconexão universal” atualmente.

O BGP-4 possibilita o intercâmbio de informações de roteamento entre os diversos sistemas autônomos, ou ASs (Autonomous Systems), que em conjunto, formam a Internet. Explicando de uma forma simplificada, ele permite que os dados trafeguem entre os ASs até chegar ao AS de destino, e dentro dele siga até o seu destino final (máquina).

Uma vez que o BGP-4 também está presente (em uma versão chamada BGP-4+ [RFC 2283]) no backbone Internet do futuro, o6bone, conhecer seus mecanismos básicos é fundamental para qualquer um que esteja ou deseja estar envolvido na administração de um AS de qualquer porte ou que precisa saber mais sobre roteamento na Internet.

^

Histórico

Há alguns anos, quando o principal backbone da Internet era a ARPANET, as instituições de pesquisa conectadas à rede precisavam gerenciar manualmente as tabelas de rotas para todos os possíveis destinos, ou seja, todas as outras redes conectadas (ver Figura 1).

Com o crescimento da Internet, verificou-se que era impraticável manter todas as tabelas atualizadas dessa forma, e que mecanismos de atualização automática eram necessários. Os pesquisadores da Internet optaram, então, por usar uma arquitetura que consistia de um reduzido e centralizado grupo de roteadores (core routers) que tinham, em suas tabelas, as rotas para todos os possíveis destinos da Internet; e um outro grupo maior de roteadores que possuíam em suas tabelas apenas informações (rotas) parciais, e não para toda a Internet.

Os core routers eram administrados pelo INOC (Internet Network Operations Center), e o grupo maior de roteadores externos ficou conhecido pelo termo “noncore routers” (roteadores fora do núcleo), que conectavam as redes locais das instituições de pesquisa ao backbone da ARPANET.

Figura 1: Backbone da ARPANET

Foi desenvolvido, então, o protocolo GGP (Gateway-To-Gateway Protocol), que foi usado nos core routers para atualização automática das tabelas de rotas entre eles. O GGP era um protocolo baseado no algoritmo de vetor de distância (Vector-Distance, também conhecido como Bellman-Ford).

Essa arquitetura tem, tecnicamente, graves pontos fracos principalmente com relação a sua capacidade de expansão, e a Internet acabou crescendo muito, indo além de um único backbone gerenciado de forma centralizada. Verificou-se, portanto, não ser possível expandir esse backbone arbitrariamente, por haver diversas limitações técnicas.

Como o backbone de cada site pode ter uma estrutura complexa, o esquema de core routers não iria conseguir suportar conectar todas as redes diretamente. Era necessário um novo esquema que permitisse aos noncore routers passar informações aos core routers sobre as redes que estavam “atrás” de si, além de oferecer autonomia de gerenciamento aos sites.

Até o momento, estava sendo usado o conceito de interconexão que levava em conta apenas a arquitetura do roteamento em uma internet e não contemplava as questões administrativas envolvidas.

Os projetistas notaram que as interconexões de um backbone com arquitetura complexa não devem ser encaradas como várias redes independentes conectadas a uma internet, mas como uma organização que controla várias redes e que garante que as informações sobre as rotas internas são consistentes e que pode escolher um de seus roteadores para fazer a ponte de comunicação para o “mundo exterior”.

Entra em cena o conceito do Sistema Autônomo (Autonomous Systems – AS), no qual as redes e roteadores estão sob o controle de uma mesma entidade administrativa. Esse conceito substitui a idéia das redes locais conectadas ao backbone central. Cada AS tem a liberdade de escolher o esquema e arquitetura que melhor lhe convém para descobrir, propagar, validar e verificar a consistência das suas rotas internas e a responsabilidade de anunciar para os outros ASs as rotas para suas redes internas não visíveis. A Figura 2 ilustra o conceito de Sistema Autônomo.

Figura 2: Exemplo de Sistema Autônomo

Para anunciar as rotas para suas redes internas entre si, os ASs precisavam concordar em usar um esquema único, como um mesmo idioma por toda a Internet; e para permitir um algoritmo de roteamento automatizado distinguir entre um AS e outro, foi designado a cada AS, um número (Autonomous System Number – ASN) pela mesma autoridade central encarregada de atribuir todos os endereços identificadores das redes conectadas à Internet (ver Figura 3).

Figura 3: Arquitetura de Backbone Usando o Conceito de ASs

^

Exterior Gateway Protocol – EGP

Dois roteadores que pertençam a ASs diferentes e trocam informações de roteamento entre si são considerados “vizinhos externos” (exterior neighbors). Se ambos pertencerem ao mesmo AS são considerados “vizinhos internos” (interior neighbors). O protocolo de roteamento usado pelos exterior neighbors é o Exterior Gateway Protocol ou simplesmente EGP [RFC 904]. É ele que permite o anúncio das rotas para as redes internas do AS para o núcleo (core) da Internet (ver Figura 4).

Com o tempo, o EGP apresentou diversas limitações técnicas e potenciais problemas para ser usado na Internet. Apesar das tentativas para produzir novas versões (EGP2 e EGP3) do protocolo, os projetistas não obtiveram sucesso por haver a necessidade de muitas alterações fundamentais na estrutura do mesmo.

O EGP apresentou deficiências insustentáveis, como restrições em topologia, incapacidade de evitar “loops” de roteamento e pouca flexibilidade para a configuração de políticas de roteamento.

Um grande desafio para os projetistas era a solução de como transformar uma arquitetura internet para não depender de um sistema centralizado (core routers) – deixando uma topologia organizada hierarquicamente e iniciando outra, com diferente estrutura. Além disso, tinha o desafio de como fazer uma arquitetura internet suportar uma forma de colaboração mais próxima entre certos ASs do que entre outros.

Figura 4: Arquitetura da NFSNET Usando o EGP

Isso levou os engenheiros do IETF a desenvolver uma solução para esses problemas através de um novo, mais moderno e mais robusto protocolo de roteamento externo, como será visto a seguir.

^

Border Gateway Protocol Version 4 – BGP-4

O BGP é um protocolo de roteamento para ser usado entre múltiplos sistemas autônomos em internets baseadas no protocolo TCP/IP. O BGP-4 [RFCs 1771, 1772] tornou-se o sucessor natural do EGP, efetivamente atacando suas deficiências mais sérias, ou seja, evitando “loops” de roteamento e permitindo o uso de políticas de roteamento entre ASs baseado em regras arbitrárias por eles definidas. Além disso, o BGP-4 foi a primeira versão do BGP a suportar endereços agregados (Classless Interdomain Routing, ou simplesmente CIDR) e o conceito de supernets.

O protocolo BGP-4 assume que o roteamento interno do AS é feito através de um sistema IGP (Interior Gateway Protocol) de roteamento interno. Este pode ser um protocolo de roteamento como o RIP, OSPF, IGRP, EIGRP; ou até mesmo através de rotas estáticas. O BGP constrói um gráfico dos ASs, usando as informações trocadas pelos “vizinhos BGP” (BGP neighbors), que são compostas dos números identificadores dos ASs, os ASN. A conexão entre ASs forma um “caminho” (path), e a coleção desses caminhos acaba formando uma rota composta pelos números dos ASs que devem ser percorridos até se chegar a um determinado AS destino.

O BGP faz uso do TCP (porta 179) para o transporte das informações de roteamento de modo que ele próprio não precisa preocupar-se a respeito a correta da transmissão das informações.

Outra característica do BGP-4 é atualização das tabelas de rotas feitas de forma incremental, como nos algoritmos de estado de enlace. A atualização completa da tabela de rotas é feita somente uma vez, quando se estabelece a sessão entre os neighbors oupeers.

Para o estabelecimento de uma sessão BGP entre neighbors ou peers, basicamente, os seguintes passos são executados:

• É estabelecida a conexão TCP entre os dois roteadores que trocam mensagens de abertura da sessão e negociam os parâmetros de operação;
• O primeiro fluxo de dados transmitido é a tabela de rotas BGP completa. Posteriores atualizações nesta tabela são feitas, incrementalmente, à medida que as mudanças ocorrerem;
• Como não há a atualização completa da tabela após a primeira, o roteador mantém a informação da versão da tabela que todos os seus peers possuem, enquanto durar a sessão entre eles. Se esta for interrompida por qualquer motivo, o processo é iniciado novamente a partir do primeiro passo;
• Mensagens de keepalive são enviadas periodicamente para manter a sessão aberta;
• Mensagens de aviso são enviadas quando ocorrem erros ou outras situações especiais;
• Caso uma conexão verifique um erro, uma mensagem é enviada e a conexão fechada, encerrando a sessão.

A figura abaixo representa a atual arquitetura da Internet, onde ASs comunicam-se via BGP-4.

Figura 5: ASs Comunicando-se Via BGP-4

^

O uso do BGP-4

O BGP é usado nas situações em que uma rede precisa conectar-se a mais de um provedor simultaneamente (multi-home), ou quando se deseja ter um pouco mais de controle sobre quais caminhos seus dados seguirão pela Internet.

Basicamente, o BGP serve para informar às redes externas a um AS quais são as rotas para redes atingíveis dentro de sua rede. Falando de outra forma, o propósito do BGP-4 é anunciar rotas para outras redes externas, ou sistemas autônomos. Esses anúncios são como “promessas” de que os dados serão transportados para o espaço IP representado pela rota sendo anunciada.

Se, por exemplo, um AS anunciar uma rota para 192.168.4.0/24 (na sintaxe anterior ao CIDR, este endereço é a classe “C” que começa em 192.168.4.0 e termina em 192.168.4.255) e alguém enviar dados destinados a qualquer endereço dentro dessa faixa, esse AS está “garantindo” que sabe enviar os dados até o destino.

^

Neighbors, Peers, eBGP e iBGP

Sistemas (roteadores) que são “vizinhos BGP” (BGP neighbors) comunicam-se através de “sessões” estabelecidas entre eles. Os roteadores de “borda” (border routers) de ASs vizinhos são considerados peers. Esses peers são as “fronteiras políticas” dos ASs, que trocam tráfego de acordo com as regras definidas pelos ASs participantes.

São chamados neighbors os sistemas BGP (roteadores) que possuem sessões BGP estabelecidas entre eles. Então, os roteadores de borda são neighbors? Sim. Porém, quando uma importância política é a eles atribuída, a forma correta de chama-los é de peers, enquanto que os neighbors são quaisquer vizinhos BGP.

Existem outras situações em que os vizinhos BGP não são, obrigatoriamente, os roteadores entre ASs e sim roteadores do mesmo AS. Neste caso as sessões estabelecidas entre eles acontece internamente ao AS. O que permite isso é o iBGP ouinternal BGP, que permite a troca de rotas no mesmo AS. De forma análoga, a troca de rotas entre ASs é feita pelo eBGP (exterior BGP). Um importante conceito do iBGP é que os neighbors não têm a obrigação de estar diretamente conectados (ver Figura 6) através de uma linha serial ou via interface Ethernet, por exemplo. Os peers por outro lado não podem estar conectados de outra forma que não seja a direta, seja link serial ou interface Ethernet.

Figura 6: Exemplo de Peers, Neighbors, eBGP e iBGP

O algoritmo do eBGP trabalha, basicamente, anunciando todas rotas que conhece, enquanto o do iBGP faz o possível para não anunciar rotas. Assim, para fazer o iBGP funcionar adequadamente dentro de um AS é necessário estabelecer sessões BGP entre todos os roteadores que “falam” iBGP (ver Figura 7), formando uma “malha completa” (full mesh) de sessões iBGP dentro do AS.

Figura 7: Exemplo de Configuração “Malha Completa” de iBGP

Estas características serão abordadas de foma mais completa posteriomente.

^

Atributos do BGP

Atributos do BGP são um conjunto de parâmetros usados para controlar informações específicas relativas a rotas, como informação sobre o caminho (path), grau de preferência da rota, o valor do next-hop da rota e informações sobre agregação. Estes parâmetros são usados pelo algoritmo do BGP como elementos para decisão da escolha das rotas e para decisão sobre filtragem de rotas. Alguns dos atributos do BGP são:

• AS_path
• Next hop
• Local preference
• Multi-Exit Discriminator (MED)
• Origin
• Atomic Aggregator
• Agregator
• Community
• Weight

Os atributos e outras características do BGP4 serão explicados em detalhes na próxima parte deste artigo.

^

Conclusão

Nesta primeira parte do artigo, foi mostrado como era a arquitetura inicial da Internet e sua evolução. Com o crescimento da rede, tornou-se necessária a criação de sistemas automatizados de configuração de rotas. Para tal, inicialmente, foi desenvolvido o EGP e, posteriormente, veio o BGP. Foram abordados, ainda que superficialmente, alguns conceitos e características do BGP-4. Na continuação deste artigo, será feita uma abordagem mais profunda do protocolo, com exemplos de configuração baseados na implementação da Cisco Systems em seus roteadores.

^

Referências bibliográficas

Internetworking with TCP/IP – Principles, Protocols and Architecture
Douglas E. Comer, 3^rd Edition, 1995, Prentice Hall

Routing In The Internet
Christian Huitema, 1995, Prentice Hall

Internet Routing Architectures
Bassam Halabi, 1997, Cisco Press

RFC 1771
A Border Gateway Protocol 4 (BGP-4)
ftp://ftp.isi.edu/in-notes/rfc1771.txt

RFC 1772
Application of the Border Gateway Protocol in the Internet
ftp://ftp.isi.edu/in-notes/rfc1772.txt

RFC 1773
Experience with the BGP-4 protocol
ftp://ftp.isi.edu/in-notes/rfc1773.txt

RFC 1930
Guidelines for creation, selection, and registration of an Autonomous System
ftp://ftp.isi.edu/in-notes/rfc1930.txt

RFC 1965
Autonomous System Confederations for BGP
ftp://ftp.isi.edu/in-notes/rfc1965.txt

BGP Route Reflection – An alternative to full mesh IBGP
ftp://ftp.isi.edu/in-notes/rfc1966.txt

RFC 1997
BGP Communities Attribute
ftp://ftp.isi.edu/in-notes/rfc1997.txt

RFC 2270
Using a Dedicated AS for Sites Homed to a Single Provider
ftp://ftp.isi.edu/in-notes/rfc2270.txt

^

Sites relacionados

BGP-4 Protocol Overview
http://www.FreeSoft.org/CIE/Topics/88.htm

Using the Border Gateway Protocol for Interdomain Routing
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm