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.
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.
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 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 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.
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 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.
Consulte também
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).
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.
Configuração
- Procedimento
- Configurando o refletor de rota
- Configuração de pares de clientes
- Configuração de peers não-clientes
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
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
Dispositivo B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
Dispositivo C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
Dispositivo D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
Dispositivo E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
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:
Configure as interfaces.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
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.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
Configure o roteamento estático ou um protocolo de gateway interior (IGP).
Este exemplo usa OSPF.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
Configure a política que redistribui as rotas DEPF para o BGP.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Configure a ID do roteador e o número do sistema autônomo (AS).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
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.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
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:
Configure as interfaces.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
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.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
Configure a política que redistribui as rotas DEPF para o BGP.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
Configure a ID do roteador e o número AS.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
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.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
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:
Configure as interfaces.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
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.
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
Configure a política que redistribui as rotas DEPF para o BGP.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
Configure a ID do roteador e o número AS.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
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.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
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
- Verificação de grupos BGP
- Verificando as informações do resumo do BGP
- Verificando as informações da tabela de roteamento
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.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0Verificaçã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.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
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.
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
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.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecvEntendendo 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.
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. |
Consulte também
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.
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
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
RR2 do dispositivo
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
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:
-
Configure a relação de peering com o dispositivo R3.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
Configure a relação de peering com o Dispositivo R0.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
Configure a relação de peering com o Dispositivo RR2.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
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.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 10.13.1.3;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 10.12.1.2;
neighbor 192.168.40.1;
}
}
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:
-
Configure a relação de peering com o dispositivo R4.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
Configure a relação de peering com o Dispositivo RR1.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
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.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 10.24.2.4;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
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
- Verificando o ID de cluster anunciado para a rota 10.1.0,1
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.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.3.3.3/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.13.1.3
Originator ID: 192.168.48.1
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.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.1.0.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.12.1.2
Originator ID: 192.168.16.1Significado
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.
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.
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:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
Para VPN de camada 2 ou prefixo VPLS:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
Para prefixo EVPN:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
Para prefixo MVPN:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
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:
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
Consulte também
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:
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 OSPFshow 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.
Consulte também
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
- Próximo salto
- AS-Path
- Outros atributos
- BGP Route Server Client RIB
- Requisitos e considerações de políticas
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-clientconfiguração inclui implicitamente a funcionalidade deno-nexthop-changesessões de single-hop e multi-hop. Para sessões BGP multi-hop, você deve configurar amultihoppalavra-chave.Ela
route-server-clientpode ser configurada nos níveis de protocolo, grupo ou vizinho da [edit protocol bgp] hierarquia.A
route-server-clientconfiguração só é aplicável quando o tipo de grupo é external. Quando aroute-server-clientconfiguração é para internal grupos, um erro de configuração é emitido ao tentar se comprometer.A
route-server-clientconfiguração não tem parâmetros.O privilégio BGP normal se aplica à
route-server-clientconfiguração.
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 :
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
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-changeCLI é implícito imposto pelaroute-server-clientconfiguraçã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-importpolíticas é configurada cominstance-any. Ao configurarinstance-importcom a política que contéminstance-any:instance-anypode ser usado em:policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anynão tem parâmetros.Usar
instance-anyem políticas diferentes deinstance-importnã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-contextCLI no nível de hierarquia divideedit protocols bgp group neighbora 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 BGPforwarding-contextCLI também oferece suporte a instâncias de não encaminhamento com pares BGP configurados comoroute-server-clientonde 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.
Consulte também
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.
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).