Nesta página
Exemplo: Aplicação de políticas de roteamento em diferentes níveis da hierarquia BGP
Configuração de políticas de roteamento para controlar anúncios de rota BGP
Exemplo: 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
Entendendo 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 duas cotações. Cada nome da política de roteamento deve ser único em uma configuração.
Quando uma política é criada e nomeada, ela deve ser aplicada antes de estar ativa. Você aplica políticas de roteamento usando o e export as import declarações no nível da protocols protocol-name hierarquia de configuração.
import No comunicado, 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 No comunicado, 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 as 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 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
Exemplo: Aplicação de 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 do 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:
Global e
exportdeclarações do BGPimport— Inclua essas declarações no nível de[edit protocols bgp]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquica[edit routing-instances routing-instance-name protocols bgp]).Grupo
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp group group-name]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquicos[edit routing-instances routing-instance-name protocols bgp group group-name]).Peer
importandexportstatements — Inclua essas declarações no nível de[edit protocols bgp group group-name neighbor address]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquica[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]).
Um nível import ou export declaração por pares substitui um grupo import ou export uma 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 no 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 interpretado 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 send-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 das 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 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 de todos os dispositivos em Figura 1.
A seção #d99e203__d99e457 descreve as etapas do dispositivo R1.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
Dispositivo 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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do 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 interior (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 a ID do roteador e o número do sistema autônomo (AS).
[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, confirme a configuração.
[edit] user@R1# commit
Resultados
A partir do modo de configuração, confirme sua configuração emitindo os show interfacescomandos show protocolsshow policy-optionse 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@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 se a configuração está funcionando corretamente.
Verificação do aprendizado de rota BGP
Propósito
Certifique-se de que as políticas de exportação do 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.
Verificação do recebimento de rotas BGP
Propósito
Certifique-se de que as políticas de exportação do BGP estejam 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.
Em resumo, quando várias políticas são aplicadas em diferentes hierarquias de CLI no BGP, apenas o aplicativo mais específico é avaliado, para exclusão de outros aplicativos de políticas menos específicos. 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 o seu comportamento de política não é tão esperado.
Exemplo: 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 ponto a ponto BGP externas.
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
Configuração
Configuração da política de roteamento
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de hierarquia [editar] e então 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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do 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 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 este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de hierarquia [editar] e então 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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do 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 de exibição para examinar as ações da política de roteamento
Problema
A tabela de roteamento contém rotas ou rotas inesperadas que estão faltando na 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 em que o injectpolicy1 termo política analisa e age.
Configuração de políticas de roteamento para controlar anúncios de rota BGP
Todos os protocolos de roteamento usam a tabela de roteamento do 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 que você controle quais rotas 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, os filtros de firewall e o guia de usuário dos policiais de tráfego.
Ao configurar a política de roteamento BGP, você pode executar as seguintes tarefas:
- Aplicação da política de roteamento
- Configuração do BGP para anunciar rotas inativas
- Configuração do BGP para anunciar a melhor rota externa para pares internos
- Configurando a frequência com que o BGP troca rotas com a tabela de roteamento
- Desativação da supressão de anúncios de rota
Aplicação da política de roteamento
Você define a política de roteamento no nível hierárquica [edit policy-options] . Para aplicar políticas definidas para BGP, inclua as declarações e export as import declarações dentro da configuração do BGP.
Você pode aplicar políticas da seguinte forma:
Global e
exportdeclarações do BGPimport— Inclua essas declarações no nível de[edit protocols bgp]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquica[edit routing-instances routing-instance-name protocols bgp]).Grupo
importeexportdeclarações — Inclua essas declarações no nível de[edit protocols bgp group group-name]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquicos[edit routing-instances routing-instance-name protocols bgp group group-name]).Peer
importandexportstatements — Inclua essas declarações no nível de[edit protocols bgp group group-name neighbor address]hierarquia (para instâncias de roteamento, incluam essas declarações no nível hierárquica[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]).
Um nível import ou export declaração por pares substitui um grupo import ou export uma 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 para a 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 para a tabela de roteamento a partir do BGP
Para aplicar políticas à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 em que você possa incluir esta declaração, veja 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 políticas às rotas que estão sendo exportadas da tabela de roteamento para 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 em que você possa incluir esta declaração, veja 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 não houver rotas compatíveis com os filtros, a tabela de roteamento exporta para o BGP apenas as rotas que aprendeu com o BGP.
Configuração do 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 em que você possa incluir esta declaração, veja 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, as 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 particular, 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 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 discriminatória 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 a configuração de uma política de exportação BGP que corresponde ao estado de uma rota anunciada. Você pode combinar em rotas ativas ou inativas. Para obter mais informações, veja as políticas de roteamento, filtros de firewall e guia de usuários de 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 tanto no nível do grupo quanto 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 rota chegar ao ponto em que o valor do MED é avaliado, inclua a conditional declaração:
advertise-external {
conditional;
}
Configurando a frequência com que 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 então anuncia 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 acessibilidade da rede. Para se proteger disso, você pode atrasar o tempo entre quando 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 de 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, veja 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 que foram aprendidas com o BGP, exceto para rotas cujo caminho 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 recusadas pela política de importação ou outra verificação 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, o Junos OS força a readvertisement do conjunto completo de rotas anunciados pelo peer.
Em uma situação de cura do caminho 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 é alterado. No entanto, há uma diferença significativa de uso de memória entre o padrão e keep all.
Considere os seguintes cenários:
Um peer readvertises rotas de volta para o peer do 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 peer do Junos OS de não readvertisar 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 nenhuma das metas de rota esperadas.
Quando keep all está configurado, o comportamento de descartar rotas recebidas nos cenários acima é substituído.
Desativação da supressão de anúncios de rota
O Junos OS não anuncia as rotas aprendidas com um peer EBGP de volta para o mesmo peer BGP externo (EBGP). Além disso, o software não anuncia essas rotas de volta para nenhum peers de EBGP que estejam no mesmo que os peer originários, independentemente da instância de roteamento. Você pode modificar esse comportamento incluindo a advertise-peer-as declaração na configuração. Para desativar a supressão padrão do anúncio, inclua a advertise-peer-as declaração:
advertise-peer-as;
O comportamento padrão de supressão de rota é desativado se a as-override declaração estiver 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, veja a seção de resumo da declaração para essas declarações.
Consulte também
Exemplo: Configuração de uma política de roteamento para anunciar a melhor rota externa para pares internos
A especificação do protocolo BGP, conforme definido na RFC 1771, especifica que um peer BGP deve anunciar a seus pares internos o caminho externo de maior preferência, mesmo que esse caminho não seja o melhor geral (em outras palavras, 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 é dimensionado 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 na RFC 1771, de anunciar a melhor rota externa pode ser benéfico. Limitar as informações do caminho nem sempre é desejável, pois a diversidade de caminhos pode ajudar a reduzir os tempos de restauração. Publicidade O melhor caminho externo também pode resolver problemas internos de oscilação de rota BGP (IBGP), conforme descrito na RFC 3345, Condição de oscilação persistente de rota (BGP) do Border Gateway Protocol (BGP).
A advertise-external declaração modifica o comportamento de um orador 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 tanto no nível do grupo quanto 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 rota chegar ao ponto em que a métrica discriminatória de saída múltipla (MED) é avaliada. Assim, uma rota externa não é anunciada se tiver, por exemplo, um caminho DE 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 se a opção conditional estiver configurada ou não.
O Junos OS também oferece suporte para a configuração de 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 qualificador 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 corresponde a 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 tais rotas a partir 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 (EBGP) externa ao dispositivo R1. O dispositivo R2 tem uma conexão IBGP com o dispositivo R3.
O 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 é anunciado 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 no 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 rota), 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 estar totalmente em malha para evitar o envio de anúncios de rota 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 de todos os dispositivos em Figura 2.
A seção #d102e166__d102e344 descreve as etapas do dispositivo R2.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
Dispositivo 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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar o dispositivo 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 interior (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 noshow interfaces, show protocolsshow policy-optionse show routing-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@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 se a configuração está funcionando corretamente.
- Verificando o caminho ativo do BGP
- Verificando o anúncio da rota externa
- Verificação da rota no dispositivo R3
- Experimentar a opção condicional
Verificando o caminho ativo do BGP
Propósito
No dispositivo R2, certifique-se de que o prefixo 172.16.6.0/24 esteja 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 tanto do dispositivo R1 quanto 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 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.
Verificação da 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.
Exemplo: 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 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 indesejadas, o envio de peer economiza recursos necessários para gerar e transmitir atualizações, e o peer receptor economiza recursos necessários para processar atualizações. Esse recurso pode ser útil, por exemplo, em uma rede virtual privada (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 comunicar ao 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 será gerada.
Você pode configurar a interoperabilidade para o dispositivo de roteamento como um todo ou apenas para grupos BGP específicos ou pares.
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.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar o Roteador PE1 para aceitar filtros de rota do dispositivo CE1 e realizar filtragem de rota de saída usando os filtros recebidos:
Configure o sistema autônomo local.
[edit routing-options] user@PE1# set autonomous-system 65500
Configure o 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 rota 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 se 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
A partir 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 vizinho BGP
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 show bgp neighbor saída de comando.
Ação
A partir 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 o encaminhamento de 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 um 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 acorrenta 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 que você configure é executada (por meio da ação implícita de próxima política) para cada rota. Assim, você pode anular 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
Exemplo: Substituindo a política padrão de roteamento BGP em 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 habitual 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 está 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.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
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 na CLI, consulte Usando o 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 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 se 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 substitui a política padrão.
Ação
A partir 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 são geralmente 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 entre 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 em 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 para a Internet e, em vez disso, estar recebendo 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 poderá 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 obter 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 malicioso enviar tráfego BGP inesperado ou indesejável para 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 com a 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 são apenas vinculadas por relações físicas, mas por negócios ou outras relações organizacionais. Um AS pode fornecer serviços a outra organização ou agir como um AS de trânsito entre duas outras ASs. Essas ASs de trânsito são vinculadas por acordos contratuais entre as partes que incluem parâmetros sobre como se conectar entre si e, o mais importante, o tipo e a quantidade de tráfego que transportam entre si. Portanto, por razões legais e financeiras, 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 nocivas. A filtragem de rotas convencional examina os atributos de uma rota e aceita ou rejeita a rota com base em tais atributos. Uma política ou filtro pode examinar o conteúdo do AS-Path, o valor do próximo salto, um valor de 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 corresponder a 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 acessibilidade para outras redes ainda mais upstream. Esta instalação de rota condicional evita a instalação de uma rota padrão que é usada para enviar tráfego para este 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.
Exemplo: Configurar uma política de roteamento para anúncio condicional que permite a instalação condicionada de prefixos em uma tabela de roteamento explica como a instalação condicional de prefixos pode ser configurada e verificada.
Consulte também
Política de anúncio e importação condicionais (Tabela de roteamento) com determinadas condições de correspondência
O BGP aceita todas as rotas sem loop aprendidas com os vizinhos e as importa para a tabela RIB-In. Se essas rotas forem aceitas pela política de importação do BGP, elas serão entã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 disposições de forma 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: 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.
As condições das 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 do 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 condicionada de prefixos, uma política de exportação deve ser configurada no dispositivo onde a exportação do prefixo deve ocorrer. A política de exportação avalia cada rota para verificar se ela satisfaz todas as condições de correspondência nos termos da from declaração. Ele também busca 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 condicionada 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 a serem exportados da tabela de roteamento.
[edit] protocols bgp { group group-name { export policy-name; } }
Consulte também
Exemplo: 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 do BGP.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Roteadores de borda multisserviço da Série M, plataformas de roteamento universal 5G da Série MX ou roteadores de núcleo da Série T
Versão 9.0 ou posterior do Junos OS
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. A Internet rotulada pelo roteador, 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 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 para o 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.
O Roteador Norte exporta as rotas BGP 172.16.0.0/16 que aprende da Internet do Roteador ao Roteador Sul. Essas rotas podem representar as rotas de propriedade do domínio do roteador da Internet. Além disso, quando a rota específica 172.16.11.1/32 está presente, o Roteador Norte também anuncia uma rota padrão. A rota 172.16.11.1 pode representar o enlace do roteador de Internet a um provedor de peering de trânsito de nível 1 que oferece conectividade de internet completa.
O Roteador Sul recebe todas as seis rotas, mas deve apenas instalar a rota padrão e uma outra rota específica (172.16.11.1/32) em sua tabela de roteamento.
Para resumir, o exemplo atende aos seguintes requisitos:
-
Na Região Norte, envie todos os prefixos de 172,16/16. Além disso, envie também 0/0 para o Sul apenas se uma rota específica estiver presente na tabela de roteamento inet.0 ( neste exemplo 172.16.11.1/32).
-
No Sul, aceite e instale a rota padrão e a rota 172.16.11.1/32 nas tabelas de roteamento e encaminhamento. Solte todas as outras rotas. Considere que o Sul pode ser um dispositivo de ponta inferior que não pode aceitar uma tabela completa de roteamento da Internet. Como resultado, o operador só quer que a South tenha a rota 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 172.16.0.0/16 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 172.16.11.1/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
Neste exemplo, quatro rotas são perdidas como resultado da política de importação no Sul. Isso porque a política de exportação sobre o 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 manté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 largue totalmente as rotas que estão sendo recusadas pela política de importação.
Rotas ocultas podem ser visualizadas 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 AS é em loop. (O caminho 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 recusadas pela 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 suportam a atualização da rota, o orador 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, verifique 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 (flapped).
Topologia
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
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 65200 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 65300
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 65300 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 65100 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 172.16.0.0/16 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 65200
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 65200 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 172.16.11.1/32 exact 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 65100
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 na CLI, consulte Usando o 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 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
Definir a condição para 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) nos roteadores Internet e Norte, respectivamente, para anunciar rotas para BGP.Nota:Certifique-se de fazer referência à condição
prefix_11(configurada 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 172,16.0.0/16 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
Definir 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 172.16.11.1/32 exact 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:Certifique-se de aplicar as políticas definidas de importação e exportação 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 65200 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 65300 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 65100 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 65200 user@South# set neighbor 10.0.78.14 user@South# set import import-selected-routes
Configure a ID do roteador e o número do sistema autônomo para os três roteadores.
Nota:Neste exemplo, a ID do roteador está configurada 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 65300
Router North [edit routing options] user@North# set router-id 192.168.8.1 user@North# set autonomous-system 65200
Router South [edit routing options] user@South# set router-id 192.168.7.1 user@South# set autonomous-system 65100
Resultados
A partir do modo de configuração, confirme sua configuração emitindo os show interfacescomandos show protocols bgpshow policy-optionse 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.
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 65200;
neighbor 10.0.89.13;
}
user@Internet# show policy-options
policy-statement into-bgp {
term 1 {
from interface lo0.0;
then accept;
}
}
user@Internet# show routing-options router-id 192.168.9.1; autonomous-system 65300;
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 65300;
neighbor 10.0.89.14;
}
group toSouth {
local-address 10.0.78.14;
export conditional-export-bgp;
peer-as 65100;
neighbor 10.0.78.13;
}
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 172.16.0.0/16 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 65200;
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 65200;
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 172.16.11.1 exact;
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 65100;
Se você terminar de configurar os roteadores, entre no commit modo de configuração.
Verificação
Confirme se a configuração está funcionando corretamente.
- Verificação do BGP
- Verificação do anúncio de prefixo da Internet do roteador para o roteador norte
- Verificação do anúncio de prefixo do roteador norte ao roteador sul
- Verificação da política de importação do BGP para instalação de prefixos
- Verificação da 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 de BGP foram estabelecidas entre os três roteadores.
Ação
A partir 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 65200 Local: 10.0.89.14+56187 AS 65300 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 65200) 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 65300 Local: 10.0.89.13+179 AS 65200 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 65300) 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 de AS do peer está listado.
Local— Verifique se o número de AS local está listado.
State— Garanta que o valor seja
Established. Se 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 estão estabelecidas entre os três roteadores.
Verificação do 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 65300 I * 172.16.12.1/32 10.0.89.14 65300 I * 172.16.13.1/32 10.0.89.14 65300 I * 172.16.14.1/32 10.0.89.14 65300 I * 172.16.15.1/32 10.0.89.14 65300 I * 192.168.9.1/32 10.0.89.14 65300 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.
Verificação do anúncio de prefixo do roteador norte ao roteador sul
Propósito
Verifique se as rotas recebidas da Internet do roteador e da 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 65300 I * 172.16.12.1/32 Self 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 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 de muitas outras rotas, para o Roteador Sul.
Verificação da política de importação do BGP para instalação de prefixos
Propósito
Verifique se a política de importação do BGP instala com sucesso os prefixos necessários.
Ação
Veja se a política de importação do 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.
A partir 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 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 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.
Verificação da exportação condicional do roteador norte para o roteador sul
Propósito
Verifique se quando a Internet do dispositivo parar 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 65300 I * 172.16.13.1/32 Self 65300 I * 172.16.14.1/32 Self 65300 I * 172.16.15.1/32 Self 65300 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 das 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.Desativação da política de importação.
Do modo operacional, execute o
show route receive-protocol bgp neighbor-address hiddencomando para visualizar 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 65200 65300 I 172.16.13.1/32 10.0.78.14 65200 65300 I 172.16.14.1/32 10.0.78.14 65200 65300 I 172.16.15.1/32 10.0.78.14 65200 65300 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 65200 I * 172.16.11.1/32 10.0.78.14 65200 65300 I * 172.16.12.1/32 10.0.78.14 65200 65300 I * 172.16.13.1/32 10.0.78.14 65200 65300 I * 172.16.14.1/32 10.0.78.14 65200 65300 I * 172.16.15.1/32 10.0.78.14 65200 65300 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 do BGP e remova as rotas ocultas da tabela de roteamento configurando as declarações e
keep noneasactivate importdeclaraçõ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
A partir 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 devido à 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 rota 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 alto-falantes de EBGP se tornem uma passagem silenciosa onde ele aceitou e anunciou todas as rotas por padrão. Esse recurso reduz efetivamente o aumento do tráfego de trânsito em 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 do 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 a ativação ou desativação para aceitar, rejeitar, rejeitar sempre cláusulas, 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 do link, que não são destinados ao uso global.
A implementação do BGP, incluindo o comportamento padrão do EBGP, é guiada por RFC4271, A Border Gateway Protocol 4 (BGP-4). No entanto, 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 um repasse silencioso para rotas sem nenhuma filtragem e, portanto, causando um aumento no tráfego, resultando em interrupçõ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 recebimento e anúncio do eBGP em um dos três estados da seguinte forma:
Valores |
Política padrão |
O que ele 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 instâncias dos tipos primário, vrf, roteador virtual e não encaminhamento. |
anunciar |
Rejeita anunciar rotas de tipo unicast de inet e unicast inet6 em instâncias dos tipos primário, vrf, roteador virtual e não encaminhamento. |
|
rejeitar sempre |
receber |
Rejeita receber todas as rotas. |
anunciar |
Rejeita anunciar todas as rotas. |