«

»

fev 17 2016

O Protocolo BGP4 – Parte 2

Há quase 8 anos, eu escrevi um post com a parte 1 de uma série de 3 artigos sobre o protocolo BGP que seriam escritos pelo Alex Soares de Moura, da RNP. Na verdade, eu apenas repliquei o post. O problema é que, na época, os posts 2 e 3 demoraram a sair e eu acabei me esquecendo do tema. É, e ninguém me lembrou…! Bom, hoje eu recebi uma mensagem do Alex com os links corrigidos para o post número 1, e aproveitei para verificar que os posts 2 e 3 estão disponíveis. Sendo assim, ei-los!

Autor do post original: Alex Soares de Moura <>
Publicado no site da Rede Nacional de Ensino e Pesquisa (RNP)

 


 

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 – Comprimento da mensagem inválido
3 – Tipo de mensagem inválido
2 – Erro na mensagem OPEN 1 – Número de versão não suportado
2 – Número de AS vizinho inválido
3 – Identificador BGP inválido
4 – Parâmetro opcional não suportado
5 – Falha na autenticação
6 – Tempo de espera inaceitável
3 – Erro na mensagem UPDATE 1 – Lista de atributos mal formada
2 – Atributo Well-Known desconhecido
3 – Atributo Well-Known faltando
4 – Erro nas flags de atributos
5 – Erro no comprimento do atributo
6 – Atributo origem inválido
7 – Loop de roteamento em AS
8 – Atributo NEXT_HOP inválido
9 – Erro no atributo Opcional
10 – Campo de rede inválido
11 – AS_path mal formado
Tabela 1 – Códigos e Sub-códigos de Erro Enviados nas Mensagens Tipo NOTIFICATION

 

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



Comente usando o Facebook!
5
0

2 comentários

1 menção

  1. Aldrin

    Muito bom!

    1

    0
  2. ferrugem

    Legal Marco!

    Revirando o Fórum aqui, achei um tópico que abri em 2008 sobre esse material do Alex, que na época acho que foi uma recomendação do Rodrigo Farias! 🙂 .. Old but solid gold! 😀

    http://blog.ccna.com.br/forum/topico/o-protocolo-bgp/

    As 3 partes já estavam lá desde 2008! Acho que ficou só faltando criar o post no Blog. Enfim, agora está no Blog também disponível para todos! O material é muito bom! 🙂

    Valeu por compartilhar!

    Grande abraço,
    Felipe Ferrugem!

    0

    0
  1. O Protocolo BGP4 – Parte 3 » Blog CloudCampus Networking Academy

    […] « O Protocolo BGP4 – Parte 2 […]

    0

    0

Deixe uma resposta