Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Refletores de rota BGP

Entendendo os refletores de rota BGP

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

Nota:

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

Devido ao requisito interno de malha completa bgp (IBGP), a maioria das redes usa refletores de rota 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, onde v é o número de dispositivos habilitados para BGP. O modelo de malha completa não escala bem. Usando um refletor de rota, 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 rota) para cada peer interno. Com essa configuração, o requisito de malha completa do IBGP é atendido.

Para usar a reflexão de rota em um AS, você designa um ou mais roteadores como um refletor de rota — normalmente, um por ponto de presença (POP). Os refletores de rota têm a capacidade BGP especial de readvertisar rotas aprendidas de um peer interno para outros pares internos. Assim, em vez de exigir que todos os pares internos sejam totalmente conectados entre si, a reflexão de rota requer apenas que o refletor de rota seja totalmente combinado com todos os pares internos. O refletor de rota e todos os seus pares internos formam um cluster, como mostrado em Figura 1.

Nota:

Para alguns dispositivos da Juniper Networks, você deve ter uma licença Advanced BGP Feature instalada em cada dispositivo que use um refletor de rota. Para obter mais informações sobre a licença, veja o guia de instalação e atualização de software.

Figura 1: Topologia de refletor de rota simples (um cluster)Topologia de refletor de rota simples (um cluster)

Figura 1 mostra o Roteador RR configurado como o refletor de rota para o Cluster 127. Os outros roteadores são designados pares internos dentro do cluster. As rotas BGP são anunciadas ao Roteador RR por qualquer um dos pares internos. RR então readverte essas rotas para todos os outros pares dentro do cluster.

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

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

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

Nota:

Um refletor de rota que oferece 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 um ID de cluster diferente para uma RR redundante para refletir a rota para outros clusters.

No entanto, à medida que os clusters se tornam grandes, uma malha completa com um refletor de rota torna-se difícil de escalar, assim como uma malha completa entre refletores de rota. Para ajudar a compensar esse problema, você pode agrupar clusters de roteadores em clusters de clusters para reflexão de rota hierárquica (ver 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 rota, o administrador de rede os configurou como parte de outro cluster (Cluster 6) para o qual RR 1 é o refletor de rota. Quando um roteador anuncia uma rota para RR 2, a RR 2 readverte a rota para todos os roteadores dentro de seu próprio cluster e, em seguida, readverte a rota para RR 1. RR 1 readverte a rota para os roteadores em seu cluster, e esses roteadores propagam a rota para baixo através de seus clusters.

Exemplo: Configuração de um refletor de rotas

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

Geralmente, os dispositivos internos habilitados para BGP (IBGP) precisam estar totalmente conectados, pois o IBGP não readverte atualizações para outros dispositivos habilitados para IBGP. A malha completa é uma malha lógica alcançada 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 escala bem em grandes implantações.

Figura 4 mostra uma rede IBGP com o Dispositivo A atuando como um refletor de rota. O dispositivo B e o Dispositivo C são clientes do refletor de rota. O dispositivo D e o Dispositivo E estão fora do cluster, por isso não sãoclientes do refletor de rota.

No Dispositivo A (o refletor de rota), você deve formar relações entre pares com todos os dispositivos habilitados para IBGP, incluindo a neighbor declaração para os clientes (Dispositivo B e Dispositivo C) e os nãoclientes (Dispositivo D e Dispositivo E). Você também deve incluir a cluster declaração e um identificador de cluster. O identificador de cluster pode ter 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 rota, você só precisa de uma neighbor declaração que forme uma relação de peer com o refletor de rota, Dispositivo A.

No Dispositivo D e no Dispositivo E, os não-clientes, você precisa de uma neighbor declaração para cada dispositivo nãocliente (D-to-E e E-to-D). Você também precisa de uma neighbor declaraçã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 clientes (Dispositivo B e Dispositivo C).

Dica:

O dispositivo D e o Dispositivo E são considerados nãoclientes porque configuraram explicitamente as relações entre pares entre si. Para torná-los clientes refletores RRroute, remova a neighbor 192.168.5.5 declaração da configuração no Dispositivo D e remova a neighbor 192.168.0.1 declaração da configuração no Dispositivo E.

Figura 4: Rede IBGP usando um refletor de rotasRede IBGP usando um refletor de rotas

Configuração

Procedimento

Configuração rápida da CLI

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

Dispositivo A

Dispositivo B

Dispositivo C

Dispositivo D

Dispositivo E

Procedimento passo a passo

Configurando o refletor de rota

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar o IBGP na rede usando o Dispositivo A da Juniper Networks como refletor de rota:

  1. Configure as interfaces.

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

    Aplique também a política que redistribui as rotas de OSPF para o 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 as rotas DEPF para o 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 entrando noshow interfaces, show protocolsshow policy-optionse show routing-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Nota:

Repita essas etapas para cada peer BGP nãocliente dentro do cluster que você está configurando, se os outros dispositivos nãoclientes forem da Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Configuração de pares de clientes

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar os pares de clientes:

  1. Configure as interfaces.

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

    Aplique também a política que redistribui as rotas de OSPF para o BGP.

  3. Configure OSPF.

  4. Configure a política que redistribui as rotas DEPF para o BGP.

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

Resultados

A partir do modo de configuração, confirme sua configuração entrando noshow interfaces, show protocolsshow policy-optionse show routing-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Nota:

Repita essas etapas para cada peer BGP do cliente dentro do cluster que você está configurando se os outros dispositivos clientes forem da Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Configuração de peers não-clientes

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar pares nãoclientes:

  1. Configure as interfaces.

  2. Configure as relações de vizinhos BGP com o refletor RRroute e com os outros pares nãoclientes.

    Aplique também a política que redistribui as rotas de OSPF para o BGP.

  3. Configure OSPF.

  4. Configure a política que redistribui as rotas DEPF para o BGP.

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

Resultados

A partir do modo de configuração, confirme sua configuração entrando noshow interfaces, show protocolsshow policy-optionse show routing-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Nota:

Repita essas etapas para cada peer BGP nãocliente dentro do cluster que você está configurando se os outros dispositivos nãoclientes forem da Juniper Networks. Caso contrário, consulte a documentação do dispositivo para obter instruções.

Verificação

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

Verificação de vizinhos BGP

Propósito

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

Ação

A partir do modo operacional, entre no show bgp neighbor comando.

Verificação de grupos BGP

Propósito

Verifique se os grupos BGP estão configurados corretamente.

Ação

A partir do modo operacional, entre no show bgp group comando.

Verificando as informações do resumo do BGP

Propósito

Verifique se a configuração do BGP está correta.

Ação

A partir do modo operacional, entre no show bgp summary comando.

Verificando as informações da tabela de roteamento

Propósito

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

Ação

A partir do modo operacional, entre no show route comando.

Entendendo um refletor de rotas que pertence a dois clusters diferentes

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

Normalmente, uma única RR é um membro de apenas um cluster. Considere, por exemplo, que em um design de 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.

No entanto, 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 porque ter uma ID de cluster na lista de clusters é adequado para a prevenção de loops neste caso.

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

Tabela 1: Regras para refletores de rota

Cenário de reflexão de rotas

Configuração

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

cliente -> RR -> não cliente

A RR preenche o ID de cluster associado a esse cliente na lista de clusters da rota refletida.

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

cliente não cliente -> RR ->

A RR preenche o ID de cluster associado 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

cliente1 -> RR -> cliente2 (cluster diferente)

A RR preenche o ID de cluster associado ao cliente1 na lista de clusters antes de refletir o ID do cluster para o cliente2. O ID de cluster associado ao cliente 2 não foi adicionado.

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

Por exemplo, quando você configurou um nível 2 RR e 2 grupos BGP, um para os clientes RR e 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)

A RR não preenche a lista de clusters com o ID de cluster antes de refletir a rota para o dispositivo não cliente porque o cluster ID é específico para um sistema autônomo.

Exemplo: Configuração de um refletor de rota que pertence a dois clusters diferentes

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

Requisitos

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

Visão geral

Neste exemplo, o Dispositivo RR1 é um refletor de rota para o Dispositivo R3 e o Dispositivo RR2. O refletor de rota RR1 tem dois IDs de cluster diferentes atribuídos, um é de 5,5,5,5 para RR1-R3 e 6,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 rotas em dois clusters diferentesRefletor de rotas em dois clusters diferentes

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

Configuração

Procedimento

Configuração rápida da CLI

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

RR1 do dispositivo

RR2 do dispositivo

Configuração do dispositivo RR1

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar o dispositivo RR1:

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

  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 entrando no show protocols comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Configuração do dispositivo RR2

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

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 entrando no show protocols comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

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

Verificando o ID do cluster anunciado para a Rota 10.3.3.3

Propósito

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

Ação

A partir do modo operacional, entre no show route advertising-protocol bgp neighbor-address comando.

Significado

Dia 10.3.3.A rota 3/32 é originária do peer cliente do dispositivo RR1, Dispositivo R3. Quando essa rota é enviada ao cliente do RR1, o Dispositivo RR2, a rota tem a 10.Dia 13.1.3 ID de cluster conectado, que é o ID de cluster para RR1-R3.

Verificando o ID de cluster anunciado para a rota 10.1.0,1

Propósito

Verifique o anúncio de rota do dispositivo RR1 para o dispositivo RR2.

Ação

A partir do modo operacional, entre no show route advertising-protocol bgp neighbor-address comando.

Significado

O 10.1.A rota 0.1/32 se origina do dispositivo RR1 não cliente peer, Dispositivo R0. Quando essa rota é enviada ao cliente do RR1, o Dispositivo RR2, a rota tem a 10.Dia 12.1.2 ID de cluster conectado, que é o ID de cluster para RR1-RR2.

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

Entender a reflexão ideal da rota DO BGP

Você pode configurar o BGP Optimal Route Reflection (BGP-ORR) com IS-IS e OSPF como protocolo de gateway interior (IGP) em um refletor de rota 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 visão do refletor de rota.

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

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

Nota:

O BGP-ORR só funciona quando o IGP é usado para resolução de rotas BGP. O BGP-ORR não funciona quando o MPLSLDP/RSVP é usado para resolução de rotas.

Nota:

Para que o BGP-ORR funcione, o prefixo BGP deve ser resolvido por meio do IGP. Em VPN de Camada 3 normal, ou VPN de Camada 2, ou VPLS, ou MVPN, ou cenários EVPN, os prefixos são resolvidos em inet.3. No inet.3, a rota primária para o protocolo de próximo salto do prefixo seria RSVP ou LDP ( e não um protocolo IGP como IS-IS ou OSPF). Para que o BGP-ORR funcione, 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 EVPN. Você pode fazer isso através dos seguintes comandos:

  • Para o prefixo VPN de Camada 3:

  • Para VPN de camada 2 ou prefixo VPLS:

  • Para prefixo EVPN:

  • Para prefixo MVPN:

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

Use a hierarquia CLI a seguir para configurar o BGP-ORR:

Configuração da reflexão de rota ideal do BGP em um refletor de rotas para anunciar o melhor caminho

Você pode configurar o BGP Optimal Route Reflection (BGP-ORR) com IS-IS e OSPF como protocolo de gateway interior (IGP) em um refletor de rota 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 visão do refletor de rota.

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

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

Para configurar o BGP-ORR:

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

Use os seguintes comandos CLI para monitorar e solucionar problemas da configuração para 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 BGP-ORR (RIB) do OSPF.

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

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

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

Visão geral do servidor de rota BGP

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

Como acontece com um refletor de rota IBGP, um servidor de rota EBGP é anexado a uma rede fora do caminho de encaminhamento direto entre os pares de EBGP usando a funcionalidade do servidor de rota. Essa conectividade pode ser por meio de um link físico direto, ou por redes de Camada 2, como VPLS LAN ou EVPN, ou por meio de uma malha IP de links EBGP ponto a ponto que oferecem acessibilidade de endereços de loopback de pares (típicos em redes de data center).

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

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

  • Controle de políticas por cliente e várias RIBs de servidor de roteamento para mitigação da ocultação de caminhos.

A programabilidade BGP aproveita a funcionalidade do servidor de roteamento. A API BGP JET bgp_route_service.proto foi aprimorada para oferecer suporte à funcionalidade do servidor de rota da seguinte forma:

  • Programe o servidor de rotas EBGP.

  • Injete rotas no servidor de rota específico RIB para anunciar seletivamente os grupos de clientes em RIBs específicas do cliente.

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

A funcionalidade do servidor de roteamento geralmente é independente da família de endereços, embora certos suportes específicos de atributo BGP possam ser específicos para a família de endereços (por exemplo, o AIGP só é suportado para famílias de endereços unicast rotulados). A funcionalidade do servidor de roteamento é suportada para todas as famílias de endereços EBGP.

Transparência de atributos BGP

A transparência de atributos EBGP [RFC7947] para o servidor de rota é suportada modificando a propagação normal da rota BGP de modo que nem atributos transitivos nem não transitivos sejam despojados ou modificados durante a propagação de rotas.

Alterações no comportamento normal de EBGP são controladas pela route-server-client configuração CLI. A route-server-client configuração da CLI no nível [edit protocols bgp group group-nameda hierarquia] implementa o comportamento de transparência do atributo BGP do servidor de roteamento.

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

  • Ela route-server-client pode ser configurada nos níveis de protocolo, grupo ou vizinho da [edit protocol bgp] hierarquia.

  • A route-server-client configuração só é aplicável quando o tipo de grupo é external. Quando a route-server-client configuração é para internal grupos, um erro de configuração é emitido ao tentar se comprometer.

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

  • O privilégio BGP normal se aplica à route-server-client configuração.

Nota:

Os atributos são tratados de forma independente em relação à transparência de atributos. Mesmo que os próximos saltos não possam ser enviados sem sermodificados pelo servidor de rota, outros atributos são enviados de forma transparente conforme aplicável a esses atributos.

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

Próximo salto

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

O comportamento do próximo salto é especificado para os seguintes cenários de servidor de rota:

  • No caso da interconexão de LAN e WAN, quando o servidor de rota é conectado aos pares do cliente por meio de uma sub-rede DE LAN e WAN compartilhada, os próximos saltos recebidos de terceiros são anunciados pelo servidor de rota sem modificação conforme definido no RFC 4271.

  • No caso da interconexão multihop de data center, quando o servidor de rota é conectado aos pares do cliente por meio de uma interconexão multihop, o multihop EBGP deve ser configurado e o comportamento da configuração da no-nexthop-change CLI é implícito imposto pela route-server-client configuração. Os próximos saltos de terceiros recebidos são anunciados pelo servidor de rota sem modificação, de acordo com o comportamento opcional de terceiros definido na RFC 4271.

  • Em outros casos, como conexões single-hop ponto a ponto entre o servidor de rota e os pares do cliente, procedimentos normais de anúncio de próximo salto são usados para evitar que a publicidade de próximo salto possa ser recusada pelos pares BGP (por exemplo, a maioria das implementações BGP, por padrão, rejeita endereços de próximo salto que não são cobertos pelo endereço da sub-rede em sessões não multipontas.

AS-Path

O AS-Path não deve ser modificado preparando o número DE local do servidor de rota. A configuração route-server-client da CLI para um peer suprime o preparatório do número de AS local nos anúncios. Além disso, o show route advertising-protocol bgp peer comando CLI é alterado para pares que são clientes de servidor de rota de forma que o AS local não seja mostrado nas métricas anunciadas.

Outros atributos

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

  • Todos os atributos da comunidade, incluindo comunidades estendidas sem publicidade, sem exportação e 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 oferece suporte a AIGP apenas para famílias de endereços BGP-LU (IPv4 e IPv6).

BGP Route Server Client RIB

Uma RIB específica do cliente do servidor de roteamento é uma visão distinta de um BGP Loc-RIB que pode conter rotas diferentes para o mesmo destino do que outras visualizações. Os clientes de servidor de roteamento, por meio de seus grupos de pares, podem associar-se a uma visão específica do cliente individual 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 caminho BGP ocorram para o mesmo destino, mas em contextos diferentes de cliente/grupo.

Para implementar o requisito de alto nível de controle flexível de políticas com seleção de caminho por cliente/grupo, o servidor de rota BGP adota a abordagem de usar instâncias de roteamento não encaminhamento (NFIs) para multi instâncias do pipeline BGP, incluindo a seleção de caminhos BGP, Loc-RIB e política. O servidor de rota é configurado para agrupar clientes de servidores de rota dentro de grupos BGP configurados em instâncias separadas de roteamento sem encaminhamento. Essa abordagem aproveita o fato de que o BGP em execução em uma instância de roteamento faz a seleção de caminhos e tem uma RIB separada do BGP executado em outras instâncias de roteamento.

Requisitos e considerações de políticas

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

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

  • Os clientes de 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 de servidor de rota devem ser configurados em sua própria instância de roteamento para receber visualizações Loc-RIB totalmente exclusivas.

  • Os clientes de servidor de roteamento devem ser configurados em diferentes grupos de peer BGP na mesma instância de roteamento para terem políticas de exportação diferentes na mesma visão Loc-RIB.

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

    • instance-any pode ser usado 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 diferentes de instance-import não surtir efeito.

  • Configurar muitas instâncias de roteamento distintas e grupos de pares afeta a escala e o desempenho.

  • A configuração do BGP forwarding-context CLI no nível de hierarquia divideedit protocols bgp group neighbor a instância de roteamento para um vizinho BGP em uma instância de configuração e uma instância de encaminhamento. A configuração do BGP forwarding-context CLI também oferece suporte a instâncias de não encaminhamento com pares BGP configurados como route-server-client onde a instância especificada é qualquer instância capaz de encaminhar uma instância primária ou de roteamento que não seja do tipo sem encaminhamento.

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
15.1
A partir do Junos OS Release 15.1, a declaração elimina a no-install interação entre o daemon de protocolos de roteamento (rpd) e outros componentes do sistema Junos, como o kernel ou o daemon de firewall distribuído (dfwd).
15.1
Em versões anteriores ao Junos OS Release 15.1, você pode reduzir a carga de trabalho em um refletor de rota que não está no caminho de encaminhamento de tráfego usando uma política de exportação de tabela de encaminhamento que rejeita as rotas aprendidas com o BGP.