Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Como habilitar a medição de atraso no enlace e a publicidade no IS-IS

Entendendo a medição de atraso do link e a publicidade no IS-IS

Benefícios da medição de atraso no enlace e publicidade no IS-IS

A medição de atraso no link e a publicidade no IS-IS fornecem os seguintes benefícios:

  • Altamente benéfico em determinadas redes, como provedores de dados do mercado de ações, onde é crucial ter acesso a dados de mercado em tempo real para tornar as negociações mais rápidas do que a concorrência. É aí que os critérios de desempenho ou latência da rede estão se tornando críticos para a seleção de caminhos de dados.
  • Ajuda a tomar decisões de seleção de caminhos com base em dados de desempenho (como latência) de uma maneira econômica e escalável.
  • Alternativa superior ao uso de métricas como contagem de saltos ou custo como métricas de roteamento.

Visão geral da medição de atraso do link e publicidade no IS-IS

O desempenho da rede é medido usando o TWAMP-Light. A partir do Junos OS Release 21.1R1, você pode obter a medição de várias métricas de desempenho em redes IP, usando mensagens de sondagem. As extensões de engenharia de tráfego IS-IS ajudam a distribuir informações de desempenho de rede de forma escalável. Essas informações podem então ser usadas para tomar decisões de seleção de caminhos com base no desempenho da rede.

O Border Gateway Protocol Link-State (BGP-LS) permite que o BGP carregue informações de estado de enlace adquiridas de IGPs, o que permite que provedores de serviços de internet (ISP) exponham seletivamente as informações com outros ISPs, provedores de serviços, CDNs e assim por diante, por meio de peering BGP normal. Novas TLVs BGP-Link State (BGP-LS) são definidas para transportar as extensões métricas de engenharia de tráfego IGP.

A ilustração a seguir mostra a métrica mínima de IGP e a métrica mínima de atraso em redes que consistem em uma rede de núcleo, metro e acesso.

Nesse cenário, a rede principal é mais barata, mas tem um atraso maior. O atalho de acesso, com a menor latência, custa caro. Como a rede principal é mais barata, a maioria do tráfego normalmente passa de 1>2>3>4>5> para 6 usando métrica mínima de IGP. Conforme exibido no cenário a), você pode alcançar o requisito mínimo de IGP executando o IS-IS com o custo apropriado configurado e o algoritmo IS-IS padrão definido para zero. Em empresas onde a latência ultraba baixa é crucial, os pacotes precisam ir de 1 a 6. Conforme exibido no cenário b), você pode alcançar uma métrica mínima de atraso definindo o algoritmo flex IS-IS com latência mínima, o que minimiza o atraso no endpoint. Este algoritmo flex consiste apenas em nós 1 e nó 6.

Exemplo: habilite o atraso no enlace IS-IS com o roteamento de pacotes de origem em redes (SPRING) em uma rede privada virtual (VPN) de Camada 3

Este exemplo mostra como configurar o atraso do enlace IS-IS com a SPRING em um cenário de VPN de Camada3. No exemplo, você pode criar duas VPNs entre PE1 e PE2. VPN1 otimiza o atraso do link e VPN2 otimiza a métrica de IGP. Embora você possa configurar o recurso para permitir tráfego bidirecional na topologia de teste, estamos focando em um cenário de tráfego unidirecional neste exemplo. Especificamente, sua tarefa é controlar o caminho de encaminhamento para o tráfego VPN de Camada 3 enviado pelo PE1 para destinos anunciados pelo PE2.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Quatro roteadores da Série MX

  • Junos OS Release 21.1R1 ou posterior em execução em todos os dispositivos

Topologia

Figura 1: Topologia IS-IS Link Delay Topology de atraso de enlace IS-IS

Na topologia, a maioria dos links tem uma métrica IGP (padrão) de 10, medições dinâmicas de atraso e coloração azul. As exceções são o caminho de cor vermelha entre PE1 e P1 e a configuração de atraso estático no link P2 para PE2.

Configuramos a topologia de teste para oferecer suporte ao atraso no link IS-IS para IPv4 e IPv6. Configuramos o roteador P2 como um refletor de rota com os dispositivos PE como seus clientes. Para manter a topologia simples, estamos usando rotas estáticas nos VRFs do roteador PE2. Isso elimina a necessidade de dispositivos CE e um protocolo de roteamento PE-CE, como o EBGP.

Seu objetivo é configurar a rede para que as rotas anunciadas pelo PE2 para VPN1 tomem um caminho que otimize o atraso, ao mesmo tempo em que se limita a usar apenas links azuis. Por outro lado, o tráfego enviado para as rotas associadas à VPN2 pode utilizar um enlace azul ou vermelho com otimização de caminho com base em sua métrica IGP.

  • A definição do algoritmo Flex (FAD) para VPN1 usa o algoritmo 128. Nós o configuramos para usar apenas links de cor azul (PE1>P2>P1>PE2) em um caminho otimizado para reduzir o atraso. Para ajudar a demonstrar a seleção adequada do caminho, você configura um atraso estático de 20000 microssegundos entre P2 e PE2. Esse atraso é significativamente maior do que o atraso dinâmico medido nos links restantes. Como resultado, você espera que o algoritmo flex 128 tráfego evite o link P2 para PE2, preferindo saltos adicionais ao longo do caminho de cores azuis (PE1>P2>P1>PE2).
  • A definição do algoritmo Flex (FAD) para VPN2 usa o algoritmo 129. Nós o configuramos para usar links azuis ou vermelhos (PE1>P1>PE2 ou PE1>P2>PE2), com o caminho otimizado na métrica IGP. Como resultado, o tráfego usando o algoritmo flex 129 tem dois caminhos de custo igual entre PE1 e PE2, ambos incorrendo em dois saltos e uma métrica resultante de 20.

Visão geral

Nas redes IP, a maior parte do tráfego costuma passar pela rede principal, o que reduz custos, mas pode resultar em uma latência maior. O tráfego de negócios, no entanto, muitas vezes se beneficia da capacidade de tomar decisões de seleção de caminhos com base em outras métricas de desempenho, como latência de caminho, em vez de retransmitir na otimização de caminho tradicional com base simplesmente em métricas de IGP. Otimizar um caminho para reduzir a latência pode beneficiar muito aplicativos como voz e vídeo em tempo real. Também pode permitir acesso de alto desempenho a dados do mercado financeiro onde milissegundos podem se traduzir em ganhos ou perdas significativos.

A partir da versão 21.1R1 do Junos OS, você pode ativar o atraso no link IS-IS em redes IP. Você pode alcançar caminhos métricas mínimos de IGP configurando o IS-IS com o custo de link apropriado usando o algoritmo IS-IS padrão (0). Isso otimiza caminhos para o endpoint que se baseiam estritamente na soma das métricas do link. Ao usar o algoritmo is-IS delay flex, você pode otimizar caminhos com base em seu atraso de ponta a ponta.

O atraso no enlace pode ser medido dinamicamente usando sondas de medição ativa de duas vias (TWAMP). Os roteadores então inundam os parâmetros de atraso do enlace. Os roteadores da área armazenam esses parâmetros no banco de dados de estado de link compartilhado (LSDB). Nós de entrada executam um algoritmo SPF contra o LSDB para computar caminhos otimizados em vários atributos, como cores de link, métrica de IGP, métrica de engenharia de tráfego (TE) ou, como mostrado neste exemplo, atraso no link.

O roteador de saída sinaliza qual algoritmo flex é desejado anexando uma comunidade de cores associada a rotas anunciadas através do BGP. No final do envio (o PE local que recebeu as rotas marcadas anunciadas pelo PE remoto), essas comunidades de cores são usadas para indexar em uma tabela de cores que resolve o protocolo remoto próximo salto (endereço loopback do PE) para um identificador de algoritmo flex. No contexto das VPNs de Camada 3, uma política de mapeamento de cores é usada no nó de entrada para selecionar quais prefixos devem ter seus próximos saltos resolvidos pela tabela de cores.

O PE local então usa sua definição local de algoritmo flex (FAD) para mapear o identificador de algoritmo flex em um conjunto de critérios de seleção de caminhos, por exemplo, "use links azuis e otimize no atraso". O PE de entrada calcula o caminho ideal com base nos valores do LSDB, empurra a pilha de rótulo MPLS relacionada para o pacote e o envia para o próximo salto associado. Isso resulta em caminhos MPLS projetados por tráfego usando o IS-IS como protocolo de sinalização.

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].

Nota:

Dependendo do tipo de MPCs em seus roteadores da Série MX, você pode precisar habilitar explicitamente serviços IP aprimorados para oferecer suporte ao recurso de atraso IS-IS. Quando você confirmar a declaração de set chassis network-services enhanced-ip configuração, você será solicitado a reiniciar o sistema.

PE1

P1

P2

PE2

Procedimento passo a passo

  1. Configure as configurações básicas do dispositivo, como nome de host, IPv4, endereços IPv6, endereços de interface de loopback, enhanced-ip modo e habilite as famílias de protocolo ISO e MPLS em todas as interfaces dos 4 roteadores.

  2. Configure o número de ID do roteador, sistema autônomo (AS) e aplique uma política de exportação de balanceamento de carga à tabela de encaminhamento em todos os roteadores para permitir o balanceamento de carga do tráfego.

  3. No PE1 e pe2, configure multicaminho de igual custo (ECMP) para permitir uma proteção rápida de redirecionamento. Configure também o próximo salto composto encadeado para permitir que os roteadores apontem rotas que compartilham o mesmo destino para um próximo salto de encaminhamento comum. Essa opção melhora o dimensionamento da base de informações de encaminhamento (FIB).

  4. Habilite o processamento de protocolo MPLS em todas as interfaces em todos os roteadores. Também habilite a engenharia de tráfego.

  5. Habilite sondas TWAMP em todos os roteadores. Essas sondas suportam a medição dinâmica do atraso do enlace entre cada par de roteadores.

  6. Configure o protocolo IS-IS para a operação ponto a ponto (as medições de atraso baseadas em TWAMP não são suportadas em links de vários pontos) e habilite o modo de proteção de nós para a operação de suplente sem loop independente de topologia (TILFA) em todas as interfaces. Você também habilita o modo passivo IS-IS na interface de loopback e desativa o nível 1 is-IS para usar apenas o nível 2 is-IS. Habilite a engenharia de tráfego com topologia unicast de camada 3 para baixar a topologia de IGP no TED. Configure o IS-IS para oferecer suporte a caminhos roteados por SPRING. A prefix-sid política de exportação é definida em uma etapa posterior. Essa política é usada para que o nó local anuncie seu endereço loopback com um mapeamento para um ou mais algoritmos flex.

  7. Configure a medição de atraso dinâmica do link IS-IS usando sondas TWAMP em todas as interfaces IS-IS em todos os roteadores (exceto pelo enlace entre P2 e PE2, que usa um valor de atraso estático neste exemplo).

  8. Configure a métrica de atraso estática no enlace entre P2 e PE2.

  9. Configure PE1 e PE2 para oferecer suporte a duas VPNs de Camada 3 (VPN1 e VPN2).

    Nota:

    Observe que as instâncias de roteamento no PE2 estão configuradas com rotas estáticas IPv4 e IPv6. Essas rotas estão configuradas com a opção receive de permitir que você teste a conectividade usando ping. O recurso de atraso IS-IS opera da mesma forma se a VPN de Camada 3 usar um protocolo de roteamento dinâmico entre o PE e um dispositivo CE conectado. Usamos rotas estáticas neste exemplo para manter a topologia simples para permitir o foco no recurso de otimização de atraso IS-IS.

  10. Configure uma política de mapa no PE1 para permitir a resolução de rotas de VPN para combinar prefixos com a tabela de cores BGP. Isso permite evocar algoritmos de encaminhamento de caminhos flex em uma base por prefixo. A map1 política de resolução está definida para o ip-color modo de resolução.

    Nota:

    Em um contexto VPN de Camada 3, uma política de mapeamento é necessária para selecionar quais prefixos podem ter seu próximo salto resolvido na tabela de cores. Simplesmente ter rotas com próximos saltos estendidos e comunidades de cores anexadas não resulta no uso da tabela de cores, a menos que uma política de mapeamento seja usada.

  11. Configure as políticas de exportação de rota VPN no PE2 para anexar as comunidades de cores desejadas às rotas de VPN que anuncia para PE1 (pelo refletor de rota). O importante aqui é como as rotas da VPN1 têm a comunidade de cores para o caminho flex 128 (otimize o atraso), enquanto as rotas anunciadas da VPN2 têm a comunidade de cores 129 anexada (otimize a métrica IGP).

  12. Configure o peering BGP entre os dispositivos PE e o refletor de rota. Configure as informações de acessibilidade da camada de rede (NLRI) unicast para oferecer suporte a saltos próximos de cores estendidos nos dispositivos PE. Habilitar essa opção permite que rotas com comunidades de cores tenham seu próximo salto resolvido através da tabela de cores. Sem a rota de configuração de próximo salto estendida, com comunidades de cores passando por uma resolução normal de próximo salto e não usará caminhos de algoritmo flex.

  13. Você também permite o suporte para rotas unicast VPN de Camada 3 e IPv6 e IPv6. No PE1 você aplica as políticas de mapeamento de cores como importação, para que ele possa agir nas rotas recebidas do dispositivo pe remoto.

    No PE 2, você aplica política de exportação para anexar a comunidade de cores desejada aos anúncios de rota VPN enviados ao PE1. A opção vpn-apply-export é necessária no PE2 para permitir que as políticas de exportação ajam em rotas de VPN anunciadas para PEs remotos.

  14. Defina a política de balanceamento de carga por pacote em todos os roteadores.

  15. Configure o suporte para o roteamento por segmentos com dois algoritmos flex (128 e 129) em todos os roteadores.

  16. Configure todos os roteadores para anunciar seu endereço de loopback com suporte para os algoritmos 128 e 129 flex. A opção prefix-segment index define o rótulo base para o endereço loopback de cada roteador. Neste exemplo, o índice base IPv4 e o índice base IPv6 estão definidos para refletir o número do roteador. Como resultado, r0 (PE1) usa 1000 para IPv4, enquanto R1 (P1) usa 1001.

  17. Em todos os roteadores, defina os RED grupos de administração e BLUE MPLS e atribua a cor desejada a cada interface. Você também permite que o tunelamento ICMP permita o suporte de rota de rastreamento no contexto das VPNs de Camada 3 baseadas em MPLS.

  18. Configure as FADs no dispositivo PE (PE1) de entrada sob a routing-options hierarquia. Neste caso, você atribui o algoritmo flex 128 para otimizar o caminho com base no delay-metric 129 para otimizar a igp-metric. Neste exemplo, o algoritmo flex 128 deve seguir apenas caminhos de cores azuis, enquanto o algoritmo flex 129 pode tomar um caminho de cores azul ou vermelho. Neste exemplo, você define as FADs no PE1 apenas porque nos concentramos apenas no caminho de encaminhamento de PE1 para PE2.

    Para dar suporte ao encaminhamento do caminho flex bidirecional, você precisará definir as FADs desejadas no dispositivo PE2. Os roteadores P não exigem uma definição de FAD, pois a FAD só é usada pelo nó de entrada ao calcular um caminho para o nó de saída.

  19. Entre no commit modo de configuração.

Resultados

Confira os resultados da configuração:

user@PE1# show interfaces

user@PE1# show policy-options

user@PE1# show protocols

user@PE1# show routing-options

user@PE1# show routing-instances

user@PE1# show services rpm

Verificação

Verificar as Adjacências IS-IS

Propósito

Verifique as adjacências IS-IS esperadas nos dispositivos de roteamento.

Ação

A partir do modo operacional, entre no show isis adjacency comando.

Significado

A saída de th indica que o PE1 formou com sucesso as adjacências IS-IS em suas ge-0/0/0.0 interfaces e ge-0/0/1.0 interfaces, que se conectam aos seus roteadores P1 e P2, respectivamente.

Verifique o banco de dados IS-IS

Propósito

Verifique se os parâmetros de atraso do link estão presentes no banco de dados IS-IS.

Ação

Use o show isis database extensive | match delay comando operacional.

Significado

A saída exibe o atraso dinâmico associado às várias interfaces da topologia. A parte destacada da saída especifica o atraso estático de 20000 microssegundos que está configurado no link P2 para PE2. O valor de atraso configurado estaticamente é significativamente maior do que qualquer uma das medições dinâmicas de atraso. Esse grande atraso está configurado para facilitar a previsão do atraso otimizado para o caminho azul pela rede.

Verifique o peering do BGP

Propósito

Verifique se ambos os PEs estabeleceram com sucesso as sessões de peering IPv4 e IPv6 para o refletor de rota.

Ação

Use o show bgp summary comando operacional. Neste caso, executamos o comando em P2, o refletor de rota, pois ele fornece um local conveniente para confirmar ambas as sessões de peering de ambos os PEs usando um único comando.

Significado

A saída confirma que todas as sessões de peering BGP estão estabelecidas corretamente. O display também confirma que as rotas de VPN de Camada 3 estão sendo anunciadas/aprendidas nessas sessões de peering.

Verifique a comunidade de cores em rotas de VPN

Propósito

Verifique se as rotas de VPN anunciadas pelo PE2 estão corretamente marcadas com uma comunidade de cores.

Ação

Use o show route detail <prefix> table <table-name> comando operacional no PE1 para exibir detalhes sobre uma rota VPN de Camada 3 aprendida com PE2.

Significado

A saída confirma que um prefixo VPN na instância de roteamento VPN1 tem uma comunidade color:0:128 de cores anexada. Além disso, você pode confirmar que o próximo salto de protocolo para esta rota é o endereço loopback do roteador PE2 com um próximo salto estendido que indexa uma entrada correspondente na tabela de cores.

Embora não mostre, você pode repetir este comando para um prefixo na tabela VPN2. Você espera descobrir que essas rotas têm o color:0:129 anexo.

Verificar a tabela de roteamento inetcolor.0

Propósito

Verifique se a inetcolor.0 tabela de roteamento está corretamente povoada com todos os IDs de roteador (endereços loopback) mostrando suporte para os algoritmos 128 e 129 flex.

Nota:

As rotas IPv6 são suportadas pela inet6color.0 tabela. Você pode verificar esta tabela usando a mesma abordagem mostrada nesta seção para a tabela de cores IPv4.

Ação

Use o show route table inetcolor.0 comando operacional.

Significado

A saída exibe as rotas na tabela de inetcolor.0 rotas. A porção destacada indica que as duas rotas são originárias do PE2. A 192.168.255.3-128<c> rota tem apenas um caminho possível e leva a ge-0/0/1.0 interface para P2 como um próximo salto. Lembre-se que o algoritmo 128 flex deve usar links azuis, e da perspectiva do PE1, o que deixa apenas a interface de cor ge-0/0/1 azul como um caminho viável.

Por outro lado, a rota para 192.168.255.3-129<c> é capaz de carregar o ge-0/0/0.0 equilíbrio tanto nas interfaces para P1 quanto ge-0/0/1.0 para P2. Lembre-se que esse caminho para o algoritmo flex pode tomar qualquer caminho que seja azul ou vermelho, podendo assim usar qualquer uma de suas interfaces ao encaminhar para o seu destino associado.

Verificar a operação do TWAMP

Propósito

Verifique se as sondas TWAMP estão operando entre roteadores com atraso dinâmico no enlace configurado.

Ação

Use o comando do show services rpm twamp client modo operacional.

Significado

A parte destacada da saída indica que o PE1 tem dois vizinhos TWAMP: P2 (10,0,1,2) e P1 (10,0,1,1).

Se desejado, use o comando do show services rpm twamp client probe-results modo operacional para ver os valores atuais e históricos de medição de atraso.

Verificar a resolução da rota

Propósito

Verifique as rotas para que a VPN1 e a VPN2 se resolvam nos caminhos de algoritmo flex esperados.

Ação

Use o comando do show route modo operacional.

Significado

A saída destacada indica que no dispositivo PE1, a rota 172.16.1.0 para VPN1 usa a FAD 128 tomando apenas o caminho de cor azul, o que faz do P1 (10.0.2.2) seu próximo salto enquanto a rota para VPN2, O 172.16.2.0 usa o FAD 129, o que significa que ele pode tomar o caminho de cor vermelha através da interface ge-0/0/0,0 para P1>PE2 ou através da interface ge-0/0/1.0 para P2> PE2. Isso também vale para as rotas IPv6, como mostrado aqui para VPN1:

A rota IPv6 da VPN1 resolve para o mesmo caminho de encaminhamento que sua contraparte IPv4, o que faz sentido, pois ambos estão usando o algoritmo flex 128 para forçar o uso de links azuis com otimização de atraso. Lembre-se que você configurou o PE2, a fonte dessas rotas, para usar uma base de rótulos de 1287 para rotas IPv4 e 4287 para rotas IPv6, e que a source-packet-routing srgb start-label 8000. Como resultado, a rota IPv4 da VPN1 tem um rótulo de 81287, enquanto a rota IPv6 da VPN1 usa 84287.

Verificar caminhos de encaminhamento

Propósito

Verifique se as rotas para VPN1 e VPN2 são encaminhadas pelos caminhos de algoritmo flex esperados.

Ação

Use os comandos de ping modo operacional e trace route operacional para verificar a acessibilidade e confirmar o caminho de encaminhamento IPv4 usado pelo PE1 ao enviar tráfego para destinos VPN como PE2.

Nota:

O uso de rotas estáticas com um próximo salto recebido no PE2 permite que você faça ping nas rotas remotas. Você pode esperar o último salto da rota de rastreamento para o tempo limite, no entanto, já que o processamento de rota de rastreamento não é suportado ao atingir uma rota de recebimento estático IPv4.

Significado

A saída indica que os caminhos de encaminhamento esperados são usados. Por exemplo, a rota de rastreamento para a rota 172.16.1.0/24 em VPN1 mostra que caminhos azuis são usados, e que o elo de alto atraso entre P2 e PE2 é evitado. Isso confirma que o algoritmo flex prefere um caminho com um salto extra se resultar em uma redução da latência de caminho de ponta a ponta. Neste caso, o enlace de 10.0.12.0 entre P2 e P1 é usado, enquanto o enlace direto entre P2 e PE2 é evitado.

Em contraste, o caminho trilhado para a rota 172.16.2.0/24, associada a VPN2 e algoritmo flex 129, é capaz de tomar qualquer um dos caminhos diretos entre PE1 e PE2. Neste caso, o caminho de encaminhamento é de PE1 para P1 e depois para o destino (PE2), onde, como observado nos últimos tempos de salto. Esse tempo limite no último salto não ocorre para rotas que apontam para um dispositivo CE (em oposição às rotas de recebimento estáticas usadas neste exemplo).

Embora não mostrem aqui pela brevidade, você espera os mesmos caminhos de encaminhamento para rotas de rastreamento para as rotas VPN IPv6 com base em se eles são mapeados para o algoritmo flex 128 ou 129, o que neste exemplo significa associado com VPN1 versus VPN2, respectivamente.