Alex Soares de Moura <alex@nc-rj.rnp.br>
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.
Códigos de Erro |
Sub códigos de Erro |
1 - Erro no cabeçalho da mensagem |
1 - Conexão não sincronizada |
2 - Erro na mensagem OPEN |
1 - Número de versão não suportado |
3 - Erro na mensagem UPDATE |
1 - Lista de atributos mal formada |
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.
Referências bibliográficas
Internetworking with TCP/IP - Principles, Protocols and Architecture
Douglas E. Comer, 3rd 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
NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004