Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração do suporte do OSPF para engenharia de tráfego

Suporte os OSPF para engenharia de tráfego

A engenharia de tráfego permite que você controle o caminho que os pacotes de dados seguem, ignorando o modelo de roteamento padrão, que usa tabelas de roteamento. A engenharia de tráfego move fluxos de enlaces congestionados para links alternativos que não seriam selecionados pelo caminho mais curto baseado em destino automaticamente computado.

Para ajudar a fornecer engenharia de tráfego e MPLS com informações sobre topologia e carregamento de rede, extensões foram adicionadas à implementação do OSPF pelo Junos OS. Quando a engenharia de tráfego é habilitada no dispositivo de roteamento, você pode habilitar o suporte à engenharia de tráfego OSPF. Quando você habilita a engenharia de tráfego para OSPF, o algoritmo de caminho mais curto (SPF) leva em conta os vários caminhos comutados por rótulos (LSPs) configurados sob MPLS e configura o OSPF para gerar anúncios opacos de estado de enlace (LSAs) que transportam parâmetros de engenharia de tráfego. Os parâmetros são usados para preencher o banco de dados de engenharia de tráfego. O banco de dados de engenharia de tráfego é usado exclusivamente para calcular caminhos explícitos para a colocação de LSPs na topologia física. O algoritmo CSPF (Constrained Shortest Path First, caminho mais curto restrito primeiro) usa o banco de dados de engenharia de tráfego para computar os caminhos que os LSPs MPLS tomam. O RSVP usa essas informações de caminho para configurar LSPs e reservar largura de banda para eles.

Por padrão, o suporte à engenharia de tráfego é desativado. Para habilitar a engenharia de tráfego, inclua a declaração de engenharia de tráfego . Você também pode configurar as seguintes extensões de engenharia de tráfego OSPF:

  • anuncia interfaces sem número — (somente OSPFv2) Anuncia o identificador local de link no pacote LSA de engenharia de tráfego local de enlace. Você não precisa incluir esta declaração se o RSVP for capaz de sinalizar interfaces não numeradas conforme definido no RFC 3477, sinalizando links não numerados no protocolo de reserva de recursos - Engenharia de tráfego (RSVP-TE).

  • preferência por protocolo de credibilidade — (somente OSPFv2) Atribui um valor de credibilidade às rotas OSPF no banco de dados de engenharia de tráfego. Por padrão, o Junos OS prefere rotas OSPF no banco de dados de engenharia de tráfego em relação a outras rotas de protocolo de gateway interior (IGP), mesmo que as rotas de outro IGP estejam configuradas com um valor de preferência menor, ou seja, mais preferido. O banco de dados de engenharia de tráfego atribui um valor de credibilidade a cada IGP e prefere as rotas do IGP com o maior valor de credibilidade. No Junos OS Release 9.4 e posterior, você pode configurar o OSPF para levar em conta a preferência do protocolo para determinar o valor da credibilidade do banco de dados de engenharia de tráfego. Quando a preferência do protocolo é usada para determinar o valor da credibilidade, as rotas OSPF não são automaticamente preferidas pelo banco de dados de engenharia de tráfego, dependendo da sua configuração.

  • ignore-lsp-metrics — ignora as métricas RSVP LSP em cálculos de atalho de engenharia de tráfego OSPF ou quando você configura LDP sobre LSPs RSVP. Essa opção evita a dependência mútua entre OSPF e RSVP, eliminando o período em que a métrica RSVP usada para tunelamento de tráfego não está atualizada. Além disso, se você estiver usando RSVP para engenharia de tráfego, você pode executar LDP simultaneamente para eliminar a distribuição de rotas externas no núcleo. Os LSPs estabelecidos pelo LDP são tunelados através dos LSPs estabelecidos pelo RSVP. O LDP trata efetivamente os LSPs projetados pelo tráfego como um único salto.

  • multicast-rpf-routes — (somente OSPFv2) Instala rotas IPv4 unicast (não LSPs) na tabela de roteamento multicast (inet.2) para verificações de encaminhamento de caminho reverso (RPF) multicast. A tabela de roteamento inet.2 consiste em rotas unicast usadas para a busca de RPF multicast. RPF é um mecanismo antispoofing usado para verificar se o pacote está entrando em uma interface que também está enviando dados de volta para a fonte do pacote.

  • sem topologia — (somente OSPFv2) Para desabilitar a disseminação de informações de topologia de estado de enlace. Se desabilitadas, as informações de topologia de engenharia de tráfego não serão mais distribuídas na área do OSPF.

  • atalhos — configura atalhos de IGP, que permitem que o OSPF use um LSP como o próximo salto como se fosse uma interface lógica do dispositivo de roteamento de entrada até o dispositivo de roteamento de saída. O endereço especificado na declaração de declaração no nível de hierarquia [editar protocolos mpls label-switched-path lsp-path-name] no dispositivo de roteamento de entrada deve combinar com o ID do roteador do dispositivo de roteamento de saída para que o LSP funcione como um link direto ao dispositivo de roteamento de saída e ser usado como entrada para os cálculos de SPF do OSPF. Quando usados dessa forma, os LSPs não são diferentes dos circuitos virtuais Asynchronous Transfer Mode (ATM) e Frame Relay (VCs), exceto que o LSPS transporta apenas tráfego IPv4.

    O OSPFv2 instala o prefixo para rotas IPv4 na tabela de roteamento inet.0 , e os LSPs são instalados por padrão na tabela de roteamento inet.3 .

    Os OSPFv3 LSPs usados para atalhos continuam a ser sinalizados usando IPv4. No entanto, por padrão, as rotas IPv6 de atalho calculadas através do OSPFv3 são adicionadas à tabela de roteamento inet6.3 . O comportamento padrão é que o BGP use apenas LSPs em seus cálculos. Se você configurar o MPLS para que ambos os BGP e IGPs usem LSPs para encaminhar tráfego, as rotas de atalho IPv6 calculadas através do OSPFv3 são adicionadas à tabela de roteamento inet6.0 .

    Nota:

    Sempre que possível, use atalhos do OSPF IGP em vez de atalhos de engenharia de tráfego.

  • lsp-metric-info-summary — Anuncia a métrica LSP em resumo LSAs para tratar o LSP como um link. Essa configuração permite que outros dispositivos de roteamento na rede usem esse LSP. Para isso, você precisa configurar a engenharia de tráfego MPLS e OSPF para anunciar a métrica LSP em resumo de LSAs.

Quando você habilita a engenharia de tráfego no dispositivo de roteamento, você também pode configurar uma métrica de OSPF que é usada exclusivamente para engenharia de tráfego. A métrica de engenharia de tráfego é usada para informações injetadas no banco de dados de engenharia de tráfego. Seu valor não afeta o encaminhamento normal do OSPF.

Exemplo: habilitar o suporte à engenharia de tráfego do OSPF

Este exemplo mostra como habilitar o suporte à engenharia de tráfego do OSPF para anunciar a métrica de caminho comutador de rótulos (LSP) em anúncios de estado de link (LSAs) sumários.

Requisitos

Antes de começar:

Visão geral

Você pode configurar o OSPF para tratar um LSP como um link e ter outros dispositivos de roteamento na rede usando este LSP. Para isso, você configura a engenharia de tráfego MPLS e OSPF para anunciar a métrica LSP em resumo de LSAs.

Neste exemplo, existem quatro dispositivos de roteamento na área 0.0.0.0, e você quer que o OSPF trate o LSP chamado R1-to-R4 que vai do dispositivo de entrada R1 até o dispositivo de saída R4 como um link.

Para OSPF, você habilita a engenharia de tráfego em todos os quatro dispositivos de roteamento na área, incluindo a traffic-engineering declaração. Essa configuração garante que o algoritmo de caminho mais curto (SPF) leve em conta os LSPs configurados sob MPLS e configure o OSPF para gerar LSAs que transportam parâmetros de engenharia de tráfego. Você garante ainda que o OSPF use o MPLS LSP como o próximo salto e anuncia a métrica LSP em LSAs sumários, incluindo a declaração opcional shortcuts lsp-metric-into-summary no dispositivo de ingresso R1.

Para MPLS, você habilita a engenharia de tráfego para que o MPLS realize engenharia de tráfego em ambos os destinos BGP e IGP, incluindo a traffic-engineering bgp-igp declaração, e você inclui o LSP chamado R1-to-R4, incluindo a label-switched-path lsp-path-name to address declaração sobre o dispositivo de entrada R1. O endereço especificado na to declaração sobre o dispositivo de entrada R1 deve combinar com o ID do roteador do dispositivo de saída R4 para que o LSP funcione como um link direto ao dispositivo de roteamento de saída e seja usado como entrada para os cálculos de SPF do OSPF. Neste exemplo, o ID do roteador do dispositivo de saída R4 é de 10.0.0.4.

Configuração

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 Modifique a configuração do Junos OS noguia de usuário da CLI.

Procedimento

Configuração rápida da CLI

Para habilitar rapidamente o suporte à engenharia de tráfego OSPF para anunciar a métrica LSP em LSAs resumidas, copie os seguintes comandos e cole-os na CLI.

Configuração em R1:

Configuração em R2:

Configuração em R3:

Configuração em R4:

Procedimento passo a passo

Para habilitar o suporte à engenharia de tráfego OSPF para anunciar métricas LSP em resumo LSAs:

  1. Configure o ID do roteador.

  2. Configure a área do OSPF e adicione as interfaces.

    Nota:

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

  3. Habilite a engenharia de tráfego do OSPF.

  4. No dispositivo R1, configure a engenharia de tráfego MPLS.

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

Resultados

Confirme sua configuração entrando nos show routing-options, show protocols ospfe show protocols mpls comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Saída para R1:

Saída para R2:

Saída para R3:

Saída para R4:

Para confirmar sua configuração OSPFv3, entre no show routing-optionse show protocols ospf3nos show protocols mpls comandos.

Verificação

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

Verificando o recurso de engenharia de tráfego para OSPF

Propósito

Verifique se a engenharia de tráfego foi habilitada para OSPF. Por padrão, a engenharia de tráfego é desabilitada.

Ação

A partir do modo operacional, entre no show ospf overview comando do OSPFv2 e entre no show ospf3 overview osPFv3.

Verificando as entradas do OSPF no banco de dados de engenharia de tráfego

Propósito

Verifique as informações do OSPF no banco de dados de engenharia de tráfego. O campo protocolo exibe OSPF e a área da qual as informações foram aprendidas.

Ação

Do modo operacional, entre no show ted database comando.

Verificando se o banco de dados de engenharia de tráfego está aprendendo informações de nós do OSPF

Propósito

Verifique se o OSPF está relatando informações de nós. O campo de nome protocolo exibe OSPF e a área da qual as informações foram aprendidas.

Ação

Do modo operacional, entre no show ted protocol comando.

Exemplo: configurar a métrica de engenharia de tráfego para uma interface OSPF específica

Este exemplo mostra como configurar o valor métrica do OSPF usado para engenharia de tráfego.

Requisitos

Antes de começar:

Visão geral

Você pode configurar uma métrica de OSPF usada exclusivamente para engenharia de tráfego. Para modificar o valor padrão da métrica de engenharia de tráfego, inclua a te-metric declaração. A métrica de engenharia de tráfego dos OSPF não afeta o encaminhamento normal do OSPF. Por padrão, a métrica de engenharia de tráfego tem o mesmo valor que a métrica OSPF. A faixa é de 1 a 65.535.

Neste exemplo, você configura a métrica de engenharia de tráfego do OSPF na interface dos OSPF fe-0/1/1 na área 0.0.0.0.

Configuração

Configuração rápida da CLI

Para configurar rapidamente a métrica de engenharia de tráfego do OSPF para uma interface específica, copiar os seguintes comandos, cole-os em um arquivo de texto, remover quaisquer quebras de linha, alterar todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de hierarquia [editar] e, em seguida, entrar no commit modo de configuração.

Procedimento

Procedimento passo a passo

Para configurar uma métrica de engenharia de tráfego OSPF para uma interface específica usada apenas para engenharia de tráfego:

  1. Crie uma área de OSPF.

    Nota:

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

  2. Configure a métrica de engenharia de tráfego dos segmentos de rede OSPF.

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

Resultados

Confirme sua configuração entrando no 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 que a configuração está funcionando corretamente.

Verificando a métrica de engenharia de tráfego configurada

Propósito

Verifique o valor da métrica da engenharia de tráfego. Confirme que o campo métrica exibe a métrica de engenharia de tráfego configurada.

Ação

Do modo operacional, entre no show ted database extensive comando.

Modo de engenharia de tráfego passiva OSPF

Normalmente, protocolos de roteamento interior, como o OSPF, não são executados em links entre sistemas autônomos. No entanto, para que a engenharia de tráfego inter-AS funcione corretamente, as informações sobre o enlace inter-AS — em particular, o endereço na interface remota — devem ser disponibilizadas dentro do sistema autônomo (AS). Normalmente, essas informações não estão incluídas nas mensagens de alcance bgp externas (EBGP) ou nos anúncios de roteamento OSPF.

Para inundar essas informações de endereço de link dentro do AS e disponibilizá-la para cálculos de engenharia de tráfego, você deve configurar o modo passivo OSPF para engenharia de tráfego em cada interface inter-AS. Você também deve fornecer o endereço remoto para o OSPF distribuir e incluí-lo no banco de dados de engenharia de tráfego. O modo de engenharia de tráfego OSPF permite que os caminhos comutados por rótulos (LSPs) MPLS descubram dinamicamente os roteadores de fronteira OSPF AS e permitam que os roteadores estabeleçam um LSP de engenharia de tráfego em vários sistemas autônomos.

Exemplo: configuração do modo de engenharia de tráfego passiva do OSPF

Este exemplo mostra como configurar o modo passivo OSPF para a engenharia de tráfego em uma interface inter-AS. O enlace do roteador de limite AS entre os pares de EBGP deve ser um enlace diretamente conectado e deve ser configurado como um enlace de engenharia de tráfego passivo.

Requisitos

Antes de começar:

Visão geral

Você pode configurar o modo passivo OSPF para engenharia de tráfego em uma interface inter-AS. O endereço usado para o nó remoto do enlace de engenharia de tráfego passivo OSPF deve ser o mesmo que o endereço usado para o enlace EBGP. Neste exemplo, você configura a interface so-1/1/0 na área 0.0.0.1 como o enlace inter-AS para distribuir informações de engenharia de tráfego com OSPF dentro do AS e incluir as seguintes configurações:

  • passiva — anuncia os endereços de interface direta em uma interface sem realmente executar o OSPF nessa interface. Uma interface passiva é aquela para a qual as informações de endereço são anunciadas como uma rota interna no OSPF, mas na qual o protocolo não é executado.

  • engenharia de tráfego — configura uma interface no modo de engenharia de tráfego passiva OSPF para permitir a descoberta dinâmica de roteadores de fronteira OSPF AS. Por padrão, o modo de engenharia de tráfego passiva do OSPF é desativado.

  • id de nó remoto — especifica o endereço IP na extremidade mais distante do enlace inter-AS. Neste exemplo, o endereço IP remoto é 192.168.207.2.

Configuração

Para configurar rapidamente o modo passivo OSPF para engenharia de tráfego, copie o seguinte comando, remova quaisquer quebras de linha e cole-o na CLI.

Procedimento

Procedimento passo a passo

Para configurar o modo de engenharia de tráfego passivo OSPF:

  1. Crie uma área de OSPF.

    Nota:

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

  2. Configure a interface so-1/1/0 como uma interface passiva configurada para engenharia de tráfego e especifique o endereço IP na extremidade mais distante do enlace inter-AS.

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

Resultados

Confirme sua configuração entrando no 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 que a configuração está funcionando corretamente.

Verificando o status das interfaces OSPF

Propósito

Verifique o status das interfaces OSPF. Se a interface for passiva, o campo de contagem de Adj é 0 porque nenhuma adjacência foi formada. Ao lado deste campo, você também pode ver a palavra Passiva.

Ação

Do modo operacional, entre no comando do show ospf interface detail OSPFv2 e insira o show ospf3 interface detail comando para o OSPFv3.

Caminhos comutados por rótulos publicitários para o OSPFv2

Um dos principais motivos para configurar caminhos comutados por rótulos (LSPs) em sua rede é controlar o caminho mais curto entre dois pontos na rede. Você pode anunciar LSPs no OSPFv2 como links ponto a ponto para que todos os dispositivos de roteamento participantes possam levar o LSP em conta ao realizar cálculos de SPF. O anúncio contém um endereço local (o endereço do LSP), um endereço remoto (o endereço do LSP) e uma métrica com a seguinte precedência:

  1. Use a métrica LSP definida sob o OSPFv2.

  2. Use a métrica LSP configurada para o caminho comutado por rótulos sob MPLS.

  3. Se você não configurar nenhum dos acima, use a métrica PADRÃO OSPFv2 de 1.

Nota:

Se você quer que um LSP anunciado no OSPFv2 seja usado em cálculos de SPF, deve haver um enlace reverso (ou seja, um enlace da extremidade traseira do LSP até a extremidade da cabeça). Você pode conseguir isso configurando um LSP na direção reversa e também anunciando-o no OSPFv2.

Exemplo: caminhos comutados por rótulos publicitários no OSPFv2

Este exemplo mostra como anunciar LSPs no OSPFv2.

Requisitos

Antes de começar, configure as interfaces do dispositivo. Consulte a Biblioteca de interfaces de rede do Junos OS para dispositivos de roteamento.

Visão geral

Para anunciar um LSP no OSPFv2, você define o LSP e configura o OSPFv2 para rotear o tráfego usando o LSP. Ao fazer isso, você pode usar o LSP para controlar o caminho mais curto entre dois pontos na rede. Você pode optar por fazer isso se quiser ter o tráfego OSPF roteado ao longo do LSP em vez de ter o OSPF usando o roteamento padrão de melhor esforço.

Neste exemplo, você configura o seguinte para anunciar um LSP no OSPFv2:

  • BGP

    Para todos os dispositivos de roteamento, configure o NÚMERO AS local 65000 e defina o grupo IBGP que reconhece os sistemas BGP especificados como pares. Todos os membros são internos para o AS local, para que você configure um grupo interno com uma lista completa de pares. Você também inclui o grupo peer AS, que é o mesmo que o número AS local que você configura.

  • MPLS

    Para todos os dispositivos de roteamento, configure a família de protocolos em cada interface lógica de trânsito e habilite o MPLS em todas as interfaces, com exceção da interface de gerenciamento (fxp0.0). Especifique o tipo de família de protocolo mpls .

  • RSVP

    Para todos os dispositivos de roteamento, habilite o RSVP em todas as interfaces, com exceção da interface de gerenciamento (fxp0.0). Você habilita o RSVP nos dispositivos desta rede para garantir que as interfaces possam sinalizar o LSP.

  • OSPFv2

    Para todos os dispositivos de roteamento, use o endereço de loopback para atribuir o ID do roteador, agrupar administrativamente todos os dispositivos na área 0.0.0.0 da OSPF, adicionar todas as interfaces participantes do OSPF à área 0.0.0.0 e desabilitar o OSPF na interface de gerenciamento (fxp0.0).

  • Caminho comutador de rótulos

    No dispositivo de roteamento de entrada R1, que é o início (ou head end) do LSP, configure um LSP com um caminho explícito. O caminho explícito indica que o LSP deve ir até o próximo endereço IP especificado no caminho sem atravessar outros nós. Neste exemplo, você cria um LSP chamado R1-to-R6 e especifica o endereço IP do dispositivo de roteamento de saída R6.

  • Anuncie o LSP no OSPFv2

    No dispositivo de roteamento de entrada R1, você anuncia o LSP como um link ponto a ponto no OSPFv2. Você pode atribuir opcionalmente uma métrica para que o LSP seja o caminho mais ou menos preferido para o destino.

Topologia

A Figura 1 mostra uma topologia de rede amostral que consiste no seguinte:

  • O BGP está configurado em todos os dispositivos de roteamento, com um sistema autônomo local (AS) 65000 que contém três dispositivos de roteamento:

    • R1 — O dispositivo R1 é o dispositivo de entrada com um ID do roteador de 10.0.0.1. A interface so-0/0/2 se conecta ao dispositivo R3.

    • R3 — O dispositivo R3 é o dispositivo de trânsito com um ID do roteador de 10.0.0.3. A interface so-0/0/2 se conecta ao dispositivo R1, e a interface so-0/0/3 se conecta ao dispositivo R6.

    • R6 — O dispositivo R6 é o dispositivo de saída com um ID do roteador de 10.0.0.6. A interface so-0/0/3 se conecta ao dispositivo R3.

  • O OSPFv2 está configurado em todos os dispositivos de roteamento.

  • MPLS e RSVP estão habilitados em todos os dispositivos de roteamento.

  • Um LSP sinalizado por RSVP está configurado no dispositivo R1.

Figura 1: Anunciar um LSP no OSPFv2 Advertising an LSP into OSPFv2

Configuração

Os exemplos a seguir exigem que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Modifique a configuração do Junos OS no guia de usuário da CLI.

Para configurar os dispositivos para anunciar um LSP no OSPFv2, execute as seguintes tarefas:

Configuração do BGP

Configuração rápida da CLI

Para configurar o BGP rapidamente em cada dispositivo de roteamento, copie os seguintes comandos e cole-os na CLI.

Configuração no dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Procedimento passo a passo

Para configurar o BGP:

  1. Em cada dispositivo de roteamento, configure o número AS local.

  2. Em cada dispositivo de roteamento, configure as conexões internas de vizinhos BGP.

  3. Se você terminar de configurar os dispositivos, comprometa a configuração.

Resultados

Confirme sua configuração inserindo os comandos e show protocols bgp os 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.

Configuração em R1:

Configuração em R3:

Configuração em R6:

Configuração de MPLS

Configuração rápida da CLI

Para configurar o MPLS rapidamente em todos os dispositivos de roteamento no AS 65000, copie os seguintes comandos e cole-os na CLI.

Configuração no dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Procedimento passo a passo

Para configurar o MPLS:

  1. Configure as interfaces de trânsito para MPLS.

  2. Habilite o MPLS.

  3. Desativar o MPLS na interface de gerenciamento (fxp0.0).

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

Resultados

Confirme sua configuração inserindo os comandos e show protocols mpls os show interfaces comandos. 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 dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Configuração de RSVP

Configuração rápida da CLI

Para configurar rapidamente o RSVP em todos os dispositivos de roteamento no AS 65000, copie os seguintes comandos e cole-os na CLI.

Configuração no dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Procedimento passo a passo

Para configurar o RSVP:

  1. Habilite o RSVP.

  2. Desativar RSVP na interface de gerenciamento (fxp0.0).

  3. Se você terminar de configurar os dispositivos, comprometa a configuração.

Resultados

Confirme sua configuração entrando no show protocols rsvp 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 no dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Configuração do OSPF

Configuração rápida da CLI

Para configurar o OSPF rapidamente, copie os seguintes comandos e cole-os na CLI.

Configuração no dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Procedimento passo a passo

Para configurar o OSPF:

  1. Configure o ID do roteador.

  2. Configure a área do OSPF e as interfaces.

  3. Desativar o OSPF na interface de gerenciamento (fxp0.0).

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

Resultados

Confirme sua configuração inserindo os comandos e os show routing-options show protocols ospf comandos. 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 dispositivo R1:

Configuração no dispositivo R3:

Configuração no dispositivo R6:

Configuração do LSP

Configuração rápida da CLI

Para configurar rapidamente o LSP no roteador R1 do dispositivo de roteamento de entrada, copie o seguinte comando e cole-o na CLI.

Procedimento passo a passo

Para configurar o LSP no dispositivo R1:

  1. Insira o modo de configuração MPLS.

  2. Crie o LSP.

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

Resultados

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

Anunciando o LSP no OSPFv2

Configuração rápida da CLI

Para anunciar rapidamente o LSP no OSPFv2 e incluir opcionalmente uma métrica para o LSP no dispositivo R1, copie os seguintes comandos e cole-os na CLI.

Procedimento passo a passo

Para anunciar o LSP no OSPFv2 no roteador R1:

  1. Insira o modo de configuração do OSPF.

  2. Inclua a label-switched-path declaração e especifique o LSP R1-to-R6 que você criou.

  3. (Opcional) Especifique uma métrica para o LSP.

  4. Se você terminar de configurar o dispositivo, comprometa a configuração.

Resultados

Confirme sua configuração entrando no 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.

Verificação

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

Verificando o vizinho do OSPF

Propósito

Verifique se outro vizinho está listado e pode ser contatado pelo LSP. O campo de interface indica o nome do LSP.

Ação

Do modo operacional, entre no show ospf neighbor comando.

Identificador de segmentos de adjacência estática para OSPF

O segmento de adjacência é um túnel de salto único encaminhado rigoroso que transporta pacotes por uma ligação específica entre dois nós, independentemente do custo do enlace. Você pode configurar rótulos de identificador de segmentos de adjacência estática (SID) para uma interface.

Configurar um SID de adjacência estática em uma interface faz com que o SID de adjacência alocado dinamicamente existente seja removido junto com a rota de trânsito para o mesmo.

Para SIDs de adjacência estática, os rótulos são escolhidos em um pool de rótulos estático reservado ou de um bloco global de roteamento por segmentos OSPF (SRGB).

Você pode reservar uma faixa de rótulo para ser usada para alocação estática de rótulos usando a configuração a seguir:

user@host# set protocols mpls label-range static-label-range start-value end-value

O pool estático pode ser usado por qualquer protocolo para alocar um rótulo nesta faixa. Você precisa garantir que nenhum dos dois protocolos use o mesmo rótulo estático. OSPF adjacência SIDs podem ser alocados a partir deste bloco de rótulos através da configuração usando a palavra-chave label. O label valor para os SIDs de adjacência específicos precisa ser configurado explicitamente. A seguir, uma configuração de amostra:

Nota:

Quando você usa ipv4-adjacency-segment o comando, a interface subjacente deve ser ponto a ponto.

SRGB é um espaço de rótulo global alocado para o protocolo com base na configuração. Os rótulos em todo o SRGB estão disponíveis para uso do OSPF e não são alocados em outros aplicativos/protocolos. SIDs de prefixo (e SIDs de nó) são indexados a partir deste SRGB.

Os OSPF Adj-SIDs podem ser alocados do OSPF SRGB usando a palavra-chave "índice" na configuração. Nesses casos, deve-se garantir que o índice Adj-SID não conflitua com nenhum outro SID prefixo no domínio. Assim como os Prefix-SIDs, os Adj-SIDs também serão configurados mencionando o índice em relação ao SRGB. No entanto, o Adj-SID ainda terá o SID como um valor e as bandeiras L e V estão definidas. A seguir, uma configuração de amostra:

SIDs de adjacência estática podem ser configurados por área e também com base na necessidade ou não da proteção. OS SIDs de adjacência devem ser configurados por interface no nível [edit protocols ospf area area interface interface-name] de hierarquia.

  • Protegido — garante que o SID de adjacência seja elegível para ter um caminho de backup e uma bandeira B seja definida em um anúncio sid de adjacência.

  • Desprotegido — garanta que nenhum caminho de backup seja calculado para um SID de adjacência específico e que uma bandeira B não seja definida em um anúncio de SID de adjacência.

A seguir, uma configuração de amostra:

Quando o roteamento por segmentos é usado em sub-redes LAN, cada roteador na LAN pode anunciar o SID de adjacência de cada um de seus vizinhos. Para configurar o SID de adjacência para uma interface LAN para um vizinho específico, você deve configurar os SIDs de adjacência sob a configuração lan-neighbor no nível [edit protocols ospf area 0.0.0.0 interface interface_name lan-neighbor neighbor-routerid] hierarquia. A seguir, uma configuração de amostra:

Use a seguinte hierarquia de CLI para configurar o SID de adjacência:

Use os seguintes comandos operacionais de CLI para verificar a configuração:

mostrar detalhes do vizinho ospf

A saída de amostra a seguir exibe os detalhes do SID configurado e dinâmico de adjacência.

Entender o roteamento de pacotes de origem em redes (SPRING)

O roteamento de pacotes de origem ou roteamento por segmentos é uma arquitetura de plano de controle que permite que um roteador de entrada guie um pacote por um conjunto específico de nós e links na rede sem depender dos nós intermediários na rede para determinar o caminho real que deve seguir. Nesse contexto, o termo "fonte" significa "o ponto em que a rota explícita é imposta".

A partir do Junos OS Release 20.3R1, o suporte ao roteamento por segmentos para o protocolo OSPF oferece funcionalidade básica com o roteamento de pacotes de origem em redes (SPRING).

Essencialmente, o roteamento por segmentos envolve IGPs como OSPF para publicidade de dois tipos de segmentos ou túneis de rede:

  • Primeiro, um rigoroso túnel de salto único encaminhado que transporta pacotes por uma ligação específica entre dois nós, independentemente do custo do enlace, conhecidos como segmentos de adjacência.

  • Em segundo lugar, um túnel multihop usando links de caminho mais curtos entre dois nós específicos, chamados de segmentos de nó.

Os roteadores de entrada podem direcionar um pacote através de um conjunto desejado de nós e links, pré-anexando o pacote com uma combinação apropriada de túneis.

O roteamento por segmentos aproveita o paradigma de roteamento de origem. Um nó direciona um pacote através de uma lista ordenada de instruções, chamada segmentos. Um segmento pode representar qualquer instrução, topologia ou serviço baseado. Um segmento pode ter uma semântica local para um nó de roteamento por segmentos ou para um nó global dentro de um domínio de roteamento por segmentos. O roteamento por segmentos impõe um fluxo por qualquer caminho topológico e cadeia de serviços, mantendo o estado por fluxo apenas no nó de entrada para o domínio do roteamento por segmentos. O roteamento por segmentos pode ser aplicado diretamente à arquitetura MPLS sem alterações no plano de encaminhamento. Um segmento é codificado como um rótulo MPLS. Uma lista ordenada de segmentos é codificada como uma pilha de rótulos. O segmento a processar está no topo da pilha. Após a conclusão de um segmento, o rótulo relacionado é retirado da pilha. O roteamento por segmentos pode ser aplicado à arquitetura IPv6, com um novo tipo de cabeçalho de extensão de roteamento. Um segmento é codificado como um endereço IPv6. Uma lista ordenada de segmentos é codificada como uma lista ordenada de endereços IPv6 no cabeçalho de extensão de roteamento. O segmento a processar é indicado por um ponteiro no cabeçalho de extensão de roteamento. Após a conclusão de um segmento, o ponteiro é incrementado.

Os atalhos de engenharia de tráfego são habilitados para rotas de segmento osPF rotuladas, quando você configura shortcuts nos seguintes níveis de hierarquia:

  • [edit protocols ospf traffic-engineering family inet] para tráfego IPv4.

  • [edit protocols ospf traffic-engineering family inet6] para tráfego IPv6.

Quando o roteamento de pacotes de origem é implantado na rede, nos dispositivos de data center, backbone e peering, switch de pacotes MPLS com uma pilha de rótulos criada pela fonte do tráfego; por exemplo, servidores de data center. No Junos OS Release 17.4R1, o tráfego roteado de origem coexiste com o tráfego tomando caminhos sinalizados por RSVP, e o roteamento de origem é implementado como comutação regular de rótulos através da tabela mpls.0 usando as operações de rótulos – pop, swap (para o mesmo valor de rótulo) e swap-push (para proteção de interface). Em todos os casos, o tráfego pode ser equilibrado entre várias interfaces de Camada 3 ou dentro de uma interface agregada. A partir do Junos OS Release 17.4R1, as estatísticas de tráfego em uma rede de roteamento por segmentos podem ser registradas em um formato em conformidade com o OpenConfig para as interfaces de Camada 3. As estatísticas são registradas apenas para o roteamento de pacotes de origem em redes (SPRING), excluindo tráfego sinalizado por RSVP e LDP, e as estatísticas MPLS familiares por interface são contabilizadas separadamente. As estatísticas do SR também incluem estatísticas de tráfego SPRING por membro do grupo de agregação de enlaces (LAG) e por identificador de segmento (SID). Para permitir o registro de estatísticas de roteamento por segmentos, inclua sensor-based-stats a declaração no nível de [edit protocol isis source-packet-routing] hierarquia.

Antes do Junos OS Release 19.1R1, os sensores estavam disponíveis para coletar estatísticas de roteamento por segmentos apenas para tráfego de trânsito MPLS, que é de natureza MPLS para MPLS. A partir do Junos OS Release 19.1R1, em roteadores da Série MX com interfaces MPC e MIC e roteadores da Série PTX, sensores adicionais são introduzidos para coletar estatísticas de roteamento por segmentos para tráfego de entrada MPLS, que é de natureza IP-to-MPLS. Com esse recurso, você pode habilitar sensores apenas para o tráfego de roteamento por segmentos OSPF de rótulos e transmitir as estatísticas para um cliente gRPC.

Você pode habilitar as estatísticas de roteamento por segmentos para tráfego de entrada MPLS usando a opção egress sob a declaração de per-sid configuração. O nome do recurso para a funcionalidade de saída por sid é:

/junos/services/segment-routing/sid/egress/usage/

Você pode ver a associação de rotas osPF de rótulo com os sensores usando a saída de show ospf spring sensor info comando. Este comando não exibe contra-valores dos sensores reais.

Os registros de estatísticas de roteamento por segmentos são exportados para um servidor. Você pode ver dados de estatísticas de roteamento por segmentos dos seguintes caminhos do OpenConfig:

  • /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-OSPF-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts

  • /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-OSPF-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts

Nota:
  • O switchover gracioso do mecanismo de roteamento (GRES) não tem suporte para estatísticas de roteamento por segmentos.

    O roteamento ativo ininterrupto (NSR) não tem suporte para OSPF de rótulos. Durante uma troca de mecanismo de roteamento, um novo sensor é criado no novo mecanismo de roteamento primário, substituindo o sensor criado pelo mecanismo de roteamento primário anterior. Como resultado, no momento da troca do mecanismo de roteamento, as estatísticas de roteamento por segmentos começam a zero.

  • A reinicialização graciosa não é suporte para os osPF de rótulos.

    Em caso de reinício gracioso, o sensor existente é excluído e um novo sensor é criado durante a inicialização do OSPF. O contador de estatísticas de roteamento por segmentos reinicia a partir de zero.

  • A atualização de software em serviço (ISSU) e a atualização ininterrupta de software (NSSU) não são suportadas. Nesses casos, o contador de estatísticas de roteamento por segmentos é reiniciado.

  • Os dados de roteamento por segmentos de estatística zero são suprimidos e não são transmitidos para os clientes gRPC.

Tabela de histórico de lançamento
Lançamento
Descrição
20.3R1
A partir do Junos OS Release 20.3R1, o suporte ao roteamento por segmentos para o protocolo OSPF oferece funcionalidade básica com o roteamento de pacotes de origem em redes (SPRING).
19.1R1
A partir do Junos OS Release 19.1R1, em roteadores da Série MX com interfaces MPC e MIC e roteadores da Série PTX, sensores adicionais são introduzidos para coletar estatísticas de roteamento por segmentos para tráfego de entrada MPLS, que é de natureza IP-to-MPLS. Com esse recurso, você pode habilitar sensores apenas para o tráfego de roteamento por segmentos OSPF de rótulos e transmitir as estatísticas para um cliente gRPC.
17.4R1
A partir do Junos OS Release 17.4R1, as estatísticas de tráfego em uma rede de roteamento por segmentos podem ser registradas em um formato em conformidade com o OpenConfig para as interfaces de Camada 3.