O Border Gateway Protocol ( BGP ) é um protocolo de troca de rota externa (um EGP ), usado em particular na rede da Internet . Seu principal objetivo é trocar informações de roteamento e acessibilidade de rede (chamados prefixos ) entre Sistemas Autônomos (AS). À medida que viaja pelo TCP , ele é considerado pertencente à camada de aplicação do modelo OSI .
Ao contrário dos protocolos de roteamento interno, o BGP não usa métricas tradicionais, mas baseia as decisões de roteamento em caminhos percorridos, atributos de prefixos e um conjunto de regras de seleção definidas pelo administrador AS. É chamado de protocolo de vetor de caminho .
O BGP suporta roteamento classless e usa agregação de rota para limitar o tamanho da tabela de rota. Desde 1994 , a versão 4 do protocolo é utilizada na Internet, sendo as anteriores consideradas obsoletas. Suas especificações são descritas no RFC 4271 A Border Gateway Protocol 4 (BGP-4) .
O BGP substituiu o Exterior Gateway Protocol (EGP) que era usado no backbone da ARPANET e permitiu a descentralização do roteamento na Internet. Seu interesse é sua escalabilidade ( escalabilidade ): ele pode processar um grande número de rotas entre muitos sistemas autônomos , evitando loops, e mascara a topologia interna dos ASs entre eles.
Algumas extensões do BGP permitem a troca de rotas IPv6 ( RFC 2545), as primeiras versões sendo limitadas ao IPv4 e a extensão multiprotocolo (MP-BGP, RFC 2858) permite que o BGP seja usado para transmitir informações de roteamento. Para muitos outros protocolos , em particular as rotas vinculadas a MPLS VPNs (IPv4, IPv6, VPLS ...).
As conexões entre dois vizinhos BGP ( vizinhos ou pares ) são configuradas explicitamente entre dois roteadores. Em seguida, eles se comunicam por meio de uma sessão TCP na porta 179 iniciada por um dos dois roteadores. O BGP é o único protocolo de roteamento a usar TCP como protocolo de transporte.
Os roteadores vizinhos são identificados por seu ID de roteador, um identificador de quatro bytes, exclusivo para cada um dos roteadores de um determinado Sistema Autônomo (AS), que pode ser escolhido arbitrariamente, mas geralmente é um endereço de loopback IPv4 de cada roteador.
Existem dois modos de operação do BGP: Interior BGP (iBGP) e Exterior BGP (eBGP). O iBGP é usado dentro de um sistema autônomo, enquanto o eBGP é usado entre dois ASes.
Em geral, as conexões eBGP são estabelecidas em conexões ponto a ponto ou em redes locais (um Internet Exchange Point, por exemplo), o TTL dos pacotes da sessão BGP é então definido como 1. Se o link físico for interrompido, o A sessão do eBGP também é, e quaisquer prefixos aprendidos por ela são anunciados como excluídos e removidos da tabela de roteamento.
Por outro lado, as conexões iBGP geralmente são estabelecidas entre endereços IP lógicos, não associados a uma interface física específica: endereços de loopback . Na verdade, convencionalmente, um protocolo de roteamento interno dinâmico ( IGP ) é usado (geralmente OSPF ou IS-IS ) que permite que os roteadores da rede em questão se conectem por meio de seus endereços de loopback . Assim, em caso de quebra de um link físico, a sessão iBGP permanece ativa se houver um link alternativo.
Uma vez estabelecida a conexão entre dois roteadores, eles trocam informações sobre as redes que conhecem e para as quais oferecem trânsito, bem como um certo número de atributos associados a essas redes que permitirão evitar loops (como AS Path ) e escolha o melhor caminho com delicadeza.
ABRIR esta mensagem é utilizada assim que se estabelece a ligação TCP entre os vizinhos BGP, permite a troca de informações como os respectivos números de AS e os IDs de roteador de cada um, e a negociação das capacidades de cada um dos peers; MANTENHA VIVO mantém a sessão aberta. Por padrão, a mensagem KEEPALIVE é enviada a cada 30 segundos, e um atraso de 90 segundos sem uma mensagem UPDATE ou KEEPALIVE recebida resulta no fechamento da sessão; ATUALIZAR esta mensagem permite o anúncio de novas rotas ou a retirada de rotas; NOTIFICAÇÃO Mensagem de fim de sessão BGP após um erro; ROUTE-REFRESH Definida na RFC 2918, a capacidade de atualização de rotas é negociada na mensagem OPEN e permite solicitar / anunciar novamente determinados prefixos após uma modificação da política de filtragem.O software que permite gerir as trocas de rotas deve implementar uma máquina de estados composta por seis estados ligados por treze eventos. Os PLCs comunicam-se através de mensagens (OPEN, KEEPALIVE, UPDATE, NOTIFICATION).
Os estados são:
As mudanças de estado e comportamento esperados são os seguintes:
Ocioso Nesse estado, o processo recusa conexões e não aloca nenhum recurso. Quando o evento de início (manual ou automático) é recebido, o processo inicia recursos e uma conexão com os vizinhos configurados e escuta as conexões de entrada na porta TCP 179 e muda para o estado Conectar. Em caso de erro, a conexão é interrompida e o processo retorna ao estado Idle; Conectar aguarda o estabelecimento da conexão TCP, então envia a mensagem OPEN e muda para o estado OpenSent. Em caso de erro, aguarda um atraso predefinido e continua a escutar na porta 179, em seguida, muda para o estado Ativo; Ativo Tenta estabelecer uma conexão TCP com o vizinho. Se for bem sucedido, envia a mensagem OPEN e passa para o estado Conectado, qualquer outro evento causa o retorno ao estado Inativo; OpenSent a mensagem OPEN foi enviada, aguarda a mensagem OPEN de volta e se não ocorrer nenhum erro, envia um KEEPALIVE e passa para OpenConfirm, nos demais casos, envia uma mensagem NOTIFICATION e retorna ao estado Idle; OpenConfirm aguarda uma mensagem KEEPALIVE e depois muda para Estabelecido, ou então uma mensagem NOTIFICATION e retorna ao estado Idle; Estabelecido a conexão BGP é estabelecida, as mensagens UPDATE e KEEPALIVE podem ser trocadas, uma mensagem NOTIFICATION provoca o retorno ao estado Idle.Cada prefixo no BGP está associado a vários atributos. Esses atributos são classificados em quatro tipos diferentes:
Aqui estão alguns atributos com seus tipos:
Atributo | Modelo | Descrição |
---|---|---|
Agregador | OT | Se agregação: Identificador e AS do roteador que realizou a agregação |
AS Path | WM | Lista ordenada de sistemas autônomos cruzados |
Agregado atômico | WD | Se agregação "atômica" (removendo ASes agregados): lista de ASs removidos após a agregação |
ID de cluster | NÓS | Identificador de cluster de refletor de rota |
Comunidade | OT | Marcação de estrada |
Preferência local | WD | Métrica para roteadores internos para preferir certas rotas |
Discriminador de saída múltipla (MED) | NÓS | Métrica destinada inicialmente a roteadores externos, a fim de fazê-los preferir certas rotas (finalmente utilizável de forma mais ampla) |
Próximo salto | WM | Endereço IP do vizinho BGP |
Origem | WM | Origem da rota (IGP, EGP ou Incompleto ) |
ID do originador | NÓS | Identificador afixado pelo refletor de rota para indicar a ID do roteador original da rota |
Peso | NÓS) | A extensão Cisco, a fim de preferir localmente certos vizinhos, nunca é transmitida aos vizinhos |
O atributo AS Path é usado para evitar loops. Se uma rota for recebida de um vizinho eBGP com seu próprio AS no AS Path, a rota será rejeitada.
MEDO atributo Multi-Exit Discriminator permite que um AS indique um link preferencial. O MED é um custo digital codificado em 32 bits, pode vir de um protocolo de roteamento interno.
O atributo MED só é comparado se o AS vizinho for idêntico. No entanto, algumas implementações tornam possível comparar os MEDs mesmo entre diferentes ASs vizinhos. Se houver mais de duas rotas possíveis de pelo menos dois ASs vizinhos, em algumas implementações, a seleção da melhor rota pode, por padrão, depender da ordem em que as comparações são feitas.
Família de comunidades ComunidadeUma rota pode ter uma lista de atributos da comunidade . Cada comunidade é um número de 32 bits geralmente representado na forma x: y, onde x é um número AS ey um número cujo significado é específico para o AS. Por exemplo, AS 100 pode ter uma política de atribuição de uma preferência local 200 na presença da comunidade 100: 200, isso permite que um AS influencie o roteamento dentro de outros ASs.
Comunidade estendidaA RFC 4360 generalizou o conceito de comunidades com este atributo OT. A comunidade estendida é composta de um ou dois bytes para o tipo e 6 ou 7 bytes para o valor. A IANA mantém um registro de valores de tipo reservados.
Para alguns tipos (por exemplo, o tipo Route-Target), o valor pode ser dividido em dois campos (AS: LocalAdmin ou IPv4: LocalAdmin). Neste caso, o tamanho de cada um dos dois campos (2 ou 4 bytes) depende do tamanho do outro (para um total de 6 bytes).
Observação: no último tipo de caso, uma vez que as comunidades estendidas RFC 7153 são compatíveis com ASs de 32 bits.
Grande ComunidadeA introdução de números AS de 32 bits apresenta um problema com o atributo de comunidade (que só pode receber um AS de 16 bits, o que torna inoperante a correspondência entre este campo e o valor real do AS). É por isso que o RFC 8092 e o RFC 8195 apresentam um atributo Large Community de 12 bytes, dividido em três campos de 4 bytes cada (AS: função: parâmetro).
Próximo saltoQuando um prefixo é anunciado para um vizinho eBGP, o atributo Next Hop representa o endereço IP de saída para esse vizinho. Este atributo não é alterado quando transmitido aos vizinhos iBGP, o que implica que a rota para o endereço IP do vizinho do eBGP é conhecida por meio de um IGP . Caso contrário, a rota BGP é marcada como inutilizável.
As rotas anunciadas pelos vizinhos do BGP são filtradas e possivelmente rejeitadas ou marcadas alterando os atributos dessas rotas. A tabela BGP é construída comparando as rotas recebidas para cada prefixo escolhendo a melhor rota. Apenas a melhor rota será usada na tabela de roteamento e anunciada aos vizinhos até onde o filtro de saída permitir.
Quando várias rotas são possíveis para a mesma rede (o que implica uma máscara de rede idêntica), o BGP prefere uma das rotas de acordo com os seguintes critérios. Apenas a melhor rota será usada e anunciada aos vizinhos.
Pedido | Sobrenome | Descrição | Preferência |
---|---|---|---|
1 | Peso | Preferência administrativa local | o mais alto |
2 | LOCAL_PREF | Preferência dentro de um AS | o mais alto |
3 | Auto-originado | Redes preferidas originadas deste roteador | verdadeiro> falso |
4 | AS_PATH | Preferência do caminho com o menor número de AS cruzado | o mais curto |
5 | ORIGEM | Preferência de caminho com base em como eles são conhecidos pelo roteador de origem | IGP> EGP> Incompleto |
6 | MULTI_EXIT_DISC | Preferência de acordo com a métrica anunciada pelo AS original | o mais fraco |
7 | Externo | Preferência de rotas eBGP sobre rotas iBGP | eBGP> iBGP |
8 | Custo IGP | Métrica no IGP do caminho para o NEXT_HOP | o mais fraco |
9 | Peering eBGP | Prefere as estradas mais estáveis | o mais velho |
10 | ID do roteador | Repartição com base na ID do roteador | o mais fraco |
Se a opção BGP Multipath estiver ativa, rotas semelhantes após a etapa número 8 serão aceitas.
No início do BGP4, em algumas topologias, o BGP não funcionava nos roteadores do núcleo, mas apenas na borda (usando as topologias EGP da época), e todas as rotas do BGP foram redistribuídas para o IGP . Pode então ser necessário esperar até que a rota esteja presente no IGP antes de se tornar utilizável no BGP.
Como este tipo de configuração é considerado uma má prática a ser evitada (principalmente tendo em vista o aumento do número de rotas BGP na Internet), essa restrição de sincronização desapareceu ao se tornar obsoleta.
No iBGP, as rotas não são transitivas, ou seja, uma rota recebida via iBGP não é encaminhada para os vizinhos iBGP, o que implica que cada roteador participante do roteamento BGP dentro de um AS deve estabelecer conexões com todos os outros ( malha completa ), o que pode representar problemas de escala , o número de conexões aumentando de acordo com o quadrado do número de roteadores presentes no AS. Duas soluções estão disponíveis para superar esse limite: refletores de rota ( RFC 4456) e confederações ( RFC 5065).
refletores de estrada esta extensão de protocolo torna possível reduzir o número de conexões necessárias dentro de um AS. Um único roteador (ou dois roteadores para redundância) estabelece sessões com todos os outros roteadores em seu grupo. Os outros roteadores (seus clientes ) só precisam se conectar a ele. confederações é usado em redes muito grandes, onde o AS é subdividido em pequenos ASs internos. As confederações podem ser usadas em conjunto com as rotas do refletor . O eBGP é usado entre confederações. As confederações são mascaradas quando o prefixo é anunciado fora do AS principal.Para evitar possíveis loops com essas configurações, atributos adicionais são usados: Cluster_ID e Originator_ID.
Quando uma rede é adicionada a um AS, ela deve ser anunciada para a malha BGP: ou para o refletor de rota, quando existir, ou para todos os roteadores BGP do AS. O BGP não é, entretanto, um substituto para um protocolo de roteamento interno.
O padrão RFC 1771 ( A Border Gateway Protocol 4 (BGP-4) ) fornecido para a codificação de números AS em 16 bits, ou seja, 64510 ASs públicos possíveis, levando em consideração que os números 64512 a 65534 são reservados para uso privado (0 e 65535 são proibidos). Em 2011, havia cerca de 15.000 ASes gratuitos e as projeções prenunciaram um esgotamento completo dos ASes disponíveis em setembro de 2013.
O RFC 6793 estende a codificação de AS de 16 para 32 bits (retomando de 0 a 65535 AS, intervalo de 16 bits e AS reservado), elevando o número de AS para mais de quatro bilhões. Um intervalo adicional de ASs privados também é definido no RFC 6996 (de 420.000.000 a 4294967294, sendo 4294967295 proibido pelo RFC 7300).
Para permitir a passagem de grupos de roteadores que não gerenciam esses novos ASs, o novo atributo OT AS4_PATH é usado.
A atribuição de ASs de 32 bits começou em 2007 e, desde 2009, o RIPE NCC distribui ASs de 32 bits sob demanda.
O BGP é usado principalmente entre operadoras e ISPs para a troca de rotas.
A maioria dos usuários finais da Internet tem apenas uma conexão com um provedor de serviços de Internet . Nesse caso, o BGP é desnecessário porque uma rota padrão é suficiente. No entanto, uma empresa que está redundantemente conectada a vários ISPs ( multi-homing ) poderia obter seu próprio número de sistema autônomo e estabelecer sessões BGP com cada um dos provedores.
Além da Internet, as redes IP privadas podem usar BGP, por exemplo, para interconectar redes locais usando OSPF .
O BGP é conhecido por ser um protocolo de roteamento lento em comparação com os IGPs, que normalmente convergem em uma fração de segundo. A velocidade de convergência do BGP depende de vários parâmetros:
O BGP é sensível à oscilação de rota rápida, com anúncios de rotas inacessíveis sendo propagadas para todos os vizinhos do BGP, forçando-os a recalcular sua tabela de roteamento. O efeito cumulativo desses anúncios pode causar sobrecarga e afetar a estabilidade do roteamento em uma rede como a Internet. Uma rota oscilante pode ser causada por um link ou interface com defeito (configuração incorreta, falha) ou um roteador reiniciando.
Um recurso chamado amortecimento (ou às vezes amortecimento , RFC 2439 BGP Route Flap Damping , amortecimento significa amortecimento em inglês) visa reduzir os efeitos da oscilação das estradas. Cada vez que uma estrada balança , o amortecimento aumentará uma penalidade numérica associada a essa estrada. Essa penalidade diminuirá exponencialmente com o tempo. Quando a penalidade exceder um limite predefinido, a rota será marcada como inacessível e as atualizações sobre ela serão ignoradas, até que um limite inferior para a penalidade seja atingido.
RIPE-229 define os parâmetros recomendados para amortecimento. No entanto, à luz da experiência com esta configuração, a recomendação do RIPE Routing Working Group chegou à conclusão de que o amortecimento não era mais recomendado e que o RIPE-229 deveria ser considerado obsoleto .
A RFC 1930 recomenda que um prefixo sempre tenha se originado do mesmo AS, exceto em casos especiais (roteamento anycast e alguns casos de multi-homing com AS privado). Em outros casos, falamos de BGP Multiple AS Origin (MOAS). Os MOAS geralmente são o resultado de um erro de configuração e podem criar incidentes de negação de serviço .
Se um roteador anunciar um prefixo para o qual não fornece trânsito, o último pode se tornar inacessível de toda ou parte da Internet. O efeito será ainda mais pronunciado se os prefixos anunciados forem mais específicos (ou seja, se a máscara de rede for mais longa) do que os prefixos legítimos, já que rotas mais específicas são sempre preferidas.
Para se proteger contra esse problema, os provedores limitam os prefixos que aceitam de seus vizinhos. Esses filtros são atualizados manualmente se o vizinho anunciar novas rotas. Dada a complexidade da gestão dessas listas de filtragem, é mais raro que as grandes operadoras filtrem os prefixos entre si. No entanto, algumas ferramentas permitem que você crie esses filtros automaticamente de acordo com o conteúdo dos bancos de dados de roteamento (como o do RIPE ). Outras abordagens são S-BGP e soBGP. Abordagens que protegem o AS original de um prefixo, entretanto, não protegem contra ataques maliciosos, uma vez que o AS Path pode então ter sido construído.
O grupo de trabalho Secure Inter-Domain Routing (SIDR) da IETF está trabalhando em um sistema para validar a fonte de um prefixo chamado Resource Public Key Infrastructure (en) (RPKI).
Incidente AS 7007 em 1997Em 25 de abril de 1997, o AS 7007 redistribuiu acidentalmente o BGP no RIP e vice-versa. Sendo o RIP um protocolo classful , isso ocasionou o surgimento de sub-redes de tamanho / 24, mais específicas que as rotas originais, o que causou instabilidades significativas na Internet. Este incidente chamou a atenção para este tipo de vulnerabilidade.
Incidente no YouTube de 2008Em fevereiro de 2008, o site do YouTube ficou inacessível por aproximadamente duas horas. O governo do Paquistão anunciou naquele dia o bloqueio do YouTube no Paquistão, ordem executada pela operadora Pakistan Telecom .
A Pakistan Telecom então anunciou a todos os roteadores ISP que era a melhor rota para enviar todo o tráfego do YouTube, que foi cortado em todo o mundo.
Este tipo de incidente é designado sob os nomes de sequestro de IP (apropriação indébita de endereço IP) ou buraco negro ( buraco negro ).
Um dos problemas que BGP tem de enfrentar na Internet é o crescimento da tabela de roteamento de roteadores na zona livre de default , isto é, aqueles que têm uma tabela de roteamento completa e não use quaisquer routers. Rota padrão . Com o tempo, os roteadores mais antigos não têm mais os recursos de memória ou CPU para manter uma tabela cheia. Por outro lado, o tamanho da tabela afeta a velocidade de convergência, a CPU sendo particularmente estressada durante grandes mudanças (estabelecimento de novas conexões ou grandes mudanças na topologia).
Até 2001, o crescimento era exponencial, ameaçando o funcionamento da Internet. Naquela época, esforços foram feitos para reduzir os prefixos, agregando-os. Isso permitiu um crescimento linear por vários anos. No entanto, o crescimento exponencial foi retomado a partir de cerca de 2004 sob a pressão do número crescente de redes finais que têm várias conexões redundantes.
Em 2013, o número de prefixos divulgados na Internet girava em torno de 400 mil.
O BGP não possui sistema de balanceamento de carga entre vários links e não leva em consideração o possível congestionamento dos links: se um AS estiver conectado a vários provedores de trânsito para a Internet, alguns podem estar congestionados enquanto outros são pouco utilizados. Em geral, os ASs tomam decisões de roteamento de forma independente, portanto, um AS tem pouca influência nas decisões feitas por outro AS e não tem controle preciso sobre o balanceamento do tráfego de entrada.
Existem várias técnicas, no entanto, para tentar reequilibrar a carga entre esses links:
Pelos mesmos motivos, o tráfego pode ser assimétrico, o que é comum entre as grandes operadoras seguindo a política conhecida como batata quente (in) , que consiste em encaminhar um pacote para uma interconexão externa à rede mais próxima, evitando assim o cruzamento de sua próprio backbone.
Em 19 de agosto de 2009, um ISP japonês (AS 9354) anunciou uma rota com um atributo AS_PATH vazio. Algumas implementações de BGP de roteador de ISP encerram a sessão de BGP com um erro ao recebê-la, causando interrupção em vários backbones de ISP.
Em 27 de agosto de 2010, um atributo experimental do BGP usado em um projeto de pesquisa entre o RIPE NCC e a Duke University foi propagado pela Internet e revelou um bug na implementação do BGP de alguns fornecedores. Isso causou instabilidade de vários milhares de prefixos na Internet.
A operadora Telekom Malaysia anuncia um grande número de novas rotas errôneas, assumidas pela Level 3 Communications , uma grande operadora de Internet, que as transmite para o mundo todo. Essa transmissão tem o efeito de redirecionar uma porção significativa do tráfego global para a Telekom Malaysia, que anuncia quase um terço das rotas de Internet existentes (cerca de 176.000 de 534.000 rotas). A infraestrutura do último não consegue absorver um fluxo tão massivo, resultando em uma desaceleração muito acentuada e interrupção nas comunicações, sentida globalmente durante parte do dia.
Existem vários roteadores na Internet que permitem a visualização da tabela de roteamento global por meio de uma interface da web. Aqui está um exemplo de consulta:
> show ip bgp 91.198.174.2 BGP routing table entry for 91.198.174.0/24, version 151383419 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 82.115.128.225 TDC [3292] WIKIMEDIA-EU [43821] 82.115.128.18 from 82.115.128.18 (62.95.30.10) Origin IGP, localpref 100, valid, external, best Community: 215745616 215746418 IPO-EU [12552] PORT80-GLOBALTRANSIT [16150] WIKIMEDIA-EU [43821] 82.115.128.26 from 82.115.128.26 (62.109.44.1) Origin IGP, localpref 100, valid, externalNeste exemplo, o endereço IP 91.198.174.2 faz parte do prefixo mais específico 91.198.174.0/24. Duas rotas estão disponíveis, a primeira cruzou dois ASes (43821, seu AS original, depois 3292) e os segundos três (43821, 16150 e 12552), sendo a Pref local igual, a primeira rota, mais curta para o que é o número de ASs cruzado, é o preferido.
A rota tem dois atributos de comunidade : 3292: 1104 e 3292: 1906.
Os nomes associados aos ASs são adicionados pela interface ao consultar um banco de dados de roteamento público.
As principais RFCs em questão são as seguintes: