Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP visão geral

Entender BGP

BGP é um protocolo de gateway externo (EGP) que é usado para trocar informações de roteamento entre roteadores em diferentes sistemas autônomos (ASs). BGP de roteamento inclui a rota completa para cada destino. 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 BGP de rede. BGP usa as informações de alcance da rede para construir um gráfico de conectividade AS, que permite BGP remover loops de roteamento e aplicar decisões de políticas em nível de AS.

As extensões multiprotocol BGP (MBGP) permitem BGP dar suporte à versão 6 de IP (IPv6).O MBGP define os atributos MP_REACH_NLRI e MP_UNREACH_NLRI, que são usados para transportar informações de alcance do 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.

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.

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 BGP implementar fragmentação, retransmissão, reconhecimento e sequência de atualizações.

O software de roteamento do Junos OS tem suporte BGP versão 4. Essa versão da BGP adiciona suporte para roteamento entre domínios sem classificação (CIDR), o que elimina o conceito de classes de rede. Em vez de assumir quais bits de um endereço representam a rede olhando para o primeiro octeto, CIDR permite especificar explicitamente o número de bits no endereço de rede, fornecendo assim um meio de reduzir o tamanho das tabelas de roteamento. BGP versão 4 também aceita a 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 são alcançáveis por ele.

Caminhos e atributos de AS

As informações de roteamento BGP de sistemas de troca incluem a rota completa para cada destino, além de informações adicionais sobre a rota. A rota para cada destino é chamada de caminho AS,e as informações de rota adicionais estão incluídas nos atributos do caminho. BGP usa os atributos do caminho e do caminho de AS para determinar completamente a topologia da rede. Uma BGP entende a topologia, ela pode detectar e eliminar loops de roteamento e selecionar entre grupos de rotas para aplicar preferências administrativas e decisões de política de roteamento.

Informações externas e internas BGP

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

Figura 1: ASS, EBGP e IBGPASS, EBGP e IBGP

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

BGP sistemas são organizados em grupos. Em um grupo IBGP, todos os peers do grupo, chamados de peersinternos, estão no mesmo AS. Peers internos podem estar em qualquer lugar do AS local e não ter que estar conectados diretamente 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 em execução IBGP, calculando o próximo hop usando o BGP hop seguinte recebido com a rota e resolvendo-a usando informações de um dos protocolos de gateway interior.

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

Várias instâncias de 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 de BGP são usadas principalmente para suporte a VPN de Camada 3.

IGP peers e peers de BGP externos (EBGP) (não-multiptihop e multihop) são todos suportados para instâncias de roteamento. BGP peering é estabelecido em uma das interfaces configuradas na routing-instances hierarquia.

Nota:

Quando um 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 na qual a configuração do BGP vizinho existe. Isso é verdade para os vizinhos que estão a um salto de distância ou a vários saltos de distância.

As rotas aprendidas com BGP peer 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 suporte à VPN de Camada 3, configure um roteador BGP na borda do provedor (PE) para receber rotas do roteador da borda do cliente (CE) e enviar as rotas das instâncias até o roteador CE, se necessário. Você pode usar várias instâncias de BGP para manter tabelas de encaminhamento por local separadas 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 a taxa de tráfego de e para o cliente.

Você pode configurar uma sessão multisshop 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.

visão BGP rotas

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

As informações a seguir descreve o caminho:

  • caminho AS, que é uma lista de números de ASs que uma rota passa para chegar ao roteador local. O primeiro número no caminho é o do último AS do 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.

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

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

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

  • Informações de roteamento locais BGP aplicadas a rotas por causa de políticas locais

  • Informações que BGP anunciam para BGP peers em mensagens de atualização

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

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

  • 0— Originalmente, o roteador aprendia a rota por meio de uma IGP (OSPF, IS-IS ou uma rota estática).

  • 1— Originalmente, o roteador adoeceu a rota por meio de um EGP (mais provável BGP).

  • 2— A origem da rota é desconhecida.

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

Uma rota de BGP interna (IBGP) com um endereço de next-hop para um vizinho BGP remoto (protocolo next hop) deve ter seu próximo hop resolvido usando alguma outra rota. BGP adiciona essa rota ao módulo de resolver rpd para resolução de next-hop. Se o RSVP for usado na rede, o BGP hop seguinte será resolvido usando a rota de entrada RSVP. Isso resulta na rota BGP apontar para um próximo hop indireto, e o próximo hop indireto apontando para um próximo salto de encaminhamento. O próximo salto de encaminhamento é obtido da rota RSVP no próximo hop. Muitas vezes, há um grande conjunto de rotas de BGP internos que têm o mesmo protocolo no próximo hop, e, nesses casos, o conjunto de rotas BGP referenciaria o mesmo salto seguinte indireto.

Antes da versão 17.2R1 Junos OS, o módulo resolvedor do processo de protocolo de roteamento (rpd) soluções de rotas dentro do IBGP recebia rotas das seguintes maneiras:

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

A partir da versão 17.2R1 Junos OS, o módulo resolvedor 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 forma:

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

  • A seleção de BGP de caminho é adiada até que a resolução completa da rota seja executada para que as informações de alcance da camada de rede (NLRI) sejam 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 do resolver rpD incluem:

  • Custo de busca de resolução RIB inferior — A saída do caminho resolvido é economizada em um cache resolvedor, de maneira que os mesmos valores de salto e métricas derivados possam ser herdados de outro conjunto de rotas que compartilham o mesmo comportamento de caminho em vez de realizar um fluxo parcial e completo de resolução da rota. Isso reduz o custo de busca da resolução da rota mantendo apenas o estado de resolução mais frequente em um cache com profundidade limitada.

  • otimização da seleção de roteamento BGP — o algoritmo de seleção de roteamento BGP é acionado duas vezes para cada roteamento IBGP recebido — primeiro, ao adicionar a rota no RIB com o próximo hop como inutilizável, e em segundo lugar, ao adicionar a rota com um próximo hop resolvido no RIB (após a resolução da rota). Isso resulta na escolha da melhor rota duas vezes. Com a otimização do resolvedor, o processo de seleção de roteamento é acionado no fluxo de recebimento apenas depois de receber as informações de next-hop do módulo resolver.

  • Armazenamento interno para evitar buscas frequentes — o cache de resolver mantém o estado de resolver mais frequente e, como resultado, a funcionalidade de busca, como a busca de rotas e next-hop é 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 hop, os caminhos podem pertencer a um grupo de equivalência de caminho. 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 roteamento, ele é primeiro olhado no banco de dados de grupo de equivalência de caminho, que contém a saída do caminho resolvido, como o próximo hop indireto e o encaminhamento do próximo hop.

BGP de mensagens

Todas as BGP têm o mesmo header de tamanho fixo, que contém um campo de sinal que é usado para sincronização e autenticação, um campo de comprimento que indica o comprimento do pacote e um campo do tipo que indica o tipo de mensagem (por exemplo, aberto, atualização, notificação, manter a duração 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 BGP mensagens abertas para criar uma BGP conexão entre eles. Uma vez estabelecida a conexão, os dois sistemas podem trocar BGP mensagens e tráfego de dados.

As mensagens abertas consistem no BGP mais os seguintes campos:

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

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

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

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

  • Comprimento do campo do parâmetro e o próprio parâmetro, são campos opcionais.

Mensagens de atualização

BGP sistemas enviam mensagens de atualização para trocar informações de alcance da rede. BGP sistemas 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 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 foram retiradas do serviço porque elas não são mais consideradas alcançáveis

  • Comprimento total do atributo do caminho — Comprimento do campo dos atributos do caminho; lista os atributos do caminho para uma rota viável até um destino

  • Atributos do caminho — Propriedades das rotas, incluindo a origem do caminho, o discriminador de saída múltiplo (MED), a preferência do sistema de origem pela rota e informações sobre agregação, comunidades, confederações e reflexão de roteamento

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

Mensagens manteralives

BGP sistemas trocam mensagens continuadas para determinar se um enlace ou host falhou ou se não está mais disponível. Mensagens manteralives são trocadas com frequência o suficiente para que o temporizador de espera não expire. Essas mensagens consistem apenas no BGP de texto.

Mensagens de notificação

BGP sistemas enviam mensagens de notificação quando uma condição de erro é detectada. Depois que a mensagem é enviada, a sessão BGP e a conexão TCP entre os BGP sistemas são fechados. As mensagens de notificação consistem no BGP mais o código e o subcódigo de erro e dados que descreve o erro.

Mensagens de atualização de rota

BGP os sistemas enviam mensagens de atualização de rota para um ponto somente se eles receberem o anúncio do recurso de atualização da rota do peer. Um BGP deve anunciar a capacidade de atualização da rota para seus colegas usando BGP de recursos se quiser receber mensagens de atualização de rota. Essa mensagem opcional é enviada para solicitar atualizações de BGP dinâmicas de BGP de BGP peers ou para enviar atualizações de rota de saída para um BGP peer.

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

  • AFI — Endereço Identificador de família (16 bits).

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

  • SAFI — Identificador de família de endereço posterior (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 BGP atualizar o segmento de IO

O processamento de roteamento BGP costuma ter vários estágios de pipeline, como recebimento de atualização, análise de atualização, criação de roteamento, resolução do next-hop, aplicação da política de exportação de um grupo de colegas da BGP, formando atualizações por peer e enviando atualizações para peers. BGP Os segmentos de IO de atualização são responsáveis pela ponta traseira deste pipeline BGP, envolvendo a geração de atualizações por peer para grupos de BGP individuais e o envio deles para os peers. Um segmento de atualização pode atender a um ou BGP grupos. BGP Tópicos de IO de atualização constroem atualizações para grupos em paralelo e independentemente de outros grupos que estão sendo atendidos por outros segmentos de atualização. Isso pode oferecer melhoria significativa na convergência de uma carga de trabalho pesada que envolve a publicidade para muitos colegas distribuídos em muitos grupos. BGP Os segmentos de IO de atualização também são responsáveis pela escrita e leitura dos soquetes TCP dos BGP peers, que anteriormente eram fornecidos por segmentos BGPIO (daí o IO do sufixo na BGP Update IO).

BGP os segmentos de IO de atualização podem ser configurados independentemente do recurso de sharding RIB, mas são obrigatórios de usar com sharding RIB, a fim de obter melhor eficiência na embalagem de prefixo na mensagem de atualização de BGP de saída. BGP sharding divide o RIB em vários sub-RIBs que são servidos por segmentos RPD separados. Assim, os prefixos que poderiam ter ido para uma única atualização de saída acabam em diferentes estilhaços. Para ser capaz de construir atualizações BGP com prefixos com o mesmo atributo de saída que pode ser de segmentos de shard RPD diferentes, todos os segmentos de segmentos de shard enviam informações de anúncios compactos para prefixos a serem anunciados a um segmento De atualização que atende BGP grupo de colegas. Com isso, o segmento de atualização, que atende BGP grupo de colegas, empacota prefixos com os mesmos atributos, potencialmente pertencentes a diferentes estilhaços 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 atualização de IO gerencia caches locais de contêineres peer, grupo, prefixo, TSI e RIB.

BGP de atualização está desabilitado por padrão. Se você configurar o encadeamento de atualização em um mecanismo de roteamento, o RPD criará segmentos de atualização. Por padrão, o número de tópicos de atualização criado é o mesmo do número de núcleos de CPU no mecanismo de roteamento. O encadeamento de atualização só é suportado em um processo de protocolo de roteamento de 64 bits (rpd). Opcionalmente, você pode especificar o número de segmentos que deseja criar usando set update-threading <number-of-threads> a instrução no nível [edit system processes routing bgp] da hierarquia. No momento, a gama é de 1 a 128.

Entender BGP seleção de caminhos

Para cada prefixo na tabela de roteamento, o processo de protocolo de roteamento escolhe um único melhor caminho. Depois que o melhor caminho for selecionado, a rota será instalada na tabela de roteamento. O melhor caminho torna-se a rota ativa caso o mesmo prefixo não seja 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 elas foram recusadas pela política de roteamento ou porque um próximo salto é inacessível) têm preferência de –1 e nunca são escolhidas.

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

    Para caminhos não BGP, escolha o caminho com o menor preference2 valor.

  4. Se o atributo AIGP (Interior Gateway Protocol, protocolo de gateway de interior acumulado) estiver ativado, prefira o caminho com o atributo AIGP inferior.

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

    Um segmento da confederação (sequência ou conjunto) tem um comprimento de caminho de 0. Um conjunto de 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 ao que se aprende 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. Escolha o caminho com a métrica mais baixa de discriminador de saída (MED).

    Dependendo se o comportamento de seleção do caminho da tabela de roteamento não determinístico estiver configurado, existem dois casos possíveis:

    • Se o comportamento de seleção do caminho da tabela de roteamento não for configurado (ou seja, se a instrução não estiver incluída na configuração BGP), para caminhos com os mesmos números AS próximos na frente do caminho AS, preferir o caminho com a métrica path-selection cisco-nondeterministic MED mais baixa. Para sempre comparar MEDs, independentemente de os ASs peer das rotas em comparação ser os mesmos, inclua a path-selection always-compare-med declaração.

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

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

    Nota:

    A comparação de MED funciona para uma seleção de caminho único em um AS (quando a rota não inclui um caminho AS), embora essa utilização seja pouco comum.

    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 caminho da tabela de roteamento para obter diferentes comportamentos.

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

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

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

    Nota:

    Um caminho é considerado um BGP de custo igual (e será usado para encaminhamento) caso um tie-break seja realizado após a etapa anterior. Todos os caminhos com o mesmo AS vizinho, aprendida por um vizinho BGP multipath.

    BGP multipath não se aplica a caminhos que compartilham o mesmo custo MED-plus-IGP mas que diferem em IGP custo. A seleção do caminho multicamada baseia-se na IGP de custo, mesmo que dois caminhos tenham o mesmo custo MED-plus-IGP.

    BGP compara o tipo de métrica IGP antes de comparar o próprio valor métrico em rt_metric2_cmp . Por exemplo, BGP rotas que são solucionadas por meio de IGP são preferidas em relação aos next-hops descartados ou recusados que sejam do tipo RTM_TYPE_UNREACH . Essas rotas são declaradas inactive por causa de suas metric-type .

  11. Se ambos os caminhos são externos, prefira o caminho ativo no momento para minimizar a agitação de rotas. Essa regra não é usada se uma das seguintes condições for verdadeira:

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

    • Ambos os peers têm a mesma ID do roteador.

    • Qualquer um dos dois é um peer da confederação.

    • Nenhum deles é 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. Preferir o caminho do peer com a ID de roteador mais baixa. Para qualquer caminho com um atributo ID do originador, substituir a ID do originador pela ID do roteador durante a comparação de ID do roteador.

  14. Preferir o caminho com o menor comprimento da lista de clusters. O comprimento é de 0, sem lista.

  15. Preferir o caminho do peer com o endereço IP de menor nível.

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 esta etapa do algoritmo incluindo a as-path-ignore opção.

Nota:

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

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

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações 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 cisco IOS ( cisco-non-deterministic ). Esse modo avalia as rotas na ordem de que elas 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. Os caminhos inelegíveis continuam ao final da lista.

    Como exemplo, imagine que você tenha três anúncios de caminho da rota 192.168.1.0/24:

    • Caminho 1 — aprendida por meio do EBGP; CAMINHO DE AS de 65010; MED de 200

    • Caminho 2 — aprendida por meio do IBGP; CAMINHO DE AS de 65020; MED de 150; IGP de 5

    • Caminho 3 — aprendida por meio do IBGP; CAMINHO DE AS de 65010; MED de 100; 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, e 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, então o dispositivo de roteamento elimina o caminho 3 da contenção. 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 da rota.

    Nota:

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

  • Sempre comparar MEDs, independentemente de os ASs peer das rotas comparadas ser os mesmos ( always-compare-med ).

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

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

    BGP multipath não se aplica a caminhos que compartilham o mesmo custo MED-plus-IGP, mas sim em IGP custo. A seleção do caminho multicamada baseia-se na IGP de custo, mesmo que dois caminhos tenham o mesmo custo MED-plus-IGP.

BGP de caminho da tabela

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

  1. Prefira o maior valor de preferência local.

  2. Preferir o comprimento de caminho AS mais curto.

  3. Prefira o menor valor de origem.

  4. Prefira o menor valor de MED.

  5. Preferir rotas aprendidas com um peer EBGP em relação a um peer IBGP.

  6. Prefere a melhor saída de AS.

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

  8. Preferir rotas do peer com a ID do roteador mais baixa.

  9. Preferir caminhos com o menor comprimento de cluster.

  10. Preferir rotas do peer com o endereço IP de menor nível. As etapas 2, 6 e 12 são os critérios de RPD.

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

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

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

Padrões suportados para BGP

O Junos OS tem suporte substancial para as seguintes drafts de RFCs e Internet, que definem padrões para ip versão 4 (IPv4) BGP.

Para ver os padrões IPv6 (IP versão 6) BGP IP suportados.

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

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

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

  • RFC 1997, atributo BGP Communities

  • RFC 2283, Extensões multiprotocol para BGP-4

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

  • RFC 2439, BGP de roteamento

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

  • RFC 2796, BGP roteamento reflexão – 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 Sistema Autônomo para BGP

  • RFC 3107, transportando informações de rótulos em BGP-4

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

  • 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

  • RFC 4360, BGP atributo Extended Communities

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

  • RFC 4456, BGP rotear reflexão: Uma alternativa ao IBGP (Full Mesh Internal BGP)

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

  • Extensão 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 roteamento limitada para Protocolo de Gateway de Borda/MultiProtocol Label Switching (BGP/MPLS) Protocolo de Internet (IP) Redes Privadas Virtuais (VPNs)

  • RFC 4724, Mecanismo de Reinicialização Graciosa para BGP

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

  • RFC 4781, Mecanismo de Reinicialização Graciosa para BGP com MPLS

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

    A opção 4b (redistribuição de eBGP de rotas IPv6 identificadas de AS para as vizinhas) não é aceita.

  • RFC 4893, BGP suporte para espaço de número AS de quatro octetos

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

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

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

  • RFC 5291, capacidade 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)

    Dispositivos em execução no 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 de endereços posterior (SAFI) e o atributo BGP encapsulamento de túnel

  • RFC 5549, publicidade IPv4 Camada de Rede informações de alcance com um IPv6 Next Hop

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

  • RFC 5668, 4-Octet AS Específico BGP Comunidade Estendida

  • RFC 6286, Identificador de BGP de sistema autônomo para BGP-4, totalmente em conformidade

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

  • RFC 6810, RpKI (Resource Public Key Infrastructure, Infraestrutura de Chave Pública de Recursos) para Protocolo de Roteador

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

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

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

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

  • RFC 7854, BGP protocolo de monitoramento (BMP)

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

  • RFC 8212, comportamento de propagação de BGP externo padrão (EBGP) sem políticas, totalmente em conformidade com as políticas

    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 com relação aos colegas de EBGP.

  • RFC 8326, paralisação BGP sessão Graceful

  • Proposta de lei da Internet-idr-rfc8203bis-00, BGP Comunicação de Paralisação Administrativa (expira em outubro de 2018)

  • Proposta de lei da Internet-ietf-grow-bmp-adj-rib-01, Suporte para Adj-RIB-Out em BGP Protocolo de Monitoramento (BMP) (expira em 3 de setembro de 2018)

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

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

  • Projeto de internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expira em julho de 2013)

  • Projeto de Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Origin Validation State Extended Community (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 mudança especificada no processo de seleção de rota não é suportada.

  • Rascunho da Internet-kato-bgp-ipv6-link-local-00.txt, Peering BGP4+ usando endereço local de enlace IPv6

A proposta de RFCs e Internet a seguir não define padrões, mas fornece informações sobre BGP e tecnologias relacionadas. A IETF os classifica de forma diversificada como "Experimentais" ou "informacionais".

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

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

  • RFC 2270, usando um AS dedicado para sites destinados a um único provedor

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

Tabela de histórico de liberação
Versão
Descrição
17.2R1
A partir da versão 17.2R1 Junos OS, o módulo resolvedor 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.
14.1R8
A partir do Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6 e 16.1R1, a opção é suportada para as-path-ignore instâncias de roteamento.