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

RESUMO 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. Essa é uma solução de peso leve para redes que não implementaram um controlador com roteamento por segmentos completo, mas ainda querem aproveitar 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 de Usuário do OSPF

Entender o algoritmo flexível do OSPF para o 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 o roteamento por segmentos sem realmente implementar um controlador de rede. Você pode usar os SIDs de prefixo para orientar 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 de IGP usam uma métrica de enlace para calcular o melhor caminho. No entanto, o melhor caminho de IGP pode nem sempre ser o melhor caminho para determinados tipos de tráfego. Portanto, o melhor caminho computado pelo IGP com base na métrica de IGP mais curta é frequentemente substituído por caminho projetado por tráfego devido aos requisitos de tráfego que não são refletidos pela métrica do IGP. Normalmente, RSVP-TE ou SR TE são usados para computar o caminho com base em métricas e restrições adicionais para superar essa limitação. O Junos instala esses caminhos nas tabelas de encaminhamento, além de ou como substituto do 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 custo igual (ECMP) e TI-LFA por fatia sem configurar BGP-LS ou caminho estático.

  • Computação de 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 restritos com base em um único rótulo.

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

Um algoritmo flexível permite que o IGP calcule os melhores caminhos adicionais com base em restrições especificadas, fornecendo engenharia de tráfego simples sem usar um controlador de rede. Essa é uma solução leve para redes que não implementaram um controlador com roteamento por segmentos completo, mas ainda querem aproveitar 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 da [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 pode influenciar a seleção do caminho do SPF.

  • Metric type- Métrica de IGP ou TE são as opções de tipo 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 TE que o OSPFv2 pode usar para calcular a rota.

  • Priority- Você pode atribuir uma prioridade às suas FADs conforme 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 administrativos para muitos protocolos no nível de [edit protocols mpls admin-groups] hierarquia para colorir um link individual. Eles 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 a configuração de 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-metric

  • 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 de prefixo de algoritmo flexível (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 com 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.

A TLV da FAD só pode ser adicionada ao Atributo BGP-LS do NLRI de Nó se o nó correspondente se originar no IGP subjacente TLV ou sub-TLV. O atributo BGP-LS associado a um NLRI de nó pode incluir uma ou mais TLVs FAD correspondentes à Definição flexível de algoritmo para cada algoritmo que o nó está anunciando.

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 NLRI prefixo 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 flexível de prefixo de algoritmo (FAPM) para permitir um caminho de ponta a ponta ideal 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 base no 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 fornece suporte inter-área.

Participação em um algoritmo flexível

Você pode configurar roteadores específicos para participar de um algoritmo flexível específico de acordo com o seu requisito. Caminhos computados com base em uma definição de algoritmo flexível são usados por várias aplicações cada uma potencialmente usando seu próprio plano de dados específico para encaminhar os dados por esses caminhos. O dispositivo participante deve anunciar explicitamente sua participação em um algoritmo flexível específico para cada aplicativo no sub TLV de algoritmo flexível de roteamento por segmentos para OSPFv2. Você pode configurar um nó para participar de um determinado algoritmo flexível, desde que ele 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 algoritmo

A Figura 1 mostra a topologia amostral, existem 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

Inclua qualquer verde

130

Inclua qualquer verde e azul

135

Exclua o vermelho

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

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 algoritmos 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 algoritmos 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 algoritmos 135 Traffic Flow for Flexible Algorithm Definition 135

RIBs de algoritmo flexível

Para cada algoritmo flexível que um roteador participa das 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 o ID de 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 na rota. 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ção do tráfego. Se você modificar uma comunidade de cores BGP para um algoritmo flexível, 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 de prefixo para diferentes algoritmos flexíveis.

  • Oferece suporte parcial ao Internet 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:

  • O 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.
  • 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 de algoritmo flexível de publicidade na ausência de participação flexível de algoritmos não é suportada.

Algoritmo flexível baseado em atributo de link específico do aplicativo

A partir do Junos OS e do 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 atributo de link específico do algoritmo flexível, conforme definido no RFC 8920.

A vantagem de ter um atributo de link específico do 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 um atributo te específico do algoritmo flexível, inclua a application-specific declaração no nível da [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 enlace tenha o RSVP habilitado e [edit protocols ospf traffic-engineering advertisement always] esteja 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 do Junos OS Evolved do atributo de link específico do aplicativo oferece suporte apenas a aplicativos de algoritmos flexíveis.

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

O comportamento padrão do algoritmo flexível específico da aplicação é usar os atributos te específicos do aplicativo de algoritmo flexível para um link se disponível e, se não, depois voltar para os atributos te específicos da aplicação comum e, se nenhum deles 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 do aplicativo comum ou um te-attribute específico do aplicativo de algoritmo flexível para cada link de algoritmo flexível. Na ausência de atributos te específicos da aplicação, o dispositivo não volta aos atributos te legados e simplesmente ignora o enlace.

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 ao RFC 8920. O sub-TLV de atributos específicos do aplicativo é um sub-TLV do enlace estendido OSPFv2 TLV 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 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 aplicativos definidas pelo usuário não é suportada.
  • Não é compatível com atributos de link específicos de aplicativos de algoritmo flexível ou melhor, quaisquer atributos de link específicos de aplicativos com BGP-LS porque o Banco de Dados de Engenharia de Tráfego (TED) não oferece suporte a atributos de link específicos do aplicativo.
  • A publicidade de um atributo de link específico do aplicativo comum com a máscara de bit do identificador de aplicativos padrão e o comprimento de máscaras de bit do identificador de aplicativos definido pelo usuário definido para zero não é suportado.

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

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

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

Exemplo: algoritmo flexível do OSPF

Visão geral

Este exemplo mostra como configurar algoritmo flexível em uma rede OSPFv2. O algoritmo flexível permite que redes sem um controlador configurem a engenharia de tráfego usando o 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 é chamado de 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 ele ofereça suporte às 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 parâmetros diferentes, como tipos de métrica, 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 Versão 21.1R1 ou posterior em execução em todos os dispositivos.

Configuração

Configuração rápida da CLI

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

Dispositivo R0

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Configuração do dispositivo R0

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

  1. Configure as interfaces do dispositivo para habilitar 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 do roteador e do sistema autônomo (AS) para propagar informações de roteamento em um conjunto de dispositivos de roteamento que pertencem ao mesmo AS.

  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ótulos MPLS para designar rótulos estáticos para os links.

  8. Configure a TI-LFA para habilitar a proteção contra falhas de enlace 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 principal falhar ou ficar indisponível.

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

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

  11. Habilite a proteção de nó-link 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. Defina algoritmos flexíveis no dispositivo R0. Atribua um nome para cada um dos 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ê habilitar a engenharia de tráfego RSVP, você pode configurar grupos administrativos para muitos protocolos para colorir um link individual.

    4. Atribua as políticas configuradas de grupos administrativos à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 enlaces relevantes devem anunciar as cores administrativas 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 de [edit protocols ospf] hierarquia.

  14. Configure a participação flexível do algoritmo 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-optionse show protocolscomandosshow policy-options. 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 se a configuração está funcionando corretamente, execute as seguintes tarefas:

Verificando o banco de dados do OSPF

Propósito

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

Ação

Do modo operacional, execute o show ospf database opaque-area extensive comando.

No R0

Significado

Esta saída em R0 ilustra que:

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

Dois FADs são anunciados por este dispositivo.

Verificando os detalhes do algoritmo flexível

Propósito

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

Ação

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

No R0

Significado

Os detalhes flexíveis do algoritmo configurados em R0 são exibidos.

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

Propósito

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

Ação

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 de OSPF específicas para algoritmos flexíveis. Cada rota é prefixada com o flex-algo-id:

Verificação de rotas flex coloradas

Propósito

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

Ação

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 formato a seguir: prefix_address-flex-algo-id<c>/64

Verificação de logs OSPF

Propósito

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

Ação

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.