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

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

Introdução
Sessão BGP
Mensagens BGP
Tipos de mensagens BGP
Conclusão
Referências bibliográficas
Sites relacionados

Nesta continuação do artigo “O Protocolo BGP-4” serão examinados, de forma mais detalhada, algumas das características básicas deste protocolo. Pela extensão do assunto abordado, ainda será necessário dar continuidade a este assunto num outro artigo.

^

Introdução

Na primeira parte deste artigo, foi visto que, quando o BGP é usado entre roteadores vizinhos (neighbors) pertencentes ao mesmo AS, ele é chamado de iBGP (interior BGP), e, quando usado entre roteadores de diferentes ASs (peers), é chamado de eBGP (exterior BGP). Foi visto também que dois roteadores que suportam o BGP-4 formam uma conexão entre eles chamada de “sessão BGP”. Tal sessão faz uso do protocolo TCP para garantir o correto transporte das informações. Por fim, também foi mencionado que, em uma sessão BGP, os roteadores vizinhos trocam mensagens variadas entre eles, com determinadas características (ex.: atributos) e propósitos.

Serão vistos, neste artigo, quais são os tipos de mensagens trocadas, as informações que elas carregam e para que servem. Em seguida, serão tratados os atributos que certas mensagens possuem.

^

Sessão BGP

Antes do estabelecimento de uma sessão BGP, os roteadores “vizinhos BGP” trocam mensagens entre si para entrar em acordo sobre quais serão os parâmetros (ex.: tempo máximo de espera entre mensagens – hold time) da sessão. Não havendo discordância e nem erros durante a negociação dos parâmetros entre as partes, a sessão BGP é estabelecida. Caso contrário, serão enviadas mensagens de erro e a sessão não será aberta.

Quando a sessão é estabelecida entre os roteadores, são trocadas mensagens contendo todas as informações de roteamento, ou seja, todos os “melhores caminhos” (best path) previamente selecionados por cada um, para os destinos conhecidos. Posteriormente, eles trocarão somente mensagens de atualização das informações de roteamento (mensagens do tipo UPDATE) de forma incremental. Esta técnica mostrou-se um avanço no que se refere à diminuição de carga nas CPUs dos roteadores e na economia da largura de banda dos enlaces quando comparada a outros protocolos que ao comunicar suas atualizações, enviam, periodicamente, a totalidade das rotas instaladas em suas tabelas.

Neste sentido, o BGP é bem econômico, somente enviando mensagens de atualizações quando ocorrem mudanças nas rotas (ex.: uma rota se tornou inválida) e informando novas rotas. Caso não existam atualizações a serem informadas, os roteadores trocam apenas mensagens (do tipo KEEPALIVE) para certificar que a comunicação entre eles está “viva”, ou seja, ainda está ativa. Estas mensagens são pequenas (apenas 19 bytes), não sobrecarregando a CPU dos roteadores e nem o enlace entre eles.

Uma característica das tabelas de rotas BGP é a existência de um número de versão, que é incrementado a cada atualização feita (através das mensagens tipo UPDATE), permitindo assim a verificação de inconsistências das informações de roteamento. Abaixo, está um exemplo da versão da tabela de roteamento:

roteador> sh ip bgp BGP table version is 72076, local router ID is 192.168.4.1 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal Origin codes: i – IGP, e – EGP, ? – incomplete Network Next Hop Metric LocPrf Weight Path (…)

Se existe um rápido aumento no número da versão das tabelas, pode ser indicativo de instabilidade na rede. A seguir, serão vistas quais e como são os tipos de mensagens trocadas entre os vizinhos BGP.

^

Mensagens BGP

As mensagens trocadas em sessões BGP têm o comprimento máximo de 4.096 bytes, e mínimo de 19 bytes. Todas as mensagens são compostas de, no mínimo, um cabeçalho e, opcionalmente, uma parte de dados. O formato do cabeçalho das mensagens BGP é:

Figura 1 – Formato do Cabeçalho das Mensagens BGP

Pode haver, ou não, uma seqüência dados após o cabeçalho.

Campo Marcador (Marker)

Serve para verificar a autenticidade da mensagem recebida e se houve perda de sincronização entre os roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem seja do tipo OPEN (abrir), ou se a mensagem tipo OPEN não possuir informação de autenticação, o campo deve estar todo preenchido com números um (1); senão, o campo marker terá o seu conteúdo baseado em parte do mecanismo de autenticação usado.

Campo Comprimento (Lenght)

Deve conter um número que representa o comprimento total da mensagem, incluindo o cabeçalho. Como podem haver mensagens que não possuem dados após o cabeçalho, a menor mensagem BGP enviada é de 19 bytes (16 + 2 + 1 bytes).

Campo Tipo (Type)

Deve conter um número que representa o código de um tipo de mensagem. Os tipos de mensagens são: KEEPALIVE, NOTIFICATION, OPEN e UPDATE.

^

Tipos de mensagens BGP

Como acabamos de ver, os roteadores vizinhos BGP (neighbors ou peers) que suportam BGP-4 trocam mensagens de quatro tipos antes ou durante uma sessão BGP. Veremos agora para que servem cada um destes tipos de mensagens.

OPEN

A mensagem do tipo OPEN é enviada para se iniciar a abertura de uma sessão BGP entre neighbors ou peers BGP. O formato desta mensagem é:

Figura 2 – Formato da Mensagem OPEN

Versão (Version) – características: [1 byte, inteiro, positivo].

Identifica a versão do BGP (3 ou 4). Este é um dos parâmetros negociados pelos roteadores que, normalmente, tentam entrar em acordo para usar a maior versão suportada. Não havendo possibilidade de consenso (ex.: um dos roteadores não suporta o BGP-4), eles tentam usar versões anteriores, até que coincidam. Nos roteadores Cisco, há como configurar a versão a ser usada pelos roteadores (se previamente se sabe qual versão ambos suportam), eliminando esta fase de negociação do processo de abertura da sessão BGP, implicando numa conseqüente economia de tempo.

Número do AS (AS Number) – características: [2 bytes, inteiro, positivo].

Deve conter o número do AS a qual o roteador (remetente da mensagem tipo OPEN) pertence.

Tempo de espera (Hold Time) – características: [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 mantém 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 máximo, o BGP considera que a comunicação com o outro roteador foi perdida e a sessão é 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 sessão será considerada como sempre “viva” (ativa) e mensagens de KEEPALIVE não serão transmitidas, pois os contadores do hold time e do KEEPALIVE não serão zerados nunca. O valor mínimo recomendado para este parâmetro é de três segundos.

Comprimento dos Parâmetros Opcionais (Optional Parameters Lenght) – características: [1 byte, inteiro, positivo].

Indica o comprimento total do campo de Parâmetros Opcionais (Optional Parameters). No caso de ausência de parâmetros opcionais, este campo será preenchido com zero.

Parâmetros Opcionais (Optional Parameters) – características: [comprimento variável].

Pode conter vários parâmetros opcionais para a negociação de abertura de uma sessão BGP. Este campo deve ser preenchido com conjuntos formados por 3 valores: [Tipo do parâmetro (1 byte), Comprimento do Parâmetro (1 byte), Valor do parâmetro (comprimento variável) ]. Um exemplo de parâmetro é o de informação de autenticação (tipo 1), usado para autenticar a sessão com o vizinho BGP.

NOTIFICATION

Este tipo de mensagem é enviada no caso de detecção de erros durante ou após o estabelecimento de uma sessão BGP. O formato da mensagem NOTIFICATION é:

Figura 3 – Formato da Mensagem Tipo NOTIFICATION

Campo Erro (Error)

Deve conter o tipo da notificação

Campo Sub Código de Erro (Error subcode)

Deve conter um valor que fornece maiores informações sobre o erro.

Campo de Dados (Data)

Pode conter dados referentes ao erro, como por exemplo, um cabeçalho mal formado (inválido), um número de AS inválido.

A tabela a seguir lista os códigos e sub-códigos de erros possíveis.

KEEPALIVE

São mensagens trocadas periodicamente com o propósito de verificar se a comunicação entre os vizinhos está ativa. A mensagem do tipo KEEPALIVE é composta apenas do cabeçalho padrão das mensagens BGP, sem dados transmitidos após o cabeçalho. O tempo máximo permitido para o recebimento de mensagens KEEPALIVE ou UPDATE é definido pelo hold time, como foi visto na descrição do tipo de mensagem OPEN.

Para manter aberta a sessão, a mensagem de KEEPALIVE deve ser enviada antes que o prazo definido no hold time expire; caso contrário a sessão será encerrada. A recomendação é que a mensagem seja enviada em até 1/3 do tempo definido no hold time. Se o seu valor for igual a zero, então as mensagens do tipo KEEPALIVE não serão enviadas.

^

Conclusão

Num próximo artigo, veremos o último tipo de mensagem (UPDATE) do BGP com seus componentes e atributos, suas definições e aplicações. Ainda nele, serão mostrados exemplos de configurações práticas baseados na implementação do protocolo BGP-4 desenvolvida pela Cisco Systems, Inc. em situações encontradas com freqüência no dia a dia de provedores de serviços Internet. Também serão apresentados alguns problemas comumente enfrentados e exemplos de erros comuns de confguração.