O Border Gateway Protocol (BGP) foi desenvolvido em 1989 para atender à necessidade de roteamento entre diferentes sistemas autônomos (AS). Atualmente, é o principal protocolo de roteamento na Internet, operando desde os provedores de serviço de Internet (ISPs) até as operadoras Tier 1, responsáveis pelas conexões intercontinentais e pela hospedagem de infraestruturas em grandes data centers. Todo o tráfego da Internet depende do BGP.
A Internet é composta por diversas redes chamadas ASN. Esse identificador é único e define a organização e a quantidade de recursos (endereços IPv4/IPv6) reservados para ela. Para um endereço IP ser acessível via Internet, ele precisa ser anunciado por meio do BGP. Portanto, podemos afirmar que o BGP é essencial para o funcionamento da Internet.
Diante disso, o protocolo BGP é vital para organizações públicas e privadas que possuem um ASN. A gestão e suporte do BGP devem ser conduzidos com atenção e qualidade, independentemente do tamanho da infraestrutura.
Esse cenário de alto de nível de gerenciamento requer compreensão dos atributos de engenharia de tráfego do BGP, como, por exemplo: communities, local-preference, AS-PATH selection, expressões regulares, MED, e dentre outros parâmetros que fazem parte de uma infraestrutura de BGP, porém dominar o básico do protocolo é vital para a saúde operacional da infraestrutura principalmente durante incidentes de falha massivas no backbone ou falhas de hardware em roteadores que operam o BGP. Um dos primeiros tópicos de aprendizagem sobre o BGP é como é a formação de uma sessão BGP para troca de informações. Iremos dissertar abaixo sobre cada status de uma sessão BGP.
Uma sessão BGP pode possuir até 6 status operacionais:
Idle
Connect
Active
OpenSent
OpenConfirm
Established
Podemos dividir 6 estados das sessões BGP em dois grupos:
Antes da sessão TCP estabelecida:
Idle
Connect
Active
Idle: Desligada administrativamente. Nesse estado, nenhuma tentativa é feita para estabelecer uma conexão TCP com o peer, e nenhuma conexão TCP de entrada é aceita do peer. Quando uma sessão BGP está presa no status idle temos alguns cenários possíveis:
Falha de hardware/software do chassi que impossibilita o protocolo de iniciar
Falta de configurações na árvore do protocolo BGP para habilitar o protocolo, alguns exemplos: falta de configurações de Router ID, AS Local do chassi ou simplesmente ligar o protocolo com o comando no shutdown rsrs.
Connect: TCP SYN transmitido. O roteador local está tentando estabelecer uma conexão TCP de saída com o peer remoto.
Nesse cenário podemos nos deparar com a sessão presa no status Connect, podemos concluir que o roteador local está configurado, porém, o peer remoto ainda não está pronto. Ou seja, não houve retorno do pacote TCP SYN enviado pelo roteador local.
Active: TCP SYN recebido. O roteador está escutando uma tentativa de conexão TCP de entrada do peer remoto.
No cenário em que o roteador apresenta sessão BGP sem evoluir do status active, temos uma evidência de que o roteador local está recebendo pacotes TCP SYN, porém não está enviando pacotes TCP para estabelecer esse. Nesse caso, o roteador local não está pronto para estabelecer a sessão BGP.
Após a sessão TCP estabelecida:
OpenSent
OpenConfirm
Established
OpenSent: O roteador enviou uma mensagem de Open contendo parâmetros como versão do BGP, ASN, capacidades suportadas, entre outros.
OpenConfirm: O roteador aguarda uma mensagem KEEPALIVE do peer para confirmar que ambos aceitaram os parâmetros da sessão.
Established: Keep alive mensagem recebida. Ambos os roteadores estão prontos para troca de mensagens de route updates
Temporizadores e Mecanismos de Controle:
Após o estabelecimento da sessão, os mecanismos de controle atuam para manter as sessões estabelecidas.
Esses mecanismos que atuam em conjunto são o Hold Timer e Keepalive Timer.
O Hold Timer é um valor de tempo predefinido por padrão, mas que pode ser ajustado e é utilizado como tempo em que um roteador espera por uma mensagem keepalive de vizinho BGP antes de determinar que vizinho está inativo.
O Hold timer é negociado entre os vizinhos durante o estado Open Sent no estabelecimento da sessão BGP. O valor negociado sempre será o de menor valor configurado entre os dois roteadores. Portanto, o valor de Hold timer não é um parâmetro que precisa ser simétrico para estebelecimento da sessão, mas o menor valor configurado será o definido como mecanismo de controle da sessão BGP.
O Keepalive é de mensagem enviada por padrão a cada 60 segundos (1/3 do valor do Hold Timer) entre os vizinhos BGP para monitorar o status da conexão mesmo que nenhuma atualização de rota esteja sendo trocada.
Caso um roteador não receba uma mensagem de Keepalive ou qualquer outra mensagem BGP dentro do time definido pelo Hold Timer, ele considera que o peer está inativo e encerra a sessão BGP. Portanto, uma mensagem de Keepalive atua como"heartbeat" (batimento cardíaco) entre os roteadores.
O BGP é um protocolo confiável, porém lento. 180 segundos é um tempo confortável para a maioria dos roteadores declarar o vizinho como inativo e realizar a comutação da tabela de rotas, porém 180s pode não ser um tempo confortável dependendo do SLA da infraestrutura. Podemos acelerar esta convergência utilizando o BFD (Bidirecional Forwarding Detection) que tem capacidade de convergências no patamar de milissegundos.
Diagnóstico e Troubleshooting:
Quando temos um cenário de sessão BGP down, passamos a ter um incidente grave geralmente, seja para você com um circuito de peering internacional de grande volume de tráfego indisponível ou para o seu cliente de trânsito que acionou o NOC para informar falha do circuito de BGP.
Em cenários de crise, ter consciência sobre cada status de uma sessão BGP irá guiar o analista de redes para uma resolução assertiva com baixo desgaste operacional com a equipe ou cliente. Em minha experiência, já lidei com cenários caóticos em que um roteador de borda com 180 Gigas de tráfego simplesmente passou por uma falha de software e todas as sessões BGP mudaram para o status idle em pleno horário de máximo consumo da operação.
No início da minha carreira, dominei o modelo OSI, e com o passar dos anos eu entendi o quão importante é esse modelo para guiar um bom troubleshooting. Assim como o modelo OSI, uma falha massiva deve ser avaliada em camadas:
Camada 1 - Física
Camada 2 - Enlace
Camada 3 - Roteamento
Camada 4 - Transporte
E assim sucessivamente. Nesse fatídico dia da falha do roteador de Borda, eu recebi o acionamento massivo do call center com 70 mil clientes offline e mais de 200 alertas de sessões BGP, monitoramento de sites e aplicativos offline. Em um primeiro momento imaginei que havia uma falha de energia, mas o meu time de campo confirmou que o roteador estava operacional. Eu não tinha conectividade com nenhum dos IPs dos ASNs roteados pelo Router de BGP principal da rede, ou seja, tudo indicava ser uma falha massiva de roteamento.
Respirei fundo e recuperei acesso ao roteador via console, realizei o troubleshooting como manda a cartilha do modelo OSI:
Status interfaces físicas (Camada 1)
Aprendizagem de MAC/ARP (Camada 2)
Checar a configuração do BGP (Camada 3)
Status da sessão BGP - Conexão TCP entre os peers (Camada 4)
Nesse ponto me deparei com todas as sessões BGP em status idle. O primeiro pensamento que vem a cabeça é: falha humana com desligamento do protocolo BGP no chassi ou falha de software para iniciar o protocolo.
A primeira ação por instinto foi acessar a árvore do protocolo BGP e aplicar um comando de shut/no shutdown. Após realizar o comando, as sessões passaram a transitar para os status de Established. A falha foi encontrada pelo fabricante e corrigida com um patch do fabricante.
Dominar o funcionamento das sessões BGP é essencial para garantir a estabilidade da rede. Ter conhecimento sobre os estados de conexão, mecanismos de controle e técnicas de troubleshooting é um diferencial na resolução de incidentes de forma rápida e eficiente.
"O conhecimento é uma arma, e a preparação é o escudo."
コメント