Fundamentos-do-bgp

A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.

OBS: Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre BGP attributes também está em produção.

O QUE É BGP

BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois speakers BGP. NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.

O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ASpath to ASpath ou Path Vector, em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.

Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).

O BGP oferece suporte a várias  address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.

CARACTERÍSTICA DO BGP

Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:

> Construção de Gráfico de ASN:

FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7

Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs:

• 64520 64600 64700
• 64520 64600 64540 64550 64700
• 64520 64540 64600 64700
• 64520 64540 64550 64700

Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo BGP Attibutes). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.

Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:

• 64512 64520 64600 64700

FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7

Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o single point of failure (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia single dualhomed (demostrado na imagem ao lado) Com isso, a BGP routing table fica:

• 64512 64520 64600 64700

• 64512 64530 64540 64700

Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload  ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este link.

OBS: BGP routing table e IP routing table serão discutido alongo desse artigo.

> Mitigação de looping:

Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance vector é derivado de que as as rotas são publicadas com um vector (distância, direção) e onde a distance é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:

• Distance Vector: Distance = direção; Vector = roteador;
• Path vector: Path = Atributos e Vector = ASN.

Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.

Ambos protocolos respeitam a regra split horizon evitando looping ou flapping de roteamento, por exemplo, na última imagem tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 descarta esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.

BGP routing table vs IP routing Table

BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos.

A tabela BGP pode ter seguintes nomes:

• BGP table;
• BGP topology table;
• BGP topology database;
• BGP routing table;
• BGP forwarding database.

OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos atomic aggregate e aggregator, porém está além do escopo deste artigo.

FUNCIONAMENTO DO BGP

Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.

Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem windown one-for-one, ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site cidr report na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.

Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma window one-for-one e usa window dynamic, permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.

OBS: as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.

Trocas de mensagens BGP, extraído do wireshark

MENSAGEM OPEN

Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:

FONTE: RFC 4271 - Página 12

• Version: campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);
• My Autonomous System: campo de 16-bit indica o ASN do remetente;
• Hold Time: campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;
• Version: BGP Identifier: um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;
• Version: Optional Parameters: identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.

MENSAGEM UPBATE

A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.

Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.

FONTE: RFC 4271 - Página 14

Atenção: alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a RFC 4271! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.

• Withdrawn Routes: é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;
• Path Attributes: uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com iana.com :

1. ORIGIN (Type code 1);
2. AS-PATH (Type code 2):
3. Next Hop (Type code 3);
4. MED (Type code 4);
5. Local Prefer (Type code 5);
6. Atomic Aggregate (Type code 6);
7. Aggregator (Type code 7);
8. Community (Type code 8);
9. Originator_ID (Type code 9);

• Network Layer Reachability Information: Uma lista de redes que pode ser alcançada por esse update.

MENSAGEM NOTIFICATION

É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada imediatamente. Um exemplo do processo notification:

Processo de Mensagem Notification

MENSAGEM KEEPALIVE

Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.

ESTADOS DE VIZINHANÇA DO BGP (FSM)

BGP é protocolo Finite State Machine, ou seja, precisa passar por vários estágio com o seu neighbor. Finite State Machine em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a cisco.com.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.

Os estágios de vizinhança são:

• Idle: o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento;
• Connect: o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;
• Open Sent: uma mensagem Open foi enviada, com os parâmetros da sessão;
• Open Confirm: o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;
• Established: os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;
• Active: um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.

Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.

FSM do BGP

1. Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;
2. Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;
3. Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;
4. Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;
5. Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;
6. No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;
7. Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;
8. Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.

PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE

Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.

Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.