Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Visão geral do BGP

Entender o BGP

O BGP é um protocolo de gateway externo (EGP) usado para trocar informações de roteamento entre roteadores em diferentes sistemas autônomos (ASs). As informações de roteamento BGP incluem a rota completa para cada destino. O BGP usa as informações de roteamento para manter um banco de dados de informações de alcance da rede, que ele troca com outros sistemas BGP. O BGP usa as informações de alcance da rede para construir um gráfico de conectividade AS, que permite ao BGP remover loops de roteamento e aplicar decisões de políticas no nível AS.

As extensões BGP (MBGP) multiprotocol permitem que o BGP ofereça suporte à versão IP 6 (IPv6).O MBGP define os atributos MP_REACH_NLRI e MP_UNREACH_NLRI, usados para transportar informações de alcance IPv6. As mensagens de atualização de informações de alcance da camada de rede (NLRI) carregam prefixos de endereço IPv6 de rotas viáveis.

O BGP permite o roteamento baseado em políticas. Você pode usar políticas de roteamento para escolher entre vários caminhos até um destino e controlar a redistribuição de informações de roteamento.

O BGP usa o TCP como protocolo de transporte, usando a porta 179 para estabelecer conexões. Executar um protocolo de transporte confiável elimina a necessidade de o BGP implementar a fragmentação, retransmissão, reconhecimento e sequenciamento de atualização.

O software de protocolo de roteamento Junos OS oferece suporte ao BGP versão 4. Esta versão do BGP adiciona suporte para o Roteamento Interdomain Sem Classe (CIDR), que elimina o conceito de aulas de rede. Em vez de assumir quais bits de um endereço representam a rede olhando para o primeiro octeto, CIDR permite que você especifique explicitamente o número de bits no endereço da rede, fornecendo assim um meio de diminuir o tamanho das tabelas de roteamento. A versão 4 do BGP também oferece suporte à agregação de rotas, incluindo a agregação de caminhos AS.

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

Sistemas autônomos

Um sistema autônomo (AS) é um conjunto de roteadores que estão sob uma única administração técnica e normalmente usam um único protocolo de gateway interno e um conjunto comum de métricas para propagar informações de roteamento dentro do conjunto de roteadores. Para outros ASs, um AS parece ter um plano de roteamento interior único e coerente e apresenta uma imagem consistente de quais destinos são alcançáveis por meio dele.

Caminhos e atributos DO AS

As informações de roteamento que os sistemas BGP trocam incluem a rota completa para cada destino, bem como informações adicionais sobre a rota. A rota para cada destino é chamada de caminho AS, e as informações adicionais de rota estão incluídas em atributos de caminho. O BGP usa o caminho AS e os atributos de caminho para determinar completamente a topologia da rede. Assim que o BGP entender a topologia, ele pode detectar e eliminar loops de roteamento e selecionar entre grupos de rotas para aplicar preferências administrativas e decisões de políticas de roteamento.

BGP externo e interno

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

Figura 1: ASs, EBGP e IBGPASs, EBGP e IBGP

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

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 entre si. 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, computando o próximo hop tomando o BGP next hop recebido com a rota e resolvendo-o usando informações de um dos protocolos de gateway interior.

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

Várias instâncias do BGP

Você pode configurar várias instâncias de BGP nos seguintes níveis de hierarquia:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Várias instâncias do BGP são usadas principalmente para suporte a VPN de Camada 3.

Os pares de IGP e os pares BGP externos (não multihop e multihop) são todos suportados para instâncias de roteamento. O peering BGP está estabelecido em uma das interfaces configuradas sob a routing-instances hierarquia.

Nota:

Quando um vizinho BGP envia mensagens BGP para o dispositivo de roteamento local, a interface de entrada na qual essas mensagens são recebidas deve ser configurada na mesma instância de roteamento em que a configuração do vizinho BGP existe. Isso é verdade para vizinhos que estão a um único salto de distância ou vários saltos de distância.

As rotas aprendidas com o peer BGP são adicionadas à instance-name.inet.0 tabela por padrão. Você pode configurar políticas de importação e exportação para controlar o fluxo de informações dentro e fora da tabela de roteamento de instâncias.

Para o suporte a VPN de Camada 3, configure o BGP no roteador de borda do provedor (PE) para receber rotas do roteador de borda do cliente (CE) e enviar as rotas das instâncias para o roteador CE, se necessário. Você pode usar várias instâncias do BGP para manter tabelas de encaminhamento separadas por site para manter o tráfego VPN separado no roteador PE.

Você pode configurar políticas de importação e exportação que permitem ao provedor de serviços controlar e limitar o tráfego de ida e para o cliente.

Você pode configurar uma sessão multihop EBGP para uma instância de roteamento VRF. Além disso, você pode configurar o peer EBGP entre os roteadores PE e CE usando o endereço de loopback do roteador CE em vez dos endereços de interface.

Permitir tráfego de protocolo para interfaces em uma zona de segurança

Nos dispositivos da Série SRX, você deve habilitar o tráfego de entrada de host esperado nas interfaces especificadas ou em todas as interfaces da zona. Caso contrário, o tráfego de entrada destinado a este dispositivo é descartado por padrão.

Por exemplo, para permitir que o tráfego BGP em uma zona específica do seu dispositivo da Série SRX use a seguinte etapa:

(Todas as interfaces) (Interface especificada)

Visão geral das rotas BGP

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

As informações a seguir descrevem o caminho:

  • CAMINHO AS, que é uma lista de números das ASs por onde passa uma rota 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 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 colegas do BGP anunciam rotas entre si em mensagens de atualização.

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

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

  • Informações de roteamento local que o BGP aplica às rotas por causa de políticas locais

  • Informações que o BGP anuncia aos colegas BGP em mensagens de atualização

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

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

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

  • 1— O roteador aprendeu originalmente a rota por um EGP (provavelmente BGP).

  • 2— A origem da rota é desconhecida.

Visão geral da resolução de rotas BGP

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

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

  1. Resolução parcial de rotas — o próximo salto de protocolo é resolvido com base em rotas de helper, como rotas de RSVP ou IGP. Os valores métricas são derivados das rotas de helper, e o próximo salto é chamado de o próximo salto de encaminhamento de resolver herdado das rotas de helper. Esses valores métricos 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 de rotas — o próximo salto final é derivado e é conhecido como a tabela de roteamento de kernel (KRT) que encaminha o próximo hop com base na política de exportação de encaminhamento.

A partir do Junos OS Release 17.2R1, o módulo de resolver de 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 forma:

  • Os métodos de resolução de rotas parciais e completos são acionados para cada rota IBGP, embora cada rota possa herdar o mesmo encaminhamento resolvido no próximo hop ou KRT no próximo hop.

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

Os benefícios da otimização de resolver rpd incluem:

  • Menor custo de pesquisa de resolução RIB — a saída do caminho resolvido é economizada em um cache de resolver, de modo que os mesmos valores derivados de next hop e métrica possam ser herdados para outro conjunto de rotas que compartilham o mesmo comportamento do caminho em vez de realizar fluxo de resolução de rotas parcial e completo. Isso reduz o custo de busca da resolução de rotas, mantendo apenas o estado de resolver mais frequente em um cache com profundidade limitada.

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

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

  • Grupo de equivalência de caminhos — Quando diferentes caminhos 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 caminhos. Essa abordagem evita a necessidade de realizar uma resolução completa de rotas para esses caminhos. Quando um novo caminho requer resolução completa de rotas, ele é visto pela primeira vez no banco de dados do grupo de equivalência de caminho, que contém a saída de caminho resolvida, como o próximo hop indireto e o próximo hop.

Visão geral das mensagens BGP

Todas as mensagens BGP têm o mesmo cabeçalho de tamanho fixo, que contém um campo de marcador usado para sincronização e autenticação, um campo de comprimento que indica o comprimento do pacote e um campo tipo que indica o tipo de mensagem (por exemplo, aberto, atualizado, notificação, keepalive e assim por diante).

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

Mensagens abertas

Depois que uma conexão TCP é estabelecida entre dois sistemas BGP, eles trocam mensagens abertas BGP para criar uma conexão BGP entre eles. Assim que a conexão for estabelecida, os dois sistemas podem trocar mensagens BGP e tráfego de dados.

As mensagens abertas consistem no cabeçalho BGP e nos seguintes campos:

  • Versão— O número atual da versão BGP é 4.

  • Número DE AS local — você configura isso incluindo a autonomous-system declaração no nível da hierarquia ou [edit logical-systems logical-system-name routing-options] da [edit routing-options] hierarquia.

  • Tempo de espera — Valor de tempo de espera proposto. Você configura o tempo de espera local com a declaração BGP hold-time .

  • Identificador BGP — endereço IP do sistema BGP. Esse endereço é determinado quando o sistema começa e é o mesmo para todas as interfaces locais e todos os peer BGP. Você pode configurar o identificador BGP incluindo a router-id declaração no nível ou [edit routing-options][edit logical-systems logical-system-name routing-options] hierarquia. Por padrão, o BGP usa o endereço IP da primeira interface encontrada no roteador.

  • Comprimento de campo de parâmetro e o parâmetro em si — são campos opcionais.

Atualizar mensagens

Os sistemas BGP enviam mensagens de atualização para trocar informações de alcance da rede. Os sistemas BGP usam essas informações para construir um gráfico que descreve as relações entre todos os ASs conhecidos.

As mensagens de atualização consistem no cabeçalho BGP mais os seguintes campos opcionais:

  • Comprimento de rotas inviáveis — Comprimento do campo de rotas retiradas

  • Rotas retiradas — prefixos de endereço IP para as rotas que estão sendo retiradas do serviço porque elas não são mais consideradas alcançáveis

  • Comprimento total do atributo do caminho — comprimento do campo de atributos do caminho; ele lista os atributos de caminho para uma rota viável para um destino

  • Atributos de caminho — propriedades das rotas, incluindo a origem do caminho, o discriminatório de múltiplas saídas (MED), a preferência do sistema de origem pela rota e informações sobre agregação, comunidades, confederações e reflexão de rotas

  • Informações de alcance da camada de rede (NLRI)— prefixos de endereço IP de rotas viáveis sendo anunciados na mensagem de atualização

Mensagens keepalive

Os sistemas BGP trocam mensagens keepalive para determinar se um link ou host falhou ou não está mais disponível. As mensagens keepalive são trocadas com frequência suficiente para que o temporizador de espera não expire. Essas mensagens consistem apenas no cabeçalho BGP.

Mensagens de notificação

Os sistemas BGP enviam mensagens de notificação quando uma condição de erro é detectada. Após o envio da mensagem, a sessão BGP e a conexão TCP entre os sistemas BGP são fechadas. As mensagens de notificação consistem no cabeçalho BGP, além do código e subcódigo de erro, além de dados que descrevem o erro.

Mensagens de atualização de rotas

Os sistemas BGP enviam mensagens de atualização de rota apenas para um peer se receberem o anúncio de recursos de atualização de rota do peer. Um sistema BGP deve anunciar o recurso de atualização de rota para seus pares usando anúncio de recursos BGP se quiser receber mensagens de atualização de rota. Esta mensagem opcional é enviada para solicitar atualizações dinâmicas de roteamento BGP de seus pares BGP ou para enviar atualizações de rota de saída para um peer BGP.

As mensagens de atualização de rota consistem nos seguintes campos:

  • AFI — Identificador de família de endereços (16 bits).

  • Res — Campo reservado (8 bits), que deve ser definido em 0 pelo remetente e ignorado pelo receptor.

  • SAFI — Identificador de família de endereços subsequente (8 bits).

Se um peer sem o recurso de atualização de rota receber uma mensagem de solicitação de atualização de rota de um peer remoto, o receptor ignora a mensagem.

Entender o sharding BGP RIB e o tópico BGP Update IO

O processamento de rotas BGP geralmente tem vários estágios de pipeline, como receber atualização, analisar atualizações, criar rotas, resolver o 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 pares.

O fragmento BGP RIB divide uma BGP RIB unificada em vários sub-RIBs e cada sub-RIB lida com um subconjunto de rotas BGP. O segmento de segmento de RPD separado chamado de segmento de fragmento BGP serve a cada sub-RIB para alcançar a simultâneo. Os segmentos de fragmento BGP são responsáveis por todas as etapas 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 pares. Os segmentos de fragmento BGP recebem as atualizações enviadas pelos colegas dos threads BGP Update IO com os threads BGP Update IO hashing os prefixos nas atualizações e envia as atualizações para os threads de fragmento BGP aplicáveis com base na computação hash. O segmento de fragmento BGP processa a configuração da mesma maneira que o segmento principal rpd, cria pares, grupos, tabelas de rotas e usa as informações de configuração para o processamento de rotas BGP.

Os threads BGP Update IO são responsáveis pela extremidade traseira deste pipeline BGP, envolvendo a geração de atualizações por peer para grupos BGP(s) individuais e o envio para os peer(s). Um segmento de atualização pode atender a um ou mais grupos BGP. Os segmentos de IO do BGP Update constroem atualizações para grupos em paralelo e independentes de outros grupos que estão sendo atendidos por outros segmentos de atualização. Isso pode oferecer uma melhoria significativa de convergência em uma carga de trabalho pesada, que envolve publicidade para muitos colegas espalhados por muitos grupos. Os threads de IO do BGP Update também são responsáveis por escrever e ler os soquetes TCP dos colegas BGP que anteriormente eram fornecidos por threads BGPIO (daí o sufixo IO no BGP Update IO).

Os threads do BGP Update IO podem ser configurados independentemente do recurso de fragmentação RIB, mas são obrigatórios de usar com fragmentos RIB, a fim de obter uma melhor eficiência de embalagem de prefixo na mensagem de atualização BGP de saída. O fragmento BGP divide a RIB em vários sub RIBs que são servidos por segmentos de RPD separados. Assim, os prefixos que poderiam ter entrado em uma única atualização de saída acabam em diferentes fragmentos. Para poder construir atualizações BGP com prefixos com o mesmo atributo de saída que pode pertencer a diferentes segmentos de fragmentos de RPD, todos os segmentos fragmentados enviam informações de anúncio compacta para que prefixos sejam anunciados em um segmento de atualização que atende a esse grupo de peer BGP. Isso permite que o segmento de atualização, que atende a esse grupo de peer BGP, embale prefixos com os mesmos atributos, potencialmente pertencentes a diferentes fragmentos na mesma mensagem de atualização de saída. Isso minimiza o número de atualizações a serem anunciadas e, assim, ajuda a melhorar a convergência. O segmento de IO de atualização gerencia caches locais de contêineres peer, grupo, prefixo, TSI e RIB.

O segmento de atualização BGP e os fragmentos BGP RIB são desativados por padrão. Se você configurar o threading de atualização e o fragmento de costela em um mecanismo de roteamento, o RPD cria segmentos de atualização. Por padrão, o número de threads de atualização e roscas fragmentadas 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 tópicos que deseja criar usando set update-threading <number-of-threads> e set rib-sharding <number-of-threads> declarações no nível de [edit system processes routing bgp] hierarquia. Para a linha de atualização BGP, a faixa é atualmente de 1 a 128 e para fragmentos BGP RIB, a faixa atualmente é de 1 a 31.

Quando você configura o NSR para os recursos BGP RIB e BGP Update IO, o RPD de backup cria o mesmo número de threads BGP shard e BGP Update IO no mecanismo de roteamento de backup. Os threads de IO de atualização BGP de RPD de backup leram a atualização BGP replicada, outras mensagens recebidas dos colegas, bem como a atualização BGP replicada e outras mensagens enviadas aos pares. Com base no hashing de prefixos, os threads de IO de atualização BGP de RPD de backup enviam essas mensagens BGP para os segmentos principais BGP e RPD aplicáveis. O fragmento BGP e os tópicos principais de RPD no RPD de backup criam o estado de rota recebido e anunciado usando essas mensagens BGP replicadas. Quando o mecanismo de roteamento primário falha, o mecanismo de roteamento de backup torna-se o mecanismo de roteamento principal e o RPD de backup torna-se o RPD principal de maneira perfeita sem afetar as sessões BGP com os pares.

Entender a seleção do caminho BGP

Para cada prefixo na tabela de roteamento, o processo de protocolo de roteamento seleciona um único caminho melhor. Após a seleção do melhor caminho, a rota é instalada na tabela de roteamento. O melhor caminho torna-se a rota ativa se o mesmo prefixo não for aprendido por um protocolo com um valor de preferência global mais baixo (mais preferido), 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 (preferência do processo de protocolo de roteamento).

    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 é 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 menor preference2 valor.

  4. Se o atributo de protocolo de gateway interior (AIGP) acumulado for habilitado, prefira o caminho com o atributo AIGP inferior.

  5. Prefira o caminho com o menor valor de caminho do sistema autônomo (AS) (ignorado se a as-path-ignore declaraçã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 com um IGP têm um código de origem menor do que as aprendidas com um protocolo de gateway externo (EGP), e ambas têm códigos de origem mais baixos do que rotas incompletas (rotas cuja origem é desconhecida).

  7. Prefira o caminho com a métrica de discriminação por múltiplas saídas (MED) mais baixa.

    Dependendo se o comportamento de seleção do caminho da tabela de roteamento não determinado está configurado, existem dois casos possíveis:

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

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

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

    Nota:

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

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

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

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

  10. Prefira o caminho cujo próximo salto é resolvido pela rota IGP com a métrica mais baixa.

    Nota:

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

    O multicaminho 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 caminho multicaminho é baseada na métrica de custo do IGP, mesmo que dois caminhos tenham o mesmo custo de MED-plus-IGP.

    O BGP compara o tipo de métrica de IGP antes de comparar o valor métrico em rt_metric2_cmpsi. Por exemplo, as rotas BGP que são resolvidas através do IGP são preferidas em vez de next-hops descartados ou rejeitados que são do tipo RTM_TYPE_UNREACH. Tais rotas são declaradas inactive por causa de suas metric-type.

  11. Se ambos os caminhos forem externos, prefira o caminho ativo atualmente para minimizar o flapping de rotas. Esta regra não é usada se alguma das seguintes condições for verdadeira:

    • path-selection external-router-id está configurada.

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

    • Ambos os pares são um par da confederação.

    • Nenhum dos dois caminhos é o caminho ativo atual.

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

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

  14. Prefira o caminho com o menor comprimento da lista de clusters. O comprimento é 0 para nenhuma lista.

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

Seleção do caminho da tabela de roteamento

A etapa de caminho as mais curta do algoritmo, por padrão, avalia o comprimento do caminho as e determina o caminho ativo. Você pode configurar uma opção que permite ao Junos OS pular essa etapa do algoritmo, incluindo a opção as-path-ignore .

Nota:

Começando pelo Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6 e 16.1R1, a opção as-path-ignore é suportada para instâncias de roteamento.

A seleção do caminho do processo de roteamento ocorre antes que a BGP se livre do caminho até a tabela de roteamento para tomar sua decisão. Para configurar o comportamento de seleção do caminho da tabela de roteamento, inclua a path-selection declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

A seleção do caminho da tabela de roteamento pode ser configurada de uma das seguintes maneiras:

  • Emular o comportamento padrão do Cisco IOS ().cisco-non-deterministic Esse modo avalia as rotas na ordem em que são recebidas e não as agrupa de acordo com o AS vizinho. Com cisco-non-deterministic o modo, o caminho ativo é sempre o primeiro. Todos os caminhos inativos, mas elegíveis, seguem o caminho ativo e são mantidos na ordem em que foram recebidos, com o caminho mais recente em primeiro lugar. Caminhos inelegíveis permanecem no final da lista.

    Como exemplo, suponha que você tenha três anúncios de caminho para a rota 192.168.1.0 /24:

    • Caminho 1 — aprendido através do EBGP; CAMINHO AS de 65010; MED de 200

    • Caminho 2 — aprendido através do IBGP; CAMINHO AS de 65020; MED de 150; Custo do IGP de 5

    • Caminho 3 — aprendido através do IBGP; CAMINHO AS de 65010; MED de 100; Custo de IGP de 10

    Esses anúncios são recebidos em rápida sucessão, em um segundo, na ordem listada. O Caminho 3 é recebido mais recentemente, então o dispositivo de roteamento o compara com o caminho 2, o próximo anúncio mais recente. O custo para o peer IBGP é melhor para o caminho 2, de modo que o dispositivo de roteamento elimina o caminho 3 da disputa. Ao comparar os caminhos 1 e 2, o dispositivo de roteamento prefere o caminho 1 porque é recebido de um peer EBGP. Isso permite que o dispositivo de roteamento instale o caminho 1 como o caminho ativo para a rota.

    Nota:

    Não recomendamos o uso dessa opção de configuração em sua rede. Ele é fornecido exclusivamente para a interoperabilidade para permitir que todos os dispositivos de roteamento da rede façam seleções de rota consistentes.

  • Sempre comparando MEDs se as ASs peer das rotas comparadas são as mesmas (always-compare-med).

  • Substitua a regra de que, se ambos os caminhos forem externos, o caminho ativo atualmente é preferido (external-router-id). Continue com a próxima etapa (Etapa 12) no processo de seleção de caminhos.

  • Adicionando o custo do IGP ao destino next-hop ao valor do MED antes de comparar os valores de MED para seleção de caminho (med-plus-igp).

    O multicaminho 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 caminho multicaminho é baseada na métrica de custo do IGP, mesmo que dois caminhos tenham o mesmo custo de MED-plus-IGP.

Seleção do caminho da Tabela BGP

Os seguintes parâmetros são seguidos para a seleção do caminho do BGP:

  1. Prefira o mais alto valor de preferência local.

  2. Prefira o menor comprimento de caminho AS.

  3. Prefira o menor valor de origem.

  4. Prefira o menor valor de MED.

  5. Prefira rotas aprendidas com um peer EBGP em vez de um peer IBGP.

  6. Prefira a melhor saída do AS.

  7. Para rotas recebidas por EBGP, prefira a rota ativa atual.

  8. Prefira rotas do peer com o ID do roteador mais baixo.

  9. Prefira caminhos com o menor comprimento de cluster.

  10. Prefira rotas do peer com o endereço IP peer mais baixo. As etapas 2, 6 e 12 são os critérios de RPD.

Efeitos da publicidade de vários caminhos até um destino

O BGP anuncia apenas o caminho ativo, a menos que você configure o BGP para anunciar vários caminhos até um destino.

Suponha que um dispositivo de roteamento tenha em sua tabela de roteamento quatro caminhos até um destino e esteja configurado para anunciar até três caminhos (add-path send path-count 3). Os três caminhos são escolhidos com base em critérios de seleção de caminhos. Ou seja, os três melhores caminhos são escolhidos em ordem de seleção de caminhos. O melhor caminho é o caminho ativo. Esse caminho é removido da consideração e um novo melhor caminho é escolhido. Esse processo é repetido até que o número especificado de caminhos seja alcançado.

Padrões suportados para BGP

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

Para uma lista de padrões BGP de versão IP 6 (IPv6) compatíveis, consulte padrões IPv6 compatíveis.

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

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

  • RFC 1772, aplicação do protocolo de gateway de fronteira na Internet

  • RFC 1997, atributo das comunidades BGP

  • RFC 2283, extensões multiprotocol 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 multiprotocol BGP-4 para roteamento inter domínio IPv6

  • RFC 2796, reflexão de rotas BGP – uma alternativa ao IBGP de malha completa

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

  • RFC 2918, recurso de atualização de rotas para BGP-4

  • RFC 3065, Confederações de Sistema Autônomo para BGP

  • RFC 3107, levando informações de rótulos no BGP-4

  • RFC 3345, condição de oscilação persistente da rota do protocolo de gateway de borda (BGP)

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

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

  • RFC 4273, Definições de objetos gerenciados para BGP-4

  • ATRIBUTO RFC 4360, BGP Extended Communities Attribute

  • RFC 4364, BGP/MPLS IP Private Networks (VPNs)

  • RFC 4456, reflexão de rotas BGP: Uma alternativa ao BGP interno de malha completa (IBGP)

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

  • Extensão do RFC 4659, BGP-MPLS IP Private Network (VPN) para VPN IPv6

  • RFC 4632, Roteamento inter domínio sem classe (CIDR): O plano de atribuição e agregação de endereços da Internet

  • RFC 4684, distribuição restrita de rotas para protocolo de gateway de borda/comutação de rótulos multiProtocol (BGP/MPLS) Protocolo de Internet (IP) Redes privadas virtuais (VPNs)

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

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

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

  • RFC 4798, conectando ilhas IPv6 com IPv4 MPLS usando roteadores de borda de provedores IPv6 (6PE)

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

  • RFC 4893, suporte BGP para espaço numérica de quatro octets AS

  • RFC 5004, evite as melhores transições de caminho bgp de um externo para outro

  • RFC 5065, Confederações de Sistema Autônomo para BGP

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

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

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

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

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

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

  • RFC 5512, o BGP Encapsulation Subsequent Address Family Identifier (SAFI) e o atributo de encapsulamento do túnel BGP

  • RFC 5549, informações de alcance da camada de rede IPv4 com um Next Hop IPv6

  • RFC 5575, Disseminação de regras de especificação de fluxo

  • RFC 5668, 4-Outet como comunidade estendida BGP específica

  • 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 de IP BGP/MPLS (VPNs)

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

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

  • Reserva rfc 6996, Sistema Autônomo (AS) para uso privado

  • RFC 7300, reserva de números do último sistema autônomo (AS)

  • RFC 7611, BGP ACCEPT_OWN Community Attribute

    Apoiamos o RFC, permitindo que os roteadores da Juniper aceitem rotas recebidas de um refletor de rotas com o valor da accept-own comunidade.

  • RFC 7752, distribuição norte-vinculada de informações de link-state 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 8212, comportamento de propagação de rotas BGP externo padrão (EBGP) sem políticas totalmente compatíveis

    Exceções:

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

  • RFC 8326, gracioso encerramento de sessão BGP

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

  • Draft da Internet-idr-rfc8203bis-00, BGP Administrative Shutdown Communication (expira outubro de 2018)

  • Draft da Internet-ietf-grow-bmp-adj-rib-out-01, Suporte para Adj-RIB-Out no BGP Monitoring Protocol (BMP) (expira em 3 de setembro de 2018)

  • Rascunho do draft da Internet-ietf-idr-aigp-06, O Atributo Métrico IGP Acumulado para BGP (expira dezembro de 2011)

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

  • Draft da Internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expira julho de 2013)

  • Draft da Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (suporte parcial) ( expira em maio de 2011)

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

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

Os seguintes RFCs e internet não definem padrões, mas fornecem informações sobre BGP e tecnologias relacionadas. O IETF classifica-os de várias forma como "experimentais" ou "informativos".

  • RFC 1965, Confederações de Sistema Autônomo para BGP

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

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

  • Draft da Internet draft-ietf-ngtrans-bgp-tunnel-04.txt, conectando ilhas IPv6 em nuvens IPv4 com BGP (expira julho de 2002)

Tabela de histórico de liberação
Versão
Descrição
17.2R1
A partir do Junos OS Release 17.2R1, o módulo de resolver de rpd é otimizado para aumentar a taxa de transferência do fluxo de processamento de entrada, acelerando a taxa de aprendizado de RIB e FIB.
14.1R8
Começando pelo Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6 e 16.1R1, a opção as-path-ignore é suportada para instâncias de roteamento.