Configuração do suporte do 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.

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.

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

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.

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.

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.

Este exemplo mostra como anunciar LSPs no OSPFv2.

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:

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.

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