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

BGP é um protocolo de gateway exterior (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 acessibilidade de 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 que o BGP remova loops de roteamento e aplique decisões de políticas no nível 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) transportam 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, a retransmissão, o reconhecimento e o 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 interdomínio 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, a CIDR permite que você especifique explicitamente o número de bits no endereço da rede, fornecendo assim um meio para 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 interior 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 podem ser alcançados por ele.

Caminhos e atributos 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. O caminho AS é a sequência de sistemas autônomos que a rota percorreu, e 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 entre AS. Quando usado dentro de um AS, o BGP é chamado de BGP interno (IBGP) e as sessões BGP realizam roteamento intra-AS. ilustra ASs, IBGP e EBGP.Figura 1

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 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 MOS. 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 salto tomando o próximo salto BGP 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 que é compartilhada entre o peer externo e o roteador local.

Múltiplas instâncias do BGP

Você pode configurar várias instâncias do 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 (EBGP) externos (tanto nonmultihop quanto multihop) são todos suportados para instâncias de roteamento. O peering BGP está estabelecido em uma das interfaces configuradas sob a hierarquia.routing-instances

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 à tabela por padrão.instance-name.inet.0 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 de 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 separadas de encaminhamento 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 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 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 firewalls 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 firewall 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:

  • Como caminho, que é uma lista de números do 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 que é usado na política de roteamento.

Os pares do 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 rotas BGP:

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

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

  • Informações que o BGP anuncia aos pares 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 para o mesmo destino, o BGP anuncia apenas o caminho ativo.

O roteador BGP que anuncia primeiro uma rota atribui a ele um dos seguintes valores para identificar sua origem. Durante a seleção de rota, 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 através de 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 de próximo salto para um vizinho BGP remoto (protocolo próximo salto) 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 próximo salto. Se o RSVP for usado na rede, o próximo salto BGP será resolvido usando a rota de entrada 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 da rota RSVP próximo salto. Muitas vezes existe um grande conjunto de rotas BGP internas que têm o mesmo protocolo 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 de resolução do processo de protocolo de roteamento (rpd) resolveu rotas dentro do IBGP recebido das seguintes maneiras:

  1. Resolução parcial de rota — 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 é referido como o próximo salto de encaminhamento de resolver herdado de rotas de helper. Esses valores métricas 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 é referido como a tabela de roteamento de kernel (KRT) encaminhando o próximo salto 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 rota parciais e completos são acionados para cada rota IBGP, embora cada rota possa herdar o mesmo encaminhamento resolvido no próximo salto ou encaminhamento krt próximo saltos.

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

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

  • Menor custo de pesquisa de resolução RIB — A saída do caminho resolvido é salva em um cache de resolver, de modo 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 do caminho em vez de realizar fluxos de resolução de rota parciais e completos. Isso reduz o custo de busca de resolução de rota, mantendo apenas o estado de resolver mais frequente em um cache com profundidade limitada.

  • Otimização de 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 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 é desencadeado no fluxo de recebimento somente após obter as informações de próximo salto do módulo 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 pesquisa de próximo salto e 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 caminho. Essa abordagem evita a necessidade de realizar uma resolução completa de rota para esses caminhos. Quando um novo caminho requer resolução completa de rotas, ele é analisado pela primeira vez no banco de dados do grupo de equivalência de caminho, que contém a saída de caminho solucionada, como o próximo salto indireto e o próximo salto.

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 que é usado tanto para sincronização quanto para autenticação, um campo de comprimento que indica o comprimento do pacote e um campo de 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. Uma vez estabelecida a conexão, os dois sistemas podem trocar mensagens BGP e tráfego de dados.

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

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

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

  • 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 declaração no nível da hierarquia ou da hierarquia.router-id[edit routing-options][edit logical-systems logical-system-name routing-options] Por padrão, o BGP usa o endereço IP da primeira interface que encontra no roteador.

  • Comprimento de campo de parâmetro e o próprio parâmetro — estes são campos opcionais.

Atualizar mensagens

Os sistemas BGP enviam mensagens de atualização para trocar informações de acessibilidade 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 e os seguintes campos opcionais:

  • Comprimento de rotas inviável — 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 acessá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 que estão 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 temporizante 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 ficam 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 rota

Os sistemas BGP enviam mensagens de atualização de rota apenas para um peer se tiverem recebido o anúncio do recurso 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 rotas BGP dinâmicas de entrada dos 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.

Entenda o fragmento do BGP RIB e o thread de IO do BGP Update

O processamento de rotas BGP geralmente tem várias etapas de pipeline, como receber atualização, analisar atualizações, criar rota, resolver o próximo salto, 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 um BGP RIB unificado em vários sub-RIBs e cada sub-RIB lida com um subconjunto de rotas BGP. A rosca de rosca BGP separada denominada BGP serve cada sub-RIB para alcançar a simultâência. Os threads de fragmento BGP são responsáveis por todas as etapas do pipeline de processamento de roteamento BGP, com exceção da formação por atualizações por peer e do envio de atualizações aos pares. Os threads de fragmento BGP recebem as atualizações enviadas por peers dos threads de IO de atualização BGP com os threads de IO de atualização BGP que 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 thread fragmentado BGP processa a configuração da mesma maneira que o thread principal de RPD, cria pares, grupos, tabelas de rota e usa as informações de configuração para processamento de rotas BGP.

Os threads de IO do BGP Update são responsáveis pela extremidade traseira deste pipeline BGP, envolvendo a geração de atualizações por peer para grupos BGP individuais e o envio para o(s) peer(s). Um tópico de atualização pode atender a um ou mais grupos BGP. Os threads de IO do BGP Update constroem atualizações para grupos em paralelo e independentes 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 pesada, que envolve publicidade para muitos pares 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 pares BGP que anteriormente eram fornecidos por threads BGPIO (daí o sufixo IO no BGP Update IO).

Os threads de IO do BGP Update podem ser configurados independentemente do recurso de fragmento 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 de BGP divide a RIB em vários sub RIBs que são atendidos por fios de RPD separados. Assim, os prefixos que poderiam ter entrado em uma única atualização de saída acabam em diferentes fragmentos. Para ser capaz de construir atualizações BGP com prefixos com o mesmo atributo de saída que pode pertencer a diferentes threads de fragmento de RPD, todos os threads de fragmento enviam informações de anúncio compactas para que os prefixos sejam anunciados em um thread de atualização servindo aquele grupo de peer BGP. Isso permite que o thread de atualização, que atende a este 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, portanto, ajuda a melhorar a convergência. O thread de IO de atualização gerencia caches locais de contêineres peer, grupo, prefixo, TSI e RIB.

O thread de atualização BGP e o fragmento 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 threads de atualização. Por padrão, o número de threads de atualização e threads de fragmentos criados é o mesmo que o número de núcleos de CPU no mecanismo de roteamento. O thread 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 e declarações no nível de hierarquia.set update-threading <number-of-threads>set rib-sharding <number-of-threads>[edit system processes routing bgp] Para thread 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 de RPD BGP de backup lêem a atualização BGP replicada, outras mensagens recebidas dos pares, 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 threads principais BGP e DEP aplicáveis. O fragmento bgp e os tópicos principais de RPD no RPD de backup cria 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 se torna o mecanismo de roteamento principal e o RPD de backup torna-se o RPD primário 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 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 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).

    As rotas que não são elegíveis para o encaminhamento (por exemplo, porque foram recusadas 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 valor.preference2

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

  5. Prefira o caminho com o menor valor de caminho do sistema autônomo (AS) (desafiado se a declaração estiver configurada).as-path-ignore

    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 exterior (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 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 estiver configurado (isto é, se a declaração não estiver incluída na configuração do BGP), para caminhos com os mesmos números DE vizinhos na frente do caminho AS, prefira o caminho com a menor métrica de MED.path-selection cisco-nondeterministic Para comparar sempre os MEDs se as ASs peer das rotas comparadas são as mesmas, inclua a declaração.path-selection always-compare-med

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

    As confederações não são consideradas ao determinar a ASs vizinha. 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 caminhos externos aprendidos por meio de sessões internas de BGP (IBGP).

  10. Prefira o caminho cujo próximo salto seja resolvido pela rota IGP com a métrica mais baixa. As rotas BGP que são resolvidas através do IGP são preferidas em rotas inalcançáveis ou recusadas.

    Nota:

    Um caminho é considerado um caminho BGP de custo igual (e será usado para o 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 vários caminhos, 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 caminhos multicaminho é baseada na métrica de custo do IGP, mesmo que dois caminhos tenham o mesmo custo MED-plus-IGP.

  11. Se ambos os caminhos são externos, prefira o caminho mais antigo, em outras palavras, o caminho que foi aprendido primeiro. Isso é feito para minimizar o flapping de rota. Essa regra não é usada se alguma das seguintes condições for verdadeira:

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

    • Ambos os pares têm a mesma 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 vez de 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 ID de origem, substitua a 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 de peer mais baixo.

Seleção do caminho da tabela de roteamento

A etapa de caminho AS mais curta do algoritmo, por padrão, avalia a duração 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 é suportada para instâncias de roteamento.as-path-ignore

A seleção do caminho do processo de roteamento ocorre antes que o BGP saia 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 declaração:path-selection

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja 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:

  • Emula o comportamento padrão do Cisco IOS ().cisco-non-deterministic Essa modalidade avalia as rotas na ordem em que são recebidas e não as agrupa de acordo com o AS vizinho. Com o modo, o caminho ativo é sempre o primeiro.cisco-non-deterministic 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 iniligí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; AS Path of 65010; MED de 200

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

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

    Esses anúncios são recebidos em rápida sucessão, dentro de 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 ele é 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 usar essa opção de configuração em sua rede. Ele é fornecido apenas para interoperabilidade para permitir que todos os dispositivos de roteamento da rede façam seleções de rota consistentes.

  • Sempre comparando os 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 ) no processo de seleção de caminhos.12

  • Adicionar o custo de IGP ao destino de próximo salto ao valor MED antes de comparar os valores de MED para seleção de caminhos ().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 caminhos multicaminho é baseada na métrica de custo do IGP, mesmo que dois caminhos tenham o mesmo custo MED-plus-IGP.

Seleção de caminhos de tabela BGP

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

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

  2. Prefira o comprimento mais curto do 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 de peer mais baixo. As etapas 2, 6 e 12 são os critérios de RPD.

Efeitos da publicidade em 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 para 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. Este 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 rascunhos de Internet, que definem padrões para IP versão 4 (IPv4) BGP.

Para uma lista de padrões BGP de versão IP 6 (IPv6) compatíveis, veja 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 entre domínios IPv6

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

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

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

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

  • RFC 3107, transportando 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 Virtual Private Networks (VPNs)

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

  • RFC 4486, subcódigos para bgp cessar mensagem de notificação

  • Extensão de RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) 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 fronteira/comutação de rótulo multiProtocol (BGP/MPLS) Protocolo de Internet (IP) Redes virtuais privadas (VPNs)

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

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

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

  • RFC 4798, conectando ilhas IPv6 ao 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 vizinho) não é suportada.

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

  • RFC 5004, evite as melhores transições de caminho 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 rotas de saída para BGP-4 (suporte parcial)

  • RFC 5292, filtro de rota de saída baseado em 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 de túnel BGP

  • RFC 5549, publicidade IPv4 Network Layer Reachability Information com um IPv6 Next Hop

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

  • RFC 5668, 4-Octet como comunidade bgp específica estendida

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

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

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

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

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

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

  • RFC 7611, ATRIBUTO DA COMUNIDADE ACCEPT_OWN BGP

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

  • RFC 7752, Distribuição norte-vinculada 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 8212, Padrão BGP externo (EBGP) Comportamento de propagação de rotas sem políticas totalmente compatíveis

    Exceções:

    Os comportamentos da RFC 8212 não são implementados por padrão, a fim de 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 de EBGP.

  • RFC 8326, Gracioso encerramento de sessão BGP

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

  • Rascunho do rascunho da Internet-idr-rfc8203bis-00, BGP Administrative Shutdown Communication (expira 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 do rascunho da Internet-ietf-idr-aigp-06, O Atributo Métrica de 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)

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

  • Rascunho 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 RFCs e o rascunho da Internet a seguir não definem padrões, mas fornecem informações sobre BGP e tecnologias relacionadas. A IETF os classifica de várias formas como "experimentais" ou "informativos".

  • RFC 1965, Confederações autônomas de sistemas para BGP

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

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

  • Rascunho 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 alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

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 é suportada para instâncias de roteamento.as-path-ignore