Nesta página
Example: Aplicar políticas de roteamento em diferentes níveis da hierarquia BGP
Configuração de políticas de roteamento para controlar anúncios de rotas BGP
Example: Configuração da filtragem de rotas de saída baseada em prefixo BGP
Entendendo a política padrão de roteamento BGP em roteadores de transporte de pacotes (Série PTX)
Anúncio condicional que permite a instalação condicional de casos de uso de prefixos
Filtro implícito para o comportamento padrão de propagação de rotas de EBGP sem políticas
Políticas básicas de roteamento BGP
Entender as políticas de roteamento
Cada política de roteamento é identificada por um nome de política. O nome pode conter letras, números e hífens (-) e pode ter até 255 caracteres de comprimento. Para incluir espaços no nome, inclua todo o nome em marcas de cotação dupla. Cada nome da política de roteamento deve ser único dentro de uma configuração.
Uma vez criada e nomeada uma política, ela deve ser aplicada antes de estar ativa. Você aplica políticas de roteamento usando as import e export declarações no nível da protocols protocol-name hierarquia de configuração.
import Na declaração, você lista o nome da política de roteamento a ser avaliado quando as rotas são importadas para a tabela de roteamento a partir do protocolo de roteamento.
export Na declaração, você lista o nome da política de roteamento a ser avaliado quando as rotas estão sendo exportadas da tabela de roteamento para um protocolo de roteamento dinâmico. Somente rotas ativas são exportadas da tabela de roteamento.
Para especificar mais de uma política e criar uma cadeia de políticas, você lista as políticas usando um espaço como um separador. Se várias políticas forem especificadas, as políticas serão avaliadas na ordem em que são especificadas. Assim que uma ação de aceitação ou rejeição é executada, a avaliação da cadeia de políticas termina.
Consulte também
Example: Aplicar políticas de roteamento em diferentes níveis da hierarquia BGP
Este exemplo mostra o BGP configurado em uma topologia de rede simples e explica como as polícias de roteamento fazem efeito quando são aplicadas em diferentes níveis da configuração BGP.
Requisitos
Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.
Visão geral
Para BGP, você pode aplicar políticas da seguinte forma:
BGP global
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp]hierarquia (para instâncias de roteamento, inclua essas declarações no nível da[edit routing-instances routing-instance-name protocols bgp]hierarquia).Grupo
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp group group-name]hierarquia (para instâncias de roteamento, inclua essas declarações no nível da[edit routing-instances routing-instance-name protocols bgp group group-name]hierarquia).Peer
importandexportstatements — Inclua essas declarações no nível de[edit protocols bgp group group-name neighbor address]hierarquia (para instâncias de roteamento, inclua essas declarações no nível de[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]hierarquia).
Uma declaração ou export nível import peer substitui um grupo import ou export declaração. Um nível import de grupo ou export declaração substitui um BGP import ou export declaração global.
Neste exemplo, uma política nomeada send-direct é aplicada em nível global, outra política nomeada send-192.168.0.1 é aplicada no nível do grupo, e uma terceira política nomeada send-192.168.20.1 é aplicada no nível vizinho.
user@host# show protocols
bgp {
local-address 172.16.1.1;
export send-direct;
group internal-peers {
type internal;
export send-192.168.0.1;
neighbor 172.16.2.2 {
export send-192.168.20.1;
}
neighbor 172.16.3.3;
}
group other-group {
type internal;
neighbor 172.16.4.4;
}
}
Um ponto-chave, e que muitas vezes é mal compreendido e que pode levar a problemas, é que, em tal configuração, apenas a política mais explícita é aplicada. Uma política de nível vizinho é mais explícita do que uma política de nível de grupo, que por sua vez é mais explícita do que uma política global.
O vizinho 172.16.2.2 está sujeito apenas à política de envio-192.168.20.1. O vizinho 172.16.3.3, sem nada mais específico, está sujeito apenas à política de envio-192.168.0.1. Enquanto isso, o vizinho 172.16.4.4 no grupo de outro grupo não tem política de grupo ou nível vizinho, por isso usa a política de envio direto.
Se você precisar ter o vizinho 172.16.2.2.2 executando a função de todas as três políticas, você pode escrever e aplicar uma nova política de nível vizinho que engloba as funções dos outros três, ou você pode aplicar todas as três políticas existentes, como uma cadeia, ao vizinho 172.16.2.2.
Topologia
Figura 1 mostra a rede de amostra.
Configuração rápida da CLI mostra a configuração para todos os dispositivos em Figura 1.
A seção #d186e203__d186e457 descreve as etapas do dispositivo R1.
Cópia de
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
Dispositivo R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set protocols bgp local-address 172.16.1.1 set protocols bgp export send-direct set protocols bgp group internal-peers type internal set protocols bgp group internal-peers export send-static-192.168.0 set protocols bgp group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group other-group type internal set protocols bgp group other-group neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static-192.168.0 term 1 from protocol static set policy-options policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger set policy-options policy-statement send-static-192.168.0 term 1 then accept set policy-options policy-statement send-static-192.168.20 term 1 from protocol static set policy-options policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger set policy-options policy-statement send-static-192.168.20 term 1 then accept set routing-options static route 192.168.0.1/32 discard set routing-options static route 192.168.20.1/32 discard set routing-options router-id 172.16.1.1 set routing-options autonomous-system 17
Dispositivo R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.10.10.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.5/30 set interfaces lo0 unit 0 family inet address 172.16.2.2/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-options router-id 172.16.2.2 set routing-options autonomous-system 17
Dispositivo R3
set interfaces fe-1/2/1 unit 0 description to-R2 set interfaces fe-1/2/1 unit 0 family inet address 10.10.10.6/30 set interfaces fe-1/2/2 unit 0 description to-R4 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.9/30 set interfaces lo0 unit 0 family inet address 172.16.3.3/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.3.3 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.4.4 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.3.3 set routing-options autonomous-system 17
Dispositivo R4
set interfaces fe-1/2/2 unit 0 description to-R3 set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.10/30 set interfaces lo0 unit 0 family inet address 172.16.4.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 172.16.4.4 set protocols bgp group internal-peers neighbor 172.16.2.2 set protocols bgp group internal-peers neighbor 172.16.1.1 set protocols bgp group internal-peers neighbor 172.16.3.3 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set routing-options router-id 172.16.4.4 set routing-options autonomous-system 17
Procedimento
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 pela CLI, consulte o uso do Editor de CLI no modo de configuração no guia de usuário da CLI.
Para configurar uma política de rota padrão IS-IS:
Configure as interfaces do dispositivo.
[edit interfaces] user@R1# set fe-1/2/0 unit 0 description to-R2 user@R1# set fe-1/2/0 unit 0 family inet address 10.10.10.1/30 user@R1# set lo0 unit 0 family inet address 172.16.1.1/32
Habilite o OSPF, ou outro protocolo de gateway interno (IGP), nas interfaces.
[edit protocols OSPF area 0.0.0.0] user@R1# set interface lo0.0 passive user@R1# set interface fe-1/2/0.0
Configure rotas estáticas.
[edit routing-options] user@R1# set static route 192.168.0.1/32 discard user@R1# set static route 192.168.20.1/32 discard
Habilite as políticas de roteamento.
[edit protocols policy-options] user@R1# set policy-statement send-direct term 1 from protocol direct user@R1# set policy-statement send-direct term 1 then accept user@R1# set policy-statement send-static-192.168.0 term 1 from protocol static user@R1# set policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24 orlonger user@R1# set policy-statement send-static-192.168.0 term 1 then accept user@R1# set policy-statement send-static-192.168.20 term 1 from protocol static user@R1# set policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24 orlonger user@R1# set policy-statement send-static-192.168.20 term 1 then accept
Configure o BGP e aplique as políticas de exportação.
[edit protocols bgp] user@R1# set local-address 172.16.1.1 user@R1# set protocols bgp export send-direct user@R1# set group internal-peers type internal user@R1# set group internal-peers export send-static-192.168.0 user@R1# set group internal-peers neighbor 172.16.2.2 export send-static-192.168.20 user@R1# set group internal-peers neighbor 172.16.3.3 user@R1# set group other-group type internal user@R1# set group other-group neighbor 172.16.4.4
Configure o número de ID e sistema autônomo (AS) do roteador.
[edit routing-options] user@R1# set router-id 172.16.1.1 user@R1# set autonomous-system 17
Se você terminar de configurar o dispositivo, comprometa a configuração.
[edit] user@R1# commit
Resultados
A partir do modo de configuração, confirme sua configuração emitindo os show interfaces, show protocolse show policy-optionsshow 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@R1# show interfaces
fe-1/2/0 {
unit 0 {
description to-R2;
family inet {
address 10.10.10.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
}
}
}
user@R1# show protocols
bgp {
local-address 172.16.1.1;
export send-direct;
group internal-peers {
type internal;
export send-static-192.168.0;
neighbor 172.16.2.2 {
export send-static-192.168.20;
}
neighbor 172.16.3.3;
}
group other-group {
type internal;
neighbor 172.16.4.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fe-1/2/0.0;
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement send-static-192.168.0 {
term 1 {
from {
protocol static;
route-filter 192.168.0.0/24 orlonger;
}
then accept;
}
}
policy-statement send-static-192.168.20 {
term 1 {
from {
protocol static;
route-filter 192.168.20.0/24 orlonger;
}
then accept;
}
}
user@R1# show routing-options
static {
route 192.168.0.1/32 discard;
route 192.168.20.1/32 discard;
}
router-id 172.16.1.1;
autonomous-system 17;
Verificação
Confirme que a configuração está funcionando corretamente.
Verificando o aprendizado de rotas BGP
Propósito
Certifique-se de que as políticas de exportação BGP estejam funcionando como esperado verificando as tabelas de roteamento.
Ação
user@R1> show route protocol direct
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[Direct/0] 1d 22:19:47
> via lo0.0
10.10.10.0/30 *[Direct/0] 1d 22:19:47
> via fe-1/2/0.0
user@R1> show route protocol static
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.1/32 *[Static/5] 02:20:03
Discard
192.168.20.1/32 *[Static/5] 02:20:03
Discarduser@R2> show route protocol bgp
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.20.1/32 *[BGP/170] 02:02:40, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.1 via fe-1/2/0.0user@R3> show route protocol bgp
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.1/32 *[BGP/170] 02:02:51, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.5 via fe-1/2/1.0user@R4> show route protocol bgp
inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.9 via fe-1/2/2.0
10.10.10.0/30 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.9 via fe-1/2/2.0Significado
No dispositivo R1, o show route protocol direct comando exibe duas rotas diretas: 172,16,1,1/32 e 10,10,10,0/30. O show route protocol static comando exibe duas rotas estáticas: 192.168.0.1/32 e 192.168.20.1/32.
No dispositivo R2, o show route protocol bgp comando mostra que a única rota que o Dispositivo R2 aprendeu através do BGP é a rota 192.168.20.1/32.
No dispositivo R3, o show route protocol bgp comando mostra que a única rota que o dispositivo R3 aprendeu através do BGP é a rota 192.168.0.1/32.
No dispositivo R4, o show route protocol bgp comando mostra que as únicas rotas que o dispositivo R4 aprendeu através do BGP são as rotas 172.16.1.1/32 e 10.10.10.0/30.
Verificando o recebimento de rotas BGP
Propósito
Certifique-se de que as políticas de exportação bgp estão funcionando como esperado verificando as rotas BGP recebidas do Dispositivo R1.
Ação
user@R2> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.20.1/32 172.16.1.1 100 I
user@R3> show route receive-protocol bgp 172.16.1.1 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.0.1/32 172.16.1.1 100 I
user@R4> show route receive-protocol bgp 172.16.1.1 inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.1.1/32 172.16.1.1 100 I 10.10.10.0/30 172.16.1.1 100 I
Significado
No dispositivo R2, o comando mostra que o route receive-protocol bgp 172.16.1.1 dispositivo R2 recebeu apenas uma rota BGP, 192.168.20.1/32, do dispositivo R1.
No dispositivo R3, o comando mostra que o route receive-protocol bgp 172.16.1.1 dispositivo R3 recebeu apenas uma rota BGP, 192.168.0.1/32, do dispositivo R1.
No dispositivo R4, o comando mostra que o route receive-protocol bgp 172.16.1.1 dispositivo R4 recebeu duas rotas BGP, 172.16.1.1/32 e 10.10.10.0/30, do dispositivo R1.
Resumindo, quando várias políticas são aplicadas em diferentes hierarquias de CLI no BGP, apenas a aplicação mais específica é avaliada, para a exclusão de outras aplicações de políticas menos específicas. Embora este ponto pareça fazer sentido, ele é facilmente esquecido durante a configuração do roteador, quando você acredita erroneamente que uma política de nível vizinho é combinada com uma política global ou de nível de grupo, apenas para descobrir que seu comportamento de política não é tão esperado.
Example: Injeção de rotas OSPF na tabela de roteamento BGP
Este exemplo mostra como criar uma política que injete rotas OSPF na tabela de roteamento BGP.
Requisitos
Antes de começar:
Configure interfaces de rede.
Configure sessões externas por pares. Veja exemplo: Configuração de sessões de peer BGP externas ponto a ponto.
Configure sessões de protocolo de gateway interior (IGP) entre pares.
Visão geral
Neste exemplo, você cria uma política de roteamento chamada injectpolicy1 e um termo de roteamento chamado injectterm1. A política injeta rotas OSPF na tabela de roteamento BGP.
Topologia
Cópia de
Configuração da política de roteamento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de hierarquia [editar] e, em seguida, entrar no commit modo de configuração.
set policy-options policy-statement injectpolicy1 term injectterm1 from protocol ospf set policy-options policy-statement injectpolicy1 term injectterm1 from area 0.0.0.1 set policy-options policy-statement injectpolicy1 term injectterm1 then accept set protocols bgp export injectpolicy1
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 pela CLI, consulte o uso do Editor de CLI no modo de configuração no guia de usuário da CLI.
Para injetar rotas OSPF em uma tabela de roteamento BGP:
Crie o termo da política.
[edit policy-options policy-statement injectpolicy1] user@host# set term injectterm1
Especifique o OSPF como uma condição compatível.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from protocol ospf
Especifique as rotas de uma área de OSPF como condição de correspondência.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set from area 0.0.0.1
Especifique se a rota deve ser aceita se as condições anteriores forem combinadas.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# set then accept
Aplique a política de roteamento ao BGP.
[edit] user@host# set protocols bgp export injectpolicy1
Resultados
Confirme sua configuração entrando no show policy-options modo de configuração e show protocols bgp comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@host# show policy-options
policy-statement injectpolicy1 {
term injectterm1 {
from {
protocol ospf;
area 0.0.0.1;
}
then accept;
}
}
user@host# show protocols bgp export injectpolicy1;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Configuração do rastreamento para a política de roteamento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de hierarquia [editar] e, em seguida, entrar no commit modo de configuração.
set policy-options policy-statement injectpolicy1 term injectterm1 then trace set routing-options traceoptions file ospf-bgp-policy-log set routing-options traceoptions file size 5m set routing-options traceoptions file files 5 set routing-options traceoptions flag policy
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 pela CLI, consulte o uso do Editor de CLI no modo de configuração no guia de usuário da CLI.
Inclua uma ação de rastreamento na política.
[edit policy-options policy-statement injectpolicy1 term injectterm1] user@host# then trace
Configure o arquivo de rastreamento para a saída.
[edit routing-options traceoptions] user@host# set file ospf-bgp-policy-log user@host# set file size 5m user@host# set file files 5 user@host# set flag policy
Resultados
Confirme sua configuração entrando no show policy-options modo de configuração e 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@host# show policy-options
policy-statement injectpolicy1 {
term injectterm1 {
then {
trace;
}
}
}
user@host# show routing-options
traceoptions {
file ospf-bgp-policy-log size 5m files 5;
flag policy;
}
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Solução de problemas
Usando o comando de log show para examinar as ações da política de roteamento
Problema
A tabela de roteamento contém rotas inesperadas ou as rotas estão ausentes da tabela de roteamento.
Solução
Se você configurar o rastreamento de políticas como mostrado neste exemplo, você pode executar o show log ospf-bgp-policy-log comando para diagnosticar problemas com a política de roteamento. O show log ospf-bgp-policy-log comando exibe informações sobre as rotas que o injectpolicy1 termo de política analisa e age.
Configuração de políticas de roteamento para controlar anúncios de rotas BGP
Todos os protocolos de roteamento usam a tabela de roteamento Junos OS para armazenar as rotas que aprendem e determinar quais rotas devem anunciar em seus pacotes de protocolo. A política de roteamento permite controlar quais roteamentos os protocolos de roteamento armazenam e recuperam da tabela de roteamento. Para obter informações sobre a política de roteamento, consulte as políticas de roteamento, filtros de firewall e o guia de usuários do Traffic Policers.
Ao configurar a política de roteamento BGP, você pode realizar as seguintes tarefas:
- Aplicar política de roteamento
- Definir BGP para anunciar rotas inativas
- Configuração do BGP para anunciar a melhor rota externa para pares internos
- Configurando com que frequência o BGP troca rotas com a tabela de roteamento
- Desativação da eliminação de anúncios de rota
Aplicar política de roteamento
Você define a política de roteamento no nível da [edit policy-options] hierarquia. Para aplicar políticas que você definiu para BGP, inclua as e export declarações import dentro da configuração BGP.
Você pode aplicar políticas da seguinte forma:
BGP global
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp]hierarquia (para instâncias de roteamento, inclua essas declarações no nível da[edit routing-instances routing-instance-name protocols bgp]hierarquia).Grupo
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp group group-name]hierarquia (para instâncias de roteamento, inclua essas declarações no nível da[edit routing-instances routing-instance-name protocols bgp group group-name]hierarquia).Peer
importandexportstatements — Inclua essas declarações no nível de[edit protocols bgp group group-name neighbor address]hierarquia (para instâncias de roteamento, inclua essas declarações no nível de[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]hierarquia).
Uma declaração ou export nível import peer substitui um grupo import ou export declaração. Um nível import de grupo ou export declaração substitui um BGP import ou export declaração global.
Para aplicar políticas, veja as seguintes seções:
- Aplicar políticas às rotas que estão sendo importadas na tabela de roteamento a partir do BGP
- Aplicar políticas às rotas que estão sendo exportadas da tabela de roteamento para o BGP
Aplicar políticas às rotas que estão sendo importadas na tabela de roteamento a partir do BGP
Para aplicar a política às rotas que estão sendo importadas na tabela de roteamento do BGP, inclua a import declaração, listando os nomes de uma ou mais políticas a serem avaliadas:
import [ policy-names ];
Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.
Se você especificar mais de uma política, elas serão avaliadas na ordem especificada, do primeiro ao último, e o primeiro filtro de correspondência é aplicado à rota. Se nenhuma correspondência for encontrada, o BGP coloca na tabela de roteamento apenas aquelas rotas que foram aprendidas com dispositivos de roteamento BGP.
Aplicar políticas às rotas que estão sendo exportadas da tabela de roteamento para o BGP
Para aplicar a política às rotas que estão sendo exportadas da tabela de roteamento para o BGP, inclua a export declaração, listando os nomes de uma ou mais políticas a serem avaliadas:
export [ policy-names ];
Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.
Se você especificar mais de uma política, elas serão avaliadas na ordem especificada, do primeiro ao último, e o primeiro filtro de correspondência é aplicado à rota. Se nenhuma rota combinar com os filtros, a tabela de roteamento exporta para BGP apenas as rotas que aprendeu com o BGP.
Definir BGP para anunciar rotas inativas
Por padrão, o BGP armazena as informações de rota que recebe das mensagens de atualização na tabela de roteamento do Junos OS, e a tabela de roteamento exporta apenas rotas ativas para o BGP, que o BGP anuncia para seus pares. Para ter a tabela de roteamento exportando para BGP a melhor rota aprendida pelo BGP mesmo que o Junos OS não o tenha selecionado como uma rota ativa, inclua a advertise-inactive declaração:
advertise-inactive;
Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.
Configuração do BGP para anunciar a melhor rota externa para pares internos
Em geral, implementações BGP implantadas não anunciam a rota externa com o maior valor de preferência local para pares internos, a menos que seja a melhor rota. Embora esse comportamento tenha sido exigido por uma versão anterior da especificação bgp versão 4, RFC 1771, ele normalmente não foi seguido a fim de minimizar a quantidade de informações anunciadas e evitar loops de roteamento. No entanto, existem cenários em que anunciar a melhor rota externa é benéfico, em especial, situações que podem resultar na oscilação da rota do IBGP.
No Junos OS Release 9.3 e posterior, você pode configurar o BGP para anunciar a melhor rota externa em um grupo interno de malha BGP (IBGP), um cluster de refletor de rotas ou uma confederação de sistema autônomo (AS), mesmo quando a melhor rota é uma rota interna.
Para configurar a advertise-external declaração em um refletor de rota, você deve desabilitar a reflexão intracluster com a no-client-reflect declaração.
Quando um dispositivo de roteamento é configurado como um refletor de rota para um cluster, uma rota anunciada pelo refletor de rota é considerada interna se for recebida de um peer interno com o mesmo identificador de cluster ou se ambos os pares não tiverem nenhum identificador de cluster configurado. Uma rota recebida de um peer interno que pertence a outro cluster, ou seja, com um identificador de cluster diferente, é considerada externa.
Em uma confederação, ao anunciar uma rota para um roteador de fronteira da confederação, qualquer rota de um sub-AS da confederação diferente é considerada externa.
Você também pode configurar o BGP para anunciar a rota externa apenas se o processo de seleção de rota chegar ao ponto em que a métrica de discriminação de múltiplas saídas (MED) é avaliada. Como resultado, uma rota externa com um caminho AS pior (ou seja, mais longa) do que a do caminho ativo não é anunciada.
O Junos OS também oferece suporte para configurar uma política de exportação BGP que corresponda ao estado de uma rota anunciada. Você pode combinar em rotas ativas ou inativas. Para obter mais informações, consulte as políticas de roteamento, filtros de firewall e o guia de usuário dos policiais de tráfego.
Para configurar o BGP para anunciar o melhor caminho externo para pares internos, inclua a advertise-external declaração:
advertise-external;
A advertise-external declaração é apoiada no nível do grupo e do vizinho. Se você configurar a declaração no nível vizinho, você deve configurá-la para todos os vizinhos de um grupo. Caso contrário, o grupo é automaticamente dividido em diferentes grupos.
Para obter uma lista completa de níveis de hierarquia nos quais você pode configurar esta declaração, consulte a seção de resumo da declaração para esta declaração.
Para configurar o BGP para anunciar o melhor caminho externo somente se o processo de seleção de rotas chegar ao ponto onde o valor do MED é avaliado, inclua a conditional declaração:
advertise-external {
conditional;
}
Configurando com que frequência o BGP troca rotas com a tabela de roteamento
O BGP armazena as informações de rota que recebe das mensagens de atualização na tabela de roteamento, e a tabela de roteamento exporta rotas ativas da tabela de roteamento para o BGP. O BGP anuncia então as rotas exportadas para seus pares. Por padrão, a troca de informações de rota entre o BGP e a tabela de roteamento ocorre imediatamente após o recebimento das rotas. Essa troca imediata de informações de rota pode causar instabilidades nas informações de alcance da rede. Para se proteger disso, você pode atrasar o tempo entre o BGP e as informações de rota de troca da tabela de roteamento.
Para configurar com que frequência o BGP e as informações de rota de troca da tabela de roteamento incluem a out-delay declaração:
out-delay seconds;
Por padrão, a tabela de roteamento retém algumas das informações de rota aprendidas com o BGP. Para que a tabela de roteamento retenha todas ou nenhuma dessas informações, inclua a keep declaração:
keep (all | none);
Para obter uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração para essas declarações.
A tabela de roteamento pode reter as informações de rota aprendidas com o BGP de uma das seguintes maneiras:
Padrão (omite a
keepdeclaração)— Mantenha todas as informações de rota aprendidas com o BGP, com exceção de rotas cujo caminho de AS é em loop e cujo loop inclui o AS local.keep all— Mantenha todas as informações de rota aprendidas com o BGP.keep none— Descarte rotas que foram recebidas de um peer e que foram rejeitadas por política de importação ou outras verificações de sanidade, como caminho AS ou próximo salto. Quando você configurakeep nonepara a sessão BGP e as mudanças na política de entrada, as forças do Junos OS readvertisement do conjunto completo de rotas anunciadas pelo peer.
Em uma situação de cura de caminhos AS, rotas com caminhos em loop teoricamente podem se tornar utilizáveis durante uma reconfiguração suave quando o limite de loop de caminho as for alterado. No entanto, existe uma diferença significativa de uso da memória entre o padrão e keep all.
Considere os seguintes cenários:
Um peer readvertises rotas de volta para o peer com o qual os aprendeu.
Isso pode acontecer nos seguintes casos:
O dispositivo de roteamento de outro fornecedor anuncia as rotas de volta para o peer de envio.
O comportamento padrão do junos OS peer de não readvertir rotas de volta ao peer de envio é substituído pela configuração
advertise-peer-as.
Um dispositivo de roteamento de borda (PE) do provedor descarta qualquer rota VPN que não tenha nenhum dos alvos de rota esperados.
Quando keep all configurado, o comportamento de descartar rotas recebidas nos cenários acima é excessivo.
Desativação da eliminação de anúncios de rota
O Junos OS não anuncia as rotas aprendidas com um peer EBGP até o mesmo BGP externo (EBGP). Além disso, o software não anuncia essas rotas de volta para nenhum pares de EBGP que estejam no mesmo que o peer de origem, independentemente da instância de roteamento. Você pode modificar esse comportamento incluindo a advertise-peer-as declaração na configuração. Para desativar a eliminação padrão de anúncios, inclua a advertise-peer-as declaração:
advertise-peer-as;
O comportamento padrão de eliminação de rotas é desativado se a as-override declaração for incluída na configuração.
Se você incluir a advertise-peer-as declaração na configuração, o BGP anuncia a rota independentemente desta verificação.
Para restaurar o comportamento padrão, inclua a no-advertise-peer-as declaração na configuração:
no-advertise-peer-as;
Se você incluir as declarações e no-advertise-peer-as as as-override declarações na configuração, a no-advertise-peer-as declaração será ignorada. Você pode incluir essas declarações em vários níveis de hierarquia.
Para obter uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte a seção de resumo da declaração para essas declarações.
Consulte também
Example: Configurando uma política de roteamento para anunciar a melhor rota externa para pares internos
A especificação do protocolo BGP, conforme definido no RFC 1771, especifica que um peer BGP deve anunciar aos seus pares internos o caminho externo de maior preferência, mesmo que esse caminho não seja o melhor geral (ou seja, mesmo que o melhor caminho seja um caminho interno). Na prática, implementações BGP implantadas não seguem essa regra. Os motivos para desviar-se da especificação são os seguintes:
Minimizando a quantidade de informações anunciadas. O BGP é escalonado de acordo com o número de caminhos disponíveis.
Evitando loops de roteamento e encaminhamento.
Existem, no entanto, vários cenários em que o comportamento, especificado no RFC 1771, de anunciar a melhor rota externa pode ser benéfico. Limitar informações de caminho nem sempre é desejável, pois a diversidade de caminhos pode ajudar a reduzir os tempos de restauração. Anunciar o melhor caminho externo também pode resolver problemas internos de oscilação de rota BGP (IBGP), conforme descrito no RFC 3345, Condição de Oscilação persistente de rotas do Protocolo de Gateway de Borda (BGP).
A advertise-external declaração modifica o comportamento de um alto-falante BGP para anunciar o melhor caminho externo para os pares do IBGP, mesmo quando o melhor caminho geral é um caminho interno.
A advertise-external declaração é apoiada no nível do grupo e do vizinho. Se você configurar a declaração no nível vizinho, você deve configurá-la para todos os vizinhos de um grupo. Caso contrário, o grupo é automaticamente dividido em diferentes grupos.
A opção conditional limita o comportamento da configuração, de advertise-external forma que a rota externa seja anunciada apenas se o processo de seleção de rotas chegar ao ponto em que a métrica discriminativa de saída múltipla (MED) é avaliada. Assim, uma rota externa não é anunciada se tiver, por exemplo, um caminho AS pior (mais longo) do que o do caminho ativo. A opção conditional restringe o anúncio de caminho externo para quando o melhor caminho externo e o caminho ativo são iguais até a etapa MED do processo de seleção de rotas. Observe que os critérios usados para selecionar o melhor caminho externo são os mesmos, independentemente de a opção conditional estar configurada ou não.
O Junos OS também oferece suporte para configurar uma política de exportação BGP que corresponda ao estado de uma rota anunciada. Você pode combinar rotas ativas ou inativas da seguinte forma:
policy-options {
policy-statement name{
from state (active|inactive);
}
}
Este qualificatório só corresponde quando usado no contexto de uma política de exportação. Quando uma rota está sendo anunciada por um protocolo que pode anunciar rotas inativas (como BGP), state inactive combina rotas anunciadas como resultado das advertise-inactive declarações e advertise-external declarações.
Por exemplo, a configuração a seguir pode ser usada como uma política de exportação BGP para pares internos para marcar rotas anunciadas devido à advertise-external configuração com uma comunidade definida pelo usuário. Essa comunidade pode ser usada mais tarde pelos roteadores receptores para filtrar essas rotas da tabela de encaminhamento. Esse mecanismo pode ser usado para resolver preocupações de que caminhos de publicidade não usados para o encaminhamento pelo remetente possam levar a loops de encaminhamento.
user@host# show policy-options
policy-statement mark-inactive {
term inactive {
from state inactive;
then {
community set comm-inactive;
}
}
term default {
from protocol bgp;
then accept;
}
then reject;
}
community comm-inactive members 65536:65284;
Requisitos
O Junos OS 9.3 ou posterior é necessário.
Visão geral
Este exemplo mostra três dispositivos de roteamento. O dispositivo R2 tem uma conexão BGP externa (EBGP) com o dispositivo R1. O dispositivo R2 tem uma conexão IBGP com o dispositivo R3.
Dispositivo R1 anuncia 172.16.6.0/24. O dispositivo R2 não define a preferência local em uma política de importação para as rotas do dispositivo R1 e, portanto, 172.16.6.0/24 tem a preferência local padrão de 100.
O dispositivo R3 anuncia 172.16.6.0/24 com uma preferência local de 200.
Quando a advertise-external declaração não está configurada no dispositivo R2, 172.16.6.0/24 não é anunciada pelo dispositivo R2 em direção ao Dispositivo R3.
Quando a advertise-external declaração é configurada no dispositivo R2 na sessão em direção ao Dispositivo R3, 172.16.6.0/24 é anunciado pelo Dispositivo R2 em direção ao Dispositivo R3.
Quando advertise-external conditional está configurado no dispositivo R2 na sessão em direção ao Dispositivo R3, 172.16.6.0/24 não é anunciado pelo Dispositivo R2 em direção ao Dispositivo R3. Se você remover a then local-preference 200 configuração do Dispositivo R3 e adicionar a path-selection as-path-ignore configuração no Dispositivo R2 (tornando assim os critérios de seleção de caminho iguais até a etapa MED do processo de seleção de rotas), 172.16.6.0/24 é anunciado pelo dispositivo R2 em direção ao Dispositivo R3.
Para configurar a advertise-external declaração em um refletor de rota, você deve desabilitar a reflexão intracluster com a no-client-reflect declaração, e o cluster do cliente deve ser totalmente malhado para evitar o envio de anúncios de rotas redundantes.
Quando um dispositivo de roteamento é configurado como um refletor de rota para um cluster, uma rota anunciada pelo refletor de rota é considerada interna se for recebida de um peer interno com o mesmo identificador de cluster ou se ambos os pares não tiverem nenhum identificador de cluster configurado. Uma rota recebida de um peer interno que pertence a outro cluster, ou seja, com um identificador de cluster diferente, é considerada externa.
Topologia
Figura 2 mostra a rede de amostra.
Configuração rápida da CLI mostra a configuração para todos os dispositivos em Figura 2.
A seção #d189e165__d189e343 descreve as etapas do dispositivo R2.
Cópia de
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
Dispositivo R1
set interfaces fe-1/2/0 unit 0 description to-R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact set policy-options policy-statement send-static term 1 then accept set policy-options policy-statement send-static term 2 then reject set routing-options static route 172.16.6.0/24 reject set routing-options router-id 192.168.0.1 set routing-options autonomous-system 100
Dispositivo R2
set interfaces fe-1/2/0 unit 0 description to-R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to-R3 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.1 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int advertise-external set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options router-id 192.168.0.2 set routing-options autonomous-system 200
Dispositivo R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int export send-static set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then local-preference 200 set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.6.0/24 reject set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5 set routing-options autonomous-system 200
Procedimento
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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar o dispositivo R2:
Configure as interfaces do dispositivo.
[edit interfaces] user@R2# set fe-1/2/0 unit 0 description to-R1 user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 description to-R3 user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Configure o OSPF ou outro protocolo de gateway interno (IGP).
[edit protocols ospf area 0.0.0.0] user@R2# set interface fe-1/2/1.0 user@R2# set interface lo0.0 passive
Configure a conexão EBGP com o dispositivo R1.
[edit protocols bgp group ext] user@R2# set type external user@R2# set peer-as 100 user@R2# set neighbor 10.0.0.1
Configure a conexão IBGP com o dispositivo R3.
[edit protocols bgp group int] user@R2# set type internal user@R2# set local-address 192.168.0.2 user@R2# set neighbor 192.168.0.3
Adicione a
advertise-externaldeclaração à sessão de peering do grupo IBGP.[edit protocols bgp group int] user@R2# set advertise-external
Configure o número do sistema autônomo (AS) e o ID do roteador.
[edit routing-options ] user@R2# set router-id 192.168.0.2 user@R2# set autonomous-system 200
Resultados
A partir do modo de configuração, confirme sua configuração entrando nosshow 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@R2# show interfaces
fe-1/2/0 {
unit 0{
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
fe-1/2/1 {
unit 0 {
description to-R3;
family inet {
address 10.0.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
type external;
peer-as 100;
neighbor 10.0.0.1;
}
group int {
type internal;
local-address 192.168.0.2;
advertise-external;
neighbor 192.168.0.3;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
user@R2# show routing-options router-id 192.168.0.2; autonomous-system 200;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Confirme que a configuração está funcionando corretamente.
- Verificando o bgp active path
- Verificando o anúncio da rota externa
- Verificando a rota no dispositivo R3
- Experimentar a opção condicional
Verificando o bgp active path
Propósito
No dispositivo R2, certifique-se de que o prefixo 172.16.6.0/24 está na tabela de roteamento e tenha o caminho ativo esperado.
Ação
user@R2> show route 172.16.6
inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/1.0
[BGP/170] 03:23:03, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Significado
O dispositivo R2 recebe a rota 172.16.6.0/24 do dispositivo R1 e do dispositivo R3. A rota do Dispositivo R3 é o caminho ativo, conforme designado pelo asterisco (*). O caminho ativo tem a mais alta preferência local. Mesmo que as preferências locais das duas rotas fossem iguais, a rota do dispositivo R3 permaneceria ativa porque tem o caminho de AS mais curto.
Verificando o anúncio da rota externa
Propósito
No dispositivo R2, certifique-se de que a rota 172.16.6.0/24 seja anunciada em direção ao dispositivo R3.
Ação
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.6.0/24 10.0.0.1 100 100 I
Significado
O dispositivo R2 está anunciando a rota 172.16.6.0/24 em direção ao dispositivo R3.
Verificando a rota no dispositivo R3
Propósito
Certifique-se de que o prefixo 172.16.6.0/24 esteja na tabela de roteamento do dispositivo R3.
Ação
user@R3> show route 172.16.6.0/24
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[Static/5] 03:34:14
Reject
[BGP/170] 06:34:43, localpref 100, from 192.168.0.2
AS path: 100 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/0.6Significado
O dispositivo R3 tem a rota estática e a rota BGP para 172.16.6.0/24.
Observe que a rota BGP está oculta no dispositivo R3 se a rota não for acessível ou se o próximo salto não puder ser resolvido. Para atender a esse requisito, este exemplo inclui uma rota padrão estática no dispositivo R3 (static route 0.0.0.0/0 next-hop 10.0.0.5).
Experimentar a opção condicional
Propósito
Veja como a opção conditional funciona no contexto do algoritmo de seleção de caminhos BGP.
Ação
No dispositivo R2, adicione a opção
conditional.[edit protocols bgp group int] user@R2# set advertise-external conditional user@R2# commit
No dispositivo R2, verifique se a rota 172.16.6.0/24 é anunciada em direção ao Dispositivo R3.
user@R2> show route advertising-protocol bgp 192.168.0.3
Como esperado, a rota não é mais anunciada. Você pode precisar esperar alguns segundos para ver esse resultado.
No dispositivo R3, desativar a ação da
then local-preferencepolítica.[edit policy-options policy-statement send-static term 1] user@R3# deactivate logical-systems R3 then local-preference user@R3# commit
No dispositivo R2, garanta que as preferências locais dos dois caminhos sejam iguais.
user@R2> show route 172.16.6.0/24 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.6.0/24 *[BGP/170] 08:02:59, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0 [BGP/170] 00:07:51, localpref 100, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/1.0No dispositivo R2, adicione a
as-path-ignoredeclaração.[edit protocols bgp] user@R2# set path-selection as-path-ignore user@R2# commit
No dispositivo R2, verifique se a rota 172.16.6.0/24 é anunciada em direção ao Dispositivo R3.
user@R2> show route advertising-protocol bgp 192.168.0.3 inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.6.0/24 10.0.0.1 100 100 I
Como esperado, a rota agora é anunciada porque o comprimento do caminho AS é ignorado e porque as preferências locais são iguais.
Example: Configuração da filtragem de rotas de saída baseada em prefixo BGP
Este exemplo mostra como configurar um roteador da Juniper Networks para aceitar filtros de rota de pares remotos e realizar a filtragem de rotas de saída usando os filtros recebidos.
Requisitos
Antes de começar:
Configure as interfaces do roteador.
Configure um protocolo de gateway interior (IGP).
Visão geral
Você pode configurar um peer BGP para aceitar filtros de rota de pares remotos e realizar filtragem de rotas de saída usando os filtros recebidos. Filtrando atualizações indesejados, o envio de peer economiza recursos necessários para gerar e transmitir atualizações, e o peer recebendo economiza recursos necessários para processar atualizações. Esse recurso pode ser útil, por exemplo, em uma REDE privada virtual (VPN) na qual subconjuntos de dispositivos de borda do cliente (CE) não são capazes de processar todas as rotas da VPN. Os dispositivos CE podem usar a filtragem de rota de saída baseada em prefixo para se comunicar com o dispositivo de roteamento de borda (PE) do provedor para transmitir apenas um subconjunto de rotas, como rotas apenas para os data centers principais.
O número máximo de filtros de rota de saída baseados em prefixo que um peer BGP pode aceitar é 5000. Se um peer remoto enviar mais de 5.000 filtros de rota de saída para um endereço peer, os filtros adicionais serão descartados e uma mensagem de log do sistema for gerada.
Você pode configurar a interoperabilidade para o dispositivo de roteamento como um todo ou apenas para grupos BGP ou pares específicos.
Topologia
Na rede de amostra, o Dispositivo CE1 é um roteador de outro fornecedor. A configuração mostrada neste exemplo está no Roteador PE1 da Juniper Networks.
Figura 3 mostra a rede de amostra.
Cópia de
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
PE1
set protocols bgp group cisco-peers type external set protocols bgp group cisco-peers description “to CE1” set protocols bgp group cisco-peers local-address 192.168.165.58 set protocols bgp group cisco-peers peer-as 35 set protocols bgp group cisco-peers outbound-route-filter bgp-orf-cisco-mode set protocols bgp group cisco-peers outbound-route-filter prefix-based accept inet set protocols bgp group cisco-peers neighbor 192.168.165.56 set routing-options autonomous-system 65500
Procedimento
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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Configurar o Roteador PE1 para aceitar filtros de rota do dispositivo CE1 e realizar a filtragem de rotas de saída usando os filtros recebidos:
Configure o sistema autônomo local.
[edit routing-options] user@PE1# set autonomous-system 65500
Configure peering externo com o dispositivo CE1.
[edit protocols bgp group cisco-peers] user@PE1# set type external user@PE1# set description “to CE1” user@PE1# set local-address 192.168.165.58 user@PE1# set peer-as 35 user@PE1# set neighbor 192.168.165.56
Configure o Roteador PE1 para aceitar filtros de rota IPv4 do dispositivo CE1 e realizar filtragem de rotas de saída usando os filtros recebidos.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter prefix-based accept inet
(Opcional) Habilite a interoperabilidade com dispositivos de roteamento que usam o código de compatibilidade específico do fornecedor de 130 para filtros de rota de saída e o tipo de código de 128.
O código padrão IANA é 3, e o tipo de código padrão é 64.
[edit protocols bgp group cisco-peers] user@PE1# set outbound-route-filter bgp-orf-cisco-mode
Resultados
A partir do modo de configuração, confirme sua configuração inserindo os show protocols comandos e show routing-options os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@PE1# show protocols
group cisco-peers {
type external;
description “to CE1”;
local-address 192.168.165.58;
peer-as 35;
outbound-route-filter {
bgp-orf-cisco-mode;
prefix-based {
accept {
inet;
}
}
}
neighbor 192.168.165.56;
}
user@PE1# show routing-options autonomous-system 65500;
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Confirme que a configuração está funcionando corretamente.
Verificando o filtro de rota de saída
Propósito
Exibir informações sobre o filtro de rota de saída baseado em prefixo recebido do dispositivo CE1.
Ação
Do modo operacional, entre no show bgp neighbor orf detail comando.
user@PE1> show bgp neighbor orf 192.168.165.56 detail
Peer: 192.168.165.56 Type: External
Group: cisco-peers
inet-unicast
Filter updates recv: 4 Immediate: 0
Filter: prefix-based receive
Updates recv: 4
Received filter entries:
seq 10 2.2.0.0/16 deny minlen 0 maxlen 0
seq 20 3.3.0.0/16 deny minlen 24 maxlen 0
seq 30 4.4.0.0/16 deny minlen 0 maxlen 28
seq 40 5.5.0.0/16 deny minlen 24 maxlen 28
Verificando o modo BGP Neighbor
Propósito
Verifique se a bgp-orf-cisco-mode configuração está habilitada para o peer, certificando-se de que a opção ORFCiscoMode seja exibida na saída de show bgp neighbor comando.
Ação
Do modo operacional, entre no show bgp neighbor comando.
user@PE1> show bgp neighbor Peer: 192.168.165.56 AS 35 Local: 192.168.165.58 AS 65500 Type: External State: Active Flags: <> Last State: Idle Last Event: Start Last Error: None Export: [ adv_stat ] Options: <Preference LocalAddress AddressFamily PeerAS Refresh> Options: <ORF ORFCiscoMode> Address families configured: inet-unicast Local Address: 192.168.165.58 Holdtime: 90 Preference: 170 Number of flaps: 0 Trace options: detail open detail refresh Trace file: /var/log/orf size 5242880 files 20
Entendendo a política padrão de roteamento BGP em roteadores de transporte de pacotes (Série PTX)
Nos roteadores de transporte de pacotes da Série PTX, a política padrão de roteamento BGP difere da de outros dispositivos de roteamento Junos OS.
Os roteadores da Série PTX são plataformas de trânsito MPLS que fazem encaminhamento ip, normalmente usando rotas de protocolo de gateway interior (IGP). O mecanismo de encaminhamento de pacotes da Série PTX pode acomodar um número relativamente pequeno de prefixos de comprimento variável.
Um roteador da Série PTX pode oferecer suporte a rotas BGP completas no plano de controle para que ele possa ser usado como refletor de rota (RR). Ele pode fazer o encaminhamento multicast de comprimento exato e pode construir o plano de encaminhamento multicast para uso pelo plano de controle unicast (por exemplo, para realizar uma busca de encaminhamento de caminho reverso para multicast).
Dada a limitação do PFE, a política de roteamento padrão para roteadores da Série PTX é para que as rotas BGP não sejam instaladas na tabela de encaminhamento. Você pode substituir a política de roteamento padrão e selecionar determinadas rotas BGP para instalar na tabela de encaminhamento.
O comportamento padrão para balanceamento de carga e rotas BGP em roteadores da Série PTX é o seguinte. Ela tem as seguintes características desejáveis:
Permite que você substitua o comportamento padrão sem precisar alterar diretamente a política padrão
Reduz a chance de mudanças acidentais que anulam os padrões
Não define ações de controle de fluxo, como aceitar e rejeitar
A política de roteamento padrão nos roteadores da Série PTX é a seguinte:
user@host# show policy-options | display inheritance defaults no-comments
policy-options {
policy-statement junos-ptx-series-default {
term t1 {
from {
protocol bgp;
rib inet.0;
}
then no-install-to-fib;
}
term t2 {
from {
protocol bgp;
rib inet6.0;
}
then no-install-to-fib;
}
term t3 {
then load-balance per-packet;
}
}
}
routing-options {
forwarding-table {
default-export junos-ptx-series-default;
}
}
user@host# show routing-options forwarding-table default-export | display inheritance defaults no-comments
default-export junos-ptx-series-default;
Como mostrado aqui, a junos-ptx-series-default política é definida em [edit policy-options]. A política é aplicada, [edit routing-options forwarding-table]usando a default-export declaração. Você pode visualizar essas configurações padrão usando a | display inheritance bandeira.
Além disso, você pode usar o show policy comando para visualizar a política padrão.
user@host> show policy junos-ptx-series-default
Policy junos-ptx-series-default:
Term t1:
from proto BGP
inet.0
then install-to-fib no
Term t2:
from proto BGP
inet6.0
then install-to-fib no
Term t3:
then load-balance per-packetRecomendamos fortemente que você não altere diretamente a junos-ptx-series-default política de roteamento.
O Junos OS cadeia a junos-ptx-series-default política e qualquer política de exportação configurada pelo usuário. Como a junos-ptx-series-default política não usa ações de controle de fluxo, qualquer política de exportação configurada é executada (por meio da ação implícita de próxima política) para cada rota. Assim, você pode substituir quaisquer ações definidas pela junos-ptx-series-default política. Se você não configurar uma política de exportação, as ações definidas por junos-ptx-series-default política são as únicas ações.
Você pode usar a ação install-to-fib de política para substituir a ação no-install-to-fib .
Da mesma forma, você pode definir a ação load-balance per-prefix para substituir a ação load-balance per-packet .
Consulte também
Example: Substituindo a política padrão de roteamento BGP nos roteadores de transporte de pacotes da Série PTX
Este exemplo mostra como substituir a política de roteamento padrão em roteadores de transporte de pacotes, como os roteadores de transporte de pacotes da Série PTX.
Requisitos
Este exemplo requer o Junos OS Release 12.1 ou posterior.
Visão geral
Por padrão, os roteadores da Série PTX não instalam rotas BGP na tabela de encaminhamento.
Para os roteadores da Série PTX, a configuração da from protocols bgp condição com a ação then accept não tem o resultado usual que tem em outros dispositivos de roteamento Junos OS. Com a política de roteamento a seguir nos roteadores da Série PTX, as rotas BGP não são instaladas na tabela de encaminhamento.
user@host# show policy-options
policy-statement accept-no-install {
term 1 {
from protocol bgp;
then accept;
}
}
user@host# show routing-options
forwarding-table {
export accept-no-install;
}
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
Nenhuma rota BGP é instalada na tabela de encaminhamento. Esse é o comportamento esperado.
Este exemplo mostra como usar a ação then install-to-fib para substituir efetivamente a política padrão de roteamento BGP.
Cópia de
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
Instalação de rotas BGP selecionadas na tabela de encaminhamento
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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para instalar rotas BGP selecionadas na tabela de encaminhamento:
Configure uma lista de prefixos para instalar na tabela de encaminhamento.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configure a política de roteamento, aplicando a lista de prefixo como uma condição.
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
Aplique a política de roteamento na tabela de encaminhamento.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Resultados
A partir do modo de configuração, confirme sua configuração inserindo os show policy-options comandos e show routing-options os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@host# show policy-options
prefix-list install-bgp {
66.0.0.1/32;
}
policy-statement override-ptx-series-default {
term 1 {
from {
prefix-list install-bgp;
}
then {
load-balance per-prefix;
install-to-fib;
}
}
}
user@host# show routing-options
forwarding-table {
export override-ptx-series-default;
}
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Confirme que a configuração está funcionando corretamente.
Verificando se a rota selecionada está instalada na tabela de encaminhamento
Propósito
Certifique-se de que a política configurada substitua a política padrão.
Ação
Do modo operacional, entre no show route forwarding-table comando.
user@host> show route forwarding-table destination 66.0.0.1
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
66.0.0.1/32 user 0 indr 2097159 3
ulst 2097156 2
5.1.0.2 ucst 574 1 et-6/0/0.1
5.2.0.2 ucst 575 1 et-6/0/0.2
Significado
Essa saída mostra que a rota para 66.0.0.1/32 está instalada na tabela de encaminhamento.
Anúncio condicional que permite a instalação condicional de casos de uso de prefixos
As redes geralmente são subdivididas em unidades menores e mais gerenciáveis chamadas sistemas autônomos (ASs). Quando o BGP é usado por roteadores para formar relações de pares no mesmo AS, ele é chamado de BGP interno (IBGP). Quando o BGP é usado por roteadores para formar relações de pares em diferentes ASs, ele é chamado de BGP externo (EBGP).
Após realizar verificações de sanidade de rota, um roteador BGP aceita as rotas recebidas de seus pares e as instala na tabela de roteamento. Por padrão, todos os roteadores nas sessões de IBGP e EBGP seguem as regras padrão de anúncio BGP. Enquanto um roteador em uma sessão do IBGP anuncia apenas as rotas aprendidas com seus pares diretos, um roteador em uma sessão de EBGP anuncia todas as rotas aprendidas com seus pares diretos e indiretos (pares de pares). Assim, em uma rede típica configurada com EBGP, um roteador adiciona todas as rotas recebidas de um peer EBGP em sua tabela de roteamento e anuncia quase todas as rotas para todos os pares de EBGP.
Um provedor de serviços que troca rotas BGP com clientes e colegas na Internet corre o risco de ameaças maliciosas e não intencionais que podem comprometer o roteamento adequado do tráfego, bem como a operação dos roteadores.
Isso tem várias desvantagens:
Non-aggregated route advertisements— Um cliente poderia anunciar erroneamente todos os seus prefixos ao ISP, em vez de um agregado de seu espaço de endereço. Dado o tamanho da tabela de roteamento da Internet, isso deve ser cuidadosamente controlado. Um roteador de borda também pode precisar apenas de uma rota padrão em direção à Internet e, em vez disso, receber toda a tabela de roteamento BGP de seus peer upstream.
BGP route manipulation— Se um administrador mal-intencionado alterar o conteúdo da tabela de roteamento BGP, ele pode impedir que o tráfego chegue ao destino desejado.
BGP route hijacking— Um administrador desonesto de um peer BGP poderia anunciar maliciosamente os prefixos de uma rede na tentativa de redirecionar o tráfego destinado à rede da vítima para a rede do administrador para ter acesso ao conteúdo do tráfego ou bloquear os serviços on-line da vítima.
BGP denial of service (DoS)— Se um administrador mal-intencionado enviar tráfego BGP inesperado ou indesejável a um roteador na tentativa de usar todos os recursos BGP disponíveis do roteador, isso pode resultar em prejudicar a capacidade do roteador de processar informações de rota BGP válidas.
A instalação condicional de prefixos pode ser usada para resolver todos os problemas mencionados anteriormente. Se um cliente precisar de acesso a redes remotas, é possível instalar uma rota específica na tabela de roteamento do roteador conectado à rede remota. Isso não acontece em uma rede EBGP típica e, portanto, a instalação condicional de prefixos torna-se essencial.
As ASs não estão apenas vinculadas a relações físicas, mas também a negócios ou outras relações organizacionais. Um AS pode fornecer serviços a outra organização ou atuar como um AS de trânsito entre duas outras ASs. Essas ASs de trânsito estão vinculadas a acordos contratuais entre as partes que incluem parâmetros de como se conectar entre si e, o mais importante, o tipo e a quantidade de tráfego que transportam entre si. Portanto, por motivos legais e financeiros, os provedores de serviços devem implementar políticas que controlem como as rotas BGP são trocadas com vizinhos, quais rotas são aceitas desses vizinhos e como essas rotas afetam o tráfego entre as ASs.
Existem muitas opções diferentes disponíveis para filtrar rotas recebidas de um peer BGP para aplicar políticas inter-AS e mitigar os riscos de receber rotas potencialmente prejudiciais. A filtragem de rotas convencional examina os atributos de uma rota e aceita ou rejeita a rota com base nesses atributos. Uma política ou filtro pode examinar o conteúdo do AS-Path, o valor do next-hop, um valor da comunidade, uma lista de prefixos, a família de endereços da rota e assim por diante.
Em alguns casos, a "condição de aceitação" padrão de combinar um determinado valor de atributo não é suficiente. O provedor de serviços pode precisar usar outra condição fora da própria rota, por exemplo, outra rota na tabela de roteamento. Como exemplo, pode ser desejável instalar uma rota padrão recebida de um peer upstream, somente se for possível verificar se esse peer tem alcance para outras redes ainda mais upstream. Essa instalação de rota condicional evita a instalação de uma rota padrão que é usada para enviar tráfego em direção a esse peer, quando o peer pode ter perdido suas rotas upstream, levando ao tráfego black-holed. Para isso, o roteador pode ser configurado para procurar a presença de uma rota específica na tabela de roteamento e, com base nesse conhecimento, aceitar ou rejeitar outro prefixo.
Example: Configurar uma política de roteamento para anúncio condicional que permite a instalação condicional de prefixos em uma tabela de roteamento explica como a instalação condicional de prefixos pode ser configurada e verificada.
Consulte também
Anúncio condicional e política de importação (tabela de roteamento) com determinadas condições de correspondência
O BGP aceita todas as rotas não-loop aprendidas com os vizinhos e as importa para a tabela RIB-In. Se essas rotas forem aceitas pela política de importação BGP, elas serão importadas para a tabela de roteamento inet.0. Nos casos em que apenas determinadas rotas sejam necessárias para serem importadas, podem ser feitas provisões para que o dispositivo de roteamento por pares exporte rotas com base em uma condição ou um conjunto de condições.
A condição para a exportação de uma rota pode ser baseada em:
O peer da rota foi aprendido com
A interface em que a rota foi aprendida
Algum outro atributo necessário
Por exemplo:
[edit]
policy-options {
condition condition-name {
if-route-exists address table table-name;
}
}
Isso é conhecido como instalação condicional de prefixos e é descrito em Exemplo: Configurando uma política de roteamento para anúncio condicional que permite a instalação condicional de prefixos em uma tabela de roteamento.
As condições nas políticas de roteamento podem ser configuradas independentemente de fazer parte das políticas de exportação ou de importação ou ambas. A política de exportação oferece suporte a essas condições herdadas da política de roteamento com base na existência de outra rota na política de roteamento. No entanto, a política de importação não suporta essas condições, e as condições não são executadas mesmo que estejam presentes.
Figura 4 ilustra onde as políticas de importação e exportação bgp são aplicadas. Uma política de importação é aplicada a rotas de entrada visíveis na saída do show route receive-protocol bgp neighbor-address comando. Uma política de exportação é aplicada a rotas de saída visíveis na saída do show route advertising-protocol bgp neighbor-address comando.
Para permitir a instalação condicional de prefixos, uma política de exportação deve ser configurada no dispositivo onde a exportação do prefixo precisa ocorrer. A política de exportação avalia cada rota para verificar se ela atende a todas as condições de correspondência previstas na from declaração. Ele também pesquisa a existência da rota definida sob a condition declaração (também configurada sob a from declaração).
Se a rota não corresponder a todo o conjunto de condições necessárias definidas na política ou se a rota definida pela condition declaração não existir na tabela de roteamento, a rota não será exportada para seus pares BGP. Assim, uma política de exportação condicional corresponde às rotas para a rota ou prefixo desejados que você deseja instalar na tabela de roteamento dos pares.
Para configurar a instalação condicional de prefixos com a ajuda de uma política de exportação:
Crie uma
conditiondeclaração para verificar prefixos.[edit] policy-options { condition condition-name { if-route-exists address table table-name; } }Crie uma política de exportação com a condição recém-criada usando a
conditiondeclaração.[edit] policy-options { policy-statement policy-name { term 1 { from { protocols bgp; condition condition-name; } then { accept; } } } }Aplique a política de exportação ao dispositivo que exige apenas prefixos selecionados para serem exportados da tabela de roteamento.
[edit] protocols bgp { group group-name { export policy-name; } }
Consulte também
Example: Configuração de uma política de roteamento para anúncio condicional que permite a instalação condicional de prefixos em uma tabela de roteamento
Este exemplo mostra como configurar a instalação condicional de prefixos em uma tabela de roteamento usando a política de exportação BGP.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Roteadores de borda multisserviços da Série M, plataformas de roteamento universal 5G da Série M ou roteadores de núcleo da Série T
Junos OS Versão 9.0 ou posterior
Visão geral
Neste exemplo, três roteadores em três sistemas autônomos diferentes (ASs) estão conectados e configurados com o protocolo BGP. O roteador identificado como Internet, que é o roteador upstream, tem cinco endereços configurados em sua interface de loopback lo0.0 (172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 e 172.16.15.1/32) e um endereço de loopback extra (192.168.9.1/32) está configurado como o ID do roteador. Esses seis endereços são exportados para BGP para emular o conteúdo de uma tabela de roteamento BGP de um roteador conectado à Internet e anunciados ao Norte.
Os roteadores Norte e Sul usam as redes 10.0.89.12/30 e 10.0.78.12/30, respectivamente, e usam 192.168.7.1 e 192.168.8.1 para seus respectivos endereços de loopback.
Figura 5 mostra a topologia usada neste exemplo.
Roteador Norte exporta uma rota padrão para BGP, e anuncia a rota padrão e as cinco rotas BGP para o Roteador Sul, que é o roteador downstream. O roteador Sul recebe a rota padrão e apenas uma outra rota (172.16.11.1/32), e instala essa rota e a rota padrão em sua tabela de roteamento.
Para resumir, o exemplo atende aos seguintes requisitos:
No Norte, envie 0/0 apenas para o Sul se uma rota específica também for enviada (no exemplo 172.16.11.1/32).
No Sul, aceite a rota padrão e a rota 172.16.11.1/32. Solte todas as outras rotas. Considere que a South pode estar recebendo toda a tabela da Internet, enquanto a operadora só quer que a South tenha o padrão e um outro prefixo específico.
O primeiro requisito é atendido com uma política de exportação no Norte:
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 10.11.0.0/5 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
table inet.0;
}
}
A lógica da política de exportação condicional pode ser resumida da seguinte forma: Se 0/0 estiver presente e se 172.16.11.1/32 estiver presente, envie o prefixo de 0/0. Isso implica que, se 172.16.11.1/32 não estiver presente, então não envie 0/0.
O segundo requisito é atendido com uma política de importação no Sul:
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
rib inet.0;
neighbor 10.0.78.14;
route-filter 0.0.0.0/0 exact;
route-filter 10.11.0.0/8 orlonger;
}
then accept;
}
term 2 {
then reject;
}
}
Neste exemplo, quatro rotas são retiradas como resultado da política de importação no Sul. Isso ocorre porque a política de exportação no Norte vazou todas as rotas recebidas da Internet, e a política de importação no Sul exclui algumas dessas rotas.
É importante entender que, no Junos OS, embora uma política de importação (filtro de rota de entrada) possa rejeitar uma rota, não usá-la para encaminhamento de tráfego e não incluí-la em um anúncio para outros pares, o roteador retém essas rotas como rotas ocultas. Essas rotas ocultas não estão disponíveis para fins de política ou roteamento. No entanto, eles ocupam espaço de memória no roteador. Um provedor de serviços filtrando rotas para controlar a quantidade de informações que estão sendo mantidas na memória e processadas por um roteador pode querer que o roteador derrube totalmente as rotas que estão sendo rejeitadas pela política de importação.
Rotas ocultas podem ser vistas usando o show route receive-protocol bgp neighbor-address hidden comando. As rotas ocultas podem então ser retidas ou retiradas da tabela de roteamento configurando a keep all | none declaração no [edit protocols bgp] nível ou [edit protocols bgp group group-name] hierarquia.
As regras da retenção de rotas BGP são as seguintes:
Por padrão, todas as rotas aprendidas com o BGP são retidas, exceto aquelas em que o caminho do AS é em loop. (O caminho de AS inclui o AS local.)
Ao configurar a
keep alldeclaração, todas as rotas aprendidas com o BGP são retidas, mesmo aquelas com o AS local no caminho AS.Ao configurar a declaração, o
keep noneBGP descarta rotas que foram recebidas de um peer e que foram rejeitadas por política de importação ou outra verificação de sanidade. Quando essa declaração é configurada e a política de entrada muda, o Junos OS anuncia novamente todas as rotas anunciadas pelo peer.
Quando você configura keep all ou keep none e os pares oferecem suporte à atualização da rota, o palestrante local envia uma mensagem de atualização e realiza uma avaliação de importação. Para esses pares, as sessões não reiniciam. Para determinar se um peer suporta a atualização, consulte Peer supports Refresh capability a saída do show bgp neighbor comando.
Se você configurar keep all ou keep none o peer não oferecer suporte à reinicialização da sessão, as sessões BGP associadas serão reiniciadas (aplainadas).
Topologia
Cópia de
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
Internet do roteador
set interfaces lo0 unit 0 family inet address 172.16.11.1/32 set interfaces lo0 unit 0 family inet address 172.16.12.1/32 set interfaces lo0 unit 0 family inet address 172.16.13.1/32 set interfaces lo0 unit 0 family inet address 172.16.14.1/32 set interfaces lo0 unit 0 family inet address 172.16.15.1/32 set interfaces lo0 unit 0 family inet address 192.168.9.1/32 set interfaces fe-0/1/3 unit 0 family inet address 10.0.89.14/30 set protocols bgp group toNorth local-address 10.0.89.14 set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.89.13 set protocols bgp group toNorth export into-bgp set policy-options policy-statement into-bgp term 1 from interface lo0.0 set policy-options policy-statement into-bgp term 1 then accept set routing-options router-id 192.168.9.1 set routing-options autonomous-system 300
Roteador Norte
set interfaces fe-1/3/1 unit 0 family inet address 10.0.78.14/30 set interfaces fe-1/3/0 unit 0 family inet address 10.0.89.13/30 set interfaces lo0 unit 0 family inet address 192.168.8.1/32 set protocols bgp group toInternet local-address 10.0.89.13 set protocols bgp group toInternet peer-as 300 set protocols bgp group toInternet neighbor 10.0.89.14 set protocols bgp group toSouth local-address 10.0.78.14 set protocols bgp group toSouth export conditional-export-bgp set protocols bgp group toSouth peer-as 100 set protocols bgp group toSouth neighbor 10.0.78.13 set policy-options policy-statement conditional-export-bgp term prefix_11 from protocol bgp set policy-options policy-statement conditional-export-bgp term prefix_11 from route-filter 10.11.0.0/5 orlonger set policy-options policy-statement conditional-export-bgp term prefix_11 then accept set policy-options policy-statement conditional-export-bgp term conditional-default from route-filter 0.0.0.0/0 exact set policy-options policy-statement conditional-export-bgp term conditional-default from condition prefix_11 set policy-options policy-statement conditional-export-bgp term conditional-default then accept set policy-options policy-statement conditional-export-bgp term others then reject set policy-options condition prefix_11 if-route-exists 172.16.11.1/32 set policy-options condition prefix_11 if-route-exists table inet.0 set routing-options static route 0/0 reject set routing-options router-id 192.168.8.1 set routing-options autonomous-system 200
Roteador Sul
set interfaces fe-0/1/2 unit 0 family inet address 10.0.78.13/30 set interfaces lo0 unit 0 family inet address 192.168.7.1/32 set protocols bgp group toNorth local-address 10.0.78.13 set protocols bgp group toNorth import import-selected-routes set protocols bgp group toNorth peer-as 200 set protocols bgp group toNorth neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from neighbor 10.0.78.14 set policy-options policy-statement import-selected-routes term 1 from route-filter 10.11.0.0/8 orlonger set policy-options policy-statement import-selected-routes term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement import-selected-routes term 1 then accept set policy-options policy-statement import-selected-routes term 2 then reject set routing-options router-id 192.168.7.1 set routing-options autonomous-system 100
Configuração da instalação condicional de prefixos
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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar a instalação condicional de prefixos:
Configure as interfaces do roteador que formam os links entre os três roteadores.
Router Internet [edit interfaces] user@Internet# set fe-0/1/3 unit 0 family inet address 10.0.89.14/30
Router North [edit interfaces] user@North# set fe-1/3/1 unit 0 family inet address 10.0.78.14/30 user@North# set fe-1/3/0 unit 0 family inet address 10.0.89.13/30
Router South [edit interfaces] user@South# set fe-0/1/2 unit 0 family inet address 10.0.78.13/30
Configure cinco endereços de interface de loopback na Internet do roteador para emular rotas BGP aprendidas com a Internet que devem ser importadas para a tabela de roteamento do Roteador Sul e configure um endereço adicional (192.168.9.1/32) que será configurado como o ID do roteador.
Router Internet [edit interfaces lo0 unit 0 family inet] user@Internet# set address 172.16.11.1/32 user@Internet# set address 172.16.12.1/32 user@Internet# set address 172.16.13.1/32 user@Internet# set address 172.16.14.1/32 user@Internet# set address 172.16.15.1/32 user@Internet# set address 192.168.9.1/32
Além disso, configure os endereços da interface de loopback nos roteadores Norte e Sul.
Router North [edit interfaces lo0 unit 0 family inet] user@North# set address 192.168.8.1/32
Router South [edit interfaces lo0 unit 0 family inet] user@South# set address 192.168.7.1/32
Configure a rota padrão estática no roteador Norte a ser anunciada para o Roteador Sul.
[edit routing-options] user@North# set static route 0/0 reject
Defina a condição para a exportação de prefixos da tabela de roteamento no Roteador Norte.
[edit policy-options condition prefix_11] user@North# set if-route-exists 172.16.11.1/32 user@North# set if-route-exists table inet.0
Definir políticas de exportação (
into-bgpeconditional-export-bgp) em roteadores Internet e Norte, respectivamente, para anunciar rotas para BGP.Nota:Garanta que você faça referência à condição (
prefix_11configurada em etapa 4), na política de exportação.Router Internet [edit policy-options policy-statement into-bgp ] user@Internet# set term 1 from interface lo0.0 user@Internet# set term 1 then accept
Router North [edit policy-options policy-statement conditional-export-bgp] user@North# set term prefix_11 from protocol bgp user@North# set term prefix_11 from route-filter 10.11.0.0/5 orlonger user@North# set term prefix_11 then accept user@North# set term conditional-default from route-filter 0.0.0.0/0 exact user@North# set term conditional-default from condition prefix_11 user@North# set term conditional-default then accept user@North# set term others then reject
Defina uma política de importação (
import-selected-routes) no roteador Sul para importar algumas das rotas anunciadas pelo Roteador Norte em sua tabela de roteamento.[edit policy-options policy-statement import-selected-routes ] user@South# set term 1 from neighbor 10.0.78.14 user@South# set term 1 from route-filter 10.11.0.0/8 orlonger user@South# set term 1 from route-filter 0.0.0.0/0 exact user@South# set term 1 then accept user@South# set term 2 then reject
Configure o BGP nos três roteadores para permitir o fluxo de prefixos entre os sistemas autônomos.
Nota:Garanta que você aplique as políticas de importação e exportação definidas aos respectivos grupos BGP para que o anúncio de prefixo ocorra.
Router Internet [edit protocols bgp group toNorth] user@Internet# set local-address 10.0.89.14 user@Internet# set peer-as 200 user@Internet# set neighbor 10.0.89.13 user@Internet# set export into-bgp
Router North [edit protocols bgp group toInternet] user@North# set local-address 10.0.89.13 user@North# set peer-as 300 user@North# set neighbor 10.0.89.14
[edit protocols bgp group toSouth] user@North# set local-address 10.0.78.14 user@North# set peer-as 100 user@North# set neighbor 10.0.78.13 user@North# set export conditional-export-bgp
Router South [edit protocols bgp group toNorth] user@South# set local-address 10.0.78.13 user@South# set peer-as 200 user@South# set neighbor 10.0.78.14 user@South# set import import-selected-routes
Configure o ID do roteador e o número do sistema autônomo para os três roteadores.
Nota:Neste exemplo, o ID do roteador está configurado com base no endereço IP configurado na interface lo0.0 do roteador.
Router Internet [edit routing options] user@Internet# set router-id 192.168.9.1 user@Internet# set autonomous-system 300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 100
Resultados
A partir do modo de configuração, confirme sua configuração emitindo os show interfaces, show protocols bgpe show policy-optionsshow 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.
Internet de dispositivos
user@Internet# show interfaces
fe-0/1/3 {
unit 0 {
family inet {
address 10.0.89.14/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.11.1/32;
address 172.16.12.1/32;
address 172.16.13.1/32;
address 172.16.14.1/32;
address 172.16.15.1/32;
address 192.168.9.1/32;
}
}
}
user@Internet# show protocols bgp
group toNorth {
local-address 10.0.89.14;
export into-bgp;
peer-as 200;
neighbor 10.0.89.13;
}
user@Internet# show policy-options
policy-statement into-bgp {
term 1 {
from interface lo0.3;
then accept;
}
}
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 300;
Dispositivo Norte
user@North# show interfaces
fe-1/3/1 {
unit 0 {
family inet {
address 10.0.78.14/30;
}
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.0.89.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.8.1/32;
}
}
}
user@North# show protocols bgp
group toInternet {
local-address 10.0.89.13;
peer-as 300;
neighbor 10.0.89.14;
}
group toSouth {
local-address 10.0.78.14;
export conditional-export-bgp;
peer-as 100;
neighbor 10.0.78.13;
}
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 10.11.0.0/5 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
table inet.0;
}
}
user@North# show routing-options
static {
route 0.0.0.0/0 reject;
}
router-id 192.168.8.1;
autonomous-system 200;
Dispositivo Sul
user@South# show interfaces
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.78.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.7.1/32;
}
}
}
user@South# show protocols bgp
bgp {
group toNorth {
local-address 10.0.78.13;
import import-selected-routes;
peer-as 200;
neighbor 10.0.78.14;
}
}
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
neighbor 10.0.78.14;
route-filter 10.11.0.0/8 orlonger;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}
user@South# show routing-options router-id 192.168.7.1; autonomous-system 100;
Se você terminar de configurar os roteadores, entre no commit modo de configuração.
Verificação
Confirme que a configuração está funcionando corretamente.
- Verificação do BGP
- Verificando o anúncio de prefixo da Internet do roteador para o roteador norte
- Verificando o anúncio de prefixo do roteador norte ao roteador sul
- Verificando a política de importação bgp para instalação de prefixos
- Verificando a exportação condicional do roteador norte para o roteador sul
- Verificando a presença de rotas ocultas por política (opcional)
Verificação do BGP
Propósito
Verifique se as sessões BGP foram estabelecidas entre os três roteadores.
Ação
Do modo operacional, execute o show bgp neighbor neighbor-address comando.
Verifique a sessão BGP na Internet do roteador para verificar se o roteador Norte é um vizinho.
user@Internet> show bgp neighbor 10.0.89.13 Peer: 10.0.89.13+179 AS 200 Local: 10.0.89.14+56187 AS 300 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ into-bgp ] Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.14 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.8.1 Local ID: 192.168.9.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-0/1/3.0 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) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality 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 200) 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: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 9 Sent 18 Checked 28 Input messages: Total 12 Updates 1 Refreshes 0 Octets 232 Output messages: Total 14 Updates 1 Refreshes 0 Octets 383 Output Queue[0]: 0Verifique a sessão BGP no roteador Norte para verificar se a Internet do roteador é uma vizinha.
user@North> show bgp neighbor 10.0.89.14 Peer: 10.0.89.14+56187 AS 300 Local: 10.0.89.13+179 AS 200 Type: External State: Established Flags: [ImportEval Sync] Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: [Preference LocalAddress PeerAS Refresh] Local Address: 10.0.89.13 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.9.1 Local ID: 192.168.8.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down Local Interface: fe-1/3/0.0 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) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality 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 300) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 6 Received prefixes: 6 Accepted prefixes: 6 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 14 Sent 3 Checked 3 Input messages: Total 16 Updates 2 Refreshes 0 Octets 402 Output messages: Total 15 Updates 0 Refreshes 0 Octets 348 Output Queue[0]: 0
Verifique os seguintes campos nessas saídas para verificar se as sessões BGP foram estabelecidas:
Peer— Verifique se o número do peer AS está listado.
Local— Verifique se o número de AS local está listado.
State— Garanta que o valor seja
Established. Caso não, verifique novamente a configuração e vejashow bgp neighbormais detalhes sobre os campos de saída.
Da mesma forma, verifique se os roteadores Norte e Sul formam relações entre pares entre si.
Significado
As sessões de BGP são estabelecidas entre os três roteadores.
Verificando o anúncio de prefixo da Internet do roteador para o roteador norte
Propósito
Verifique se as rotas enviadas da Internet do roteador são recebidas pelo Roteador Norte.
Ação
Do modo operacional na Internet do roteador, execute o
show route advertising-protocol bgp neighbor-addresscomando.user@Internet> show route advertising-protocol bgp 10.0.89.13 inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 Self I * 172.16.12.1/32 Self I * 172.16.13.1/32 Self I * 172.16.14.1/32 Self I * 172.16.15.1/32 Self I * 192.168.9.1/32 Self I
A saída verifica se a Internet do roteador anuncia as rotas 172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, 172.16.15.1/32 e 192.168.9.1/32 (o endereço de loopback usado como ID do roteador) para o Roteador Norte.
Do modo operacional no Roteador Norte, execute o
show route receive-protocol bgp neighbor-addresscomando.user@North> show route receive-protocol bgp 10.0.89.14 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.11.1/32 10.0.89.14 300 I * 172.16.12.1/32 10.0.89.14 300 I * 172.16.13.1/32 10.0.89.14 300 I * 172.16.14.1/32 10.0.89.14 300 I * 172.16.15.1/32 10.0.89.14 300 I * 192.168.9.1/32 10.0.89.14 300 I
A saída verifica se o roteador Norte recebeu todas as rotas anunciadas pela Internet do roteador.
Significado
Os prefixos enviados pela Internet do roteador foram instalados com sucesso na tabela de roteamento do Roteador Norte.
Verificando o anúncio de prefixo do roteador norte ao roteador sul
Propósito
Verifique se as rotas recebidas da Internet do roteador e a rota padrão estática são anunciadas pelo roteador Norte ao Roteador Sul.
Ação
Do modo operacional no Roteador Norte, execute o
show route 0/0 exactcomando.user@North> show route 0/0 exact inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:10:22 RejectA saída verifica a presença da rota padrão estática (0.0.0.0/0) na tabela de roteamento do Roteador Norte.
Do modo operacional no Roteador Norte, execute o
show route advertising-protocol bgp neighbor-addresscomando.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self I * 172.16.11.1/32 Self 300 I * 172.16.12.1/32 Self 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
A saída verifica se o roteador Norte está anunciando a rota estática e a rota 172.16.11.1/32 recebida da Internet do roteador, bem como muitas outras rotas, para o Roteador Sul.
Verificando a política de importação bgp para instalação de prefixos
Propósito
Verifique se a política de importação BGP instala com sucesso os prefixos necessários.
Ação
Veja se a política de importação no Roteador Sul está operacional verificando se apenas a rota padrão estática do Roteador Norte e a rota 172.16.11.1/32 do Roteador Sul estão instaladas na tabela de roteamento.
Do modo operacional, execute o show route receive-protocol bgp neighbor-address comando.
user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 200 I * 172.16.11.1/32 10.0.78.14 200 300 I
A saída verifica se a política de importação BGP está operacional no Roteador Sul, e apenas a rota padrão estática de 0.0.0.0/0 do Roteador Norte e a rota 172.16.11.1/32 da Internet do roteador vazaram para a tabela de roteamento no Roteador Sul.
Significado
A instalação de prefixos é bem-sucedida devido à política de importação BGP configurada.
Verificando a exportação condicional do roteador norte para o roteador sul
Propósito
Verifique se, quando a Internet do dispositivo deixar de enviar a rota 172.16.11.1/32, o Dispositivo Norte deixa de enviar a rota padrão de 0/0.
Ação
Fazer com que a Internet de dispositivos pare de enviar a rota 172.16.11.1/32 desativando o endereço 172.16.11.1/32 na interface de loopback.
[edit interfaces lo0 unit 0 family inet] user@Internet# deactivate address 172.16.11.1/32 user@Internet# commit
Do modo operacional no Roteador Norte, execute o
show route advertising-protocol bgp neighbor-addresscomando.user@North> show route advertising-protocol bgp 10.0.78.13 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.12.1/32 Self 300 I * 172.16.13.1/32 Self 300 I * 172.16.14.1/32 Self 300 I * 172.16.15.1/32 Self 300 I
A saída verifica se o roteador Norte não está anunciando a rota padrão para o Roteador Sul. Esse é o comportamento esperado quando a rota 172.16.11.1/32 não estiver presente.
Reativar o endereço 172.16.11.1/32 na interface de loopback da Internet do dispositivo.
[edit interfaces lo0 unit 0 family inet] user@Internet# activate address 172.16.11.1/32 user@Internet# commit
Verificando a presença de rotas ocultas por política (opcional)
Propósito
Verifique a presença de rotas ocultas pela política de importação configurada no Roteador Sul.
Esta seção demonstra os efeitos de várias mudanças que você pode fazer na configuração, dependendo de suas necessidades.
Ação
Veja rotas ocultas da tabela de roteamento do roteador Sul por:
Usando a opção
hiddenpara oshow route receive-protocol bgp neighbor-addresscomando.Desativando a política de importação.
Do modo operacional, execute o
show route receive-protocol bgp neighbor-address hiddencomando para ver rotas ocultas.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 172.16.12.1/32 10.0.78.14 200 300 I 172.16.13.1/32 10.0.78.14 200 300 I 172.16.14.1/32 10.0.78.14 200 300 I 172.16.15.1/32 10.0.78.14 200 300 I
A saída verifica a presença de rotas ocultas pela política de importação (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 e 172.16.15.1/32) no Roteador Sul.
Desativar a política de importação BGP configurando a
deactivate importdeclaração no nível de[edit protocols bgp group group-name]hierarquia.[edit protocols bgp group toNorth] user@South# deactivate import user@South# commit
Execute o comando do
show route receive-protocol bgp neighbor-addressmodo operacional para verificar as rotas após a desativação da política de importação.user@South> show route receive-protocol bgp 10.0.78.14 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 10.0.78.14 200 I * 172.16.11.1/32 10.0.78.14 200 300 I * 172.16.12.1/32 10.0.78.14 200 300 I * 172.16.13.1/32 10.0.78.14 200 300 I * 172.16.14.1/32 10.0.78.14 200 300 I * 172.16.15.1/32 10.0.78.14 200 300 I
A saída verifica a presença de rotas anteriormente ocultas (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32 e 172.16.15.1/32).
Ative a política de importação bgp e remova as rotas ocultas da tabela de roteamento configurando as
activate importekeep nonedeclarações, respectivamente, no nível de[edit protocols bgp group group-name]hierarquia.[edit protocols bgp group toNorth] user@South# activate import user@South# set keep none user@South# commit
Do modo operacional, execute o
show route receive-protocol bgp neighbor-address hiddencomando para verificar as rotas após ativar a política de importação e configurar akeep nonedeclaração.user@South> show route receive-protocol bgp 10.0.78.14 hidden inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
A saída verifica se as rotas ocultas não são mantidas na tabela de roteamento por causa da declaração configurada
keep none.
Filtro implícito para o comportamento padrão de propagação de rotas de EBGP sem políticas
SUMMARY Esta seção fala sobre o uso de um filtro implícito para regular o comportamento de propagação de rotas EBGP quando não há uma política explícita configurada.
Benefícios
Este recurso oferece os seguintes benefícios:
Regulates BGP implementation— Impede que os palestrantes de EBGP se tornem uma passagem silenciosa onde aceitavam e anunciavam todas as rotas por padrão. Esse recurso efetivamente reduz o aumento do tráfego de trânsito nos sistemas autônomos leaf, especialmente quando eles são multi-homed para quaisquer provedores de serviços de Internet upstream. Assim, também evita a queda silenciosa de tráfego, negação de serviço e interrupções globais na internet.
Implicit filter— A configuração facilita o uso de um filtro implícito, onde o comportamento padrão ainda está definido para receber e anunciar todas as rotas por padrão. A declaração de configuração só adiciona uma opção de especificar habilitação ou desativação para aceitar, rejeitar, rejeitar cláusulas sempre, quando necessário. O filtro implícito garante que os usuários com implantações existentes que dependem da política BGP padrão não experimentem interrupções operacionais.
Visão geral
BGP é o protocolo autônomo inter domínio atual usado para roteamento global da Internet. Ele também oferece suporte a vários serviços, como VPNs e estado de enlace, que não são destinados ao uso global.
A implementação do BGP, incluindo o comportamento padrão do EBGP, é guiada pelo RFC4271, A Border Gateway Protocol 4 (BGP-4). No entanto, ele não fornece nenhuma orientação explícita sobre a especificação de quais rotas devem ser distribuídas. Isso leva a implementação BGP original a ser uma passagem silenciosa para rotas sem filtragem e, portanto, causando um aumento no tráfego, resultando em paralisações globais na Internet.
A partir do Junos OS Release 20.3R1, introduzimos um filtro defaults ebgp no-policy implícito no nível de hierarquia existente [edit protocols bgp] . A configuração separa a política padrão para receber e anunciar, em cláusulas separadas (aceitar, rejeitar ou rejeitar sempre) para permitir que o comportamento varie de forma independente.
Se não houver uma política explícita configurada, o filtro implícito permite que você habilite o comportamento padrão de receber e anunciar o comportamento em um dos três estados da seguinte forma:
Valores |
Política padrão |
O que ela faz |
|---|---|---|
Aceitar |
Receber |
Aceita receber todas as rotas (também o comportamento padrão). |
Anunciar |
Aceita anunciar todas as rotas (também o comportamento padrão). |
|
Rejeitar |
Receber |
Rejeita receber rotas de tipo unicast de inet e unicast inet6, em casos, tipos primários, vrf, roteador virtual e não encaminhamento. |
Anunciar |
Rejeita anunciar rotas de tipo unicast de inet e unicast inet6, em casos, tipos primários, vrf, roteador virtual e não encaminhamento. |
|
rejeitar sempre |
Receber |
Rejeita receber todas as rotas. |
Anunciar |
Rejeita anunciar todas as rotas. |