Visão geral do BGP

Esta seção discute os seguintes tópicos:

• Sistemas autônomos
• Caminhos e atributos do AS
• BGP externo e interno
• Múltiplas instâncias do BGP
• Permitir Tráfego de Protocolo para Interfaces em uma Zona de Segurança

BGP externo e interno

O BGP oferece suporte a dois tipos de trocas de informações de roteamento: trocas entre diferentes ASs e trocas dentro de um único AS. Quando usado entre ASs, o BGP é chamado de BGP externo (EBGP) e as sessões de BGP executam o roteamento entre AS. Quando usado em um AS, o BGP é chamado de BGP interno (IBGP) e as sessões de BGP executam o roteamento intra-AS. A Figura 1 ilustra ASs, IBGP e EBGP.

Figura 1: ASs, EBGP e IBGP

Um sistema BGP compartilha informações de alcance de rede com sistemas BGP adjacentes, que são chamados de vizinhos ou pares.

Os sistemas BGP são organizados em grupos. Em um grupo do IBGP, todos os pares do grupo — chamados de pares internos — estão no mesmo AS. Os pares internos podem estar em qualquer lugar do AS local e não precisam estar diretamente conectados uns aos outros. Grupos internos usam rotas de um IGP para resolver endereços de encaminhamento. Eles também propagam rotas externas entre todos os outros roteadores internos que executam o IBGP, calculando o próximo salto pegando o próximo salto do BGP recebido com a rota e resolvendo-o usando informações de um dos protocolos de gateway interno.

Em um grupo EBGP, os pares do grupo — chamados de pares externos — estão em ASs diferentes e normalmente compartilham uma sub-rede. Em um grupo externo, o próximo salto é calculado em relação à interface que é compartilhada entre o peer externo e o roteador local.

Uma rota BGP é um destino, descrito como um prefixo de endereço IP, e informações que descrevem o caminho para o destino.

As informações a seguir descrevem o caminho:

• Caminho AS, que é uma lista de números dos ASs pelos quais uma rota passa para chegar ao roteador local. O primeiro número no caminho é o do último AS no caminho — o AS mais próximo do roteador local. O último número no caminho é o AS mais distante do roteador local, que geralmente é a origem do caminho.

• Atributos de caminho, que contêm informações adicionais sobre o caminho AS usado na política de roteamento.

Os peers BGP anunciam rotas entre si em mensagens de atualização.

O BGP armazena suas rotas na tabela de roteamento do Junos OS (inet.0). A tabela de roteamento armazena as seguintes informações sobre as rotas BGP:

• Informações de roteamento aprendidas com mensagens de atualização recebidas de pares

• Informações de roteamento local que o BGP aplica a rotas devido a políticas locais

• Informações que o BGP anuncia para pares BGP em mensagens de atualização

Para cada prefixo na tabela de roteamento, o processo de protocolo de roteamento seleciona um único melhor caminho, chamado de caminho ativo. A menos que você configure o BGP para anunciar vários caminhos para o mesmo destino, o BGP anuncia apenas o caminho ativo.

O roteador BGP que primeiro anuncia uma rota atribui a ela um dos seguintes valores para identificar sua origem. Durante a seleção de rota, o valor de origem mais baixo é preferido.

• 0— O roteador originalmente aprendeu a rota através de um IGP (OSPF, IS-IS ou uma rota estática).

• 1— O roteador originalmente aprendeu a rota através de um EGP (provavelmente BGP).

• 2 — A origem da rota é desconhecida.

Uma rota BGP (IBGP) interna com um endereço de próximo salto para um vizinho BGP remoto (próximo salto do protocolo) deve ter seu próximo salto resolvido usando alguma outra rota. O BGP adiciona essa rota ao módulo de resolvedor rpd para resolução de próximo salto. Se o RSVP for usado na rede, o próximo salto do BGP será resolvido usando a rota de entrada do RSVP. Isso resulta na rota BGP apontando para um próximo salto indireto e o próximo salto indireto apontando para um próximo salto de encaminhamento. O próximo salto de encaminhamento é derivado do próximo salto da rota RSVP. Geralmente, há um grande conjunto de rotas BGP internas que têm o mesmo protocolo no próximo salto e, nesses casos, o conjunto de rotas BGP faria referência ao mesmo próximo salto indireto.

Antes do Junos OS Release 17.2R1, o módulo resolvedor do processo de protocolo de roteamento (rpd) resolveu rotas dentro do IBGP e recebeu rotas das seguintes maneiras:

1. Resolução parcial de rotas — o próximo salto do protocolo é resolvido com base em rotas auxiliares, como rotas RSVP ou IGP. Os valores de métrica são derivados das rotas auxiliares e o próximo salto é chamado de encaminhamento do resolvedor do próximo salto herdado das rotas auxiliares. Esses valores de métrica são usados para selecionar rotas na base de informações de roteamento (RIB), também conhecida como tabela de roteamento.

2. Resolução completa da rota — o próximo salto final é derivado e é referido como o próximo salto de encaminhamento da tabela de roteamento do kernel (KRT) com base na política de exportação de encaminhamento.

A partir do Junos OS Release 17.2R1, o módulo resolver do rpd é otimizado para aumentar a taxa de transferência do fluxo de processamento de entrada, acelerando a taxa de aprendizado de RIB e FIB. Com esse aprimoramento, a resolução da rota é afetada da seguinte maneira:

• Os métodos de resolução de rota parcial e completa são acionados para cada rota do IBGP, embora cada rota possa herdar o mesmo próximo salto de encaminhamento resolvido ou o próximo salto de encaminhamento KRT.

• A seleção de caminho BGP é adiada até que a resolução completa da rota seja executada para informações de alcance de camada de rede (NLRI) recebidas de um vizinho BGP, que pode não ser a melhor rota no RIB após a seleção de rota.

Os benefícios da otimização do resolvedor rpd incluem:

• Menor custo de pesquisa de resolução de RIB — A saída do caminho resolvido é salva em um cache de resolvedor, para que os mesmos valores derivados de próximo salto e métrica possam ser herdados para outro conjunto de rotas que compartilham o mesmo comportamento de caminho em vez de executar o fluxo de resolução de rota parcial e completo. Isso reduz o custo de pesquisa de resolução de rota, mantendo apenas o estado do resolvedor mais frequente em um cache com profundidade limitada.

• Otimização de seleção de rota BGP — O algoritmo de seleção de rota BGP é acionado duas vezes para cada rota IBGP recebida — primeiro, ao adicionar a rota no RIB com o próximo salto como inutilizável e, segundo, ao adicionar a rota com um próximo salto resolvido no RIB (após a resolução da rota). Isso resulta na seleção da melhor rota duas vezes. Com a otimização do resolvedor, o processo de seleção de rota é acionado no fluxo de recebimento somente após obter as informações do próximo salto do módulo do resolvedor.

• Cache interno para evitar pesquisas frequentes — o cache do resolvedor mantém o estado do resolvedor mais frequente e, como resultado, a funcionalidade de pesquisa, como pesquisa de próximo salto e pesquisa de rota, é feita a partir do cache local.

• Grupo de equivalência de caminho — Quando caminhos diferentes compartilham o mesmo estado de encaminhamento ou são recebidos do mesmo protocolo no próximo salto, os caminhos podem pertencer a um grupo de equivalência de caminho. Essa abordagem evita a necessidade de executar a resolução completa de rotas para esses caminhos. Quando um novo caminho requer resolução de rota completa, ele é pesquisado primeiro no banco de dados do grupo de equivalência de caminho, que contém a saída do caminho resolvido, como próximo salto indireto e encaminhamento do próximo salto.

Esta seção discute os seguintes tópicos:

• Mensagens abertas
• Atualizar mensagens
• Mensagens de manutenção de atividade
• Mensagens de notificação
• Mensagens de Atualizar de Rota

O processamento de rotas BGP geralmente tem vários estágios de pipeline, como receber atualização, analisar atualização, criar rota, resolver next-hop, aplicar a política de exportação de um grupo de peer BGP, formar atualizações por peer e enviar atualizações aos peers.

A fragmentação de BGP RIB divide um BGP RIB unificado em vários sub-RIBs e cada sub-RIB lida com um subconjunto de rotas BGP. O thread RPD separado denominado thread de fragmento BGP atende a cada sub-RIB para obter simultaneidade. Os threads de fragmento BGP são responsáveis por todos os estágios do pipeline de processamento de rotas BGP, com exceção da formação de atualizações por peer e do envio de atualizações aos peers. Os threads de fragmento BGP recebem as atualizações enviadas por pares dos threads de E/S de atualização de BGP com os threads de E/S de atualização de BGP fazendo hash dos prefixos nas atualizações e enviam as atualizações para os threads de fragmento BGP aplicáveis com base no cálculo de hash. O thread de fragmento BGP processa a configuração da mesma maneira que o thread principal do RPD, cria pares, grupos, tabelas de rotas e usa as informações de configuração para processamento de rotas BGP.

Os threads de E/S de atualização de BGP são responsáveis pelo final desse pipeline BGP, envolvendo a geração de atualizações por peer para grupos BGP individuais e o envio para os peers. Um thread de atualização pode atender a um ou mais grupos BGP. Os threads de E/S de atualização de BGP constroem atualizações para grupos em paralelo e independentemente de outros grupos que estão sendo atendidos por outros threads de atualização. Isso pode oferecer uma melhoria significativa de convergência em uma carga de trabalho de gravação pesada, que envolve publicidade para muitos pares espalhados por muitos grupos. Os threads de E/S de atualização de BGP também são responsáveis por gravar e ler os soquetes TCP dos peers BGP que eram fornecidos anteriormente por threads BGPIO (daí o sufixo IO em BGP Update IO).

Os threads de E/S de atualização do BGP podem ser configurados independentemente do recurso de fragmentação RIB, mas são obrigatórios para uso com a fragmentação RIB, a fim de obter uma melhor eficiência de empacotamento de prefixo na mensagem de atualização BGP de saída. A fragmentação de BGP divide o RIB em vários sub-RIBs que são atendidos por threads RPD separados. Portanto, os prefixos que poderiam ter entrado em uma única atualização de saída acabam em fragmentos diferentes. Para poder construir atualizações de BGP com prefixos com o mesmo atributo de saída que pode pertencer a diferentes threads de fragmento RPD, todos os threads de fragmento enviam informações de anúncio compactas para prefixos a serem anunciados para um thread de atualização que atende a esse grupo de peer BGP. Isso permite que o thread de atualização, atendendo a esse grupo de peer BGP, empacote prefixos com os mesmos atributos, potencialmente pertencentes a fragmentos diferentes na mesma mensagem de atualização de saída. Isso minimiza o número de atualizações a serem anunciadas e, portanto, ajuda a melhorar a convergência. O thread de E/S de atualização gerencia caches locais de contêineres de peer, grupo, prefixo, TSI e RIB.

O thread de atualização de BGP e a fragmentação de RIB de BGP estão desabilitados por padrão. Se você configurar o threading de atualização e o sharding de nervuras em um mecanismo de roteamento, o RPD criará threads de atualização. Por padrão, o número de threads de atualização e threads de fragmento criados é o mesmo que o número de núcleos de CPU no mecanismo de roteamento. O threading de atualização só é suportado em um processo de protocolo de roteamento de 64 bits (rpd). Opcionalmente, você pode especificar o número de threads que deseja criar usando set update-threading <number-of-threads> instruções and set rib-sharding <number-of-threads> no nível da [edit system processes routing bgp] hierarquia. Para o thread de atualização do BGP, o intervalo é atualmente de 1 a 128 e para a fragmentação BGP RIB, o intervalo é atualmente de 1 a 31.

Quando você configura o NSR para os recursos de fragmentação BGP RIB e BGP Update IO, o RPD de backup cria o mesmo número de threads de fragmento BGP e BGP Update IO no mecanismo de roteamento de backup. Os threads de E/S de atualização de BGP RPD de backup leem a atualização de BGP replicada, outras mensagens recebidas dos pares, bem como a atualização de BGP replicada e outras mensagens enviadas aos pares. Com base no hash de prefixos, os threads de E/S de atualização de BGP RPD de backup enviam essas mensagens BGP para o fragmento BGP aplicável e os threads principais do RPD. O fragmento BGP e os threads principais do RPD no RPD de backup criam o estado da rota recebida e anunciada usando essas mensagens BGP replicadas. Quando o mecanismo de roteamento primário falha, o mecanismo de roteamento de backup se torna o mecanismo de roteamento primário e o RPD de backup se torna o RPD principal sem afetar as sessões de BGP com os pares.

Para cada prefixo na tabela de roteamento, o processo de protocolo de roteamento seleciona um único melhor caminho. Depois que o melhor caminho é selecionado, a rota é instalada na tabela de roteamento. O melhor caminho se torna a rota ativa se o mesmo prefixo não for aprendido por um protocolo com um valor de preferência global menor (mais preferencial), também conhecido como distância administrativa. O algoritmo para determinar a rota ativa é o seguinte:

1. Verifique se o próximo salto pode ser resolvido.

2. Escolha o caminho com o menor valor de preferência (protocolo de roteamento, preferência, processo).

   As rotas que não são elegíveis para serem usadas para encaminhamento (por exemplo, porque foram rejeitadas pela política de roteamento ou porque um próximo salto está inacessível) têm uma preferência de –1 e nunca são escolhidas.

3. Prefira o caminho com maior preferência local.

   Para caminhos não BGP, escolha o caminho com o valor de preference2 mais baixo.

4. Se o atributo AIGP (interior gateway protocol) acumulado estiver habilitado, adicione a métrica IGP e prefira o caminho com o atributo AIGP inferior.

5. Prefira o caminho com o valor de caminho do sistema autônomo (AS) mais curto (ignorado se a as-path-ignore instrução estiver configurada).

   Um segmento de confederação (sequência ou conjunto) tem um comprimento de caminho de 0. Um conjunto AS tem um comprimento de caminho de 1.

6. Prefira a rota com o código de origem inferior.

   As rotas aprendidas de um IGP têm um código de origem inferior àquelas aprendidas de um protocolo de gateway exterior (EGP), e ambas têm códigos de origem inferiores às rotas incompletas (rotas cuja origem é desconhecida).

7. Prefira o caminho com a menor métrica de discriminador múltiplo de saída (MED).

   Dependendo se o comportamento de seleção de caminho da tabela de roteamento não determinístico está configurado, há dois casos possíveis:

   • Se o comportamento de seleção de caminho da tabela de roteamento não determinístico não estiver configurado (ou seja, se a path-selection cisco-nondeterministic declaração não estiver incluída na configuração do BGP), para caminhos com os mesmos números de AS vizinhos na frente do caminho de AS, prefira o caminho com a métrica de MED mais baixa. Para sempre comparar MEDs, independentemente de os ASs peer das rotas comparadas serem iguais ou não, inclua a path-selection always-compare-med declaração.

   • Se o comportamento de seleção de caminho da tabela de roteamento não determinístico estiver configurado (ou seja, a path-selection cisco-nondeterministic instrução está incluída na configuração do BGP), prefira o caminho com a métrica MED mais baixa.

   As confederações não são consideradas ao determinar os ASs vizinhos. Uma métrica MED ausente é tratada como se um MED estivesse presente, mas zero.

   Observação:

   A comparação MED funciona para seleção de caminho único em um AS (quando a rota não inclui um caminho AS), embora esse uso seja incomum.

   Por padrão, somente os MEDs de rotas que têm os mesmos sistemas autônomos (ASs) de peer são comparados. Você pode configurar opções de seleção de caminho da tabela de roteamento para obter diferentes comportamentos.

8. Prefira caminhos estritamente internos, que incluem rotas IGP e rotas geradas localmente (estáticas, diretas, locais e assim por diante).

9. Prefira caminhos BGP (EBGP) estritamente externos a caminhos externos aprendidos por meio de sessões BGP (IBGP) internas.

10. Prefira o caminho cujo próximo salto é resolvido por meio da rota IGP com a métrica mais baixa. As rotas BGP resolvidas por meio do IGP são preferidas em relação às rotas inalcançáveis ou rejeitadas.

    Observação:

    Um caminho é considerado um caminho de igual custo BGP (e será usado para encaminhamento) se um tie-break for executado após a etapa anterior. Todos os caminhos com o mesmo AS vizinho, aprendidos por um vizinho BGP habilitado para multipath, são considerados.

    O multipath BGP não se aplica a caminhos que compartilham o mesmo custo MED-plus-IGP, mas diferem no custo do IGP. A seleção de caminhos múltiplos é baseada na métrica de custo do IGP, mesmo que dois caminhos tenham o mesmo custo de MED mais IGP.

11. Se ambos os caminhos forem externos, prefira o caminho mais antigo, ou seja, o caminho que foi aprendido primeiro. Isso é feito para minimizar a oscilação de rota. Essa regra não será usada se qualquer uma das seguintes condições for verdadeira:

    • path-selection external-roteador-id está configurado.

    • Ambos os pares têm o mesmo ID de roteador.

    • Qualquer um dos pares é um par de confederação.

    • Nenhum dos caminhos é o caminho ativo atual.

12. Prefira o caminho do peer com o ID de roteador mais baixo. Para qualquer caminho com um atributo de ID do originador, substitua o ID do originador pelo ID do roteador durante a comparação do ID do roteador.

13. Prefira o caminho com o menor comprimento de lista de cluster. O comprimento é 0 para nenhuma lista.

14. Prefira o caminho do peer com o endereço IP do peer mais baixo.

15. Prefira uma rota primária a uma rota secundária. Uma rota primária é aquela que pertence à tabela de roteamento. Uma rota secundária é aquela que é adicionada à tabela de roteamento por meio de uma política de exportação.

• Seleção de caminho da tabela de roteamento
• Seleção de caminho da tabela BGP
• Efeitos da publicidade de vários caminhos para um destino

O Junos OS melhora a resolução de rotas de serviço para rotas auxiliares multipath BGP que usam estruturas list-nexthop. O resolvedor de rotas agora cria e mantém dependências internas para todos os caminhos contribuintes em uma rota multipath, permitindo uma redefinição precisa e dinâmica quando os nexthops indiretos mudam, independentemente de a rota contribuinte estar ativa ou inativa.

Esse recurso melhora a estabilidade da rota de serviço e evita caminhos de encaminhamento obsoletos em redes que usam BGP ECMP com resolução indireta de nexthop.

• Benefícios
• Antes de começar
• Como o recurso funciona
• Exemplo operacional
• Referência de comandos da CLI
• Limitações

O Junos OS oferece suporte substancial aos seguintes RFCs e rascunhos da Internet, que definem padrões para o BGP IP versão 4 (IPv4).

Para obter uma lista de padrões BGP IP versão 6 (IPv6) suportados, consulte Padrões IPv6 suportados.

O Junos OS BGP oferece suporte à autenticação para trocas de protocolo (autenticação MD5).

• RFC 1745, BGP4/IDRP para IP — interação OSPF

• RFC 1772, Aplicação do Border Gateway Protocol na Internet

• RFC 1997, atributo de comunidades BGP

• RFC 2283, extensões multiprotocolo para BGP-4

• RFC 2385, proteção de sessões BGP por meio da opção de assinatura TCP MD5

• RFC 2439, amortecimento de flap de rota BGP

• RFC 2545, uso de extensões multiprotocolo BGP-4 para roteamento entre domínios IPv6

• RFC 2796, reflexão de rota BGP — uma alternativa ao IBGP de malha completa

• RFC 2858, extensões multiprotocolo para BGP-4

• RFC 2918, recurso de Atualizar de Rota para BGP-4

• RFC 3065, Confederações de sistemas autônomos para BGP

• RFC 3107, transportando informações de rótulo no BGP-4

• RFC 3345, condição de oscilação de rota persistente do Border Gateway Protocol (BGP)

• RFC 3392, Anúncio de recursos com BGP-4

• RFC 4271, um protocolo de gateway de borda 4 (BGP-4)

• RFC 4273, Definições de Objetos Gerenciados para BGP-4

• RFC 4360, atributo de comunidades estendidas do BGP

• RFC 4364, redes privadas virtuais (VPNs) IP BGP/MPLS

• RFC 4456, Reflexão de rota BGP: uma alternativa ao BGP interno de malha completa (IBGP)

• RFC 4486, subcódigos para mensagem de notificação de cessação de BGP

• RFC 4576, usando um bit de opções de anúncio de estado de enlace (LSA) para evitar loops em redes privadas virtuais (VPNs) IP BGP/MPLS

• RFC 4659, extensão de rede privada virtual (VPN) IP BGP-MPLS para VPN IPv6

• RFC 4632, roteamento entre domínios sem classe (CIDR): o plano de atribuição e agregação de endereços da Internet

• RFC 4684, distribuição de rota restrita para protocolo de gateway de borda/comutação de rótulo multiprotocolo (BGP/MPLS), protocolo de Internet (IP), redes privadas virtuais (VPNs)

• RFC 4724, mecanismo de reinicialização gracioso para BGP

• RFC 4760, extensões multiprotocolo para BGP-4

• RFC 4781, mecanismo de reinicialização gracioso para BGP com MPLS

• RFC 4798, Conectando ilhas IPv6 por IPv4 MPLS usando roteadores de borda de provedor IPv6 (6PE)

  A opção 4b (redistribuição eBGP de rotas IPv6 rotuladas do AS para o AS vizinho) não é suportada.

• RFC 4893, suporte BGP para espaço numérico AS de quatro octetos

• RFC 5004, evite as transições de melhor caminho do BGP de um externo para outro

• RFC 5065, Confederações de sistemas autônomos para BGP

• RFC 5082, o mecanismo de segurança TTL generalizado (GTSM)

• RFC 5291, recurso de filtragem de rota de saída para BGP-4 (suporte parcial)

• RFC 5292, filtro de rota de saída baseado em prefixo de endereço para BGP-4 (suporte parcial)

  Os dispositivos que executam o Junos OS podem receber mensagens ORF baseadas em prefixo.

• RFC 5396, Representação Textual de Números de Sistema Autônomo (AS)

• RFC 5492, Anúncio de recursos com BGP-4

• RFC 5512, o identificador de família de endereços subsequentes (SAFI) de encapsulamento BGP e o atributo de encapsulamento de túnel BGP

• RFC 5549, anunciando informações de alcance da Camada de Rede IPv4 com um próximo salto IPv6

• RFC 8955, Disseminação de Regras de Especificação de Fluxo

• RFC 8956, disseminação de regras de especificação de fluxo para IPv6

• RFC 5668, comunidade estendida de BGP específica de 4 octetos AS

• RFC 5701, atributo de comunidade estendida BGP específico de endereço IPv6

• RFC 5925, a opção de autenticação TCP

• RFC 6286, identificador BGP exclusivo em todo o sistema autônomo para BGP-4 totalmente compatível

• RFC 6368, BGP interno como protocolo de borda de provedor/cliente para redes privadas virtuais (VPNs) IP BGP/MPLS

• RFC 6774, distribuição de diversos caminhos BGP

• RFC 6793, suporte BGP para espaço numérico de sistema autônomo (AS) de quatro octetos

• RFC 6810, o recurso infraestrutura de chave pública (RPKI) para protocolo de roteador

• RFC 6811, validação de origem do prefixo BGP

• RFC 6996, Reserva de Sistema Autônomo (AS) para Uso Privado

• RFC 7300, Reserva dos Últimos Números do Sistema Autônomo (AS)

• RFC 7311, o atributo de métrica de IGP acumulado para BGP

• RFC 7404, usando apenas endereçamento local de enlace dentro de uma rede IPv6

• RFC 7432, VPN Ethernet baseada em BGP MPLS (eVPN)

• RFC 7606, tratamento de erros revisado para mensagens BGP UPDATE

• RFC 7611, BGP atributo da comunidade ACCEPT_OWN

  Oferecemos suporte ao RFC permitindo que os roteadores da Juniper aceitem rotas recebidas de um refletor de rota com o valor da accept-own comunidade.

• RFC 7752, distribuição ao norte de informações de estado de enlace e engenharia de tráfego (TE) usando BGP

• RFC 7854, protocolo de monitoramento BGP (BMP)

• RFC 7911, anúncio de vários caminhos no BGP

• RFC 8097, prefixo BGP, estado de validação de origem, comunidade estendida

• RFC 8210, o recurso infraestrutura de chave pública (RPKI) para protocolo de roteador, versão 1

• RFC 8212, comportamento de propagação de rota BGP externa (EBGP) padrão sem políticas - totalmente compatível

  Exceções:

  Os comportamentos no RFC 8212 não são implementados por padrão para evitar a interrupção da configuração existente do cliente. O comportamento padrão ainda é mantido para aceitar e anunciar todas as rotas em relação aos pares EBGP.

• RFC 8277, usando o BGP para vincular rótulos MPLS a prefixos de endereço

• RFC 8326, desligamento gracioso da sessão BGP

• RFC 8481, esclarecimentos sobre a validação de origem do BGP com base na infraestrutura de chave pública (RPKI) do recurso

• RFC 8538, suporte de mensagem de notificação para reinicialização graciosa do BGP

• RFC 8571, BGP - Anúncio de estado do enlace (BGP-LS) de extensões de métrica de desempenho de engenharia de tráfego IGP

• RFC 8584, estrutura para VPN Ethernet Encaminhamento designado Extensibilidade de eleição

• RFC 8642, comportamento de política para comunidades BGP conhecidas

• RFC 8669, prefixo de roteamento por segmentos, extensões de identificador de segmento para BGP

• RFC 8810, revisão dos procedimentos de registro de códigos de capacidade

• Profundidade máxima de SID (MSD) de sinalização RFC 8814 usando o protocolo de gateway de borda - Estado do enlace (suporte parcial)

• RFC 8950, anunciando informações de alcance de camada de rede (NLRI) IPv4 com um próximo salto IPv6

• RFC 8955

• RFC 8956

• RFC 9003, comunicação de desligamento administrativo BGP estendido

• RFC 9012, o atributo de encapsulamento de túnel BGP

• RFC 9029, Atualizações da Política de Alocação para o Protocolo de Gateway de Borda - Registros de Parâmetros de Estado do Enlace (BGP-LS)

• RFC 9069, suporte para RIB local no protocolo de monitoramento BGP (BMP)

• RFC 9085, Border Gateway Protocol - Extensões BGP-LS (Link State) para Roteamento por segmentos

• RFC 9117, Procedimento de validação revisado para disseminação de especificações de fluxo BGP. Isso permite que as especificações de fluxo sejam originadas dentro do mesmo sistema autônomo que o peer BGP que executa a validação.

• RFC 9234, prevenção e detecção de vazamento de rota usando funções em mensagens UPDATE e OPEN

• RFC 9384, um subcódigo de cessação de notificação de BGP para detecção de encaminhamento bidirecional (BFD)

• Rascunho da Internet draft-idr-rfc8203bis-00, Comunicação de desligamento administrativo do BGP (expira em outubro de 2018)

• Rascunho da Internet draft-ietf-grow-bmp-adj-rib-out-01, suporte para Adj-RIB-Out no protocolo de monitoramento BGP (BMP) (expira em 3 de setembro de 2018)

• Rascunho da Internet-ietf-idr-aigp-06, O atributo de métrica IGP acumulado para BGP (expira em dezembro de 2011)

• Rascunho da Internet-ietf-idr-as0-06, Codificação do processamento AS 0 (expira em fevereiro de 2013)

• Rascunho da Internet draft-ietf-idr-link-bandwidth-06.txt, Comunidade Estendida de Largura de Banda de Link BGP (expira em julho de 2013)

• Rascunho da Internet draft-ietf-sidr-origin-validation-signaling-00, prefixo BGP, estado de validação de origem, comunidade estendida (suporte parcial) (expira em maio de 2011)

  A comunidade estendida (estado de validação de origem) é suportada na política de roteamento do Junos OS. A alteração especificada no procedimento de seleção de rota não é suportada.

• draft-kato-bgp-ipv6-link-local-00.txt de rascunho da Internet, peering BGP4+ usando endereço local de link IPv6

Os RFCs e o rascunho da Internet a seguir não definem padrões, mas fornecem informações sobre o BGP e tecnologias relacionadas. O IETF os classifica como "Experimentais" ou "Informativos".

• RFC 1965, Confederações de Sistemas Autônomos para BGP

• RFC 1966, BGP Route Reflection — uma alternativa ao IBGP de malha completa

• RFC 2270, usando um AS dedicado para sites hospedados em um único provedor

• RFC 3345, condição de oscilação de rota persistente do Border Gateway Protocol (BGP)

• RFC 3562, considerações de gerenciamento de chaves para a opção de assinatura TCP MD5

• Rascunho da Internet draft-ietf-ngtrans-bgp-túnel-04.txt, Conectando ilhas IPv6 em nuvens IPv4 com BGP (expira em julho de 2002)