Protocolo de gateway de fronteira - Border Gateway Protocol

"BGP" redireciona aqui. Para outros usos, consulte BGP (desambiguação) .
Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

O Border Gateway Protocol ( BGP ) é um protocolo de gateway externo padronizado projetado para trocar informações de roteamento e acessibilidade entre sistemas autônomos (AS) na Internet . O BGP é classificado como um protocolo de roteamento de vetor de caminho e toma decisões de roteamento com base em caminhos, políticas de rede ou conjuntos de regras configurados por um administrador de rede .

O BGP usado para roteamento dentro de um sistema autônomo é chamado de Interior Border Gateway Protocol , Internal BGP ( iBGP ). Em contraste, a aplicação do protocolo na Internet é chamada de Exterior Border Gateway Protocol , External BGP ( eBGP ).

História

O Border Gateway Protocol foi descrito pela primeira vez em 1989 no RFC 1105 e está em uso na Internet desde 1994. O IPv6 BGP foi definido pela primeira vez no RFC  1654 em 1994 e foi aprimorado para o RFC  2283 em 1998.

A versão atual do BGP é a versão 4 (BGP4), publicada como RFC 4271 em 2006. O RFC 4271 corrigiu erros, esclareceu ambigüidades e atualizou a especificação com práticas comuns da indústria. O principal aprimoramento foi o suporte para Classless Inter-Domain Routing (CIDR) e o uso de agregação de rotas para diminuir o tamanho das tabelas de roteamento . O novo RFC permite que o BGP4 carregue uma ampla gama de "famílias de endereços" IPv4 e IPv6 . É também chamado de Multiprotocol Extensions, que é Multiprotocol BGP (MP-BGP).

Operação

Vizinhos BGP, chamados de pares, são estabelecidos pela configuração manual entre roteadores para criar uma sessão TCP na porta 179. Um alto-falante BGP envia mensagens keep-alive de 19 bytes a cada 60 segundos para manter a conexão. Entre os protocolos de roteamento, o BGP é único no uso de TCP como protocolo de transporte.

Quando o BGP é executado entre dois pares no mesmo sistema autônomo (AS), ele é referido como BGP interno ( i-BGP ou Protocolo de gateway de borda interna ). Quando é executado entre diferentes sistemas autônomos, é denominado External BGP ( eBGP ou Exterior Border Gateway Protocol ). Routers sobre a fronteira de uma como a troca de informações com o outro, como são chamados de fronteira ou borda routers ou simplesmente pares eBGP e estão tipicamente ligados directamente, enquanto os pares de i-BGP podem ser interligados através de outros routers intermédios. Outras topologias de implantação também são possíveis, como a execução de peering eBGP dentro de um túnel VPN , permitindo que dois sites remotos troquem informações de roteamento de maneira segura e isolada.

A principal diferença entre o peering iBGP e eBGP está na maneira como as rotas recebidas de um par são propagadas para outros pares. Por exemplo, novas rotas aprendidas de um par eBGP são normalmente redistribuídas para todos os pares iBGP, bem como todos os outros pares eBGP (se o modo de trânsito estiver habilitado no roteador). No entanto, se novas rotas forem aprendidas em um peering iBGP, elas serão anunciadas novamente apenas para todos os peers eBGP. Essas regras de propagação de rota exigem efetivamente que todos os pares iBGP dentro de um AS sejam interconectados em uma malha completa.

O modo como as rotas são propagadas pode ser controlado em detalhes por meio do mecanismo de mapas de rotas . Este mecanismo consiste em um conjunto de regras. Cada regra descreve, para rotas que correspondem a alguns critérios dados, que ação deve ser executada. A ação pode ser eliminar a rota ou modificar alguns atributos da rota antes de inseri-la na tabela de roteamento .

Negociação de extensões

Máquina de estado BGP

Durante o handshake de peering, quando as mensagens OPEN são trocadas, os alto-falantes do BGP podem negociar recursos opcionais da sessão, incluindo extensões multiprotocolo e vários modos de recuperação. Se as extensões multiprotocolo para BGP forem negociadas no momento da criação, o alto-falante do BGP pode prefixar a Informação de Alcançabilidade da Camada de Rede (NLRI) que anuncia com um prefixo de família de endereço. Essas famílias incluem IPv4 (padrão), IPv6, Redes privadas virtuais IPv4 / IPv6 e BGP multicast. Cada vez mais, o BGP é usado como um protocolo de sinalização generalizado para transportar informações sobre rotas que podem não fazer parte da Internet global, como VPNs.

Para tomar decisões em suas operações com pares, um par BGP usa uma máquina de estados finitos simples (FSM) que consiste em seis estados: Idle; Conectar; Ativo; OpenSent; OpenConfirm; e estabelecido. Para cada sessão ponto a ponto, uma implementação de BGP mantém uma variável de estado que rastreia em qual desses seis estados a sessão está. O BGP define as mensagens que cada ponto deve trocar para mudar a sessão de um estado para outro.

O primeiro estado é o estado Ocioso. No estado Idle, o BGP inicializa todos os recursos, recusa todas as tentativas de conexão BGP de entrada e inicia uma conexão TCP com o par. O segundo estado é Conectar. No estado Conectado, o roteador espera a conexão TCP ser concluída e faz a transição para o estado OpenSent se for bem-sucedido. Se malsucedido, ele inicia o cronômetro ConnectRetry e faz a transição para o estado Ativo após a expiração. No estado Ativo, o roteador redefine o temporizador ConnectRetry para zero e retorna ao estado Conectar. No estado OpenSent, o roteador envia uma mensagem Open e espera por outra para fazer a transição para o estado OpenConfirm. Mensagens Keepalive são trocadas e, após o recebimento bem-sucedido, o roteador é colocado no estado Estabelecido. No estado estabelecido, o roteador pode enviar e receber: Keepalive; Atualizar; e mensagens de notificação de e para seu par.

  • Estado inativo :
    • Recuse todas as conexões BGP de entrada.
    • Inicie a inicialização dos gatilhos de evento.
    • Inicia uma conexão TCP com seu par BGP configurado.
    • Escuta uma conexão TCP de seu par.
    • Muda seu estado para Conectar.
    • Se ocorrer um erro em qualquer estado do processo FSM, a sessão BGP será encerrada imediatamente e retornada ao estado Ocioso. Algumas das razões pelas quais um roteador não progride do estado Inativo são:
      • A porta TCP 179 não está aberta.
      • Uma porta TCP aleatória em 1023 não está aberta.
      • Endereço de mesmo nível configurado incorretamente em qualquer um dos roteadores.
      • Número AS configurado incorretamente em qualquer um dos roteadores.
  • Estado de conexão :
    • Espera uma negociação TCP bem-sucedida com o par.
    • O BGP não passa muito tempo neste estado se a sessão TCP foi estabelecida com sucesso.
    • Envia mensagem aberta para par e muda de estado para OpenSent.
    • Se ocorrer um erro, o BGP passa para o estado Ativo. Alguns motivos para o erro são:
      • A porta TCP 179 não está aberta.
      • Uma porta TCP aleatória em 1023 não está aberta.
      • Endereço de mesmo nível configurado incorretamente em qualquer um dos roteadores.
      • Número AS configurado incorretamente em qualquer um dos roteadores.
  • Estado ativo :
    • Se o roteador não conseguir estabelecer uma sessão TCP bem-sucedida, ele terminará no estado Ativo.
    • O BGP FSM tenta reiniciar outra sessão TCP com o par e, se for bem-sucedido, envia uma mensagem aberta ao par.
    • Se não for bem-sucedido novamente, o FSM é redefinido para o estado Ocioso.
    • Falhas repetidas podem resultar em um roteador alternando entre os estados Inativo e Ativo. Algumas das razões para isso incluem:
      • A porta TCP 179 não está aberta.
      • Uma porta TCP aleatória em 1023 não está aberta.
      • Erro de configuração do BGP.
      • Congestionamento de rede.
      • Interface de rede oscilante.
  • Estado OpenSent :
    • O BGP FSM escuta uma mensagem aberta de seu par.
    • Assim que a mensagem for recebida, o roteador verifica a validade da mensagem Open.
    • Se houver um erro, é porque um dos campos na mensagem de abertura não corresponde entre os pares, por exemplo, incompatibilidade de versão do BGP, o roteador de peering espera um My AS diferente, etc. O roteador então envia uma mensagem de notificação ao par indicando por que o erro ocorreu.
    • Se não houver erro, uma mensagem Keepalive é enviada, vários timers são definidos e o estado é alterado para OpenConfirm.
  • OpenConfirm State :
    • O par está ouvindo uma mensagem Keepalive de seu par.
    • Se uma mensagem Keepalive for recebida e nenhum cronômetro tiver expirado antes do recebimento do Keepalive, o BGP fará a transição para o estado Estabelecido.
    • Se um cronômetro expirar antes que uma mensagem Keepalive seja recebida, ou se ocorrer uma condição de erro, o roteador fará a transição de volta para o estado Ocioso.
  • Estado estabelecido :
    • Nesse estado, os pares enviam mensagens de atualização para trocar informações sobre cada rota anunciada ao par BGP.
    • Se houver algum erro na mensagem de atualização, uma mensagem de notificação será enviada ao par e o BGP fará a transição de volta para o estado Ocioso.

Conectividade do roteador e rotas de aprendizagem

No arranjo mais simples, todos os roteadores em um único AS e participando do roteamento BGP devem ser configurados em uma malha completa: cada roteador deve ser configurado como um par para todos os outros roteadores. Isso causa problemas de dimensionamento, uma vez que o número de conexões necessárias aumenta quadraticamente com o número de roteadores envolvidos. Para aliviar o problema, o BGP implementa duas opções: refletores de rota (RFC 4456) e confederações BGP (RFC 5065). A discussão a seguir sobre o processamento UPDATE básico assume uma malha iBGP completa.

Um determinado roteador BGP pode aceitar ATUALIZAÇÕES de informação de alcance de camada de rede (NLRI) de vários vizinhos e anunciar NLRI para o mesmo ou para um conjunto diferente de vizinhos. Conceitualmente, o BGP mantém sua própria tabela de roteamento mestre, chamada de base de informações de roteamento local (Loc-RIB), separada da tabela de roteamento principal do roteador. Para cada vizinho, o processo BGP mantém uma base de informações de roteamento adjacente conceitual , de entrada (Adj-RIB-In) contendo o NLRI recebido do vizinho e uma base de informações de saída conceitual (Adj-RIB-Out) para que o NLRI seja enviado para o vizinho.

O armazenamento físico e a estrutura dessas tabelas conceituais são decididos pelo implementador do código BGP. Sua estrutura não é visível para outros roteadores BGP, embora eles geralmente possam ser interrogados com comandos de gerenciamento no roteador local. É bastante comum, por exemplo, armazenar os dois Adj-RIBs e o Loc-RIB juntos na mesma estrutura de dados, com informações adicionais anexadas às entradas RIB. As informações adicionais informam ao processo BGP coisas como se as entradas individuais pertencem ao Adj-RIBs para vizinhos específicos, se o processo de seleção de rota de par-vizinho tornou as políticas recebidas elegíveis para Loc-RIB e se as entradas Loc-RIB são elegíveis para ser submetido ao processo de gerenciamento da tabela de roteamento do roteador local.

O BGP enviará as rotas que considerar melhores para o processo da tabela de roteamento principal. Dependendo da implementação desse processo, a rota BGP não é necessariamente selecionada. Por exemplo, um prefixo conectado diretamente, aprendido com o próprio hardware do roteador, geralmente é o mais preferido. Enquanto a interface da rota conectada diretamente estiver ativa, a rota BGP para o destino não será colocada na tabela de roteamento. Assim que a interface cair e não houver mais rotas preferenciais, a rota Loc-RIB será instalada na tabela de roteamento principal.

Até recentemente, era um erro comum dizer "O BGP carrega políticas". O BGP realmente carregava as informações com as quais as regras dentro dos roteadores que falam BGP poderiam tomar decisões de política. Algumas das informações transportadas com a intenção explícita de serem usadas em decisões políticas são comunidades e discriminadores de múltiplas saídas (MED).

O padrão BGP especifica uma série de fatores de decisão, mais do que aqueles que são usados ​​por qualquer outro processo de roteamento comum, para selecionar o NLRI para entrar no Loc-RIB. O primeiro ponto de decisão para avaliar o NLRI é que seu atributo do próximo salto deve ser alcançável (ou resolvível). Outra maneira de dizer que o próximo salto deve ser alcançável é que deve haver uma rota ativa, já na tabela de roteamento principal do roteador, para o prefixo no qual o endereço do próximo salto pode ser alcançado.

Em seguida, para cada vizinho, o processo BGP aplica vários critérios padrão e dependentes de implementação para decidir quais rotas conceitualmente devem entrar no Adj-RIB-In. O vizinho pode enviar várias rotas possíveis para um destino, mas o primeiro nível de preferência está no nível do vizinho. Apenas uma rota para cada destino será instalada no Adj-RIB-In conceitual. Este processo também excluirá, do Adj-RIB-In, quaisquer rotas que sejam retiradas pelo vizinho.

Sempre que um Adj-RIB-In conceitual muda, o processo BGP principal decide se alguma das novas rotas do vizinho é preferida às rotas já no Loc-RIB. Nesse caso, ele os substitui. Se uma determinada rota é retirada por um vizinho, e não há outra rota para aquele destino, a rota é removida do Loc-RIB e não mais enviada pelo BGP para o gerenciador da tabela de roteamento principal. Se o roteador não tiver uma rota para esse destino de nenhuma origem não-BGP, a rota retirada será removida da tabela de roteamento principal.

Depois de verificar se o próximo salto pode ser alcançado, se a rota vier de um par interno (ou seja, iBGP), a primeira regra a ser aplicada, de acordo com o padrão, é examinar o atributo LOCAL_PREFERENCE. Se houver várias rotas iBGP do vizinho, aquela com a LOCAL_PREFERENCE mais alta é selecionada, a menos que haja várias rotas com a mesma LOCAL_PREFERENCE. No último caso, o processo de seleção de rota passa para o próximo desempate . Embora LOCAL_PREFERENCE seja a primeira regra no padrão, uma vez verificada a acessibilidade do NEXT_HOP, a Cisco e vários outros fornecedores consideram primeiro um fator de decisão denominado PESO que é local para o roteador (ou seja, não transmitido pelo BGP). A rota com o maior PESO é a preferida.

LOCAL_PREFERENCE, WEIGHT e outros critérios podem ser manipulados pela configuração local e recursos de software. Essa manipulação, embora comumente usada, está fora do escopo da norma. Por exemplo, o atributo COMMUNITY (veja abaixo) não é usado diretamente pelo processo de seleção do BGP. O processo vizinho do BGP, entretanto, pode ter uma regra para definir LOCAL_PREFERENCE ou outro fator baseado em uma regra programada manualmente para definir o atributo se o valor de COMUNIDADE corresponder a algum critério de correspondência de padrão. Se a rota foi aprendida de um par externo, o processo BGP por vizinho calcula um valor LOCAL_PREFERENCE das regras de política local e então compara LOCAL_PREFERENCE de todas as rotas do vizinho.

No nível por vizinho - ignorando modificadores de política específicos de implementação - a ordem das regras de desempate é:

  1. Prefira a rota com o AS_PATH mais curto. Um AS_PATH é o conjunto de números AS que devem ser percorridos para alcançar o destino anunciado. AS1-AS2-AS3 é mais curto do que AS4-AS5-AS6-AS7.
  2. Prefira rotas com o valor mais baixo de seu atributo ORIGIN.
  3. Prefira rotas com o menor valor MULTI_EXIT_DISC (discriminador de múltiplas saídas ou MED).

Uma vez que as rotas candidatas são recebidas dos vizinhos, o software Loc-RIB aplica desempatadores adicionais às rotas para o mesmo destino.

  1. Se pelo menos uma rota foi aprendida de um vizinho externo (ou seja, a rota foi aprendida do eBGP), elimine todas as rotas aprendidas do iBGP.
  2. Prefira a rota com menor custo interior ao NEXT_HOP, conforme tabela de roteamento principal. Se dois vizinhos anunciaram a mesma rota, mas um vizinho pode ser alcançado por um link de baixa taxa de bits e o outro por um link de alta taxa de bits, e o protocolo de roteamento interno calcula o custo mais baixo com base na taxa de bits mais alta, a rota através do link de alta taxa de bits seria preferível e outras rotas abandonadas.
Se houver mais de uma rota ainda amarrada neste ponto, várias implementações de BGP oferecem uma opção configurável para compartilhamento de carga entre as rotas, aceitando todas (ou todas até algum número).
  1. Prefira a rota aprendida com o alto-falante BGP com o identificador BGP numericamente mais baixo
  2. Prefira a rota aprendida com o alto-falante BGP com o endereço IP de ponto mais baixo

Comunidades

Comunidades BGP são tags de atributos que podem ser aplicadas a prefixos de entrada ou saída para atingir algum objetivo comum. Embora seja comum dizer que o BGP permite que um administrador defina políticas sobre como os prefixos são tratados pelos ISPs, isso geralmente não é possível, estritamente falando. Por exemplo, o BGP nativamente não tem nenhum conceito para permitir que um AS diga a outro AS para restringir a propaganda de um prefixo apenas para clientes de peering norte-americanos. Em vez disso, um ISP geralmente publica uma lista de comunidades conhecidas ou proprietárias com uma descrição para cada uma, o que essencialmente se torna um acordo de como os prefixos devem ser tratados. A RFC 1997 define três comunidades bem conhecidas que têm significado global; NO_EXPORT, NO_ADVERTISE e NO_EXPORT_SUBCONFED. RFC 7611 define ACCEPT_OWN. Exemplos de comunidades comuns incluem ajustes de preferência local, restrições de tipo geográficas ou de pares, identificação de ataque de negação de serviço e opções de prefixação de AS. Um ISP pode declarar que quaisquer rotas recebidas de clientes com a comunidade XXX: 500 serão anunciadas para todos os pares (padrão), enquanto a comunidade XXX: 501 será anunciada apenas para a América do Norte. O cliente simplesmente ajusta sua configuração para incluir a comunidade ou comunidades corretas para cada rota, e o ISP é responsável por controlar para quem o prefixo é anunciado. O usuário final não tem capacidade técnica para impor as ações corretas tomadas pelo ISP, embora os problemas nessa área sejam geralmente raros e acidentais.

É uma tática comum para os clientes finais usarem comunidades BGP (geralmente ASN: 70,80,90,100) para controlar a preferência local que o ISP atribui às rotas anunciadas em vez de usar o MED (o efeito é semelhante). O atributo de comunidade é transitivo, mas as comunidades aplicadas pelo cliente raramente se propagam fora do AS do próximo salto. Nem todos os ISPs divulgam suas comunidades ao público.

O BGP Extended Community Attribute foi adicionado em 2006, a fim de estender a gama de tais atributos e fornecer uma estruturação de atributo de comunidade por meio de um campo de tipo. O formato estendido consiste em um ou dois octetos para o campo de tipo seguido por sete ou seis octetos para o respectivo conteúdo de atributo da comunidade. A definição deste atributo de comunidade estendida está documentada na RFC 4360. A IANA administra o registro para tipos de comunidades estendidas do BGP. O próprio Atributo de Comunidades Estendidas é um atributo BGP opcional transitivo. No entanto, um bit no campo de tipo dentro do atributo decide se a comunidade estendida codificada é de natureza transitiva ou não transitiva. O registro da IANA, portanto, fornece diferentes intervalos de números para os tipos de atributos. Devido ao intervalo de atributos estendido, seu uso pode ser múltiplo. O RFC 4360 define exemplarmente a "Comunidade estendida específica de dois octetos AS", a "Comunidade estendida específica de endereço IPv4", a "Comunidade estendida opaca", a "Comunidade de destino de rota" e a "Comunidade de origem de rota". Vários rascunhos de QoS do BGP também usam essa estrutura de atributo de comunidade estendida para sinalização de QoS entre domínios.

Nota: desde o RFC 7153, as comunidades estendidas são compatíveis com ASNs de 32 bits.

Com a introdução dos números AS de 32 bits, alguns problemas ficaram imediatamente óbvios com o atributo de comunidade que define apenas um campo ASN de 16 bits, o que impede a correspondência entre este campo e o valor ASN real. É a razão pela qual RFC 8092 e RFC 8195 introduzem um atributo Large Community de 12 bytes, dividido em três campos de 4 bytes cada (AS: função: parâmetro).

Discriminadores de múltiplas saídas

Os MEDs, definidos no padrão BGP principal, foram originalmente destinados a mostrar a outro AS vizinho a preferência do AS de publicidade quanto a qual dos vários links é preferido para o tráfego de entrada. Outra aplicação dos MEDs é anunciar o valor, normalmente com base no atraso, de vários AS que têm presença em um IXP , que eles impõem para enviar tráfego a algum destino.

Formato do cabeçalho da mensagem

A seguir está o formato do cabeçalho da mensagem do BGP versão 4:

deslocamento de bit 0-15 16-23 24-31
0 Marcador
32
64
96
128 Comprimento Modelo
  • Marcador : incluído para compatibilidade, deve ser definido para todos.
  • Comprimento : comprimento total da mensagem em octetos , incluindo o cabeçalho.
  • Tipo : Tipo de mensagem BGP. Os seguintes valores são definidos:
    • Aberto (1)
    • Atualização (2)
    • Notificação (3)
    • KeepAlive (4)
    • Atualização de rota (5)

Escalabilidade interna

O BGP é "o mais escalonável de todos os protocolos de roteamento".

Um sistema autônomo com BGP interno (iBGP) deve ter todos os seus pares iBGP conectados uns aos outros em uma malha completa (onde todos falam com todos diretamente). Essa configuração full-mesh requer que cada roteador mantenha uma sessão com todos os outros roteadores. Em redes grandes, esse número de sessões pode degradar o desempenho dos roteadores, devido à falta de memória ou a altos requisitos de processo da CPU.

Refletores de rota

Os refletores de rota reduzem o número de conexões necessárias em um AS. Um único roteador (ou dois para redundância) pode ser transformado em refletor de rota: outros roteadores no AS precisam apenas ser configurados como pares para eles. Um refletor de rota oferece uma alternativa ao requisito de malha completa lógica do protocolo de gateway de borda interna (IBGP). Um RR atua como um ponto focal para as sessões do IBGP. O objetivo do RR é a concentração. Vários roteadores BGP podem fazer par com um ponto central, o RR - agindo como um servidor refletor de rota - em vez de par com todos os outros roteadores em uma malha completa. Todos os outros roteadores IBGP tornam-se clientes do refletor de rota.

Esta abordagem, semelhante ao OSPF recurso DR / BDR 's, fornece grandes redes com escalabilidade acrescentou IBGP. Em uma rede IBGP totalmente em malha de 10 roteadores, 90 instruções CLI individuais (espalhadas por todos os roteadores na topologia) são necessárias apenas para definir o AS remoto de cada par: isso rapidamente se torna uma dor de cabeça de gerenciar. Uma topologia RR poderia reduzir essas 90 instruções para 18, oferecendo uma solução viável para as redes maiores administradas por ISPs.

Um refletor de rota é um ponto único de falha , portanto, pelo menos um segundo refletor de rota pode ser configurado a fim de fornecer redundância. Como é um par adicional para os outros 10 roteadores, ele vem com a contagem de instrução adicional para o dobro menos 2 da configuração do refletor de rota único. Um adicional 11 * 2-2 = 20 instruções neste caso devido à adição do Roteador adicional. Além disso, em um ambiente de caminhos múltiplos BGP, isso também pode se beneficiar com a adição de throughput de comutação / roteamento local se os RRs estiverem atuando como roteadores tradicionais em vez de apenas uma função de servidor refletor de rota dedicada.

Regras

Uma configuração típica da implantação do BGP Route Reflector, conforme proposto pela Seção 6, RFC 4456.

Os servidores RR propagam rotas dentro do AS com base nas seguintes regras:

  • Se uma rota for recebida de um par não cliente, reflita apenas para clientes e pares EBGP.
  • Se uma rota for recebida de um cliente cliente, reflita para todos os clientes não clientes e também para clientes, exceto o originador da rota e reflita para os parceiros EBGP.

Cacho

RR e seus clientes formam um "Cluster". O "Cluster-ID" é então anexado a cada rota anunciada pelo RR para seus clientes ou não clientes. Cluster-ID é um atributo BGP cumulativo e não transitivo e cada RR DEVE preceder o CLUSTER_ID local ao CLUSTER_LIST, a fim de evitar loops de roteamento. Os refletores e confederações de rota reduzem o número de pares iBGP para cada roteador e, portanto, reduzem a sobrecarga de processamento. Os refletores de rota são uma técnica pura de melhoria de desempenho, enquanto as confederações também podem ser usadas para implementar políticas mais refinadas.

Confederação BGP

As confederações são conjuntos de sistemas autônomos. Na prática comum, apenas um dos números de AS da confederação é visto pela Internet como um todo. As confederações são usadas em redes muito grandes, onde um grande AS pode ser configurado para abranger ASs internos menores e mais gerenciáveis.

O AS confederado é composto por vários ASs. Cada AS confederado sozinho tem o iBGP totalmente integrado e tem conexões com outros ASs dentro da confederação. Mesmo que esses ASs tenham peers eBGP para ASs dentro da confederação, os ASs trocam o roteamento como se usassem iBGP. Dessa forma, a confederação preserva as informações de próximo salto, métrica e preferência local. Para o mundo exterior, a confederação parece ser um único AS. Com essa solução, os problemas do AS de trânsito do iBGP podem ser resolvidos, pois o iBGP requer uma malha completa entre todos os roteadores BGP: grande número de sessões TCP e duplicação desnecessária do tráfego de roteamento.

As confederações podem ser usadas em conjunto com refletores de rota. Ambas as confederações e os refletores de rota podem estar sujeitos a oscilação persistente, a menos que regras de design específicas, afetando o BGP e o protocolo de roteamento interno, sejam seguidas.

No entanto, essas alternativas podem apresentar problemas próprios, incluindo os seguintes:

  • oscilação de rota
  • roteamento abaixo do ideal
  • aumento do tempo de convergência BGP

Além disso, os refletores de rota e as confederações BGP não foram projetados para facilitar a configuração do roteador BGP. No entanto, essas são ferramentas comuns para arquitetos de rede BGP experientes. Essas ferramentas podem ser combinadas, por exemplo, como uma hierarquia de refletores de rota.

Estabilidade

As tabelas de roteamento gerenciadas por uma implementação de BGP são ajustadas continuamente para refletir as mudanças reais na rede, como links quebrando e sendo restaurados ou roteadores caindo e voltando. Na rede como um todo, é normal que essas mudanças ocorram quase continuamente, mas para qualquer roteador ou link em particular, as mudanças devem ser relativamente raras. Se um roteador estiver mal configurado ou gerenciado, ele pode entrar em um ciclo rápido entre os estados inativo e ativo. Este padrão de retirada repetida e novo anúncio conhecido como oscilação de rota pode causar atividade excessiva em todos os outros roteadores que sabem sobre o link quebrado, já que a mesma rota é continuamente injetada e retirada das tabelas de roteamento. O design do BGP é tal que a entrega de tráfego pode não funcionar enquanto as rotas estão sendo atualizadas. Na Internet, uma alteração de roteamento BGP pode causar interrupções por vários minutos.

Um recurso conhecido como amortecimento de flap de rota ( RFC 2439 ) é incorporado a muitas implementações de BGP em uma tentativa de mitigar os efeitos do flap de rota. Sem amortecimento, a atividade excessiva pode causar uma carga de processamento pesada nos roteadores, o que pode, por sua vez, atrasar as atualizações em outras rotas e, assim, afetar a estabilidade geral do roteamento. Com o amortecimento, a oscilação de uma rota diminui exponencialmente . Na primeira instância, quando uma rota se torna indisponível e reaparece rapidamente, o amortecimento não tem efeito, de modo a manter os tempos normais de failover do BGP. Na segunda ocorrência, o BGP evita esse prefixo por um certo período de tempo; as ocorrências subsequentes são expiradas exponencialmente. Depois que as anormalidades cessaram e um período de tempo adequado passou para a rota ofensiva, os prefixos podem ser reintegrados e sua ficha limpa. O amortecimento também pode mitigar ataques de negação de serviço ; os tempos de amortecimento são altamente personalizáveis.

Também é sugerido na RFC 2439 (em "Design Choices -> Stability Sensitive Suppression of Route Advertisement") que o amortecimento de flap de rota é um recurso mais desejável se implementado em Sessões de Protocolo de Gateway de Fronteira Exterior (sessões eBGP ou simplesmente chamadas de pares externos) e não em Sessões de Protocolo de Gateway de Fronteira Interior (sessões iBGP ou simplesmente chamadas de pares internos); Com esta abordagem, quando uma rota flaps dentro de um sistema autônomo, ela não é propagada para os ASs externos - flapping uma rota para um eBGP terá uma cadeia de flapping para a rota particular em todo o backbone. Este método também evita com sucesso a sobrecarga do amortecimento do flap de rota para sessões de iBGP.

No entanto, pesquisas subsequentes mostraram que o amortecimento de flaps pode, na verdade, aumentar os tempos de convergência em alguns casos e pode causar interrupções na conectividade, mesmo quando os links não estão oscilando. Além disso, como os links de backbone e os processadores de roteador se tornaram mais rápidos, alguns arquitetos de rede sugeriram que o amortecimento de flaps pode não ser tão importante quanto costumava ser, uma vez que as alterações na tabela de roteamento podem ser tratadas com muito mais rapidez pelos roteadores. Isso levou o Grupo de Trabalho de Roteamento RIPE a escrever que "com as implementações atuais de amortecimento de flap BGP, a aplicação de amortecimento de flap em redes ISP NÃO é recomendada. ... Se o amortecimento de flap for implementado, o ISP operando essa rede causará lado -efeitos para seus clientes e usuários de Internet do conteúdo e serviços de seus clientes ... Esses efeitos colaterais provavelmente seriam piores do que o impacto causado por simplesmente não executar o amortecimento de flap. " Melhorar a estabilidade sem os problemas de amortecimento do flap é o assunto da pesquisa atual.

Crescimento da tabela de roteamento

Crescimento da tabela BGP na Internet
Número de AS na Internet vs número de AS registrado

Um dos maiores problemas enfrentados pelo BGP e, de fato, pela infraestrutura da Internet como um todo, é o crescimento da tabela de roteamento da Internet. Se a tabela de roteamento global crescer a ponto de alguns roteadores mais antigos e menos capazes não conseguirem atender aos requisitos de memória ou à carga da CPU para manter a tabela, esses roteadores deixarão de ser gateways eficazes entre as partes da Internet que conectam. Além disso, e talvez ainda mais importante, tabelas de roteamento maiores demoram mais para se estabilizar (veja acima) após uma grande mudança de conectividade, deixando o serviço de rede não confiável, ou mesmo indisponível, nesse ínterim.

Até o final de 2001, a tabela de roteamento global estava crescendo exponencialmente , ameaçando um eventual colapso generalizado da conectividade. Na tentativa de evitar isso, os ISPs cooperaram para manter a tabela de roteamento global tão pequena quanto possível, usando Classless Inter-Domain Routing (CIDR) e agregação de rotas . Embora isso tenha desacelerado o crescimento da tabela de roteamento para um processo linear por vários anos, com a expansão da demanda por multihoming por redes de usuários finais, o crescimento foi mais uma vez superlinear em meados de 2004.

512k dia

Um estouro semelhante ao Y2K disparado em 2014 para os modelos que não foram atualizados de forma adequada.

Embora uma tabela IPv4 BGP completa em agosto de 2014 (512k dia) excedesse 512.000 prefixos, muitos roteadores mais antigos tinham um limite de 512k (512.000–524.288) de entradas na tabela de roteamento. Em 12 de agosto de 2014, interrupções resultantes de tabelas cheias atingiram eBay , LastPass e Microsoft Azure, entre outros. Vários roteadores Cisco comumente usados ​​tinham TCAM , uma forma de memória endereçável por conteúdo de alta velocidade , para armazenar rotas anunciadas de BGP. Em roteadores afetados, o TCAM foi alocado por padrão como rotas IPv4 de 512k e rotas IPv6 de 256k. Enquanto o número relatado de rotas IPv6 anunciadas foi de apenas cerca de 20k, o número de rotas IPv4 anunciadas atingiu o limite padrão, causando um efeito de transbordamento, pois os roteadores tentaram compensar o problema usando roteamento de software lento (em oposição ao roteamento rápido de hardware via TCAM ) O principal método para lidar com este problema envolve as operadoras alterando a alocação de TCAM para permitir mais entradas IPv4, realocando algumas das TCAM reservadas para rotas IPv6, o que requer uma reinicialização na maioria dos roteadores. O problema de 512k foi previsto por vários profissionais de TI.

As alocações reais que empurraram o número de rotas acima de 512k foi o anúncio de cerca de 15.000 novas rotas em curto prazo, começando às 07:48 UTC. Quase todas essas rotas foram para os Sistemas Autônomos Verizon 701 e 705, criados como resultado da desagregação de blocos maiores, introduzindo milhares de novas rotas / 24 e fazendo a tabela de roteamento chegar a 515.000 entradas. As novas rotas parecem ter sido reagregadas em 5 minutos, mas a instabilidade na Internet aparentemente continuou por várias horas. Mesmo se a Verizon não tivesse feito a tabela de roteamento exceder 512k entradas no pico curto, isso teria acontecido logo de qualquer maneira por meio do crescimento natural.

A sumarização de rota é freqüentemente usada para melhorar a agregação da tabela de roteamento global BGP, reduzindo assim o tamanho da tabela necessária nos roteadores de um AS. Considere que ao AS1 foi alocado o grande espaço de endereço de 172.16.0.0 / 16 , isso seria contado como uma rota na tabela, mas devido à necessidade do cliente ou para fins de engenharia de tráfego, o AS1 deseja anunciar rotas menores e mais específicas de 172.16.0.0 / 18 , 172.16.64.0 / 18 e 172.16.128.0 / 18 . O prefixo 172.16.192.0 / 18 não tem nenhum host, portanto, o AS1 não anuncia uma rota específica 172.16.192.0 / 18 . Tudo isso conta como AS1 anunciando quatro rotas.

AS2 verá as quatro rotas do AS1 ( 172.16.0.0 / 16 , 172.16.0.0 / 18 , 172.16.64.0 / 18 e 172.16.128.0 / 18 ) e cabe à política de roteamento do AS2 decidir se deve ou não faça uma cópia das quatro rotas ou, como 172.16.0.0 / 16 se sobrepõe a todas as outras rotas específicas, para armazenar apenas o resumo, 172.16.0.0 / 16 .

Se o AS2 deseja enviar dados para o prefixo 172.16.192.0 / 18 , eles serão enviados aos roteadores do AS1 na rota 172.16.0.0/16 . No roteador AS1, ele será descartado ou uma mensagem ICMP de destino inacessível será enviada de volta, dependendo da configuração dos roteadores AS1.

Se AS1 posteriormente decidir descartar a rota 172.16.0.0 / 16 , deixando 172.16.0.0 / 18 , 172.16.64.0 / 18 e 172.16.128.0 / 18 , AS1 reduzirá o número de rotas anunciadas para três. AS2 verá as três rotas e, dependendo da política de roteamento do AS2, armazenará uma cópia das três rotas ou agregará o prefixo 172.16.0.0/18 e 172.16.64.0 / 18 a 172.16.0.0 / 17 , reduzindo assim o número de rotas que o AS2 armazena em apenas dois: 172.16.0.0 / 17 e 172.16.128.0 / 18 .

Se AS2 quiser enviar dados para o prefixo 172.16.192.0 / 18 , eles serão descartados ou uma mensagem ICMP de destino inacessível será enviada de volta aos roteadores do AS2 (não AS1 como antes), porque 172.16.192.0 / 18 não estaria em a tabela de roteamento.

Esgotamento de números de AS e ASNs de 32 bits

A RFC 1771 ( A Border Gateway Protocol 4 (BGP-4) ) planejou a codificação de números AS em 16 bits, para 64510 possíveis AS públicos, uma vez que ASN 64512 a 65534 eram reservados para uso privado (0 e 65535 sendo proibidos). Em 2011, apenas 15.000 números de AS ainda estavam disponíveis e as projeções previam um esgotamento completo dos números de AS disponíveis em setembro de 2013.

O RFC 6793 estende a codificação AS de 16 para 32 bits (mantendo o intervalo AS de 16 bits de 0 a 65535 e seus números AS reservados), que agora permite até 4 bilhões de AS disponíveis. Um intervalo de AS privado adicional também é definido no RFC 6996 (de 4200000000 a 4294967294, sendo 4294967295 proibido pelo RFC 7300).

Para permitir a passagem de grupos de roteadores incapazes de gerenciar esses novos ASNs, o novo atributo OT AS4_PATH é usado.

As atribuições do ASN de 32 bits começaram em 2007.

Balanceamento de carga

Outro fator que causa esse crescimento da tabela de roteamento é a necessidade de balanceamento de carga de redes multihomed. Não é uma tarefa trivial equilibrar o tráfego de entrada para uma rede multihomed em seus vários caminhos de entrada, devido à limitação do processo de seleção de rota BGP. Para uma rede multihomed, se ela anunciar os mesmos blocos de rede em todos os seus pares BGP, o resultado pode ser que um ou vários de seus links de entrada ficam congestionados enquanto os outros links permanecem subutilizados, porque todas as redes externas escolheram isso conjunto de caminhos congestionados como o ideal. Como a maioria dos outros protocolos de roteamento, o BGP não detecta congestionamento.

Para contornar esse problema, os administradores de BGP dessa rede com hospedagem múltipla podem dividir um grande bloco de endereço IP contíguo em blocos menores e ajustar o anúncio de rota para fazer com que diferentes blocos pareçam ideais em caminhos diferentes, de modo que redes externas escolham um caminho diferente para alcançar diferentes blocos dessa rede multihomed. Esses casos aumentarão o número de rotas conforme visto na tabela BGP global.

Um método que está crescendo em popularidade para resolver o problema de balanceamento de carga é implantar gateways BGP / LISP ( Locator / Identifier Separation Protocol ) em um ponto de troca da Internet para permitir a engenharia de tráfego de entrada em vários links. Essa técnica não aumenta o número de rotas vistas na tabela BGP global.

Segurança

Consulte também: sequestro de BGP

Por design, os roteadores que executam BGP aceitam rotas anunciadas de outros roteadores BGP por padrão. Isso permite o roteamento automático e descentralizado do tráfego pela Internet, mas também deixa a Internet potencialmente vulnerável a interrupções acidentais ou maliciosas, conhecidas como sequestro de BGP . Devido à extensão em que o BGP está embutido nos sistemas centrais da Internet e ao número de diferentes redes operadas por muitas organizações diferentes que coletivamente compõem a Internet, corrigindo esta vulnerabilidade (por exemplo, introduzindo o uso de chaves criptográficas para verificar a identidade dos roteadores BGP) é um problema técnico e economicamente desafiador.

Extensões

Uma extensão do BGP é o uso de caminhos múltiplos - isso normalmente requer MED, peso, origem e caminho AS idênticos, embora algumas implementações forneçam a capacidade de relaxar a verificação do caminho AS para esperar apenas um comprimento de caminho igual em vez dos números reais do AS no caminho, espera-se que corresponda também. Isso pode ser estendido ainda mais com recursos como dmzlink-bw da Cisco, que permite uma proporção de compartilhamento de tráfego com base em valores de largura de banda configurados em links individuais.

Multiprotocol Extensions for BGP (MBGP), às vezes referido como Multiprotocol BGP ou Multicast BGP e definido no IETF RFC 4760, é uma extensão para (BGP) que permite que diferentes tipos de endereços (conhecidos como famílias de endereços) sejam distribuídos em paralelo. Enquanto o BGP padrão suporta apenas endereços unicast IPv4, o BGP Multiprotocol suporta endereços IPv4 e IPv6 e suporta variantes unicast e multicast de cada um. O BGP multiprotocolo permite que as informações sobre a topologia de roteadores com capacidade de multicast IP sejam trocadas separadamente da topologia de roteadores unicast IPv4 normais. Assim, ele permite uma topologia de roteamento multicast diferente da topologia de roteamento unicast. Embora o MBGP permita a troca de informações de roteamento multicast entre domínios, outros protocolos, como a família Protocol Independent Multicast, são necessários para construir árvores e encaminhar o tráfego multicast.

Multiprotocol BGP também é amplamente implantado no caso de MPLS L3 VPN, para trocar rótulos VPN aprendidos para as rotas dos sites do cliente sobre a rede MPLS, a fim de distinguir entre diferentes sites do cliente quando o tráfego dos outros sites do cliente chega ao Provedor Roteador de borda (roteador PE) para roteamento.

Usos

O BGP4 é padrão para roteamento de Internet e exigido da maioria dos provedores de serviços de Internet (ISPs) para estabelecer o roteamento entre si. Redes IP privadas muito grandes usam BGP internamente. Um exemplo é a junção de uma série de grandes redes Open Shortest Path First (OSPF), quando o OSPF por si só não se ajusta ao tamanho necessário. Outra razão para usar o BGP é o multihoming de uma rede para melhor redundância, seja para vários pontos de acesso de um único ISP ou para vários ISPs.

Implementações

Os roteadores, especialmente os pequenos destinados ao uso em pequenos escritórios / escritórios domésticos (SOHO), podem não incluir software BGP. Alguns roteadores SOHO simplesmente não são capazes de executar BGP / usando tabelas de roteamento BGP de qualquer tamanho. Outros roteadores comerciais podem precisar de uma imagem executável de software específica que contenha o BGP ou de uma licença que o habilite. Os pacotes de código aberto que executam BGP incluem GNU Zebra , Quagga , OpenBGPD , BIRD , XORP e Vyatta . Dispositivos comercializados como switches da Camada 3 têm menos probabilidade de oferecer suporte a BGP do que dispositivos comercializados como roteadores , mas os Switches da Camada 3 de ponta geralmente podem executar BGP.

Os produtos comercializados como switches podem ou não ter uma limitação de tamanho nas tabelas BGP, como 20.000 rotas, muito menor do que uma tabela completa da Internet mais rotas internas. Esses dispositivos, no entanto, podem ser perfeitamente razoáveis ​​e úteis quando usados ​​para o roteamento BGP de alguma parte menor da rede, como um confederation-AS representando uma das várias empresas menores que estão conectadas, por um backbone de backbones BGP ou um pequeno empresa que anuncia rotas para um ISP, mas aceita apenas uma rota padrão e talvez um pequeno número de rotas agregadas.

Um roteador BGP usado apenas para uma rede com um único ponto de entrada para a Internet pode ter um tamanho de tabela de roteamento muito menor (e, portanto, os requisitos de RAM e CPU) do que uma rede com hospedagem múltipla. Até mesmo o multihoming simples pode ter um tamanho de tabela de roteamento modesto. Consulte RFC 4098 para parâmetros de desempenho independentes do fornecedor para convergência de roteador BGP único no plano de controle. A quantidade real de memória necessária em um roteador BGP depende da quantidade de informações BGP trocadas com outros alto-falantes BGP e da maneira como o roteador específico armazena as informações BGP. O roteador pode ter que manter mais de uma cópia de uma rota, para que ele possa gerenciar políticas diferentes para publicidade de rota e aceitação para um AS vizinho específico. O termo visualização é freqüentemente usado para essas diferentes relações de política em um roteador em execução.

Se uma implementação de roteador usa mais memória por rota do que outra implementação, essa pode ser uma escolha de design legítima, trocando a velocidade de processamento pela memória. Uma tabela IPv4 BGP completa em agosto de 2015 tem mais de 590.000 prefixos. Os grandes ISPs podem adicionar outros 50% para rotas internas e de clientes. Novamente, dependendo da implementação, tabelas separadas podem ser mantidas para cada visualização de um AS de par diferente.

Implementações notáveis ​​de código aberto e gratuito de BGP incluem:

Os sistemas para testar a conformidade com BGP, desempenho de carga ou estresse vêm de fornecedores como:

Documentos de padrões

  • Atualização seletiva de rota para BGP , rascunho IETF
  • RFC  1772 , Aplicação do Border Gateway Protocol no Internet Protocol (BGP-4) usando SMIv2
  • RFC  2439 , BGP Route Flap Damping
  • RFC  2918 , capacidade de atualização de rota para BGP-4
  • RFC  3765 , Comunidade NOPEER para Controle de Escopo de Rotas do Protocolo de Gateway de Fronteira (BGP)
  • RFC  4271 , A Border Gateway Protocol 4 (BGP-4)
  • RFC  4272 , Análise de Vulnerabilidades de Segurança BGP
  • RFC  4273 , Definições de objetos gerenciados para BGP-4
  • RFC  4274 , Análise de Protocolo BGP-4
  • RFC  4275 , Pesquisa de Implementação BGP-4 MIB
  • RFC  4276 , Relatório de Implementação BGP-4
  • RFC  4277 , Experiência com o Protocolo BGP-4
  • RFC  4278 , variação de maturidade dos padrões em relação à opção de assinatura TCP MD5 (RFC 2385) e a especificação BGP-4
  • RFC  4456 , BGP Route Reflection - Uma alternativa para Full Mesh Internal BGP (iBGP)
  • RFC  4724 , Graceful Restart Mechanism for BGP
  • RFC  4760 , Multiprotocol Extensions for BGP-4
  • RFC  4893 , suporte BGP para espaço numérico AS de quatro octetos
  • RFC  5065 , Confederações de Sistemas Autônomos para BGP
  • RFC  5492 , Propaganda de Capacidades com BGP-4
  • RFC  5575 , Disseminação de Regras de Especificação de Fluxo
  • RFC  7752 , Distribuição de limite norte de link-state e informações de engenharia de tráfego usando BGP
  • RFC  7911 , Anúncio de vários caminhos no BGP
  • draft-ietf-idr-custom-decision-08  - Processo de decisão personalizada do BGP, 3 de fevereiro de 2017
  • RFC  3392 , Obsoleto - Propaganda de Capacidades com BGP-4
  • RFC  2796 , Obsoleto - BGP Route Reflection - Uma alternativa para Full Mesh iBGP
  • RFC  3065 , Obsoleto - Confederações do Sistema Autônomo para BGP
  • RFC  1965 , Obsoleto - Confederações do Sistema Autônomo para BGP
  • RFC  1771 , Obsoleto - A Border Gateway Protocol 4 (BGP-4)
  • RFC  1657 , Obsoleto - Definições de Objetos Gerenciados para a Quarta Versão do Border Gateway
  • RFC  1655 , Obsoleto - Aplicação do Border Gateway Protocol na Internet
  • RFC  1654 , Obsoleto - A Border Gateway Protocol 4 (BGP-4)
  • RFC  1105 , Obsoleto - Border Gateway Protocol (BGP)
  • RFC  2858 , obsoleto - extensões multiprotocolo para BGP-4

Veja também

Notas

Referências

Leitura adicional

links externos