Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Como configurar algoritmos flexíveis no OSPF para engenharia de tráfego de roteamento por segmentos

Um algoritmo flexível permite que os IGPs sozinhos computem caminhos baseados em restrições na rede, fornecendo assim uma engenharia de tráfego simples sem usar um controlador de rede. Esta é uma solução leve para redes que não implementaram um controlador com roteamento completo por segmentos, mas ainda querem colher os benefícios do roteamento por segmentos em sua rede.

O que vem a seguir

Para obter mais informações sobre a configuração de algoritmos flexíveis, consulte o Guia do usuário do OSPF

Entenda o algoritmo flexível de OSPF para roteamento por segmentos

A partir do Junos OS Release 21.1R1, você pode fatiar uma rede definindo algoritmos flexíveis que computam caminhos usando diferentes parâmetros e restrições de enlace com base em seus requisitos. Por exemplo, você pode definir um algoritmo flexível que computa um caminho para minimizar a métrica do IGP e definir outro algoritmo flexível para computar um caminho baseado na métrica de engenharia de tráfego para dividir a rede em planos separados. Esse recurso permite que redes sem um controlador configurem a engenharia de tráfego usando roteamento por segmentos sem realmente implementar um controlador de rede. Você pode usar os SIDs de prefixo para direcionar pacotes ao longo dos caminhos baseados em restrições. Você pode configurar os SIDs de prefixo para algoritmo flexível por meio de configurações de políticas.

Os protocolos IGP usam uma métrica de link para calcular o melhor caminho. No entanto, o melhor caminho de IGP pode nem sempre ser o melhor caminho para certos tipos de tráfego. Portanto, o IGP computado o melhor caminho com base na métrica de IGP mais curta é frequentemente substituído por caminho projetado de tráfego devido aos requisitos de tráfego que não são refletidos pela métrica do IGP. Normalmente, o RSVP-TE ou SR TE é usado para computar o caminho com base em métricas e restrições adicionais para superar essa limitação. O Junos instala tais caminhos nas tabelas de encaminhamento, além de ou como um substituto para o caminho original computado pelos IGPs.

Benefícios da configuração de algoritmo flexível

  • Uma versão leve da engenharia de tráfego de roteamento por segmentos que pode ser usada no núcleo da rede.

  • Permite configurar a engenharia de tráfego usando o roteamento por segmentos mesmo sem instalar um controlador de rede.

  • Utilize multicaminho de igual custo (ECMP) e TI-LFA por fatia sem configurar BGP-LS ou caminho estático.

  • Compute o caminho de backup TI-LFA usando a mesma definição flexível de algoritmo e computação de restrições.

  • Aproveite a engenharia de tráfego de roteamento por segmentos usando apenas o OSPFv2 sem configurar RSVP ou LDP.

  • Capacidade de provisionar caminhos primários limitados com base em um único rótulo.

O que é a definição flexível de algoritmos (FAD)?

Um algoritmo flexível permite que o IGP calcule os melhores caminhos adicionais com base em restrições especificadas, fornecendo assim uma engenharia de tráfego simples sem usar um controlador de rede. Esta é uma solução leve para redes que não implementaram um controlador com roteamento completo por segmentos, mas ainda querem colher os benefícios do roteamento por segmentos em sua rede. Cada operador pode definir restrições ou cores separadas, dependendo de seus requisitos.

Para definir um algoritmo flexível, inclua flex-algorithm id a declaração no nível de [edit routing-options] hierarquia. A definição flexível de algoritmo (FAD) é atribuída com um identificador que varia de 128 a 255. Esse algoritmo flexível pode ser definido em um ou mais roteadores em uma rede. Um algoritmo flexível computa o melhor caminho com base nos seguintes parâmetros:

  • Calculation type— SPF ou SPF rigoroso são as duas opções de tipo de cálculo disponíveis. Você pode especificar um desses tipos de cálculo em sua FAD. Selecione o tipo de cálculo SPF se quiser influenciar a computação SPF em seu dispositivo com base em uma determinada política local, como atalhos de engenharia de tráfego. Se você selecionar SPF rigoroso, a política local não poderá influenciar a seleção do caminho SPF.

  • Metric type- Métrica de IGP ou TE são as opções de tipo de métrica disponíveis. Você pode especificar um desses tipos de métrica em sua FAD dependendo do seu requisito de rede. Se você não quiser usar a métrica IGP para um link específico, você pode configurar uma métrica de TE que o OSPFv2 pode usar para o cálculo da rota.

  • Priority- Você pode atribuir uma prioridade às suas FADs conforme o seu requisito e o OSPFv2 prioriza um anúncio de FAD específico em relação a outra FAD com base em sua prioridade atribuída.

  • Set of Link constraints- Você pode configurar grupos de administradores para muitos protocolos no nível de [edit protocols mpls admin-groups] hierarquia para colorir um link individual. Estes admin-groups podem então ser definidos como include any, include-all ou exclude no nível de [edit routing-options flex-algorithm definition admin-groups] hierarquia.

Recomendamos configurar algoritmo flexível em apenas alguns roteadores para fornecer redundância e evitar conflitos. A definição flexível de algoritmos é anunciada no IGP como FAD sub-TLVs. Em redes muito grandes, não recomendamos configurar mais de 8 definições flexíveis de algoritmo, pois cada algoritmo flexível calculará seu próprio caminho e pode causar problemas de desempenho além disso.

A FAD padrão tem os seguintes parâmetros:

  • tipo de cálculo: spf

  • tipo de métrica: igp-métrica

  • prioridade: 0

  • Restrições de enlace: nenhuma

Nota:

Modificar a definição flexível de algoritmo em uma rede ao vivo ou em tempo real pode causar interrupções no tráfego até que todos os nós convergam nos novos caminhos.

A partir do Junos OS 21.4R1, oferecemos suporte a definição flexível de algoritmos (FAD)" e "Métrica flexível de prefixo de algoritmo (FAPM)" no TED e implementamos duas novas TLVs correspondentes "FAD TLV" e "FAPM TLV" no BGP-LS. O valor do FAD TLV contém Flex-Algorithm, Tipo Métrica, Tipo de Cálculo e Prioridade, todos eles um byte cada. O TLV pode ter zero ou mais sub-TLVs incluídos nele. Os cinco sub-tlvs são Flex Algo Exclude Any Affinity, Flex Algo Include Any Affinity, Flex Algo Include All Affinity, Flex Algo Definition Flags e Flex Algo Exclude SRLG.

O FAD TLV só pode ser adicionado ao atributo BGP-LS do NLRI de nós se o nó correspondente se originar no IGP TLV ou sub-TLV subjacente. O atributo BGP-LS associado a um NLRI de nós pode incluir uma ou mais TLVs FAD correspondentes à definição flexível de algoritmo para cada algoritmo de que o nó é publicidade.

O valor do FAPM TLV contém Flex-Algorithm (1 byte), Reservado (3 bytes) e Métrica (4 bytes). O FAPM TLV pode ser adicionado ao atributo BGP-LS do Prefix NLRI originado por um nó, somente se o nó correspondente se originar do Prefixo.

A partir do Junos OS Release 22.4R1, definimos a métrica de prefixo de algoritmo flexível (FAPM) para permitir um caminho ideal de ponta a ponta para um prefixo interárea. O roteador de borda de área (ABR) deve incluir o FAPM ao anunciar o prefixo entre áreas que podem ser alcançadas com o algoritmo flexível (flex algo). Quando um prefixo é inalcançável, a ABR não deve incluir esse prefixo nesse algo flex quando se anuncia entre áreas. A FAPM definida oferece suporte interárea.

Participação em um algoritmo flexível

Você pode configurar roteadores específicos para participar em um algoritmo flexível específico conforme o seu requisito. Caminhos computados com base em uma definição flexível de algoritmo são usados por vários aplicativos cada um potencialmente usando seu próprio plano de dados específico para o encaminhamento dos dados por tais caminhos. O dispositivo participante deve anunciar explicitamente sua participação em um algoritmo flexível específico para cada aplicativo no algoritmo flexível de roteamento por segmentos sub TLV para OSPFv2. Você pode configurar um nó para participar em um determinado algoritmo flexível, desde que possa suportar as restrições especificadas nesse FAD.

Para configurar a participação em um algoritmo flexível, inclua a flex-algorithm declaração no nível de [edit protocols isis source-packet- routing] hierarquia. O mesmo dispositivo pode anunciar uma FAD e também participar de um algoritmo flexível.

Topologia de rede configurada com definições flexíveis de algoritmos

A Figura 1 mostra a topologia da amostra, há 8 roteadores R0, R1, R2, R3, R4, R5, R6 e R7. Quatro algoritmos flexíveis, 128, 129, 130 e 135 são definidos e configurados com grupos administrativos conforme listado na tabela a seguir:

Definição de algoritmo flex (FAD)

Cor

128

Inclua qualquer vermelho

129

Incluir qualquer verde

130

Inclua qualquer verde e azul

135

Exclua o vermelho

Figura 1: Topologia flexível de algoritmos Flexible Algorithm Topology

A Figura 2 mostra como a FAD 128 roteia o tráfego em qualquer interface configurada com o grupo administrador vermelho.

Figura 2: Fluxo de tráfego para definição flexível de algoritmo 128 Traffic Flow for Flexible Algorithm Definition 128

A Figura 3 mostra como a FAD 129 roteia o tráfego em qualquer interface configurada com o grupo administrador verde.

Figura 3: Fluxo de tráfego para definição flexível de algoritmo 129 Traffic Flow for Flexible Algorithm Definition 129

A Figura 4 mostra como a FAD 130 roteia o tráfego em qualquer interface configurada com o grupo administrador verde e azul.

Figura 4: Fluxo de tráfego para definição flexível de algoritmos 130 Traffic flow for Flexible Algorithm Definition 130

A Figura 5 mostra como a FAD 135 roteia o tráfego em qualquer interface que não esteja configurada com o grupo administrador vermelho.

Figura 5: Fluxo de tráfego para definição flexível de algoritmo 135 Traffic Flow for Flexible Algorithm Definition 135

RIBs flexíveis de algoritmo

Para cada algoritmo flexível que um roteador participa nas rotas de algoritmo flexíveis correspondentes são instalados nos grupos RIB de algoritmo flexível correspondentes também conhecidos como tabelas de roteamento. Por padrão, rotas de algoritmo flexíveis OSPFv2 rotuladas são instaladas nos inet.color inet(6)color.0 e mpls.0 RIBs.

Comunidade BGP e algoritmos flexíveis

Um algoritmo flexível pode ter uma comunidade de cores BGP associada para resolver rotas de outros serviços, como o serviço VPN. Por padrão, a comunidade de cores BGP associada é a mesma que a ID do algoritmo flexível. As rotas de entrada de algoritmo flexíveis instaladas nas tabelas de inet(6)color.0 terão essa comunidade de cores no percurso. No entanto, você pode configurar uma comunidade de cores BGP diferente no nível de [edit routing-options flex-algorithm id color desired color community value] hierarquia.

Nota:

Mudar a comunidade de cores BGP para um algoritmo flexível pode resultar em interrupções no tráfego. Se você modificar uma comunidade de cores BGP para um algoritmo flexível, então todas as rotas relativas a esse algoritmo flexível serão removidas da RIB e adicionadas novamente com novas cores.

Recursos suportados e sem suporte

O Junos OS oferece suporte a algoritmos flexíveis nos seguintes cenários:

  • Suporte para configurar e anunciar SIDs prefixos para diferentes algoritmos flexíveis.

  • Oferece suporte parcial ao Internet Draft draft-ietf-lsr-flex-algo-05.txt algoritmo flexível de IGP

  • A implementação atual para algoritmos flexíveis é suportada apenas para OSPFv2, pois apenas o OSPFv2 oferece suporte ao roteamento por segmentos.

O Junos OS não oferece suporte aos seguintes recursos em conjunto com algoritmos flexíveis:

  • A métrica de atraso do enlace não é suportada.

  • Algoritmo flexível é aplicável apenas para topologia unicast padrão, a multi-topologia OSPFv2 não é suportada.

  • Os atalhos OSPFv2 e outras opções de configuração de engenharia de tráfego OSPFv2 não são aplicáveis à computação flexível de algoritmos. .
  • A implementação atual para algoritmos flexíveis não é suportada para o OSPFv3.
  • O vazamento entre áreas (OSPFv2) de SIDs de prefixo flexível de algoritmos não é suportado.

  • A resolução de conflitos de Prefixo e SID não é suportada.

  • A funcionalidade alternativa sem loop remoto não é suportada porque TI-LFA é a computação FRR preferida.

  • A definição flexível de algoritmos de publicidade na ausência de participação flexível de algoritmos não é suportada.

  • O anúncio de atributos de link para algoritmo flex usando os anúncios de atributos de link específicos do aplicativo não é suportado.

  • A classe de transporte RIB não é suportada.

Algoritmo flexível baseado em atributo de link específico para aplicativos

A partir do Junos OS e junos OS Evolved Release 22.2R1, você pode anunciar diferentes atributos te, como te-metric, delay-metric ou admin-groups para RSVP e algoritmos flexíveis no mesmo link. Isso é feito usando um algoritmo flexível de atributo de link específico para aplicativos conforme definido na RFC 8920.

A vantagem de ter um atributo de link específico do aplicativo de algoritmo flexível anunciando grupos te-metric, delay-metric ou admin é que um único link pode anunciar diferentes atributos de te-link para aplicativos legados, como RSVP e diferentes atributos te-link para algoritmos flexíveis.

Para configurar o te-attribute específico do aplicativo de algoritmo flexível, inclua a application-specific declaração no nível de [edit protocols ospf area interface] hierarquia e a strict-asla-based-flex-algorithm declaração no nível de [edit protocols ospf source-packet-routing] hierarquia. Com essa implementação, não é mais obrigatório que o link tenha o RSVP habilitado e [edit protocols ospf traffic-engineering advertisement always] seja configurado, o que é o caso do comportamento existente de atributos de engenharia de tráfego de publicidade.

Nota:

A implementação do Junos OS e junos OS Evolved do atributo de link específico para aplicativos oferece suporte apenas a aplicativos de algoritmo flexíveis.

Algoritmo flexível baseado em atributos de link específicos para aplicativos rigorosos

O comportamento padrão do algoritmo flexível específico do aplicativo é usar os atributos de te-attributes específicos do aplicativo flexível para um link se disponível e, se não, depois voltar para os atributos de te-atributos específicos de aplicativos comuns e, se nenhum dos dois estiver disponível, use os atributos te legados.

A declaração strict-asla-based-flex-algorithm de [edit protocols ospf source-packet-routing] configuração no precisa ser aplicada a todos os algoritmos flexíveis em execução nos dispositivos da rede para evitar loops de roteamento.

Se strict-asla-based-flex-algorithm estiver configurado em todos os dispositivos, deve ser anunciado um te-attribute específico de aplicativo ou um atributo te-attribute específico do aplicativo flexível para cada link flexível de algoritmo. Na ausência de atributos te específicos do aplicativo, o dispositivo não volta aos atributos te legados e simplesmente ignora o link.

O sistema operacional oferece suporte aos seguintes recursos em conjunto com algoritmo flexível baseado em atributo de link específico do aplicativo:

  • O subTLV de atributo de te específico do aplicativo para atender à RFC 8920. O sub-TLV de te-atributos específicos do aplicativo é um sub-TLV do TLV de enlace estendido OSPFv2 conforme definido no RFC 7684.

  • Oferece suporte parcial à máscara de bit de identificador de aplicativo padrão para anunciar o X-bit para algoritmos flexíveis. Apenas os grupos de te-metric, delay-metric ou admin são anunciados como parte do atributo de link específico do aplicativo sub-TLV.

O sistema operacional não oferece suporte aos seguintes recursos em conjunto com algoritmo flexível baseado em atributo de link específico do aplicativo:

  • A publicidade de máscaras de bit de identificador de aplicativo definidas pelo usuário não é suportada.
  • A readvertising do atributo de link específico do aplicativo de algoritmo flexível ou melhor, quaisquer atributos de link específicos para aplicativos com BGP-LS não é suportado porque o banco de dados de engenharia de tráfego (TED) não oferece suporte a atributos de link específicos para aplicativos.
  • Publicidade de um atributo de link específico de aplicativo comum com máscara de bit identificador de aplicativo padrão e máscaras de bit de identificador de aplicativo definidas pelo usuário definidas para zero não é suportada.

  • Publicidade A restrição do link SRLG em algoritmo flexível não é suportada.

  • O suporte à engenharia de tráfego para vários aplicativos não é suportado, exceto para algoritmos flexíveis.

  • Definir grupos de administradores independentes do MPLS não é suportado.

Exemplo: Algoritmo flexível OSPF

Visão geral

Este exemplo mostra como configurar algoritmo flexível em uma rede OSPFv2. O algoritmo flexível permite que redes sem controlador configurem a engenharia de tráfego usando roteamento por segmentos sem realmente implementar um controlador de rede.

A partir do Junos OS Release 21.1R1, você pode fatiar uma rede definindo algoritmos flexíveis que computam caminhos usando diferentes parâmetros e restrições de enlace com base em seus requisitos. O conjunto composto por tipo de cálculo, tipo métrica e um conjunto de restrições é referido como uma definição flexível de algoritmo (FAD). Você pode definir FADs e anunciar o mesmo em uma rede OSPFv2. Um dispositivo também pode ser configurado para participar de um determinado algoritmo flexível, desde que suporte as restrições para essa FAD específica.

Topologia

A Figura 6 mostra uma topologia de algoritmo flexível na qual existem 6 dispositivos R0, R1, R2, R3, R4 e R5. Dois algoritmos flexíveis 128 e 129 são definidos em cada um desses dispositivos. Os grupos administrativos vermelhos, azuis e verdes estão configurados nos dispositivos. Os FADs com diferentes parâmetros, como tipos de métricas, tipos de cálculo e restrições de enlace são definidos em cada um dos dispositivos.

Figura 6: Topologia Flexible Algorithm Topology flexível de algoritmos

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Seis roteadores da Série MX.
  • Junos OS Release 21.1R1 ou posterior em todos os dispositivos.

Configuração

Configuração rápida da CLI

Para configurar rapidamente este exemplo, 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 hierarquia [editar].

Dispositivo R0

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Configuração do dispositivo R0

Para configurar algoritmo flexível para OSPFv2, execute as seguintes etapas no dispositivo R0:

  1. Configure as interfaces do dispositivo para permitir o transporte ip.

  2. Configure o endereço de interface de loopback (lo0) usado como ID do roteador para sessões de OSPF.

  3. Configure o número de ID e sistema autônomo (AS) do roteador para propagar informações de roteamento em um conjunto de dispositivos de roteamento que pertencem ao mesmo QUE.

  4. Defina uma política para carregar pacotes de equilíbrio e aplicar a política por pacote para permitir o balanceamento de carga do tráfego.

  5. Configure o filtro de rota para o termo de política de roteamento que permite que o Dispositivo R0 atinja a rede 192.168.255.10/32.

  6. Configure o MPLS em todas as interfaces, excluindo a interface de gerenciamento.
  7. Configure a faixa de rótulo MPLS para atribuir rótulos estáticos para os links.

  8. Configure a TI-LFA para permitir a proteção contra falhas de link e nó. O SR usando TI-LFA oferece uma restauração mais rápida da conectividade de rede roteando o tráfego instantaneamente para um backup ou um caminho alternativo se o caminho primário falhar ou ficar indisponível.

  9. Configure o número máximo de rótulos para caminhos roteados por segmentos para a proteção de atributos de caminho mais curto de backup.

  10. Configure atributos do segmento de prefixo, o rótulo inicial e a faixa de índice para blocos globais de roteamento por segmentos (SRGBs) no SPRING para o protocolo OSPF.

  11. Habilite a proteção de enlaces de nó nas interfaces OSPF que seguem o caminho pós-convergência.

  12. Configure a interface de loopback como passiva para garantir que os protocolos não passem pela interface de loopback e que a interface de loopback seja anunciada corretamente em toda a rede.

  13. Definir algoritmos flexíveis no dispositivo R0. Atribua um nome para cada uma das FADs que varia de 128 a 255.

    Especifique os parâmetros da definição. O OSPFv2 calcula o caminho com base nesses parâmetros especificados da FAD.

    1. Especifique o tipo de cálculo com base no qual o protocolo OSPFv2 calcula o caminho.

    2. Especifique o tipo de métrica com base no qual o OSPFv2 calcula o caminho.

    3. Se você tiver habilitado a engenharia de tráfego RSVP, você pode configurar grupos de administradores para muitos protocolos para colorir um link individual.

    4. Atribua as políticas configuradas de grupos de administrador às interfaces R0 do dispositivo.

    5. Defina os grupos administrativos de acordo com o seu requisito.

      Nota:

      Para que FADs com restrições de enlace funcionem, todos os links relevantes devem anunciar as cores de administrador no OSPFv2. Você deve habilitar o RSVP nas interfaces ou se não tiver configurado o RSVP para engenharia de tráfego, certifique-se de configurar o anúncio de engenharia de tráfego definido sempre no nível hierárquico [edit protocols ospf] .

  14. Configure a participação flexível de algoritmos no dispositivo R0. O mesmo dispositivo pode anunciar uma FAD e também participar de um algoritmo flexível.
  15. Anuncie segmentos de prefixo por meio da configuração de políticas.

Resultados

Confira os resultados da configuração:

A partir do modo de configuração, confirme sua configuração entrando no, show interfacesshow routing-options, e show protocolsshow policy-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Para confirmar que a configuração está funcionando corretamente, execute as seguintes tarefas:

Verificando o banco de dados OSPF

Propósito

Verificando se a sinalização flexível do algoritmo é exibida no banco de dados OSPF.

Ação

A partir do modo operacional, execute o show ospf database opaque-area extensive comando.

No R0

Significado

Esta saída no R0 ilustra que:

Três algoritmos de roteamento por segmentos (incluindo dois algoritmos flexíveis) são anunciados por este dispositivo.

Duas FADs são anunciadas por este dispositivo.

Verificando os detalhes flexíveis do algoritmo

Propósito

Verificando se os detalhes flexíveis do algoritmo são exibidos.

Ação

A partir do modo operacional, execute o show ospf spring flex-algorithm <flex-algorithm-id> comando.

No R0

Significado

Os detalhes flexíveis do algoritmo que estão configurados no R0 são exibidos.

Verificação de rotas internas de OSPF específicas do algoritmo flexível

Propósito

Verificando se as rotas internas de OSPF específicas do algoritmo fexible são exibidas.

Ação

A partir do modo operacional, execute o show ospf route flex-algorithm <flex-algorithm-id> comando.

No R0

Significado

O show ospf route comando é estendido com flex-algorithm a opção de mostrar rotas internas osPF específicas do algoritmo flexível. Cada rota é prefixada com o flex-algo-id:

Verificação de rotas de cores flexíveis

Propósito

Verificando se as rotas internas de OSPF específicas do algoritmo fexible são exibidas.

Ação

A partir do modo operacional, execute o show route protocol ospf comando.

No R0

Significado

A saída exibe todas as rotas flex coloridas programadas na tabela inetcolor.0 no seguinte formato: prefix_address-flex-algo-id<c>/64

Verificação de logs OSPF

Propósito

Verificar se os logs OSPF exibem a palavra-chave flexível do algoritmo.

Ação

A partir do modo operacional, execute o show ospf log comando.

No R0

Significado

A saída exibe a palavra-chave FlexAlgo adicionada para os logs SPF.