Preferências de rota estáticas e próximas hops qualificados
Entender as preferências de rota estáticas e os próximos hops qualificados
Um endereço de destino de rota estático pode ter vários hops próximos associados a ele. Nesse caso, várias rotas são inseridas na tabela de roteamento, e a seleção de rotas deve ocorrer. Como o critério principal para a seleção de rotas é a preferência de rota, você pode controlar as rotas que são usadas como a rota primária para um determinado destino, definindo a preferência de rota associada a um próximo salto específico. As rotas com menor preferência de rota são sempre usadas para rotear o tráfego. Quando você não define uma rota preferida, o Junos OS escolhe de forma aleatória um dos endereços next-hop para instalar na tabela de encaminhamento.
Em geral, as propriedades padrão atribuídas a uma rota estática aplicam-se a todos os endereços next-hop configurados para a rota estática. Se, no entanto, você quiser configurar dois endereços de next-hop possíveis para uma rota específica e tê-los tratados de maneira diferente, você pode definir um como um próximo hop qualificado.
Os próximos hops qualificados permitem que você associe uma ou mais propriedades com um endereço next-hop específico. Você pode definir uma preferência geral por uma rota estática específica e, em seguida, especificar uma preferência diferente para o próximo hop qualificado. Por exemplo, suponha que dois endereços next-hop (10.10.10.10 e 10.10.10.7) estejam associados à rota estática 192.168.47.5/32. Uma preferência geral é atribuída a toda a rota estática e, em seguida, uma preferência diferente é atribuída apenas ao endereço next-hop qualificado 10.10.10.7. Por exemplo:
route 192.168.47.5/32 {
next-hop 10.10.10.10;
qualified-next-hop 10.10.10.7 {
preference 6;
}
preference 5;
}
Neste exemplo, o próximo hop qualificado 10.10.10.7 é atribuído a preferência 6, e o next-hop 10.10.10.10 é atribuído a preferência 5.
A e metric as preference opções na [edit route route qualified-next-hop] hierarquia só se aplicam aos próximos hops qualificados. A preferência e a métrica de next-hop qualificadas substituem a preferência e a métrica de rota para esse próximo hop qualificado específico, semelhante à forma como a preferência de rota substitui a preferência e a métrica padrão (para essa rota específica).
A partir do Junos OS Release 15.1R4, o roteador não oferece mais suporte a uma configuração onde uma rota estática aponta para um próximo salto vinculado a um assinante. Normalmente, isso pode ocorrer quando o RADIUS atribui o próximo salto com o atributo Framed-IP-Address. Uma alternativa a essa configuração incorreta é fazer com que o servidor RADIUS forneça um atributo de rota emoldurada que corresponda à rota estática.
Exemplo: configurar preferências de rota estáticas e qualificar next hops para controlar a seleção de rotas estáticas
Este exemplo mostra como controlar a seleção de rotas estáticas.
Requisitos
Neste exemplo, nenhuma configuração especial além da inicialização do dispositivo é necessária.
Visão geral
Neste exemplo, a rota estática 192.168.47.0/24 tem dois próximos hops possíveis. Como um link tem maior largura de banda, esse link é o caminho preferido. Para aplicar essa preferência, a qualified-next-hop declaração está incluída na configuração em ambos os dispositivos. Veja a Figura 1.
Topologia
Configuração
Procedimento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
Dispositivo B em rede de provedor
set interfaces ge-1/2/0 unit 0 description B->D set interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24 set interfaces fe-1/2/1 unit 2 description secondary-B->D set interfaces fe-1/2/1 unit 2 family inet address 192.168.2.1/24 set interfaces lo0 unit 57 family inet address 10.0.0.1/32 set interfaces lo0 unit 57 family inet address 10.0.0.2/32 set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2 set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 preference 25
Dispositivo D na rede do cliente
set interfaces ge-1/2/0 unit 1 description D->B set interfaces ge-1/2/0 unit 1 family inet address 172.16.1.2/24 set interfaces fe-1/2/1 unit 3 description secondary-D->B set interfaces fe-1/2/1 unit 3 family inet address 192.168.2.2/24 set interfaces lo0 unit 2 family inet address 192.168.47.5/32 set interfaces lo0 unit 2 family inet address 192.168.47.6/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1 set routing-options static route 0.0.0.0/0 qualified-next-hop 192.168.2.1 preference 25
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para controlar a seleção de rotas estáticas:
No dispositivo B, configure as interfaces.
[edit interfaces] user@B# set ge-1/2/0 unit 0 description B->D user@B# set ge-1/2/0 unit 0 family inet address 172.16.1.1/24 user@B# set fe-1/2/1 unit 2 description secondary-B->D user@B# set fe-1/2/1 unit 2 family inet address 192.168.2.1/24 user@B# set lo0 unit 57 family inet address 10.0.0.1/32 user@B# set lo0 unit 57 family inet address 10.0.0.2/32
No dispositivo B, configure uma rota estática para a rede do cliente.
[edit routing-options static route 192.168.47.0/24] user@B# set next-hop 172.16.1.2
No dispositivo B, configure uma rota de backup para a rede do cliente.
[edit routing options static route 192.168.47.0/24] user@B# set qualified-next-hop 192.168.2.2 preference 25
No dispositivo D, configure as interfaces.
[edit interfaces] user@D# set ge-1/2/0 unit 1 description D->B user@D# set ge-1/2/0 unit 1 family inet address 172.16.1.2/24 user@D# set fe-1/2/1 unit 3 description secondary-D->B user@D# set fe-1/2/1 unit 3 family inet address 192.168.2.2/24 user@D# set lo0 unit 2 family inet address 192.168.47.5/32 user@D# set lo0 unit 2 family inet address 192.168.47.6/32
No dispositivo D, configure uma rota padrão estática para redes externas.
[edit routing options static route 0.0.0.0/0] user@D# set next-hop 172.16.1.1
No dispositivo D, configure uma rota padrão estática de backup para redes externas.
[edit routing options static route 0.0.0.0/0] user@D# set qualified-next-hop 192.168.2.1 preference 25
Resultados
Confirme sua configuração emitindo os e show routing-options comandosshow interfaces. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@B# show interfaces
ge-1/2/0 {
unit 0 {
description B->D;
family inet {
address 172.16.1.1/24;
}
}
}
fe-1/2/1 {
unit 2 {
description secondary-B->D;
family inet {
address 192.168.2.1/24;
}
}
}
lo0 {
unit 57 {
family inet {
address 10.0.0.1/32;
address 10.0.0.2/32;
}
}
}
user@B# show routing-options
static {
route 192.168.47.0/24 {
next-hop 172.16.1.2;
qualified-next-hop 192.168.2.2 {
preference 25;
}
}
}
user@D# show interfaces
ge-1/2/0 {
unit 1 {
description D->B;
family inet {
address 172.16.1.2/24;
}
}
}
fe-1/2/1 {
unit 3 {
description secondary-D->B;
family inet {
address 192.168.2.2/24;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.47.5/32;
address 192.168.47.6/32;
}
}
}
user@D# show routing-options
static {
route 0.0.0.0/0 {
next-hop 172.16.1.1;
qualified-next-hop 192.168.2.1 {
preference 25;
}
}
}
Se você terminar de configurar os dispositivos, insira o commit a partir do modo de configuração em ambos os dispositivos.
Verificação
Confirme que a configuração está funcionando corretamente.
- Verificando as tabelas de roteamento
- Pingando os endereços remotos
- Garantir que a rota de backup se torne a rota ativa
Verificando as tabelas de roteamento
Propósito
Certifique-se de que as rotas estáticas apareçam nas tabelas de roteamento do Dispositivo B e do Dispositivo D.
Ação
user@B> show route protocol static
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.47.0/24 *[Static/5] 02:02:03
> to 172.16.1.2 via ge-1/2/0.0
[Static/25] 01:58:21
> to 192.168.2.2 via fe-1/2/1.2
user@D> show route protocol static
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 02:02:12
> to 172.16.1.1 via ge-1/2/0.1
[Static/25] 01:58:31
> to 192.168.2.1 via fe-1/2/1.3
Significado
Os asterisco (*) nas tabelas de roteamento mostram as rotas ativas. As rotas de backup estão listadas a seguir.
Pingando os endereços remotos
Propósito
Verifique se as rotas estáticas estão funcionando.
Do dispositivo B, ping um dos endereços da interface de loopback no Dispositivo D.
Do dispositivo D, ping um dos endereços da interface de loopback no dispositivo B.
Ação
user@B> ping 192.168.47.5 PING 192.168.47.5 (192.168.47.5): 56 data bytes 64 bytes from 192.168.47.5: icmp_seq=0 ttl=64 time=156.126 ms 64 bytes from 192.168.47.5: icmp_seq=1 ttl=64 time=120.393 ms 64 bytes from 192.168.47.5: icmp_seq=2 ttl=64 time=175.361 ms
user@D> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.315 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=31.819 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.268 ms
Garantir que a rota de backup se torne a rota ativa
Propósito
Se a rota primária se tornar inutilizável, certifique-se de que a rota secundária de backup fique ativa.
Ação
Desativar a rota ativa desativando a interface ge-1/2/0.0 no dispositivo B.
user@B# deactivate interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24 user@B# commit
Verifique a tabela de roteamento do dispositivo B.
user@B> show route protocol static inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.47.0/24 *[Static/25] 02:06:24 > to 192.168.2.2 via fe-1/2/1.2
Significado
A rota de backup tornou-se a rota ativa.
Conservação de endereços IP usando rotas estáticas
Os provedores de hospedagem hospedam vários servidores para vários clientes e querem conservar o uso de seu espaço de endereço IP. Tradicionalmente, quando um cliente provedor de hospedagem adiciona novos servidores, os servidores são alocados em um pequeno bloco de endereços IP, como um bloco de /29, e os servidores do cliente estão todos localizados nesse bloco de endereços IP.
A questão, Ilustrada
Por exemplo, o Cliente A pode precisar de três servidores e recebe o bloco 10.3.3.0/29 (10.3.3.0 a 10.3.3.7). Nesse cenário, vários endereços IP são consumidos. Estes incluem os endereços IP de rede e broadcast (10.3.3.0 e 10.3.3.7), os endereços para o gateway de roteador ao qual os servidores estão conectados e os endereços dos servidores individuais. Para alocar três servidores, oito endereços IP precisam ser alocados. Dividir uma única rede /24 em 32/29 redes resulta em 96 endereços IP dos 256, nesse /24 está sendo consumido pela rede, broadcast e endereços de gateway. Quando esse efeito é multiplicado em milhares de provedores de hospedagem, o espaço de endereço IP está longe de ser usado de maneira eficiente. A Figura 2 ilustra o problema.
de endereço IP
Nesta configuração, cada cliente é alocado em um bloco de /29 de espaço de endereço. Para cada bloco, os endereços de rede, broadcast e gateway não estão disponíveis para endereçamento IP de servidor, o que resulta em três endereços IP sendo usados de forma ineficiente. Além disso, os blocos consomem endereços IP não usados para expansão futura.
Solução
Esse problema pode ser resolvido configurando a interface no roteador com um endereço do prefixo IPv4 reservado para espaço de endereço compartilhado (RFC 6598) e usando rotas estáticas apontadas para interfaces. A IANA registrou a alocação de um IPv4/10 para uso como espaço de endereço compartilhado. A faixa de endereço de endereço compartilhado é de 100.64.0.0/10.
A interface do roteador é alocada em um endereço IP a partir do espaço RFC 6598, por isso não está consumindo espaço de endereço roteável publicamente, e a conectividade é tratada com rotas estáticas em uma interface. A interface do servidor está configurada com um endereço roteável publicamente, mas as interfaces do roteador não são. Os endereços de rede e broadcast são consumidos do espaço RFC 6598 em vez do espaço de endereço roteável publicamente.
Esse recurso é suportado em switches QFX10000 a partir do Junos OS 17.1R1.
A Figura 3 mostra o uso eficiente do espaço de endereço IP.
de endereço compartilhado
Nesta configuração, cada cliente recebe endereços IP individuais alocados por servidor. Existe uma rota estática que pode ser configurada como uma rota de hospedagem. A interface do roteador recebe um endereço IP do espaço RFC 6598 para que ele não consuma espaço de endereço roteável publicamente, e a conectividade é tratada com rotas estáticas para uma interface.
Configuração
A configuração seria assim para o Cliente A no roteador de gateway:
interfaces {
ge-1/0/1 {
unit 0 {
family inet {
address 100.64.0.1/30;
}
}
}
}
routing-options {
static {
route 203.0.113.10/32 {
qualified-next-hop ge-1/0/1.0;
}
route 203.0.113.11 {
qualified-next-hop ge-1/0/1.0;
}
}
}
Com essa configuração, nenhum endereço IP roteável publicamente é desperdiçado. Vale destacar que, quando um pacote é encaminhado nesta configuração do roteador para o servidor do servidor do Cliente A 203.0.113.10, a rota é encaminhada para a interface ge-1/0/1.0 que tem um endereço IP de 100.64.0.1.
Os servidores para o cliente A seriam configurados da seguinte forma:
ifconfig eth0 203.0.113.10 netmask 255.255.255.255route add -host 100.64.0.1/32 dev eth0 route add default gw 100.64.0.1
ifconfig eth0 203.0.113.11 netmask 255.255.255.255route add -host 100.64.0.1/32 dev eth0 route add default gw 100.64.0.1
Este exemplo mostra uma única rota de host por servidor, que é um mapeamento de 1:1. Isso pode equivaler a um grande número de rotas de host estáticas, se mantidas. Para fins de escalonamento, precisamos dar suporte a rotas nãohost nesse ambiente. Por exemplo, se houvesse um Cliente C nessa configuração que tivesse oito servidores, seria muito mais eficiente alocar uma rota /29 no roteador que aponta a interface na qual os oito servidores estão conectados. Se o Cliente C fosse alocado IPs de servidor de 203.0.114.8 a 203.0.114.15 e estes fossem conectados por meio da interface ge-1/0/2.0, isso se pareceria:
user@host# set routing-options static route 203.0.114.8/29 qualified-next-hop ge-1/0/2.0
Entender o controle de rotas estáticas nas tabelas de roteamento e encaminhamento
Você pode controlar a importação de rotas estáticas para as tabelas de roteamento e encaminhamento de várias maneiras. As maneiras primárias incluem atribuir um ou mais dos seguintes atributos à rota:
reter — mantém a rota na tabela de encaminhamento após o processo de roteamento ser desligado ou reinicializar o dispositivo.
sem readvertise — impede que a rota seja readvertida para outros protocolos de roteamento.
passiva — rejeita o tráfego destinado à rota.
Este tópico inclui as seguintes seções:
Retenção de rotas
Por padrão, as rotas estáticas não são retidas na tabela de encaminhamento quando o processo de roteamento é encerrado. Quando o processo de roteamento começar novamente, quaisquer rotas configuradas como rotas estáticas devem ser adicionadas novamente à tabela de encaminhamento. Para evitar essa latência, as rotas podem ser sinalizadas como retenções, de modo que sejam mantidas na tabela de encaminhamento mesmo após o encerramento do processo de roteamento. A retenção garante que as rotas estejam sempre na tabela de encaminhamento, mesmo imediatamente após uma reinicialização do sistema.
Prevenção de ververtisement
Rotas estáticas são elegíveis para versões de leitura por outros protocolos de roteamento por padrão. Em uma área onde talvez você não queira ler essas rotas estáticas em nenhuma circunstância, você pode sinalizar as rotas estáticas como sem readvertise.
Rejeição forçada do tráfego de rotas passivas
Geralmente, apenas rotas ativas estão incluídas nas tabelas de roteamento e encaminhamento. Se o endereço next-hop de uma rota estática for inalcançável, a rota estará marcada como passiva e não estiver incluída nas tabelas de roteamento ou encaminhamento. Para forçar uma rota a ser incluída nas tabelas de roteamento, independentemente da acessibilidade do next-hop, você pode sinalizar a rota como passiva. Se uma rota for sinalizada passiva e seu endereço next-hop for inalcançável, a rota estará incluída na tabela de roteamento e todo o tráfego destinado à rota for rejeitado.
Exemplo: impedir que uma rota estática seja readvertida
Este exemplo mostra como evitar que uma rota estática seja readvertida no OSPF, impedindo assim que a rota apareçam nas tabelas de roteamento e encaminhamento.
Requisitos
Neste exemplo, nenhuma configuração especial além da inicialização do dispositivo é necessária.
Visão geral
Este exemplo mostra como configurar uma política de roteamento que readverte rotas estáticas para o OSPF, com exceção de uma rota estática que não é readvertida porque está marcada com a no-readvertise declaração.
Topologia
A Figura 4 mostra a rede amostral.
Configuração
Procedimento
- Configuração rápida da CLI
- Procedimento passo a passo
- Procedimento passo a passo
- Procedimento passo a passo
- Resultados
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
Dispositivo A
set interfaces fe-1/2/0 unit 4 description A->B set interfaces fe-1/2/0 unit 4 family inet address 10.0.2.2/30 set protocols ospf area 0.0.0.0 interface fe-1/2/0.4
Dispositivo B
set interfaces fe-1/2/0 unit 3 description B->A set interfaces fe-1/2/0 unit 3 family inet address 10.0.2.1/30 set interfaces fe-1/2/1 unit 6 description B->C set interfaces fe-1/2/1 unit 6 family inet address 10.0.3.1/30 set protocols bgp group ext type external set protocols bgp group ext peer-as 23 set protocols bgp group ext neighbor 10.0.3.2 set protocols ospf export send-static set protocols ospf area 0.0.0.0 interface fe-1/2/0.3 set policy-options policy-statement send-static from protocol static set policy-options policy-statement send-static then accept set routing-options static route 0.0.0.0/0 next-hop 10.0.3.2 set routing-options static route 192.168.0.0/24 next-hop 10.0.3.2 set routing-options static route 192.168.0.0/24 no-readvertise set routing-options autonomous-system 17
Dispositivo C
set interfaces fe-1/2/0 unit 7 description B->C set interfaces fe-1/2/0 unit 7 family inet address 10.0.3.2/30 set interfaces lo0 unit 5 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 17 set protocols bgp group ext neighbor 10.0.3.1 set routing-options autonomous-system 23
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar o dispositivo A:
Configure a interface para o dispositivo B.
[edit interfaces fe-1/2/0 unit 4] user@A# set description A->B user@A# set family inet address 10.0.2.2/30
Configure o OSPF para formar uma relação de peer do OSPF com o Dispositivo B.
[edit protocols ospf area 0.0.0.0] user@A# set interface fe-1/2/0.4
Procedimento passo a passo
Para configurar o dispositivo B:
Configure as interfaces para o dispositivo A e o dispositivo C.
[edit interfaces] user@B# set fe-1/2/0 unit 3 description B->A user@B# set fe-1/2/0 unit 3 family inet address 10.0.2.1/30 user@B# set fe-1/2/1 unit 6 description B->C user@B# set fe-1/2/1 unit 6 family inet address 10.0.3.1/30
Configure uma ou mais rotas estáticas e o número do sistema autônomo (AS).
[edit routing-options] user@B# set static route 0.0.0.0/0 next-hop 10.0.3.2 user@B# set static route 192.168.0.0/24 next-hop 10.0.3.2 user@B# set autonomous-system 17
Configure a política de roteamento.
Essa política exporta rotas estáticas da tabela de roteamento para o OSPF.
[edit policy-options policy-statement send-static] user@B# set from protocol static user@B# set then accept
Inclua a
no-readvertisedeclaração para impedir que a rota 192.168.0.0/24 seja exportada para o OSPF.[edit routing-options] user@B# set static route 192.168.0.0/24 no-readvertise
Configure os protocolos de roteamento.
A configuração BGP forma uma relação de peer BGP (EBGP) externa com o dispositivo C.
A configuração do OSPF forma uma relação de peer dos OSPF com o Dispositivo A e aplica a política de roteamento estático de envio .
[edit protocols] user@B# set bgp group ext type external user@B# set bgp group ext peer-as 23 user@B# set bgp group ext neighbor 10.0.3.2 user@B# set ospf export send-static user@B# set ospf area 0.0.0.0 interface fe-1/2/0.3
Procedimento passo a passo
Para configurar o dispositivo C:
Crie a interface para o dispositivo B e configure a interface de loopback.
[edit interfaces ] user@C# set fe-1/2/0 unit 7 description B->C user@C# set fe-1/2/0 unit 7 family inet address 10.0.3.2/30 user@C# set lo0 unit 5 family inet address 192.168.0.1/32
Configure a sessão de peering EBGP com o dispositivo B.
[edit protocols bgp group ext] user@C# set type external user@C# set peer-as 17 user@C# set neighbor 10.0.3.1
Configure o número AS.
[edit routing-options] user@C# set autonomous-system 23
Resultados
Confirme sua configuração emitindo osshow interfaces, show policy-optionse show routing-options show protocolscomandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
Dispositivo A
user@A# show interfaces
fe-1/2/0 {
unit 4 {
description A->B;
family inet {
address 10.0.2.2/30;
}
}
}
user@A# show protocols
ospf {
area 0.0.0.0 {
interface fe-1/2/0.4;
}
}
Dispositivo B
user@B# show interfaces
interfaces {
fe-1/2/0 {
unit 3 {
description B->A;
family inet {
address 10.0.2.1/30;
}
}
}
fe-1/2/1 {
unit 6 {
description B->C;
family inet {
address 10.0.3.1/30;
}
}
}
}
user@B# show policy-options
policy-statement send-static {
from protocol static;
then accept;
}
user@B# show protocols
bgp {
group ext {
type external;
peer-as 23;
neighbor 10.0.3.2;
}
}
ospf {
export send-static;
area 0.0.0.0 {
interface fe-1/2/0.3;
}
}
user@B# show routing-options
static {
route 0.0.0.0/0 next-hop 10.0.3.2;
route 192.168.0.0/24 {
next-hop 10.0.3.2;
no-readvertise;
}
}
autonomous-system 17;
Dispositivo C
user@C# show interfaces
fe-1/2/0 {
unit 7 {
description B->C;
family inet {
address 10.0.3.2/30;
}
}
}
lo0 {
unit 5 {
family inet {
address 192.168.0.1/32;
}
}
}
user@C# show protocols
bgp {
group ext {
type external;
peer-as 17;
neighbor 10.0.3.1;
}
}
user@C# show routing-options autonomous-system 23;
Se você terminar de configurar os dispositivos, insira o commit a partir do modo de configuração.
Verificação
Confirme que a configuração está funcionando corretamente.
Verificando a tabela de roteamento
Propósito
Certifique-se de que a no-readvertise declaração está funcionando.
Ação
No dispositivo A, execute o
show route protocol ospfcomando para garantir que a rota 192.168.0.0/24 não aparece na tabela de roteamento do dispositivo A.user@A> show route protocols ospf inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:03:15, metric 0, tag 0 > to 10.0.2.1 via fe-1/2/0.4 224.0.0.5/32 *[OSPF/10] 00:04:07, metric 1 MultiRecvNo dispositivo B, desativa a
no-readvertisedeclaração.user@B# deactivate routing-options static route 192.168.0.0/24 no-readvertise
No dispositivo A, reexamina o
show route protocol ospfcomando para garantir que a rota 192.168.0.0/24 seja exibida na tabela de roteamento do dispositivo A.user@A> show route protocols ospf inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:04:24, metric 0, tag 0 > to 10.0.2.1 via fe-1/2/0.4 192.168.0.0/24 *[OSPF/150] 00:00:15, metric 0, tag 0 > to 10.0.2.1 via fe-1/2/0.4 224.0.0.5/32 *[OSPF/10] 00:05:16, metric 1 MultiRecv
Significado
A no-readvertise declaração está funcionando como esperado.
Verificando a configuração de rota estática
Propósito
Verifique se as rotas estáticas estão na tabela de roteamento e se essas rotas estão ativas.
Ação
Da CLI, entre no show route terse comando.
Saída de amostra
nome de comando
user@host> show route terse inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 192.168.47.5/32 S 5 Reject * 172.16.0.0/12 S 5 >192.168.71.254 * 192.168.0.0/18 S 5 >192.168.71.254 * 192.168.40.0/22 S 5 >192.168.71.254 * 192.168.64.0/18 S 5 >192.168.71.254 * 192.168.64.0/21 D 0 >fxp0.0 * 192.168.71.246/32 L 0 Local * 192.168.220.4/30 D 0 >ge-0/0/1.0 * 192.168.220.5/32 L 0 Local * 192.168.220.8/30 D 0 >ge-0/0/2.0 * 192.168.220.9/32 L 0 Local * 192.168.220.12/30 D 0 >ge-0/0/3.0 * 192.168.220.13/32 L 0 Local * 192.168.220.17/32 L 0 Reject * 192.168.220.21/32 L 0 Reject * 192.168.220.24/30 D 0 >at-1/0/0.0 * 192.168.220.25/32 L 0 Local * 192.168.220.28/30 D 0 >at-1/0/1.0 * 192.168.220.29/32 L 0 Local * 224.0.0.9/32 R 100 1 MultiRecv
Significado
A saída mostra uma lista das rotas que estão atualmente na tabela de roteamento inet.0 . Verifique as seguintes informações:
Cada rota estática configurada está presente. As rotas estão listadas em ordem crescente por endereço IP. As rotas estáticas são identificadas com uma coluna S no protocolo (P) da saída.
Cada rota estática está ativa. As rotas ativas mostram o endereço IP de próximo salto na coluna Next hop . Se o endereço next-hop de uma rota for inalcançável, o endereço next-hop será identificado como Rejeitar. Essas rotas não são rotas ativas, mas aparecem na tabela de roteamento porque o atributo passivo é definido.
A preferência por cada rota estática estática está correta. A preferência por uma rota específica está listada na coluna Prf da saída.