Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP refletores de roteador

Compreender BGP refletores de roteador

Este tópico discute o uso de refletores de roteamento para simplificar a configuração e ajudar no dimensionamento. Uma outra maneira de reduzir a carga de trabalho em um refletor de roteamento que não está no caminho do encaminhamento de tráfego é usar a no-install instrução em nível [edit protocols bgp family family-name] de hierarquia. A partir da versão 15.1 do Junos OS, a declaração elimina a interação entre os protocolos de roteamento (rpd) e outros componentes do sistema Junos, como o kernel ou o daemon de no-install firewall distribuído (dfwd). Essa interação é eliminada ao proibir que quaisquer rotas nas bases de informações de roteamento (RIBs) de roteamento (RIBs) associadas sejam publicadas a esses componentes.

Nota:

Nas versões anteriores à Versão 15.1 do Junos OS, você pode reduzir a carga de trabalho em um refletor de roteamento que não está no caminho do encaminhamento de tráfego usando uma política de exportação de tabela de encaminhamento que rejeita rotas aprendidas com BGP.

Devido ao requisito de malha BGP interno (IBGP), a maioria das redes usa refletores de roteamento para simplificar a configuração. A fórmula para calcular o número de sessões necessárias para uma malha completa é v * (v - 1)/2, na qual v é o número de dispositivos BGP ativados por BGP. O modelo de malha completa não tem boa escala. Usando um refletor de roteador, você agrupa roteadores em clusters, que são identificados por identificadores numéricos exclusivos do sistema autônomo (AS). Dentro do cluster, você deve configurar uma sessão BGP de um único roteador (o refletor de roteador) para cada peer interno. Com essa configuração, o requisito de malha completa do IBGP é atendido.

Para usar o reflexão de rota em um AS, você designa um ou mais roteadores como um refletor de roteador, normalmente, um por ponto de presença (PoP). Os refletores de roteador têm a BGP de reversão de rotas aprendidas de um peer interno a outros peers internos. Portanto, em vez de exigir que todos os colegas internos sejam totalmente unidos entre si, o reflexão de roteador requer apenas que o refletor de roteador seja totalmente 100% com todos os peers internos. O refletor de roteador e todos os seus peers internos formam um cluster, como mostrado em Figura 1 .

Nota:

Para alguns Juniper Networks, você deve ter uma licença Advanced BGP Recurso instalada em cada dispositivo que use um refletor de roteador. Para obter detalhes da licença, consulte o Guia de Instalação e Atualização de Software.

Figura 1: Topologia de refletor de roteador simples (Um cluster)Topologia de refletor de roteador simples (Um cluster)

Figura 1 mostra o roteador RR configurado como o refletor de rota para Cluster 127. Os outros roteadores são peers internos designados dentro do cluster. BGP rotas são anunciadas ao Roteador RR por qualquer um dos peers internos. Em seguida, RR reverte essas rotas para todos os outros peers do cluster.

Você pode configurar vários clusters e enlace-los configurando uma malha completa de refletores de rota (consulte Figura 2 ).

Figura 2: Reflexão básica de rotear (múltiplos clusters)Reflexão básica de rotear (múltiplos clusters)

Figura 2 mostra os refletores de rota RR 1, RR 2, RR 3 e RR 4 como peers internos totalmente sedados. Quando um roteador anuncia uma rota para RR 1, RR 1 reverte a rota para os outros refletores de rota, o que, por sua vez, reverte a rota para os roteadores restantes dentro do AS. A reflexão de roteamento permite que a rota seja propagada por todo o AS sem os problemas de dimensionamento criados pelo requisito de malha completa.

Nota:

Um refletor de roteador com suporte a vários clusters não aceita uma rota com a mesma ID de cluster de um roteador não cliente. Portanto, você deve configurar uma ID de cluster diferente para um RR redundante para refletir a rota para outros clusters.

Entretanto, conforme os clusters se tornam grandes, uma malha completa com um refletor de rota torna-se difícil de dimensionar, assim como uma malha completa entre refletores de rota. Para ajudar a resolver esse problema, você pode agrupar clusters de roteadores em clusters de clusters para reflexão hierárquica da rota (consulte Figura 3 ).

Figura 3: Reflexão de rota hierárquica (clusters de clusters)Reflexão de rota hierárquica (clusters de clusters)

Figura 3 mostra RR 2, RR 3 e RR 4 como refletores de rota para clusters 127, 19 e 45, respectivamente. Em vez de malhar totalmente esses refletores de roteamento, o administrador de rede os configurou como parte de outro cluster (Cluster 6), no qual RR 1 é o refletor de rotas. Quando um roteador anuncia uma rota para RR 2, RR 2 readverte a rota para todos os roteadores em seu próprio cluster e, em seguida, reverte a rota para RR 1. RR 1 readverte a rota para os roteadores em seu cluster, e esses roteadores propagam a rota por seus clusters.

Exemplo: Configurando um refletor de roteamento

Este exemplo mostra como configurar um refletor de rota.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Em geral, os dispositivos BGP internos habilitados para IBGP precisam ser totalmente habilitados, porque o IBGP não readverte atualizações para outros dispositivos habilitados para IBGP. A malha completa é uma malha lógica conquistada por meio da configuração de várias neighbor declarações em cada dispositivo habilitado para IBGP. A malha completa não é necessariamente uma malha completa física. Manter uma malha completa (lógica ou física) não é uma grande escala em grandes implantações.

Figura 4 mostra uma rede IBGP com o Dispositivo A atuando como um refletor de rota. Os dispositivos B e C são clientes do refletor de rota. Dispositivo D e Dispositivo E estão fora do cluster, portanto, eles são nonclients do refletor de rota.

No dispositivo A (o refletor de roteador), você deve formar relações de peer com todos os dispositivos habilitados por IBGP, incluindo a instrução para os clientes (Dispositivo B e Dispositivo C) e neighbor os nonclients (Dispositivo D e Dispositivo E). Você também deve incluir a cluster instrução e um identificador de cluster. O identificador de cluster pode ser de qualquer valor de 32 bits. Este exemplo usa o endereço IP da interface de loopback do refletor de rota.

No dispositivo B e no dispositivo C, os clientes refletores de roteador, você só precisa de uma declaração que formou uma relação de colegas com o neighbor refletor de rota, o Dispositivo A.

No dispositivo D e no dispositivo E, os nonclients, você precisa de uma instrução para cada dispositivo neighbor nonclient (D-to-E e E-to-D). Você também precisa de neighbor uma instrução para o refletor de rota (D-to-A e E-to-A). O dispositivo D e o dispositivo E não precisam de neighbor declarações para os dispositivos do cliente (Dispositivo B e Dispositivo C).

Dica:

Os dispositivos D e Device E são considerados não-participantes porque configuraram explicitamente relações de colegas entre si. Para torná-los clientes refletores RRroute, remova a instrução da configuração no dispositivo D e remova a instrução da neighbor 192.168.5.5neighbor 192.168.0.1 configuração no Dispositivo E.

Figura 4: Rede IBGP usando um refletor de roteadorRede IBGP usando um refletor de roteador

Configuração

Procedimento

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Dispositivo A

Dispositivo B

Dispositivo C

Dispositivo D

Dispositivo E

Procedimento passo a passo

Configurando o refletor de roteamento

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o IBGP na rede usando Juniper Networks dispositivo A como refletor de roteador:

  1. Configure as interfaces.

  2. Configure BGP, incluindo o identificador de cluster e as relações com todos os dispositivos habilitados por IBGP no sistema autônomo (AS).

    Aplique também a política que redistribui OSPF rotas em BGP.

  3. Configure o roteamento estático ou um protocolo de gateway interior (IGP).

    Este exemplo usa OSPF.

  4. Configure a política que redistribui OSPF rotas em BGP.

  5. Configure a ID do roteador e o número do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Nota:

Repetir essas etapas para cada ponto BGP no cluster que você está configurando, caso os outros dispositivos não-delimitados sejam de Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Configuração de peers de cliente

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar peers de cliente:

  1. Configure as interfaces.

  2. Configure a BGP do vizinho com o refletor de rota.

    Aplique também a política que redistribui OSPF rotas em BGP.

  3. Configure OSPF.

  4. Configure a política que redistribui OSPF rotas em BGP.

  5. Configure a ID do roteador e o número AS.

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Nota:

Repetir essas etapas para cada BGP cliente no cluster configurado caso os outros dispositivos clientes sejam de Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Configuração de peers não-dependentes

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar peers não-dependentes:

  1. Configure as interfaces.

  2. Configure as BGP do vizinho com o refletor RRroute e com os outros colegas não-dependentes.

    Aplique também a política que redistribui OSPF rotas em BGP.

  3. Configure OSPF.

  4. Configure a política que redistribui OSPF rotas em BGP.

  5. Configure a ID do roteador e o número AS.

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Nota:

Repetir essas etapas para cada ponto de BGP no cluster que você está configurando caso os outros dispositivos não-delimitados sejam de Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificar os BGP vizinhos

Propósito

Verifique se BGP está em execução em interfaces configuradas e se a sessão de BGP está estabelecida para cada endereço do vizinho.

Ação

Do modo operacional, insira o show bgp neighbor comando.

Verificar grupos BGP

Propósito

Verificar se os grupos BGP estão configurados corretamente.

Ação

Do modo operacional, insira o show bgp group comando.

Verificar informações BGP resumo

Propósito

Verificar se a configuração BGP da rede está correta.

Ação

Do modo operacional, insira o show bgp summary comando.

Verificar informações da tabela de roteamento

Propósito

Verificar se a tabela de roteamento contém as rotas do IBGP.

Ação

Do modo operacional, insira o show route comando.

Entender um refletor de rota que pertence a dois clusters diferentes

O objetivo da reflexão de roteamento é a prevenção de loop quando os dispositivos de roteamento internos de BGP (IBGP) não estão totalmente conectados. Para isso, os RRs quebram uma das regras da operação BGP normal: Eles revertem rotas aprendidas de um BGP interno para outros BGP internos.

Normalmente, um único RR é um membro de apenas um cluster. Considere, por exemplo, que em um design RR hierárquico, um RR de nível dois pode ser o cliente de um RR de nível 1, mas eles não podem ser clientes um do outro.

Entretanto, quando dois RRs são clientes um do outro e as rotas estão sendo refletidas de um cluster para outro, apenas um dos IDs de cluster está incluído na lista de clusters. Isso ocorre porque, neste caso, ter uma ID de cluster na lista de clusters é adequado para a prevenção de loops.

Tabela 1 sintetiza as regras que os refletores de roteam usam ao preencher a lista de clusters de uma rota refletida com IDs de cluster.

Tabela 1: Regras para refletores de roteador

Cenário de reflexão de rotas

Configuração

Ao refletir uma rota de um dos clientes para um roteador não cliente

cliente -> RR -> não cliente

O RR preencherá a ID de cluster associada a esse cliente na lista de clusters da rota refletida.

Ao refletir uma rota de um roteador não cliente para um roteador cliente

cliente não-cliente -> RR->

O RR preencherá a ID de cluster associada a esse cliente na lista de clusters da rota refletida.

Ao refletir uma rota de um roteador cliente para outro roteador cliente que está em um cluster diferente

client1 -> RR -> client2 (cluster diferente)

O RR preencherá a ID de cluster associada ao cliente1 na lista de clusters antes de refletir a ID do cluster ao cliente2. A ID de cluster associada ao cliente 2 não é adicionada.

Ao refletir uma rota de um roteador cliente para um roteador não cliente que está em um sistema autônomo diferente.

Por exemplo, quando você configura um grupo de nível 2 RR e 2 BGP, um para os clientes RR e o outro para o nível 1 RR, e você está refletindo uma rota de um sistema autônomo para outro sistema autônomo.

cliente -> RR -> não cliente (AS diferente)

O RR não preencherá a lista de clusters com a ID de cluster antes de refletir a rota para o dispositivo não cliente, porque a ID de cluster é específica de um sistema autônomo.

Exemplo: Configurando um refletor de roteamento que pertence a dois clusters diferentes

Este exemplo mostra como configurar um refletor de rota (RRs) que pertence a dois clusters diferentes. Esse não é um cenário comum, mas pode ser útil em algumas situações.

Requisitos

Configure as interfaces de dispositivos e um protocolo de gateway interno (IGP). Para um exemplo de uma configuração RR que inclui a interface e IGP configuração, consulte Exemplo: Configurando um refletor de roteamento.

Visão geral

Neste exemplo, o dispositivo RR1 é um refletor de rota para o dispositivo R2 e o dispositivo RR2. O refletor de roteador RR1 tem dois IDs de cluster diferentes atribuídos, um é 5.5.5.5 para RR1-R2 e 6.6.6 para RR1-RR2.

O dispositivo RR2 é um refletor de rota para o dispositivo R4.

Considere a figura Figura 5 .

Figura 5: Refletor de roteador em dois clusters diferentesRefletor de roteador em dois clusters diferentes

Este exemplo mostra a configuração BGP no dispositivo RR1 e no dispositivo RR2.

Configuração

Procedimento

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Dispositivo RR1

Dispositivo RR2

Configuração do dispositivo RR1

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o dispositivo RR1:

  1. Configure a relação de peering com o dispositivo R2.

  2. Configure a relação de peering com o dispositivo R0.

  3. Configure a relação de peering com o dispositivo RR2.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show protocols comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Configuração do dispositivo RR2

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o dispositivo RR2:

  1. Configure a relação de peering com o dispositivo R4.

  2. Configure a relação de peering com o dispositivo RR1.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show protocols comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação da ID de cluster anunciada para a rota 2.2.2.2

Propósito

Verifique se BGP está em execução em interfaces configuradas e se a sessão de BGP está estabelecida para cada endereço do vizinho.

Ação

Do modo operacional, insira o show route advertising-protocol bgp neighbor-address comando.

Significado

A rota 2.2.2.2/32 é originada do ponto de cliente do dispositivo RR1, o dispositivo R2. Quando essa rota é enviada ao cliente do RR1, o dispositivo RR2, a rota tem o ID de cluster 5.5.5 conectado, que é a ID de cluster para RR1-R2.

Verificação da ID de cluster anunciada para a rota 1.1.1.1

Propósito

Marque o anúncio de rota do dispositivo RR1 ao dispositivo RR2.

Ação

Do modo operacional, insira o show route advertising-protocol bgp neighbor-address comando.

Significado

A rota 1.1.1.1/32 é originada do peer não cliente do Dispositivo RR1, o Dispositivo R0. Quando essa rota é enviada ao cliente do RR1, o dispositivo RR2, a rota tem o ID de cluster 6.6.6 conectado, que é a ID de cluster para RR1-RR2.

O dispositivo RR1 preserva a ID de cluster de entrada do dispositivo RR2 ao anunciar para outro cliente em um cluster diferente (Dispositivo R4).

Compreender a BGP ideal da reflexão de rotas

Você pode configurar BGP Optimal Route Reflection (BGP-ORR) com IS-IS e OSPF como o protocolo de gateway interior (IGP) em um refletor de roteador para anunciar o melhor caminho para os grupos de clientes BGP-ORR. Isso é feito usando a métrica de IGP mais curta da perspectiva de um cliente, em vez da visualização do refletor de roteador.

Grupos de clientes que compartilham a mesma IGP ou similares podem ser agrupados como um BGP peer. Você pode configurar optimal-route-reflection para habilitar BGP-ORR nesse BGP peer group. Você também pode configurar um dos nós do cliente como o nó principal () em um grupo de colegas BGP para que IGP métrica desse nó principal seja usada para selecionar o melhor caminho e anuiá-lo aos clientes no mesmo grupo de BGP igp-primary peer. Opcionalmente, você também pode selecionar outro nó cliente como o nó de backup (), que é usado quando o nó principal () é igp-backupigp-primary inalcançável.

Para habilitar BGP-ORR, inclua a optimal-route-reflection instrução no nível edit protocols bgp group group-name [ ] da hierarquia.

Nota:

BGP-ORR só funciona quando IGP é usado para BGP de roteação. BGP-ORR não funciona quando MPLSLDP/RSVP é usado para a resolução da rota.

Nota:

Para BGP-ORR funcionar, o prefixo BGP deve ser resolvido por meio IGP. Em cenários de VPN de Camada 3 ou VPN de Camada 2, OU VPLS ou MVPN ou EVPN, os prefixos são resolvidos por meio do inet.3. No inet.3, a rota primária para o protocolo-next-hop do prefixo seria RSVP ou LDP ( e não um protocolo IGP como IS-IS ou OSPF). Para BGP-ORR funcionar, você precisa configurar o roteador para usar inet.0 para a resolução de rota de VPN de Camada 3, ou VPN de Camada 2, ou VPLS ou MVPN ou prefixos de EVPN. Você pode fazer isso pelos seguintes comandos:

  • Para prefixo VPN de Camada 3:

  • Para prefixo VPN de Camada 2 ou VPLS:

  • Para prefixo de EVPN:

  • Para prefixo de MVPN:

Outro método é vazar as rotas IGP para inet.3 e torná-las como a rota primária em inet.3.

Use a seguinte hierarquia de CLI para configurar BGP-ORR:

Configurando BGP reflexão de roteamento ideal em um refletor de rotas para anunciar o melhor caminho

Você pode configurar BGP Optimal Route Reflection (BGP-ORR) com IS-IS e OSPF como o protocolo de gateway interior (IGP) em um refletor de roteador para anunciar o melhor caminho para os grupos de clientes BGP-ORR. Isso é feito usando a métrica de IGP mais curta da perspectiva de um cliente, em vez da visualização do refletor de roteador.

Para habilitar BGP-ORR, inclua a optimal-route-reflection instrução no nível edit protocols bgp group group-name [ ] da hierarquia.

Grupos de clientes que compartilham a mesma IGP ou similares podem ser agrupados como um BGP peer. Você pode configurar optimal-route-reflection para habilitar BGP-ORR nesse BGP peer group.

Para configurar BGP-ORR:

  1. Configure a reflexão de rota ideal.
  2. Configure um dos nós do cliente como o nó principal () em um grupo de BGP peer para que IGP métrica desse nó principal seja usada para selecionar o melhor caminho e anuiá-lo aos clientes no mesmo grupo de BGP igp-primary peer.
  3. (Opcional) Configure outro nó cliente como o nó de backup (), que é usado quando o nó principal () é igp-backupigp-primary inalcançável.

Use os seguintes comandos CLI para monitorar e solucionar problemas na configuração BGP-ORR:

  • show bgp group— Veja as configurações primárias e de backup do BGP-ORR.

  • show isis bgp-orr— Veja a métrica IS-IS BGP-ORR (RIB).

  • show ospf bgp-orr— Veja a métrica OSPF BGP-ORR (RIB).

  • show ospf route— Veja as entradas na tabela OSPF roteamento

  • show route— Veja as entradas ativas nas tabelas de roteamento.

  • show route advertising protocol bgp peer— Verificar se as rotas estão sendo anunciadas de acordo com as regras BGP-ORR.

BGP visão geral do servidor de roteia

Um servidor de roteamento BGP é o equivalente externo de BGP (EBGP) de um refletor de roteamento IBGP interno que simplifica o número de sessões EBGP diretas de ponto a ponto necessárias em uma rede. Os servidores de roteamento EBGP são transparentes em termos de propagação de atributo BGP para que uma rota recebida de um servidor de roteamento transporte o conjunto de atributos de BGP (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP e Comunidades) se a rota for de um peer EBGP conectado diretamente.

Assim como com um refletor de roteamento IBGP, um servidor de roteamento EBGP está conectado a uma rede fora do caminho de encaminhamento direto entre os colegas do EBGP usando a funcionalidade do servidor de roteamento. Essa conectividade pode ser por meio de um enlace físico direto, ou por meio de redes de Camada 2, como VPLS LAN ou EVPN, ou por meio de uma malha IP de enlaces EBGP ponto a ponto, fornecendo alcance de endereços de loopback de peers (típicos em redes de data center).

O protocolo BGP é aprimorado para fornecer recursos de servidor de rota com as seguintes funcionalidades descritas no RFC 7947:

  • Atribua transparência para NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP e comunidades.

  • Controle de política por cliente e vários RIBs de servidor de roteamento para mitigar o ocultar o caminho.

BGP programabilidade utiliza a funcionalidade do servidor de rotas. A API BGP JET foi aprimorada para dar suporte à funcionalidade do servidor bgp_route_service.proto de rotear da seguinte forma:

  • Programe o servidor de rota do EBGP.

  • Injete rotas até o servidor de roteamento RIB específico para anuá-la seletivamente para os grupos de clientes em RIBs específicos do cliente.

A API BGP JET inclui um objeto do tipo peer que identifica rotas individuais como bgp_route_service.proto EBGP ou IBGP (padrão).

A funcionalidade do servidor de rotear é geralmente independente da família de endereços, embora determinados recursos específicos de BGP possam ser específicos para a família de endereços (por exemplo, o AIGP só é suportado para famílias de endereços com rótulo unicast). A funcionalidade do servidor de rotear é suportada para todas as famílias de endereços EBGP.

BGP Transparência de atributos

A transparência do atributo EBGP [RFC7947] para o servidor de roteamento é suportada modificando BGP propagação da rota BGP de forma que nem atributos transitivos nem não transitivos sejam despojados ou modificados ao propagar rotas.

As alterações ao comportamento EBGP normal são controladas pela route-server-client configuração de CLI. A configuração de CLI no nível da hierarquia implementa o servidor de route-server-clientedit protocols bgp group group-name rote BGP comportamento de transparência dos atributos.

  • O servidor de rota fornece transparência de atributo para configurações de EBGP de salto único e multi-hop. Portanto, route-server-client a configuração inclui implicitamente a funcionalidade de no-nexthop-change sessões de single-hop e multi-hop. Para sessões de BGP multi-hop, você deve configurar a multihop palavra-chave.

  • A route-server-client configuração pode ser nos níveis de protocolo, grupo ou vizinho da hierarquia edit protocol bgp [ ]

  • A route-server-client configuração só é aplicável quando o tipo de grupo é externo. Quando o está configurado para grupos internos, um erro de configuração route-server-client é emitido ao tentar cometer.

  • A route-server-client configuração não tem parâmetros.

  • O BGP de uso normal se aplica à route-server-client configuração.

Nota:

Os atributos são manuseados independentemente em relação à transparência dos atributos. Mesmo que os next-hops não sejam enviados sem modificação pelo servidor de rota, outros atributos são enviados de maneira transparente, conforme aplicável a esses atributos.

A seguir, uma configuração de route-server-client amostra:

Next-Hop

O atributo next-hop não deve ser modificado impondo o next-hop self ou modificar o next-hop, a menos que esteja configurado explicitamente por meio de uma política. O servidor de rota deve propagar BGP next-hop de acordo com as regras de next-hop de terceiros do RFC 4271.

O comportamento do next-hop é especificado para os seguintes cenários de servidor de rota:

  • No caso da interconexão de LAN e WAN, quando o servidor de roteamento está conectado aos colegas do cliente por meio de uma subnet de LAN e WAN compartilhada, os next-hops de terceiros recebidos são anunciados pelo servidor de roteamento sem modificação conforme definido na RFC 4271.

  • No caso da interconexão multihop de data center, quando o servidor de roteamento está conectado aos colegas do cliente por meio de uma interconexão multihop, o multihop EBGP deve ser configurado e o comportamento da configuração de CLI é implicitamente imposto pela no-nexthop-changeroute-server-client configuração. Os next-hops de terceiros recebidos são anunciados pelo servidor de rota sem modificação, de acordo com o comportamento opcional de terceiros definido em RFC 4271.

  • Em outros casos, como conexões de salto único ponto a ponto entre o servidor de roteamento e os colegas do cliente, os procedimentos de anúncios de next-hop normais são usados para impedir a publicidade de next-hops que podem ser recusadas por peers de BGP (por exemplo, a maioria das implementações BGP, por padrão, rejeita os endereços de next-hop que não são cobertos pelo endereço de sub-rede em sessões não multipoint.

CAMINHO AS

O as-Path não deve ser modificado enquanto se espera o número AS local do servidor de rotas. Configurar route-server-client a CLI para um peer elimina a pré-espera do número AS local nos anúncios. Além disso, o comando CLI é alterado para peers que são clientes de servidor de roteagem, de forma que o AS local não seja mostrado nas show route advertising-protocol bgp peer métricas anunciadas.

Outros atributos

  • MULTI_EXIT_DISC atributo (opcional, não transitivo) deve ser propagado conforme recebido.

  • Todos os atributos da comunidade, incluindo a não publicidade, a não exportação e as comunidades estendidas não transitivas, devem ser propagados conforme recebido.

  • O atributo IGP acumulado (AIGP) (opcional, não transitivo) deve ser propagado conforme recebido.

    Nota:

    O Junos OS aceita AIGP apenas para famílias de BGP-LU (IPv4 e IPv6).

BGP Route Server Client RIB

UMA RIB específica do cliente do servidor de roteio é uma visualização BGP Loc-RIB que pode conter rotas diferentes para o mesmo destino do que outras visualizações. Os clientes do servidor de roteagem, por meio de seus grupos de colegas, podem se associar a uma visualização específica do cliente ou a uma RIB comum compartilhada.

Para oferecer a capacidade de anunciar rotas diferentes para diferentes clientes para o mesmo destino, é conceitualmente necessário permitir que várias instâncias da seleção de caminhos BGP ocorram para o mesmo destino, mas em contextos diferentes de cliente/grupo.

Para implementar o requisito de alto nível de controle de política flexível com a seleção de caminho de cada cliente/grupo, o servidor de roteamento BGP usa a abordagem de usar instâncias de roteamento não encaminhamento (NFIs) para multi-instâncias no pipeline BGP, incluindo BGP seleção de caminhos, Loc-RIB e política. O servidor de roteamento está configurado para agrupar clientes do servidor de roteamento em BGP grupos configurados em instâncias de roteamento não encaminhamento diferentes. Essa abordagem aproveita o fato de BGP executado em uma instância de roteamento faz a seleção do caminho e tem uma RIB separada da BGP em execução em outras instâncias de roteamento.

Requisitos e considerações de políticas

Para propagar rotas entre clientes do servidor de roteamento, as rotas são vazadas entre os RIBs das instâncias de roteamento com base em políticas configuradas.

A configuração do servidor de roteia para controle de políticas inclui as seguintes considerações:

  • Os clientes do servidor de roteamento devem ser configurados na mesma instância primária ou instância de roteamento para receber a mesma visualização Loc-RIB.

  • Os clientes do servidor de roteamento devem ser configurados em sua própria instância de roteamento para receber visualizações loc-RIB totalmente exclusivas.

  • Os clientes do servidor de roteamento devem ser configurados em grupos de BGP diferentes na mesma instância de roteamento para ter uma política de exportação diferente na mesma visualização Loc-RIB.

  • Para que as visualizações RIB específicas do cliente do servidor de roteamento recebam todas as rotas de outras tabelas por padrão, uma malha completa de políticas instance-import está configurada com instance-any . Ao configurar com instance-import a política instance-any contendo:

    • instance-any podem ser usadas em:

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-any não tem parâmetros.

    • Usar instance-any em políticas que não tenha efeito instance-import algum.

  • Configurar várias instâncias de roteamento e grupos de colegas diferentes afeta a escala e o desempenho.

  • A BGP de CLI no nível da hierarquia divide a instância de roteamento de um BGP em uma instância de configuração e forwarding-contextedit protocols bgp group neighbor de encaminhamento. A configuração de CLI da BGP também tem suporte para instâncias de não encaminhamento com BGP peers configurados como se a instância especificada fosse capaz de encaminhamento de uma instância primária ou de roteamento que não seja do tipo sem forwarding-contextroute-server-client encaminhamento.

Tabela de histórico de liberação
Versão
Descrição
15.1
A partir da versão 15.1 do Junos OS, a declaração elimina a interação entre os protocolos de roteamento (rpd) e outros componentes do sistema Junos, como o kernel ou o daemon de no-install firewall distribuído (dfwd).
15.1
Nas versões anteriores à Versão 15.1 do Junos OS, você pode reduzir a carga de trabalho em um refletor de roteamento que não está no caminho do encaminhamento de tráfego usando uma política de exportação de tabela de encaminhamento que rejeita rotas aprendidas com BGP.