Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração de áreas de OSPF

Entendendo as áreas de OSPF

No OSPF, um único sistema autônomo (AS) pode ser dividido em grupos menores chamados áreas. Isso reduz o número de anúncios de estado de enlace (LSAs) e outros tráfegos aéreos OSPF enviados na rede, e reduz o tamanho do banco de dados de topologia que cada roteador deve manter. Os dispositivos de roteamento que participam do roteamento OSPF executam uma ou mais funções com base em sua localização na rede.

Este tópico descreve os seguintes tipos de área OSPF e funções de dispositivo de roteamento:

Áreas

Uma área é um conjunto de redes e hosts dentro de um AS que foram agrupados administrativamente. Recomendamos que você configure uma área como uma coleção de redes sub-redes sub-redes IP contíguas. Os dispositivos de roteamento que estão totalmente dentro de uma área são chamados de roteadores internos. Todas as interfaces em roteadores internos estão diretamente conectadas a redes dentro da área.

A topologia de uma área está oculta do resto do AS, reduzindo significativamente o tráfego de roteamento no AS. Além disso, o roteamento dentro da área é determinado apenas pela topologia da área, fornecendo à área alguma proteção contra dados de roteamento ruins.

Todos os dispositivos de roteamento em uma área têm bancos de dados de topologia idênticos.

Roteadores de borda de área

Os dispositivos de roteamento que pertencem a mais de uma área e conectam uma ou mais áreas de OSPF à área de backbone são chamados de roteadores de fronteira de área (ABRs). Pelo menos uma interface está dentro do backbone, enquanto outra interface está em outra área. Os ABRs também mantêm um banco de dados topológico separado para cada área à qual estão conectados.

Áreas de backbone

Uma área de backbone OSPF consiste em todas as redes na área ID 0.0.0.0, seus dispositivos de roteamento conectados e todos os ABRs. O backbone em si não tem ABRs. O backbone distribui informações de roteamento entre áreas. O backbone é simplesmente outra área, de modo que as regras e as regras das áreas se aplicam: um dispositivo de roteamento que está diretamente conectado ao backbone é um roteador interno no backbone, e a topologia do backbone está oculta das outras áreas do AS.

Os dispositivos de roteamento que compõem o backbone devem ser fisicamente contíguos. Caso não estejam, você deve configurar links virtuais para criar a aparência da conectividade do backbone. Você pode criar links virtuais entre dois ABRs que tenham uma interface para uma área nãobackbone comum. O OSPF trata dois dispositivos de roteamento acompanhados por um link virtual como se estivessem conectados a uma rede ponto a ponto sem números.

Roteadores de limite AS

Os dispositivos de roteamento que trocam informações de roteamento com dispositivos de roteamento em redes não-OSPF são chamados de roteadores de limite AS. Eles anunciam rotas aprendidas externamente em todo o OSPF AS. Dependendo da localização do roteador de limite AS na rede, ele pode ser um ABR, um roteador de backbone ou um roteador interno (com exceção das áreas de stub). Os roteadores internos em uma área de stub não podem ser um roteador de limite AS porque as áreas de stub não podem conter nenhum LSAs tipo 5.

Os dispositivos de roteamento dentro da área onde reside o roteador de limite AS conhecem o caminho para esse roteador de limite AS. Qualquer dispositivo de roteamento fora da área só conhece o caminho para a ABR mais próxima que está na mesma área onde o roteador de limite AS reside.

Roteador backbone

Os roteadores backbone são dispositivos de roteamento que têm uma ou mais interfaces conectadas à área de backbone OSPF (área ID 0.0.0.0).

Roteador interno

Os dispositivos de roteamento que se conectam a apenas uma área de OSPF são chamados de roteadores internos. Todas as interfaces em roteadores internos estão diretamente conectadas a redes em uma única área.

Áreas de Stub

As áreas de Stub são áreas pelas quais ou em que os anúncios externos de AS não estão inundados. Você pode querer criar áreas de stub quando grande parte do banco de dados topológico consiste em anúncios externos DE. Isso reduz o tamanho das bases de dados topológicas e, portanto, a quantidade de memória necessária nos roteadores internos na área de stub.

Os dispositivos de roteamento em uma área de stub dependem das rotas padrão originadas pela ABR da área para chegar a destinos externos de AS. Você deve configurar a opção default-metric na ABR antes que ela anuncie uma rota padrão. Uma vez configurada, a ABR anuncia uma rota padrão no lugar das rotas externas que não estão sendo anunciadas dentro da área de stub, para que os dispositivos de roteamento na área de stub possam chegar a destinos fora da área.

As seguintes restrições se aplicam a áreas de stub: você não pode criar um link virtual por uma área de stub, uma área de stub não pode conter um roteador de limite AS, o backbone não pode ser uma área de stub e você não pode configurar uma área como uma área de stub e uma área não tão stubby.

Áreas não tão stubby

Uma área de stub osPF não tem rotas externas, portanto, você não pode redistribuir de outro protocolo em uma área de stub. Uma área não tão grande (NSSA) permite que rotas externas sejam inundadas dentro da área. Essas rotas são então vazados para outras áreas. No entanto, rotas externas de outras áreas ainda não entram no NSSA.

A seguinte restrição se aplica aos NSSAs: você não pode configurar uma área como uma área de stub e um NSSA.

Áreas de trânsito

As áreas de trânsito são usadas para passar tráfego de uma área adjacente para o backbone (ou para outra área se o backbone estiver a mais de dois saltos de distância de uma área). O tráfego não se origina, nem é destinado à área de trânsito.

Tipos de área osPF e LSAs aceitos

A tabela a seguir fornece detalhes sobre os tipos de área de OSPF e LSAs aceitos:

Visão geral do roteador designado para OSPF

Grandes LANs que têm muitos dispositivos de roteamento e, portanto, muitas adjacências OSPF podem produzir tráfego pesado de pacotes de controle à medida que anúncios de estado de enlace (LSAs) são inundados em toda a rede. Para aliviar o potencial problema de tráfego, o OSPF usa roteadores designados em todas as redes multiacesso (tipos de redes multiacessos broadcast e nãotransmitidas [NBMA]). Em vez de transmitir LSAs para todos os seus vizinhos OSPF, os dispositivos de roteamento enviam seus LSAs para o roteador designado. Cada rede multiacesso tem um roteador designado, que executa duas funções principais:

  • Originar anúncios de enlaces de rede em nome da rede.

  • Estabeleça adjacências com todos os dispositivos de roteamento na rede, participando assim da sincronização dos bancos de dados de estado do enlace.

Nas LANs, a eleição do roteador designado ocorre quando a rede OSPF é inicialmente estabelecida. Quando os primeiros links OSPF estão ativos, o dispositivo de roteamento com o mais alto identificador de roteador (definido pelo valor de configuração de id do roteador , que normalmente é o endereço IP do dispositivo de roteamento, ou o endereço loopback) é eleito o roteador designado. O dispositivo de roteamento com o segundo maior identificador de roteador é eleito o roteador designado para backup. Se o roteador designado falhar ou perder a conectividade, o roteador designado de backup assume sua função e uma nova eleição de roteador designado para backup ocorre entre todos os roteadores da rede OSPF.

O OSPF usa o identificador do roteador para duas finalidades principais: eleger um roteador designado, a menos que você especifique manualmente um valor de prioridade e identificar o dispositivo de roteamento do qual um pacote é originado. Na eleição de roteador designado, as prioridades do roteador são avaliadas primeiro, e o dispositivo de roteamento com maior prioridade é eleito roteador designado. Se o roteador priorizar o empate, o dispositivo de roteamento com o mais alto identificador de roteador, que normalmente é o endereço IP do dispositivo de roteamento, é escolhido como o roteador designado. Se você não configurar um identificador de roteador, o endereço IP da primeira interface a ficar on-line será usado. Esta é geralmente a interface de loopback. Caso contrário, a primeira interface de hardware com um endereço IP é usada.

Pelo menos um dispositivo de roteamento em cada rede ip lógica ou sub-rede deve ser elegível para ser o roteador designado para OSPFv2. Pelo menos um dispositivo de roteamento em cada link lógico deve ser elegível para ser o roteador designado para o OSPFv3.

Por padrão, os dispositivos de roteamento têm uma prioridade de 128. Uma prioridade de 0 marca o dispositivo de roteamento como inelegibilidade para se tornar o roteador designado. Uma prioridade de 1 significa que o dispositivo de roteamento tem a menor chance de se tornar um roteador designado. Uma prioridade do 255 significa que o dispositivo de roteamento é sempre o roteador designado.

Exemplo: configuração de um identificador de roteador OSPF

Este exemplo mostra como configurar um identificador de roteador OSPF.

Requisitos

Antes de começar:

Visão geral

O identificador do roteador é usado pelo OSPF para identificar o dispositivo de roteamento do qual um pacote se originou. O Junos OS seleciona um identificador de roteador de acordo com o seguinte conjunto de regras:

  1. Por padrão, o Junos OS seleciona o endereço IP físico mais baixo configurado de uma interface como identificador do roteador.

  2. Se uma interface de loopback estiver configurada, o endereço IP da interface de loopback se tornará o identificador do roteador.

  3. Se várias interfaces de loopback forem configuradas, o endereço de loopback mais baixo se tornará o identificador do roteador.

  4. Se um identificador de roteador estiver explicitamente configurado usando a router-id address declaração sob o nível de [edit routing-options] hierarquia, as três regras acima serão ignoradas.

Nota:

1. O comportamento do identificador de roteador descrito aqui é bom mesmo quando configurado sob [edit routing-instances routing-instance-name routing-options] e [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options] níveis hierárquicos.

2. Se o identificador do roteador for modificado em uma rede, os anúncios de estado de link (LSAs) anunciados pelo identificador do roteador anterior serão retidos no banco de dados OSPF até que o intervalo de retransmissão de LSA seja cronometrado. Por isso, é recomendável configurar explicitamente o identificador do roteador sob o nível hierárquico [edit routing-options] para evitar comportamentos imprevisíveis se o endereço da interface em uma interface de loopback mudar.

Neste exemplo, você configura o identificador de roteador OSPF configurando seu valor de ID do roteador para o endereço IP do dispositivo, que é 192.0.2.24.

Configuração

Configuração rápida da CLI

Para configurar rapidamente um identificador de roteador OSPF, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [editar] e então entrar no commit modo de configuração.

Procedimento

Procedimento passo a passo

Para configurar um identificador de roteador OSPF:

  1. Configure o identificador do roteador OSPF inserindo o valor da [router-id] configuração.

  2. Se você terminar de configurar o dispositivo, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show routing-options router-id comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Depois de configurar o ID do roteador e ativar o OSPF no dispositivo de roteamento, o ID do roteador é referenciado por vários comandos de modo operacional OSPF que você pode usar para monitorar e solucionar problemas do protocolo OSPF. Os campos de ID do roteador estão claramente marcados na saída.

Exemplo: Controle da eleição de roteador designado pelo OSPF

Este exemplo mostra como controlar a eleição de roteador designado pelo OSPF.

Requisitos

Antes de começar:

Visão geral

Este exemplo mostra como controlar a eleição de roteador designado pelo OSPF. No exemplo, você define a interface OSPF para ge-/0/0/1 e a prioridade do dispositivo para 200. Quanto maior o valor da prioridade, maior a probabilidade de o dispositivo de roteamento se tornar o roteador designado.

Por padrão, os dispositivos de roteamento têm uma prioridade de 128. Uma prioridade de 0 marca o dispositivo de roteamento como inelegibilidade para se tornar o roteador designado. Uma prioridade de 1 significa que o dispositivo de roteamento tem a menor chance de se tornar um roteador designado.

Configuração

Configuração rápida da CLI

Para configurar rapidamente uma eleição de roteador designado pelo OSPF, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [editar] e então entrar no commit modo de configuração.

Procedimento

Procedimento passo a passo

Para controlar a eleição de roteador designado pelo OSPF:

  1. Configure uma interface OSPF e especifique a prioridade do dispositivo.

    Nota:

    Para especificar uma interface OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Se você terminar de configurar o dispositivo, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Verificação

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

Verificação da eleição de roteador designado

Propósito

Com base na prioridade que você configurou para uma interface OSPF específica, você pode confirmar o endereço do roteador designado da área. O dr ID, DR ou campo DR-ID exibe o endereço do roteador designado da área. O campo BDR ID, BDR ou BDR-ID exibe o endereço do roteador designado para backup.

Ação

A partir do modo operacional, insira o show ospf interface e os show ospf neighbor comandos para o OSPFv2 e insira o show ospf3 interface e os show ospf3 neighbor comandos para o OSPFv3.

Entenda as áreas de OSPF e áreas de backbone

As redes OSPF em um sistema autônomo (AS) são agrupadas administrativamente em áreas. Cada área dentro de um AS opera como uma rede independente e tem uma ID de área exclusiva de 32 bits, que funciona como um endereço de rede. Em uma área, o banco de dados de topologia contém apenas informações sobre a área, os anúncios de estado de link (LSAs) são inundados apenas para nós dentro da área, e as rotas são computadas apenas dentro da área. A topologia de uma área está oculta do resto do AS, reduzindo significativamente o tráfego de roteamento no AS. As sub-redes são divididas em outras áreas, que são conectadas para formar toda a rede principal. Os dispositivos de roteamento que estão totalmente dentro de uma área são chamados de roteadores internos. Todas as interfaces em roteadores internos estão diretamente conectadas a redes dentro da área.

A área central de um AS, chamada de área de backbone, tem uma função especial e é sempre atribuída a área ID 0.0.0.0.0. (Em uma rede simples de área única, esta também é a ID da área.) Os IDs de área são identificadores numéricos exclusivos, em notação decimal pontilhada, mas não são endereços IP. Os IDs de área só precisam ser exclusivos dentro de um AS. Todas as outras redes ou áreas no AS devem estar diretamente conectadas à área de backbone por um dispositivo de roteamento que tenha interfaces em mais de uma área. Esses dispositivos de roteamento de conexão são chamados de roteadores de área de borda (ABRs). A Figura 1 mostra uma topologia OSPF de três áreas conectadas por dois ABRs.

Figura 1: Topologia osPF multiárea Multiarea OSPF Topology

Como todas as áreas são adjacentes à área do backbone, os roteadores OSPF enviam todo o tráfego não destinado à sua própria área através da área do backbone. Os ABRs na área de backbone são então responsáveis por transmitir o tráfego através da ABR apropriada para a área de destino. Os ABRs resumem os registros de estado do enlace de cada área e anunciam resumos de endereços de destino para áreas vizinhas. Os anúncios contêm a ID da área em que cada destino está, de modo que os pacotes sejam roteados para a ABR apropriada. Por exemplo, nas áreas de OSPF mostradas na Figura 1, os pacotes enviados do roteador A ao roteador C são automaticamente roteados por ABR B.

O Junos OS oferece suporte à detecção ativa de backbone. A detecção ativa de backbone é implementada para verificar se os ABRs estão conectados ao backbone. Se a conexão com a área do backbone for perdida, a métrica padrão do dispositivo de roteamento não será anunciada, redirecionando efetivamente o tráfego através de outra ABR com uma conexão válida com o backbone. A detecção ativa de backbone permite o trânsito por uma ABR sem conexão de backbone ativa. Uma ABR anuncia a outros dispositivos de roteamento que é uma ABR mesmo se a conexão com o backbone estiver baixa, para que os vizinhos possam considerá-lo para rotas interáreas.

Uma restrição de OSPF exige que todas as áreas sejam conectadas diretamente à área do backbone para que os pacotes possam ser devidamente roteados. Todos os pacotes são roteados primeiro para a área de backbone por padrão. Os pacotes destinados a uma área diferente da área do backbone são então encaminhados para a ABR apropriada e para o host remoto dentro da área de destino.

Em grandes redes com muitas áreas, nas quais a conectividade direta entre todas as áreas e a área do backbone é fisicamente difícil ou impossível, você pode configurar links virtuais para conectar áreas não contiguosas. Os links virtuais usam uma área de trânsito que contém dois ou mais ABRs para passar o tráfego de rede de uma área adjacente para outra. Por exemplo, a Figura 2 mostra um enlace virtual entre uma área nãotiguosa e a área do backbone por uma área conectada a ambos.

Figura 2: Topologia OSPF com um link OSPF Topology with a Virtual Link virtual

Na topologia mostrada na Figura 2, um link virtual é estabelecido entre a área 0.0.0.3 e a área de backbone através da área 0.0.0.2. Todo o tráfego de saída destinado a outras áreas é roteado pela área 0.0.0.2 até a área de backbone e, em seguida, para a ABR apropriada. Todo o tráfego de entrada destinado à área 0.0.0.3 é roteado para a área de backbone e depois pela área 0.0.0.2.

Exemplo: configuração de uma rede OSPF de área única

Este exemplo mostra como configurar uma rede OSPF de área única.

Requisitos

Antes de começar:

Visão geral

Para ativar o OSPF em uma rede, você deve habilitar o protocolo OSPF em todas as interfaces dentro da rede em que o tráfego OSPF deve viajar. Para habilitar o OSPF, você deve configurar uma ou mais interfaces no dispositivo dentro de uma área de OSPF. Assim que as interfaces estiverem configuradas, os OSPF LSAs são transmitidos em todas as interfaces habilitadas para OSPF, e a topologia de rede é compartilhada em toda a rede.

Em um sistema autônomo (AS), a área de backbone é sempre atribuída à área ID 0.0.0.0 (dentro de uma rede simples e de área única, esta também é a ID da área). Os IDs de área são identificadores numéricos exclusivos, em notação decimal pontilhada. Os IDs de área só precisam ser exclusivos dentro de um AS. Todas as outras redes ou áreas no AS devem estar diretamente conectadas à área de backbone por roteadores de fronteira de área que tenham interfaces em mais de uma área. Você também deve criar uma área de backbone se sua rede consiste em várias áreas. Neste exemplo, você cria a área do backbone e adiciona interfaces, como ge-0/0/0, conforme necessário para a área de OSPF.

Para usar o OSPF no dispositivo, você deve configurar pelo menos uma área de OSPF, como a mostrada na Figura 3.

Figura 3: Topologia de rede OSPF típica de área única Typical Single-Area OSPF Network Topology

Topologia

Configuração

Configuração rápida da CLI

Para configurar rapidamente uma rede OSPF de área única, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [editar] e então entrar no commit modo de configuração.

Procedimento

Procedimento passo a passo

Para configurar uma rede OSPF de área única:

  1. Configure a rede OSPF de área única especificando o ID da área e a interface associada.

    Nota:

    Para uma rede OSPFv3 de área única, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Se você terminar de configurar o dispositivo, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Verificação

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

Verificando as interfaces na área

Propósito

Verifique se a interface para OSPF ou OSPFv3 foi configurada para a área apropriada. Confirme que o campo de área exibe o valor que você configurou.

Ação

A partir do modo operacional, insira o show ospf interface comando para o OSPFv2 e insira o show ospf3 interface comando para o OSPFv3.

Exemplo: configuração de uma rede OSPF multiárea

Este exemplo mostra como configurar uma rede OSPF multiárea. Para reduzir a manutenção de tráfego e topologia dos dispositivos em um sistema autônomo (AS) OSPF, você pode agrupar os dispositivos de roteamento habilitados para OSPF em várias áreas.

Requisitos

Antes de começar:

Visão geral

Para ativar o OSPF em uma rede, você deve habilitar o protocolo OSPF em todas as interfaces dentro da rede em que o tráfego OSPF deve viajar. Para habilitar o OSPF, você deve configurar uma ou mais interfaces no dispositivo dentro de uma área de OSPF. Assim que as interfaces estiverem configuradas, os OSPF LSAs são transmitidos em todas as interfaces habilitadas para OSPF, e a topologia de rede é compartilhada em toda a rede.

Cada área de OSPF consiste em dispositivos de roteamento configurados com o mesmo número de área. Na Figura 4, o roteador B reside na área de backbone do AS. A área de backbone é sempre atribuída à área ID 0.0.0.0. (Todos os IDs de área devem ser exclusivos dentro de um AS.) Todas as outras redes ou áreas no AS devem estar diretamente conectadas à área de backbone por um roteador que tenha interfaces em mais de uma área. Neste exemplo, esses roteadores de borda de área são A, C, D e E. Você cria uma área adicional (área 2) e atribuí-la à área única ID 0.0.0.2 e, em seguida, adiciona interface ge-0/0/0 à área de OSPF.

Para reduzir a manutenção de tráfego e topologia dos dispositivos em um AS OSPF, você pode agrupa-los em várias áreas, conforme mostrado na Figura 4. Neste exemplo, você cria a área do backbone, cria uma área adicional (área 2) e atribua a ela uma área única ID 0.0.0.2, e configura o Dispositivo B como roteador de borda de área, onde a interface ge-0/0/0 participa da área 0 e interface ge-0/2 participa na área DEPF 2.

Figura 4: Topologia Typical Multiarea OSPF Network Topology de rede OSPF multiárea típica

Topologia

Configuração

Procedimento

Configuração rápida da CLI

Para configurar rapidamente uma rede OSPF multiarea, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [editar] e então entrar no commit modo de configuração.

Dispositivo A

Dispositivo C

Dispositivo B

Dispositivo D

Dispositivo E

Procedimento passo a passo

Para configurar uma rede OSPF multiárea:

  1. Configure a área do backbone.

    Nota:

    Para uma rede OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Configure uma área adicional para sua rede OSPF.

    Nota:

    Para uma rede OSPFv3 multiárea, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  3. Se você terminar de configurar o dispositivo, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Verificação

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

Verificando as interfaces na área

Propósito

Verifique se a interface para OSPF ou OSPFv3 foi configurada para a área apropriada. Confirme que o campo de área exibe o valor que você configurou.

Ação

A partir do modo operacional, insira o show ospf interface comando para o OSPFv2 e insira o show ospf3 interface comando para o OSPFv3.

Entendendo a adjacência multiárea para OSPF

Por padrão, uma única interface pode pertencer a apenas uma área de OSPF. No entanto, em algumas situações, você pode querer configurar uma interface para pertencer a mais de uma área. Isso permite que o enlace correspondente seja considerado um enlace intraárea em várias áreas e seja preferido em outros caminhos intraáreas de alto custo. Por exemplo, você pode configurar uma interface para pertencer a várias áreas com um enlace de backbone de alta velocidade entre dois roteadores de borda de área (ABRs) para que você possa criar adjacências multiáreas que pertencem a diferentes áreas.

No Junos OS Release 9.2 e posterior, você pode configurar uma interface lógica para pertencer a mais de uma área OSPFv2. O suporte para o OSPFv3 foi introduzido no Junos OS Release 9.4. Conforme definido na RFC 5185, OSPF Multi-Area Adjacency, os ABRs estabelecem várias adjacências pertencentes a diferentes áreas na mesma interface lógica. Cada adjacência multiárea é anunciada como um link de ponto a ponto sem números na área configurada pelos roteadores conectados ao link. Para cada área, uma das interfaces lógicas é tratada como primária, e as interfaces restantes que estão configuradas para a área são designadas como secundárias.

Qualquer interface lógica não configurada como uma interface secundária para uma área é tratada como a interface primária para essa área. Uma interface lógica pode ser configurada como interface primária apenas para uma área. Para qualquer outra área para a qual você configure a interface, você deve configurá-la como uma interface secundária.

Exemplo: configuração da adjacência multiárea para OSPF

Este exemplo mostra como configurar adjacência multiárea para OSPF.

Requisitos

Antes de começar, planeje sua rede OSPF multiárea. Veja exemplo: Configuração de uma rede OSPF multiárea.

Visão geral

Por padrão, uma única interface pode pertencer a apenas uma área de OSPF. Você pode configurar uma única interface para pertencer a várias áreas de OSPF. Isso permite que o enlace correspondente seja considerado um enlace intraárea em várias áreas e seja preferido em outros caminhos intraáreas de alto custo. Ao configurar uma interface secundária, considere o seguinte:

  • Para o OSPFv2, você não pode configurar interfaces de rede multiacesso de ponto a multiponto e nãotransmitidas (NBMA) como uma interface secundária porque as interfaces secundárias são tratadas como um enlace nãonumerado ponto a ponto.

  • Interfaces secundárias são suportadas para interfaces LAN (a interface principal pode ser uma interface LAN, mas quaisquer interfaces secundárias são tratadas como links de ponto a ponto sem números sobre a LAN). Nesse cenário, você deve garantir que existam apenas dois dispositivos de roteamento na LAN ou que existam apenas dois dispositivos de roteamento na LAN que tenham interfaces secundárias configuradas para uma área de OSPF específica.

  • Como o objetivo de uma interface secundária é anunciar um caminho topológico por meio de uma área OSPF, você não pode configurar uma interface secundária ou uma interface primária com uma ou mais interfaces secundárias para ser passiva. Interfaces passivas anunciam seu endereço, mas não executam o protocolo OSPF (as adjacências não são formadas e pacotes de olá não são gerados).

  • Qualquer interface lógica não configurada como uma interface secundária para uma área é tratada como uma interface primária para essa área. Uma interface lógica pode ser configurada como a interface primária apenas para uma área. Para qualquer outra área para a qual você configure a interface, você deve configurá-la como uma interface secundária.

  • Você não pode configurar a secondary declaração com a interface all declaração.

  • Você não pode configurar uma interface secundária por seu endereço IP.

Figura 5: Adjacência multiárea no OSPF Multiarea Adjacency in OSPF

Neste exemplo, você configura uma interface para estar em duas áreas, criando uma adjacência multiárea com um link entre dois ABRs: ABR R1 e ABR R2. Em cada ABR, a área 0.0.0.1 contém a interface primária e é o elo principal entre os ABRs e a área 0.0.0.2 contém a interface lógica secundária, que você configura incluindo a secondary declaração. Você configura interface so-0/0/0 no ABR R1 e interface so-1/0/0 no ABR R2.

Configuração

Configuração rápida da CLI

Para configurar rapidamente uma interface lógica secundária para uma área OSPF, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [editar] e então entrar no commit modo de configuração.

Configuração no ABR R1:

Configuração no ABR R2:

Procedimento

Procedimento passo a passo

Para configurar uma interface lógica secundária:

  1. Configure as interfaces do dispositivo.

    Nota:

    Para o OSPFv3, em cada interface especifique a família de endereços inet6 e inclua o endereço IPv6.

  2. Configure o identificador do roteador.

  3. Em cada ABR, configure a interface primária para a área de OSPF.

    Nota:

    Para o OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  4. Em cada ABR, configure a interface secundária para a área de OSPF.

  5. Se você terminar de configurar os dispositivos, confirme a configuração.

Resultados

Confirme sua configuração inserindo os show interfacesshow routing-optionscomandos e a show protocols ospf configuração. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Configuração no ABR R1:

Configuração no ABR R2:

Verificação

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

Verificando a interface secundária

Propósito

Verifique se a interface secundária aparece para a área configurada. O campo secundário é exibido se a interface estiver configurada como uma interface secundária. A saída também pode mostrar a mesma interface listada em várias áreas.

Ação

A partir do modo operacional, insira o show ospf interface detail comando para o OSPFv2 e insira o show ospf3 interface detail comando para o OSPFv3.

Verificando as interfaces na área

Propósito

Verifique as interfaces configuradas para a área especificada.

Ação

A partir do modo operacional, entre no show ospf interface area area-id comando do OSPFv2 e insira o show ospf3 interface area area-id comando para OSPFv3..

Verificando as adjacências vizinhas

Propósito

Verifique as adjacências de vizinhos primários e secundários. O campo secundário exibe se o vizinho estiver em uma interface secundária.

Ação

A partir do modo operacional, insira o show ospf neighbor detail comando para o OSPFv2 e insira o show ospf3 neighbor detail comando para o OSPFv3.

Entendendo as adjacências multiáreas para OSPFv3

Uma área é um conjunto de redes e hosts dentro de um domínio OSPFv3 que foram agrupados administrativamente. Por padrão, uma única interface pode pertencer a apenas uma área OSPFv3. No entanto, em algumas situações, você pode querer configurar uma interface para pertencer a mais de uma área para evitar roteamento abaixo do ideal. Isso permite que o enlace correspondente seja considerado um enlace intraárea em várias áreas e seja preferido em relação a links intraáreas de alto custo.

No Junos OS Release 9.2 e posterior, você pode configurar uma interface para pertencer a mais de uma área OSPFv2. O suporte para o OSPFv3 foi introduzido no Junos OS Release 9.4. Conforme definido na RFC 5185, OSPF Multi-Area Adjacency, os ABRs estabelecem várias adjacências pertencentes a diferentes áreas na mesma interface lógica. Cada adjacência multiárea é anunciada como um link de ponto a ponto sem números na área configurada pelos roteadores conectados ao link.

Uma interface é considerada principalmente em uma área. Quando você configura a mesma interface em outra área, ela é considerada essencialmente na outra área. Você designa a área secundária incluindo a secondary declaração no nível de [edit protocols ospf3 area area-number interface interface-name] hierarquia.

Exemplo: configuração de uma adjacência multiárea para OSPFv3

Este exemplo mostra como configurar uma adjacência multiárea para OSPFv3.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Os caminhos intraáreas OSPFv3 são preferidos em caminhos interáreas. Neste exemplo, o Dispositivo R1 e o Dispositivo R2 são roteadores de borda de área (ABRs) com interfaces na área 0 e na área 1. A ligação entre o dispositivo R1 e o R2 está na área 0 e é um link de alta velocidade. Os links na área 1 são de menor velocidade.

Se você quiser encaminhar parte do tráfego da área 1 entre o Dispositivo R1 e o Dispositivo R2 pelo link de alta velocidade, um método para atingir esse objetivo é tornar o enlace de alta velocidade uma adjacência multiárea para que o link faça parte da área 0 e da área 1.

Se a ligação de alta velocidade entre o Dispositivo R1 e o Dispositivo R2 permanecer apenas na área 1, o Dispositivo R1 sempre roteia o tráfego para o Dispositivo R4 e o Dispositivo R5 pela área 1 nos links de menor velocidade. O dispositivo R1 também usa a área intraárea 1 caminho pelo Dispositivo R3 para chegar à área 1 destinos downstream do dispositivo R2.

Claramente, esse cenário resulta em roteamento abaixo do ideal.

Um link virtual OSPF não pode ser usado para resolver esse problema sem mover o enlace entre o dispositivo R1 e o dispositivo R2 para a área 1. Você pode não querer fazer isso se o link físico pertence à topologia de backbone da rede.

A extensão de protocolo OSPF/OSPFv3 descrita no RFC 5185, a adjacência multiárea OSPF resolve o problema, permitindo que o enlace entre o Dispositivo R1 e o Dispositivo R2 faça parte da área do backbone e da área 1.

Para criar uma adjacência multiárea, você configura uma interface a ser em duas áreas, com o ge-1/2/0 no dispositivo R1 configurado tanto na área 0 quanto na área 1, e no dispositivo R2 ge-1/0 configurado na área 0 e na área 1. Tanto no dispositivo R1 quanto no dispositivo R2, a área 0 contém a interface primária e é o elo principal entre os dispositivos. A Área 1 contém a interface lógica secundária, que você configura ao incluir a secondary declaração.

Figura 6: Adjacência OSPFv3 Multiarea Adjacency multiárea OSPFv3

A configuração rápida da CLI mostra a configuração para todos os dispositivos na Figura 6. A seção #d19e74__d19e376 descreve as etapas do Dispositivo R1 e do Dispositivo R2.

Configuração

Procedimento

Configuração rápida da CLI

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

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Dispositivo R6

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 o dispositivo R1:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 nas interfaces que estão na área 0.

  3. Habilite o OSPFv3 na interface que está na área 1.

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 o dispositivo R2:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 nas interfaces que estão na área 0.

  3. Habilite o OSPFv3 na interface que está na área 1.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show interfaces comandos e show protocols os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Dispositivo R1

Dispositivo R2

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 fluxo de tráfego

Propósito

Verifique se o tráfego usa o enlace de alta velocidade entre o dispositivo R1 e o dispositivo R2 para chegar a destinos na área 1.

Ação

Desde o modo operacional no dispositivo R1, use o traceroute comando verifique o fluxo de tráfego para o dispositivo R5 e dispositivo R6.

Significado

A saída de traceroute mostra que o tráfego usa o 9009:1:: link entre o dispositivo R1 e o dispositivo R2.

Verificando se o fluxo de tráfego muda quando você remove a adjacência multiárea

Propósito

Verifique os resultados sem a adjacência multiarea configurada.

Ação
  1. Desativar as interfaces de enlace de backbone na área 1 tanto no R1 quanto no R2.

  2. Desde o modo operacional no dispositivo R1, use o traceroute comando verifique o fluxo de tráfego para o dispositivo R5 e dispositivo R6.

Significado

Sem a adjacência multiárea, a saída mostra roteamento abaixo do ideal, com o tráfego tomando o caminho pela área 1 links de baixa velocidade.

Entendendo as áreas de stub osPF, áreas totalmente stubby e áreas não tão stubby

A Figura 7 mostra um sistema autônomo (AS) em que muitas rotas externas são anunciadas. Se as rotas externas compõem uma parte significativa de um banco de dados de topologia, você pode suprimir os anúncios em áreas que não têm links fora da rede. Ao fazer isso, você pode reduzir a quantidade de memória que os nós usam para manter o banco de dados de topologia e liberá-lo para outros usos.

Figura 7: Rede OSPF AS com áreas de stub e NSSAs OSPF AS Network with Stub Areas and NSSAs

Para controlar o anúncio de rotas externas em uma área, o OSPF usa áreas de stub. Ao designar uma interface de roteador de borda de área (ABR) para a área como uma interface de stub, você suprime anúncios de rotas externas por meio da ABR. Em vez disso, a ABR anuncia uma rota padrão (por si só) no lugar das rotas externas e gera um resumo da rede (Tipo 3) anúncios de estado de link (LSAs). Os pacotes destinados a rotas externas são enviados automaticamente para a ABR, que funciona como um gateway para tráfego de saída e roteia o tráfego adequadamente.

Nota:

Você deve configurar explicitamente a ABR para gerar uma rota padrão quando anexada a um stub ou não-tão-stubby-area (NSSA). Para injetar uma rota padrão com um valor métrica especificado na área, você deve configurar a opção default-metric e especificar um valor métrica.

Por exemplo, a área 0.0.0.3 na Figura 7 não está diretamente conectada à rede externa. Todo o tráfego de saída é roteado pela ABR até o backbone e depois para os endereços de destino. Ao designar a área 0.0.0.3 como área de stub, você reduz o tamanho do banco de dados de topologia para essa área limitando as entradas de rota a apenas essas rotas internas para a área.

Uma área de stub que só permite rotas internas para a área e restringe a entrada de LSAs tipo 3 na área de stub é muitas vezes chamada de área totalmente stubby. Você pode converter a área 0.0.0.3 em uma área totalmente stubby configurando a ABR para anunciar apenas e permitir que a rota padrão entre na área. Rotas e destinos externos para outras áreas não são mais resumidos ou permitidos em uma área totalmente stubby.

Nota:

Se você configurar incorretamente uma área totalmente stubby, você pode encontrar problemas de conectividade de rede. Você deve ter conhecimento avançado do OSPF e entender o seu ambiente de rede antes de configurar áreas totalmente desacordas.

Semelhante à área 0.0.0.3 na Figura 7, a área 0.0.0.4 não tem conexões externas. No entanto, a área 0.0.0.4 tem rotas estáticas para clientes que não são rotas internas de OSPF. Você pode limitar os anúncios de rota externa à área e anunciar as rotas estáticas para os clientes, designando a área como NSSA. Em um NSSA, o roteador de limite AS gera LSAs externos (Tipo 7) NSSA e os inunda no NSSA, onde eles estão contidos. Os LSAs tipo 7 permitem que um NSSA ofereça suporte à presença de roteadores de fronteira AS e suas informações de roteamento externas correspondentes. A ABR converte LSAs tipo 7 em LSAs externos (Tipo 5) e os leaka para outras áreas, mas rotas externas de outras áreas não são anunciadas dentro do NSSA.

Exemplo: Configuração de stub de OSPF e áreas totalmente stubby

Este exemplo mostra como configurar uma área de stub osPF e uma área totalmente stubby para controlar o anúncio de rotas externas em uma área.

Requisitos

Antes de começar:

Visão geral

A área de backbone, que é 0 na Figura 8, tem uma função especial e é sempre atribuída a área ID 0.0.0.0. Os IDs de área são identificadores numéricos exclusivos, em notação decimal pontilhada. Os IDs de área só precisam ser únicos dentro de um sistema autônomo (AS). Todas as outras redes ou áreas (como 3, 7 e 9) no AS devem estar diretamente conectadas à área de backbone por roteadores de borda de área (ABRs) que têm interfaces em mais de uma área.

As áreas de Stub são áreas através das quais ou em que o OSPF não inunda anúncios externos de estado de enlace (LSAs tipo 5). Você pode criar áreas de stub quando grande parte do banco de dados de topologia consiste em anúncios externos de AS e deseja minimizar o tamanho dos bancos de dados de topologia nos roteadores internos na área de stub.

As seguintes restrições se aplicam às áreas de stub:

  • Você não pode criar um link virtual por meio de uma área de stub.

  • Uma área de stub não pode conter um roteador de limite AS.

  • Você não pode configurar o backbone como uma área de stub.

  • Você não pode configurar uma área como uma área de stub e uma área não tão stubby (NSSA).

Neste exemplo, você configura cada dispositivo de roteamento na área 7 (ID de área 0.0.0.7) como um roteador stub e algumas configurações adicionais na ABR:

  • stub— Especifica que essa área se torne uma área de stub e não seja inundada com LSAs tipo 5. Você deve incluir a stub declaração em todos os dispositivos de roteamento que estão na área 7 porque esta área não tem conexões externas.

  • default-metric— Configura a ABR para gerar uma rota padrão com uma métrica especificada na área de stub. Essa rota padrão permite o encaminhamento de pacotes da área de stub para destinos externos. Você configura essa opção apenas na ABR. A ABR não gera automaticamente uma rota padrão quando anexada a um stub. Você deve configurar explicitamente essa opção para gerar uma rota padrão.

  • no-summaries—(Opcional) Impede que a ABR anucie rotas sumárias de publicidade na área de stub convertendo a área de stub em uma área totalmente stubby. Se configurada em combinação com a default-metric declaração, uma área totalmente stubby só permite rotas internas para a área e anuncia a rota padrão para a área. Rotas e destinos externos para outras áreas não são mais resumidos ou permitidos em uma área totalmente stubby. Apenas a ABR requer essa configuração adicional porque é o único dispositivo de roteamento dentro da área totalmente stubby que cria LSAs tipo 3 usados para receber e enviar tráfego de fora da área.

Nota:

No Junos OS Release 8.5 e posterior, o seguinte se aplica:

  • Uma interface de identificador de roteador que não está configurada para executar OSPF não é mais anunciada como uma rede stub em LSAs OSPF.

  • O OSPF anuncia uma rota local com um comprimento de prefixo de 32 como um link de stub se a interface de loopback estiver configurada com um comprimento de prefixo diferente de 32. O OSPF também anuncia a rota direta com o comprimento de máscara configurado, como em versões anteriores.

Figura 8: Topologia de rede OSPF com áreas stub e NSSAs OSPF Network Topology with Stub Areas and NSSAs

Topologia

Configuração

Configuração rápida da CLI

  • Para configurar rapidamente uma área de stub osPF, copie o comando a seguir e cole-o na CLI. Você deve configurar todos os dispositivos de roteamento que fazem parte da área de stub.

  • Para configurar rapidamente a ABR para injetar uma rota padrão na área, copie o comando a seguir e cole-o na CLI. Você aplica essa configuração apenas na ABR.

  • (Opcional) Para configurar rapidamente a ABR para restringir todos os anúncios sumários e permitir apenas rotas internas e anúncios de rota padrão na área, copie o comando a seguir e cole-o na CLI. Você aplica essa configuração apenas na ABR.

Procedimento

Procedimento passo a passo

Para configurar áreas de stub de OSPF:

  1. Em todos os dispositivos de roteamento da área, configure uma área de stub de OSPF.

    Nota:

    Para especificar uma área de stub OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Na ABR, injete uma rota padrão na área.

  3. (Opcional) Na ABR, restrinja a entrada de LSAs sumários na área. Esta etapa converte a área de stub em uma área totalmente stubby.

  4. Se você terminar de configurar os dispositivos, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Configuração em todos os dispositivos de roteamento:

Configuração na ABR (a saída também inclui a configuração opcional):

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Verificação

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

Verificando as interfaces na área

Propósito

Verifique se a interface para OSPF foi configurada para a área apropriada. Confirme que a saída inclui o Stub como o tipo de área de OSPF.

Ação

A partir do modo operacional, insira o show ospf interface detail comando para o OSPFv2 e insira o show ospf3 interface detail comando para o OSPFv3.

Verificando o tipo de área de OSPF

Propósito

Verifique se a área de OSPF é uma área de stub. Confirme que a saída exibe o Stub normal como o tipo Stub.

Ação

A partir do modo operacional, insira o show ospf overview comando para o OSPFv2 e insira o show ospf3 overview comando para o OSPFv3.

Exemplo: Configuração de áreas não tão stubby do OSPF

Este exemplo mostra como configurar um OSPF não tão stubby area (NSSA) para controlar o anúncio de rotas externas em uma área.

Requisitos

Antes de começar:

Visão geral

A área de backbone, que é 0 na Figura 9, tem uma função especial e é sempre atribuída a área ID 0.0.0.0. Os IDs de área são identificadores numéricos exclusivos, em notação decimal pontilhada. Os IDs de área só precisam ser exclusivos dentro de um AS. Todas as outras redes ou áreas (como 3, 7 e 9) no AS devem ser conectadas diretamente à área de backbone por ABRs que tenham interfaces em mais de uma área.

Uma área de stub osPF não tem rotas externas, portanto, você não pode redistribuir rotas de outro protocolo em uma área de stub. Os NSSAs OSPF permitem que rotas externas sejam inundadas dentro da área.

Além disso, você pode ter uma situação em que a exportação de LSAs tipo 7 para o NSSA é desnecessária. Quando um roteador de limite AS também é um ABR com um NSSA conectado, os LSAs tipo 7 são exportados para o NSSA por padrão. Se a ABR for anexada a vários NSSAs, um LSA tipo 7 separado é exportado para cada NSSA por padrão. Durante a redistribuição de rota, este dispositivo de roteamento gera LSAs tipo 5 e LSAs tipo 7. Você pode desativar a exportação de LSAs tipo 7 para o NSSA.

Nota:

A seguinte restrição se aplica aos NSSAs: você não pode configurar uma área como uma área de stub e uma NSSA.

Você configura cada dispositivo de roteamento na área 9 (ID da área 0.0.0.9) com a seguinte configuração:

  • nssa— especifica um OSPF NSSA. Você deve incluir a nssa declaração em todos os dispositivos de roteamento na área 9, pois essa área só tem conexões externas com rotas estáticas.

Você também configura a ABR na área 9 com as seguintes configurações adicionais:

  • no-summaries— impede a ABR de anunciar rotas sumárias para o NSSA. Se configurado em combinação com a default-metric declaração, o NSSA só permite rotas internas para a área e anuncia a rota padrão para a área. Rotas e destinos externos para outras áreas não são mais resumidos ou permitidos no NSSA. Apenas a ABR requer essa configuração adicional porque é o único dispositivo de roteamento dentro do NSSA que cria LSAs tipo 3 usados para receber e enviar tráfego de fora da área.

  • default-lsa— configura a ABR para gerar uma rota padrão para o NSSA. Neste exemplo, você configura o seguinte:

    • default-metric— Especifica que a ABR gera uma rota padrão com uma métrica especificada para o NSSA. Essa rota padrão permite o encaminhamento de pacotes do NSSA para destinos externos. Você configura essa opção apenas na ABR. A ABR não gera automaticamente uma rota padrão quando anexada a um NSSA. Você deve configurar explicitamente essa opção para a ABR para gerar uma rota padrão.

    • metric-type—(Opcional) Especifica o tipo de métrica externa para o LSA padrão, que pode ser tipo 1 ou Tipo 2. Quando o OSPF exporta informações de rota de ASs externos, ele inclui um custo, ou métrica externa, na rota. A diferença entre as duas métricas é como o OSPF calcula o custo da rota. Métricas externas do tipo 1 são equivalentes à métrica de estado do enlace, onde o custo é igual à soma dos custos internos mais o custo externo. As métricas externas do tipo 2 usam apenas o custo externo atribuído pelo roteador de limite AS. Por padrão, o OSPF usa a métrica externa Tipo 2.

    • type-7— (Opcional) inunda LSAs padrão tipo 7 no NSSA se a no-summaries declaração estiver configurada. Por padrão, quando a no-summaries declaração é configurada, um LSA Tipo 3 é injetado em NSSAs para versão Junos OS 5.0 e posterior. Para oferecer suporte à compatibilidade retrógrada com versões anteriores do Junos OS, inclua a type-7 declaração.

O segundo exemplo também mostra a configuração opcional necessária para desabilitar a exportação de LSAs tipo 7 para o NSSA, incluindo a no-nssa-abr declaração sobre o dispositivo de roteamento que executa as funções de um ABR e um roteador de limite AS.

Figura 9: Topologia de rede OSPF com áreas stub e NSSAs OSPF Network Topology with Stub Areas and NSSAs

Topologia

Configuração

Configuração de dispositivos de roteamento para participar em uma área não tão grande

Configuração rápida da CLI

Para configurar rapidamente um NSSA OSPF, copie o comando a seguir e cole-o na CLI. Você deve configurar todos os dispositivos de roteamento que fazem parte do NSSA.

Para configurar rapidamente uma ABR que participa de um OSPF NSSA, copie os seguintes comandos e cole-os na CLI.

Procedimento passo a passo

Para configurar NSSAs OSPF:

  1. Em todos os dispositivos de roteamento da área, configure um NSSA OSPF.

    Nota:

    Para especificar uma área NSSA DO OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Na ABR, insira o modo de configuração de OSPF e especifique a área 0.0.0.9 do NSSA que você já criou.

  3. Na ABR, injete uma rota padrão na área.

  4. (Opcional) Na ABR, especifique o tipo de métrica externa para a rota padrão.

  5. (Opcional) Na ABR, especifique a inundação de LSAs tipo 7.

  6. Na ABR, restrinja a entrada de LSAs sumários na área.

  7. Se você terminar de configurar os dispositivos, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Configuração em todos os dispositivos de roteamento na área:

Configuração na ABR. A saída também inclui as declarações e type-7 opcionaismetric-type.

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Desativação da exportação de anúncios de estado de link tipo 7 em áreas não tão stubby

Configuração rápida da CLI

Para desabilitar rapidamente a exportação de LSAs do Tipo 7 para o NSSA, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia [edição] e, em seguida, entrar no commit modo de configuração. Você configura essa configuração em um roteador de limite AS que também é uma ABR com uma área NSSA anexada.

Procedimento passo a passo

Você pode configurar essa configuração se tiver um roteador de limite AS que também é um ABR com uma área NSSA anexada.

  1. Desativar a exportação de LSAs tipo 7 para o NSSA.

    Nota:

    Para especificar o OSPFv3, inclua a ospf3 declaração no nível de [edit protocols] hierarquia.

  2. Se você terminar de configurar o dispositivo, confirme a configuração.

Resultados

Confirme sua configuração inserindo o show protocols ospf comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Para confirmar sua configuração OSPFv3, entre no show protocols ospf3 comando.

Verificação

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

Verificando as interfaces na área

Propósito

Verifique se a interface para OSPF foi configurada para a área apropriada. Confirme que a saída inclui o Stub NSSA como o tipo de área de OSPF.

Ação

A partir do modo operacional, insira o show ospf interface detail comando para o OSPFv2 e insira o show ospf3 interface detail comando para o OSPFv3.

Verificando o tipo de área de OSPF

Propósito

Verifique se a área de OSPF é uma área de stub. Confirme que a saída não é tão Stubby Stub quanto o tipo Stub.

Ação

A partir do modo operacional, insira o show ospf overview comando para o OSPFv2 e insira o show ospf3 overview comando para o OSPFv3.

Verificando o tipo de LSAs

Propósito

Verifique o tipo de LSAs que estão na área. Se você desabilitar a exportação de LSAs tipo 7 para um NSSA, confirme que o campo Type não inclui o NSSA como um tipo de LSA.

Ação

A partir do modo operacional, insira o show ospf overview comando para o OSPFv2 e insira o show ospf3 overview comando para o OSPFv3.

Entendendo as áreas stub e totalmente stubby do OSPFv3

A configuração do Junos OSPFv3 para redes IPv6 é idêntica à configuração do OSPFv2. Você configura o protocolo com set ospf3 comandos em vez de set ospf comandos e usa show ospf3 comandos em vez de show ospf comandos para verificar o status do OSPF. Além disso, certifique-se de definir endereços IPv6 nas interfaces que executam o OSPFv3.

As áreas de Stub são áreas através das quais ou em que o OSPF não inunda anúncios externos de estado de enlace (LSAs tipo 5). Você pode criar áreas de stub quando grande parte do banco de dados de topologia consiste em anúncios externos de AS e deseja minimizar o tamanho dos bancos de dados de topologia nos roteadores internos na área de stub.

As seguintes restrições se aplicam às áreas de stub:

  • Você não pode criar um link virtual por meio de uma área de stub.

  • Uma área de stub não pode conter um roteador de limite AS.

  • Você não pode configurar o backbone como uma área de stub.

  • Você não pode configurar uma área como uma área de stub e uma área não tão stubby (NSSA).

Exemplo: Configuração de stubs OSPFv3 e áreas totalmente stubby

Este exemplo mostra como configurar uma área de stub OSPFv3 e uma área totalmente stubby para controlar o anúncio de rotas externas em uma área.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

A Figura 10 mostra a topologia usada neste exemplo.

Figura 10: Topologia de rede OSPFv3 com áreas OSPFv3 Network Topology with Stub Areas de Stub

Neste exemplo, você configura cada dispositivo de roteamento na área 7 (ID de área 0.0.0.7) como um roteador stub e algumas configurações adicionais na ABR:

  • stub— Especifica que essa área se torne uma área de stub e não seja inundada com LSAs tipo 5. Você deve incluir a stub declaração em todos os dispositivos de roteamento que estão na área 7 porque esta área não tem conexões externas.

  • default-metric— Configura a ABR para gerar uma rota padrão com uma métrica especificada na área de stub. Essa rota padrão permite o encaminhamento de pacotes da área de stub para destinos externos. Você configura essa opção apenas na ABR. A ABR não gera automaticamente uma rota padrão quando anexada a um stub. Você deve configurar explicitamente essa opção para gerar uma rota padrão.

  • no-summaries—(Opcional) Impede que a ABR anucie rotas sumárias de publicidade na área de stub convertendo a área de stub em uma área totalmente stubby. Se configurada em combinação com a default-metric declaração, uma área totalmente stubby só permite rotas internas para a área e anuncia a rota padrão para a área. Rotas e destinos externos para outras áreas não são mais resumidos ou permitidos em uma área totalmente stubby. Apenas a ABR requer essa configuração adicional porque é o único dispositivo de roteamento dentro da área totalmente stubby que cria LSAs tipo 3 usados para receber e enviar tráfego de fora da área.

Nota:

No Junos OS Release 8.5 e posterior, o seguinte se aplica:

  • Uma interface de identificador de roteador que não está configurada para executar OSPF não é mais anunciada como uma rede stub em LSAs OSPF.

  • O OSPF anuncia uma rota local com um comprimento de prefixo de 32 como um link de stub se a interface de loopback estiver configurada com um comprimento de prefixo diferente de 32. O OSPF também anuncia a rota direta com o comprimento de máscara configurado, como em versões anteriores.

A configuração rápida da CLI mostra a configuração para todos os dispositivos na Figura 10. A seção #d24e104__d24e443 descreve as etapas do Dispositivo 2, Dispositivo 6, Dispositivo 7 e Dispositivo 8.

Configuração

Procedimento

Configuração rápida da CLI

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

Dispositivo 1

Dispositivo 2

Dispositivo 3

Dispositivo 4

Dispositivo 5

Dispositivo 6

Dispositivo 7

Dispositivo 8

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 o dispositivo 2:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 nas interfaces que estão na área 0.

  3. Habilite o OSPFv3 na interface que está na área 7.

  4. Especifique a área 7 como uma área de stub do OSPFv3.

    A stub declaração é necessária em todos os dispositivos de roteamento da área.

  5. Na ABR, injete uma rota padrão na área.

  6. (Opcional) Na ABR, restrinja a entrada de LSAs sumários na área.

    Esta etapa converte a área de stub em uma área totalmente stubby.

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 o dispositivo 6:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 na interface que está na área 7.

  3. Especifique a área 7 como uma área de stub do OSPFv3.

    A stub declaração é necessária em todos os dispositivos de roteamento da área.

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 o dispositivo 7:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 na interface que está na área 9.

  3. Configure rotas estáticas que permitem a conectividade às rotas dos clientes.

  4. Configure uma política de roteamento para redistribuir as rotas estáticas.

  5. Aplique a política de roteamento na instância OSPFv3.

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 o dispositivo 8:

  1. Configure as interfaces.

  2. Configure dois endereços de interface de loopback para simular rotas de clientes.

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.

Dispositivo 2

Dispositivo 6

Dispositivo 7

Dispositivo 8

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 tipo de área OSPFv3

Propósito

Verifique se a área do OSPFv3 é uma área de stub. Confirme que a saída exibe Stub como o tipo Stub.

Ação

A partir do modo operacional no Dispositivo 2 e no Dispositivo 6, entre no show ospf3 overview comando.

Significado

No dispositivo 2, o tipo de stub de área 0 é Not Stub. O tipo de stub de área 7 é Stub. A métrica padrão de stub é de 10.

No dispositivo 6, o tipo de stub de área 7 é Stub.

Verificação das rotas na área de stub do OSPFv3

Propósito

Certifique-se de que as rotas esperadas estejam presentes nas tabelas de roteamento.

Ação

A partir do modo operacional no Dispositivo 6 e Dispositivo 2, insira o show route comando.

Significado

No Dispositivo 6, a rota padrão foi aprendida devido à default-metric declaração sobre o Dispositivo 2 da ABR. Caso contrário, as únicas rotas OSPFv3 na tabela de roteamento do Dispositivo 6 são o endereço de rede 2001:db8:9009:4:/64 e o endereço multicast OSPFv3 ff02::5/128 para todos os roteadores de estado de enlace SPF, também conhecidos como AllSPFRouters.

No Dispositivo 2, todas as rotas OSPFv3 foram aprendidas, incluindo as rotas externas para clientes, 2001:db8:1010:1/128 e 2001:db8:2020:1/128.

Entendendo as áreas não tão stubby do OSPFv3

Como uma área de stub osPF, uma área de stub osPFv3 não tem rotas externas, de modo que você não pode redistribuir rotas de outro protocolo em uma área de stub. As NSSAs (Áreas não tão stubby) permitem que rotas externas sejam inundadas dentro da área. Os roteadores em um NSSA não recebem anúncios externos de estado de enlace (LSAs) de roteadores de fronteira de área (ABRs), mas podem enviar informações externas de roteamento para redistribuição. Eles usam LSAs tipo 7 para informar os ABRs sobre essas rotas externas, que a ABR então se traduz em LSAs externos tipo 5 e inundações normalmente para o resto da rede OSPF.

Exemplo: Configuração de áreas não tão stubby do OSPFv3

Este exemplo mostra como configurar um OSPFv3 não tão stubby area (NSSA) para controlar o anúncio de rotas externas para a área.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Neste exemplo, o Dispositivo 7 redistribui rotas estáticas do Cliente 1 para o OSPFv3. O dispositivo 7 está na área 9, que está configurada como um NSSA. O dispositivo 3 é o ABR conectado ao NSSA. Um NSSA é um tipo de área de stub que pode importar rotas externas do sistema autônomo e mandá-las para outras áreas, mas ainda não pode receber rotas externas de AS de outras áreas. Como a área 9 é definida como um NSSA, o Dispositivo 7 usa LSAs tipo 7 para informar a ABR (Dispositivo 3) sobre essas rotas externas. O dispositivo 3 então traduz as rotas do tipo 7 para digitar 5 LSAs externos e os inunda normalmente para o resto da rede OSPF.

Na área 3, o dispositivo 5 redistribui rotas estáticas do Cliente 2 para o OSPFv3. Essas rotas são aprendidas no Dispositivo 3, mas não no Dispositivo 7 ou 10. O dispositivo 3 injeta uma rota estática padrão na área 9 para que o Dispositivo 7 e 10 ainda possam chegar às rotas do Cliente 2.

Você configura cada dispositivo de roteamento na área 9 (ID da área 0.0.0.9) com a seguinte configuração:

  • nssa— especifica um OSPFv3 NSSA. Você deve incluir a nssa declaração em todos os dispositivos de roteamento na área 9.

Você também configura a ABR na área 9 com as seguintes configurações adicionais:

  • no-summaries— impede a ABR de anunciar rotas sumárias para o NSSA. Se configurado em combinação com a default-metric declaração, o NSSA só permite rotas internas para a área e anuncia a rota padrão para a área. Rotas e destinos externos para outras áreas não são mais resumidos ou permitidos no NSSA. Apenas a ABR requer essa configuração adicional porque é o único dispositivo de roteamento dentro do NSSA que cria LSAs sumários do Tipo 3 usados para receber e enviar tráfego de fora da área.

  • default-lsa— configura a ABR para gerar uma rota padrão para o NSSA. Neste exemplo, você configura o seguinte:

    • default-metric— Especifica que a ABR gera uma rota padrão com uma métrica especificada para o NSSA. Essa rota padrão permite o encaminhamento de pacotes do NSSA para destinos externos. Você configura essa opção apenas na ABR. A ABR não gera automaticamente uma rota padrão quando anexada a um NSSA. Você deve configurar explicitamente essa opção para a ABR para gerar uma rota padrão.

    • metric-type—(Opcional) Especifica o tipo de métrica externa para o LSA padrão, que pode ser tipo 1 ou Tipo 2. Quando o OSPFv3 exporta informações de rota de ASs externos, ele inclui um custo, ou métrica externa, na rota. A diferença entre as duas métricas é como o OSPFv3 calcula o custo da rota. Métricas externas do tipo 1 são equivalentes à métrica de estado do enlace, onde o custo é igual à soma dos custos internos mais o custo externo. As métricas externas do tipo 2 usam apenas o custo externo atribuído pelo roteador de limite AS. Por padrão, o OSPFv3 usa a métrica externa Tipo 2.

    • type-7— (Opcional) inunda LSAs padrão tipo 7 no NSSA se a no-summaries declaração estiver configurada. Por padrão, quando a no-summaries declaração é configurada, um LSA Tipo 3 é injetado em NSSAs para versão Junos OS 5.0 e posterior. Para oferecer suporte à compatibilidade retrógrada com versões anteriores do Junos OS, inclua a type-7 declaração.

Figura 11: Topologia de rede OSPFv3 com um NSSA OSPFv3 Network Topology with an NSSA

A configuração rápida da CLI mostra a configuração para todos os dispositivos na Figura 11. A seção #d26e123__d26e507 descreve as etapas do Dispositivo 3, Dispositivo 7 e Dispositivo 9.

Configuração

Procedimento

Configuração rápida da CLI

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

Dispositivo 1

Dispositivo 3

Dispositivo 4

Dispositivo 5

Dispositivo 7

Dispositivo 8

Dispositivo 9

Dispositivo 10

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 o dispositivo 3:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 nas interfaces que estão na área 0.

  3. Habilite o OSPFv3 na interface que está na área 9.

  4. Configure um OSPFv3 NSSA.

    A nssa declaração é necessária em todos os dispositivos de roteamento da área.

  5. Na ABR, injete uma rota padrão na área.

  6. (Opcional) Na ABR, especifique o tipo de métrica externa para a rota padrão.

  7. (Opcional) Na ABR, especifique a inundação de LSAs tipo 7.

  8. Na ABR, restrinja a entrada de LSAs sumários na área.

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 o dispositivo 5:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 na interface que está na área 3.

  3. Configure rotas estáticas que permitem a conectividade às rotas dos clientes.

  4. Configure uma política de roteamento para redistribuir as rotas estáticas.

  5. Aplique a política de roteamento na instância OSPFv3.

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 o dispositivo 7:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 na interface que está na área 9.

  3. Configure um OSPFv3 NSSA.

    A nssa declaração é necessária em todos os dispositivos de roteamento da área.

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 o dispositivo 8:

  1. Configure as interfaces.

  2. Configure dois endereços de interface de loopback para simular rotas de clientes.

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.

Dispositivo 3

Dispositivo 5

Dispositivo 7

Dispositivo 8

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 tipo de área OSPFv3

Propósito

Verifique se a área do OSPFv3 é uma área NSSA. Confirme que a saída é Stub NSSA exibida como o tipo Stub.

Ação

Do modo operacional no Dispositivo 3, o Dispositivo 7 e o Dispositivo 10 entram no show ospf3 overview comando.

Significado

No dispositivo 3, o tipo de stub de área 0 é Not Stub. O tipo de stub de área 9 é Stub NSSA. A métrica padrão de stub é de 10.

No dispositivo 7 e no dispositivo 10, o tipo de stub de área 9 é Stub NSSA.

Verificação das rotas na área de stub do OSPFv3

Propósito

Certifique-se de que as rotas esperadas estejam presentes nas tabelas de roteamento.

Ação

A partir do modo operacional do Dispositivo 7 e do Dispositivo 3, entre no show route comando.

Significado

No Dispositivo 7, a rota padrão foi aprendida devido à default-metric declaração sobre o Dispositivo 3 da ABR. Caso contrário, as únicas rotas OSPFv3 na tabela de roteamento do Dispositivo 7 são aquelas locais para a área 9 e o endereço multicast OSPFv3 ff02::5/128 para todos os roteadores de estado de enlace SPF, também conhecidos como AllSPFRouters.

O dispositivo 10 tem a rota padrão injetada pelo Dispositivo 3 e também as rotas externas OSPF injetadas pelo Dispositivo 7.

Nem o Dispositivo 7 nem o Dispositivo 10 têm as rotas externas de clientes que foram injetadas no OSPFv3 pelo Dispositivo 5.

No Dispositivo 3, todas as rotas OSPFv3 foram aprendidas, incluindo as rotas externas para clientes, 2001:db8:1010:1/128 e 2001:db8:2020:1/128.

Verificando o tipo de LSAs

Propósito

Verifique o tipo de LSAs que estão na área.

Ação

A partir do modo operacional no Dispositivo 7, entre no show ospf3 database nssa detail comando.

Significado

No Dispositivo 7, os NSSA LSAs são a rota padrão externa tipo 1, aprendida com o Dispositivo 3 e as rotas estáticas externas tipo 2 para a rede cliente 1.

Entendendo a filtragem de áreas não tão stubby

Você pode ter uma situação em que a exportação de LSAs tipo 7 para uma área não tão stubby (NSSA) é desnecessária. Quando um roteador de limite de sistema autônomo (ASBR) também é um roteador de fronteira de área (ABR) com um NSSA conectado, os LSAs tipo 7 são exportados para o NSSA por padrão.

Além disso, quando o ASBR (também um ABR) é anexado a vários NSSAs, um LSA tipo 7 separado é exportado para cada NSSA por padrão. Durante a redistribuição de rota, este dispositivo de roteamento gera LSAs tipo 5 e LSAs tipo 7. Assim, para evitar que a mesma rota seja redistribuída duas vezes (dos LSAs tipo 5 e LSAs tipo 7), você pode desabilitar a exportação de LSAs tipo 7 para o NSSA, incluindo a no-nssa-abr declaração sobre o dispositivo de roteamento.

Exemplo: Configuração de áreas não tão stubby do OSPFv3 com filtragem

Este exemplo mostra como configurar um OSPFv3 não tão stubby area (NSSA) quando não há necessidade de injetar rotas externas no NSSA como anúncios de estado de link tipo 7 (LSAs).

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Quando um roteador de borda de sistema autônomo (ASBR) também é um roteador de borda de área NSSA (ABR), o dispositivo de roteamento gera Tipo 5 e LSAs tipo 7. Você pode impedir que o roteador crie LSAs tipo 7 para o NSSA com a no-nssa-abr declaração.

Neste exemplo, o Dispositivo 5 e o Dispositivo 3 estão em redes de clientes. O dispositivo 4 e o Dispositivo 2 estão injetando as rotas do cliente no OSPFv3. A área 1 é um NSSA. Como o Dispositivo 4 é um NSSA ABR e um ASBR, ele gera ambos os LSAs tipo 7 e tipo 5 e injeta LSAs tipo 7 na área 1 e LSAs tipo 5 na área 0. Para impedir que os LSAs do tipo 7 sejam injetados na área 1, a no-nssa-abr declaração incluída na configuração do Dispositivo 4.

Figura 12: Topologia de rede OSPFv3 com um NSSA ABR que também é um ASBR OSPFv3 Network Topology with an NSSA ABR That Is Also an ASBR

A configuração rápida da CLI mostra a configuração para todos os dispositivos na Figura 12. A seção #d28e64__d28e386 descreve as etapas do Dispositivo 4.

Configuração

Procedimento

Configuração rápida da CLI

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

Dispositivo 1

Dispositivo 2

Dispositivo 3

Dispositivo 4

Dispositivo 5

Dispositivo 6

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, veja "Usando o editor de CLI no modo de configuração" no Guia do usuário da CLI.

Para configurar o dispositivo 4:

  1. Configure as interfaces.

  2. Habilite o OSPFv3 nas interfaces que estão na área 0.

  3. Habilite o OSPFv3 na interface que está na área 1.

  4. Configure um OSPFv3 NSSA.

    A nssa declaração é necessária em todos os dispositivos de roteamento da área.

  5. Na ABR, injete uma rota padrão na área.

  6. (Opcional) Na ABR, especifique o tipo de métrica externa para a rota padrão.

  7. (Opcional) Na ABR, especifique a inundação de LSAs tipo 7.

  8. Na ABR, restrinja a entrada de LSAs sumários na área.

  9. Desativar a exportação de LSAs tipo 7 para o NSSA.

    Essa configuração é útil se você tiver um roteador de limite AS que também é uma ABR com uma área NSSA anexada.

  10. Configure rotas estáticas para a rede do cliente.

  11. Configure uma política para injetar as rotas estáticas no OSPFv3.

  12. Aplique a política ao OSPFv3.

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.

Dispositivo 4

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

Verificação

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

Verificação das rotas na área de stub do OSPFv3

Propósito

Certifique-se de que as rotas esperadas estejam presentes nas tabelas de roteamento.

Ação

A partir do modo operacional no Dispositivo 1 e Dispositivo 6, entre no show route comando.

Significado

No Dispositivo 1, a rota padrão (::/0) foi aprendida por causa da default-metric declaração sobre a ABR, Dispositivo 4. As rotas do cliente 2001:db8:3030:1 e 2001:db8:4040:1 foram aprendidas com o Dispositivo 2. As rotas de 2001:db8:1010:1 e 2001:db8:2020:1 foram suprimidas. Eles não são necessários porque a rota padrão pode ser usada.

No dispositivo 6 na área 0, todas as rotas do cliente foram aprendidas.

Verificando o tipo de LSAs

Propósito

Verifique o tipo de LSAs que estão na área.

Ação

A partir do modo operacional no Dispositivo 1, entre no show ospf3 database nssa detail comando.

Significado

O dispositivo 4 não está enviando LSAs do Tipo 7 (NSSA) para rotas de clientes 2001:db8:1010:1/128 e 2001:db8:2020:1/128. Se você apagasse ou desativasse a no-nssa-abr declaração e depois repetisse o comando, veria que o show ospf3 database nssa detail Dispositivo 4 está enviando LSAs tipo 7 para 2001:db8:1010:1/128 e 2001:db8:2020:1/128.