Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Entenda o protocolo de medição ativa bidirecional

Saiba como usar o TWAMP (Two-Way Active Measurement Protocol) para medir o desempenho da rede entre dois dispositivos quaisquer em uma rede.

O TWAMP (Two-Way Active Management Protocol), descrito no RFC 5357, é uma extensão do OWAMP (One-Way Active Management Protocol) que fornece medições bidirecionais ou de ida e volta em vez de recursos unidirecionais. As medições bidirecionais são úteis porque os atrasos de ida e volta não exigem sincronização do relógio do host e o suporte remoto pode ser uma função de eco simples. No entanto, a solicitação/resposta de eco do Internet Control Message Protocol (ICMP) (usada pelo ping) para essa finalidade tem várias deficiências. O TWAMP define um protocolo aberto para medir métricas bidirecionais ou de ida e volta com maior precisão do que outros métodos usando carimbos de data/hora (atrasos de processamento também podem ser fatorados).

Use o Explorador de recursos: protocolo de medição ativa bidirecional para confirmar o suporte à plataforma e à versão para recursos específicos.

Revise a seção Comportamento TWAMP específico da plataforma para obter notas relacionadas à sua plataforma.

Benefícios do TWAMP

  • A configuração da sonda TWAMP ajuda você a ativar, testar, monitorar e solucionar problemas de sua rede de ponta a ponta sem usar um dispositivo de teste dedicado.

  • Os carimbos de data/hora TWAMP fornecem métricas bidirecionais ou de ida e volta com maior precisão do que outros métodos (os atrasos de processamento também podem ser fatorados).

  • O TWAMP é frequentemente usado para verificar a conformidade do contrato de nível de serviço (SLA), e o recurso TWAMP é frequentemente usado nesse contexto.

  • As medições bidirecionais são melhores do que as medidas unidirecionais porque os atrasos de ida e volta não exigem sincronização do relógio do host. Isso é possível porque o refletor coloca seu próprio número de sequência no pacote.

Observação:

Recomendamos que você não configure o cliente RPM e um servidor TWAMP no mesmo dispositivo. Isso pode causar alguns problemas nos resultados da sondagem RPM.

Entender o protocolo de medição ativa bidirecional (TWAMP)

Normalmente, o TWAMP opera entre interfaces em dois dispositivos que desempenham funções específicas. O TWAMP é frequentemente usado para verificar a conformidade com o SLA (Contrato de Nível de Serviço), e o recurso TWAMP é frequentemente apresentado nesse contexto. O TWAMP usa dois protocolos relacionados, executados entre vários elementos definidos:

  • TWAMP-Control — Inicia, inicia e encerra sessões de teste. O protocolo TWAMP-Control é executado entre um elemento Control-Client e um elemento Server.

  • TWAMP-Test— Troca pacotes de teste entre dois elementos TWAMP. O protocolo TWAMP-Test é executado entre um elemento Session-Sender e um elemento Session-Reflector.

Os quatro elementos são mostrados na Figura 1:

Figura 1: Quatro elementos do TWAMP Architecture of Two-Way Active Measurement Protocol TWAMP showing interactions: Control-Client, Server, Session-Sender, Session-Reflector, TWAMP-Control, TWAMP-Test.

Embora quatro dispositivos TWAMP diferentes possam executar as quatro funções lógicas de TWAMP Control-Client, Server, Session-Sender e Session-Reflector, dispositivos diferentes podem desempenhar funções diferentes. Uma implementação comum combina as funções de Control-Client e Session-Sender em um dispositivo (conhecido como controlador TWAMP ou cliente TWAMP) e as funções de Server e Session-Reflector no outro dispositivo (conhecido como respondente TWAMP ou servidor TWAMP). Nesse caso, cada dispositivo executa os protocolos TWAMP-Control (entre Control-Client e Server) e TWAMP-Test (entre Session-Sender e Session-Reflector).

A arquitetura cliente-servidor TWAMP conforme implementada é assim:

  • Cliente TWAMP

    • O Control-Client configura, inicia e interrompe as sessões de teste TWAMP.

    • O Session-Sender cria pacotes de teste TWAMP que são enviados para o Session-Reflector no servidor TWAMP.

  • Servidor TWAMP

    • O Session-Reflector envia de volta um pacote de medição quando um pacote de teste é recebido, mas não mantém um registro de tais informações.

    • O servidor gerencia uma ou mais sessões com o cliente TWAMP e escuta mensagens de controle em uma porta TCP.

O empacotamento desses elementos em processos de cliente e servidor TWAMP é mostrado na Figura 2.

Figura 2: Os elementos do TWAMP implementados como cliente (esquerda) e servidor (direita). TWAMP architecture showing Control-Client, Session-Sender, Server, and Session-Reflector roles for network performance measurement.

Suporte TWAMP Light

TWAMP Light, conforme definido no Apêndice I do RFC 5357, é uma versão sem estado do TWAMP onde os parâmetros de teste são predefinidos em vez de negociados. Todos os pacotes de teste recebidos pelo servidor em uma porta de teste são refletidos de volta e esquecidos imediatamente. Para os dispositivos que os suportam, você também pode configurar endereços de destino IPv6, incluindo endereços de destino locais de enlace IPv6.

Use o Explorador de recursos: protocolo de medição ativa bidirecional para confirmar o suporte à plataforma e à versão para recursos específicos.

Suporte ao protocolo de medição ativa bidirecional simples (STAMP)

Conforme definido no RFC 8762, Simple Two-Way Active Measurement Protocol, o STAMP padroniza e expande o modo operacional TWAMP Light, que foi definido no Apêndice I do RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Para os dispositivos que oferecem suporte ao STAMP, um refletor compatível com STAMP garante um tamanho de payload simétrico (de acordo com o RFC 6038) e opera no modo stateful ou stateful, dependendo se o número de sequência no payload refletido é copiado do quadro do cliente ou gerado de forma independente. Um refletor stateful pode detectar em que direção ocorreram quedas. Nas versões anteriores, oferecemos suporte a cargas simétricas e reflexão sem estado. Oferecemos suporte à reflexão stateful, conformidade total com o padrão STAMP e valores de queda unidirecionais para clientes. Oferecemos suporte a valores de queda unidirecionais não apenas para clientes STAMP, mas também para clientes no modo gerenciado TWAMP. Para o Junos OS Evolved, o STAMP é configurado no nível de [edit services monitoring twamp server light] hierarquia. A reflexão stateful é configurada com a stateful-sequence instrução. Para servidores, o novo padrão para offload-type é now pfe-timestamp em vez de inline-timestamp.

Use o Explorador de recursos: Protocolo de medição ativa bidirecional simples (STAMP) para confirmar o suporte à plataforma e à versão.

Rastreamento de rota estático

A partir do Junos OS Evolved Release 24.4R1, estendemos o suporte para rastreamento de rotas estáticas ao Junos OS Evolved e incluímos também o suporte para testes do Protocolo de Medição Ativa Bidirecional (TWAMP). Você usa sondas TWAMP para detectar o status do link e alterar o estado da rota preferencial com base nos resultados da sondagem. As rotas estáticas rastreadas podem ser IPv4 ou IPv6, e cada rota estática rastreada IPv4 e IPv6 suporta até 16 próximos saltos. Você também pode configurar os valores de métrica, preferência de rota e tag para cada prefixo de destino IPv4 ou IPv6. No entanto, você configura esse recurso de forma diferente em dispositivos Junos OS Evolved; Você configura a sla-tracking declaração no nível da [edit routing-options] hierarquia. Você também usa um comando diferente, show route sla-tracking, para ver informações sobre essas rotas.

Suporte ao roteamento por segmentos para configurar caminhos

A partir do Junos OS Evolved Release 24.4R1 para os roteadores PTX que o suportam e no Junos OS Release 25.4R1 para os roteadores MX que o suportam, adicionamos suporte no Two-Way Active Measurement Protocol (TWAMP) para roteamento por segmentos (SR), conforme definido no RFC 8402, que especifica amplamente a arquitetura SR. Oferecemos suporte a dois tipos de SR para sondas TWAMP:

  • SR-MPLS: Usa uma lista de rótulos, cada um representando um nó final do segmento.

  • SRv6: Usa um cabeçalho de roteamento IPv6 tipo 4 introduzido no RFC 8754, com cada nó final do segmento representado como um endereço IPv6 ou identificador de segmento (SID) IPv6.

Você pode especificar a lista de segmentos SR-MPLS ou SRv6 para uma sonda TWAMP alcançar o refletor. Além disso, você pode especificar as mesmas informações para o caminho de retorno do refletor para o cliente. Essas informações de caminho de retorno são incorporadas na própria sonda usando as extensões propostas em Simple TWAMP (STAMP) Extensions for Roteamento por segmentos Networks, draft-ietf-ippm-stamp-srpm, ou seja, o caminho de retorno TLV e seus sub-TLVs da lista de segmentos de retorno, conforme apropriado, dependendo do tipo de roteamento por segmentos. As sondas TWAMP são temporais no Mecanismo de Roteamento ou no Mecanismo de Encaminhamento de Pacotes.

Para configurar esse recurso para o Junos OS Evolved, inclua a source-routing [edit services monitoring twamp client control-connection name test-session session-name] declaração no nível de hierarquia. Para configurar esse recurso para o Junos OS, inclua a source-routing [edit services rpm twamp client control-connection name test-session session-name] declaração no nível da hierarquia.

Carimbo de data/hora

Por padrão, para a maioria das plataformas, os carimbos de data/hora são definidos no processador host do Mecanismo de Encaminhamento de Pacotes. Para levar em conta a latência na comunicação de mensagens de sondagem, você pode descarregar o carimbo de data/hora dos pacotes de sondagem para o hardware do Mecanismo de Encaminhamento de Pacotes. Esse tipo de carimbo de data/hora é chamado de carimbo de data/hora em linha, em que o carimbo de data/hora é feito no hardware no gerador ou no refletor, logo antes de o pacote deixar o dispositivo. O suporte para esse descarregamento e timestamping em linha varia de acordo com a versão, a plataforma e o suporte à placa de linha:

  • Junos OS: Antes do Junos OS Release 25.4R1, você podia habilitar o carimbo de data/hora em linha configurando uma si- interface OR sp- . A partir do Junos OS Release 25.4R1, para as placas de linha MX que o suportam, você pode descarregar o carimbo de data/hora para o hardware do Mecanismo de Encaminhamento de Pacotes usando a offload-type inline-timestamp opção. Esse recurso de carimbo de data/hora embutido também oferece suporte ao Flex Algo e SR-MPLS.

    Se si- as interfaces estiverem configuradas em um roteador MX para TWAMP, essa opção será o padrão para carimbo de data/hora. Para depurar a implementação da si- interface, você precisa configurar a none opção ou .pfe-timestamp

    Você configura a offload-type (inline-timestamp | none | pfe-timestamp) instrução em um destes níveis de hierarquia: [edit services rpm twamp client control-connection name test-session name], [edit services rpm twamp server], ou [edit services rpm twamp server light].

  • Junos OS Evolved: Os carimbos de data/hora são definidos pelo Mecanismo de Roteamento ou pelo Mecanismo de Encaminhamento de Pacotes para o tráfego IPv4. Para o tráfego IPv6, os carimbos de data/hora são definidos apenas pelo Mecanismo de Roteamento. Para o tráfego IPv6, a partir do Junos OS Evolved 22.3R1, oferecemos suporte a carimbos de data e hora do Mecanismo de Encaminhamento de Pacotes. Antes do Junos OS Evolved Release 22.3R1, para tráfego IPv6, a declaração no nível de [edit services monitoring twamp client control-connection name test-session name] hierarquia deve ser configurada offload-type como none. A partir do Junos OS Evolved Release 22.4R1 para dispositivos suportados, você pode configurar a inline-timestamping offload-type opção da declaração para habilitar carimbos de data/hora definidos em linha pelo hardware. A partir do Junos OS Evolved Release 23.4R1 para servidores, o padrão para a offload-type instrução agora pfe-timestamp é em vez de inline-timestamp. A partir do Junos OS Evolved Release 25.4R1, o recurso de carimbo de data/hora em linha também oferece suporte ao Flex Algo e SR-MPLS.

Diferenças do Junos OS Evolved no suporte ao TWAMP

O suporte do Junos OS Evolved para TWAMP é limitado ao seguinte:

  • Tráfego IPv4 e IPv6 somente para sessões de controle e sessões de teste. A partir do Junos OS Evolved Release 21.4R1, os endereços de origem e destino IPv6 (exceto endereços locais de link) são suportados para listas de clientes, conexões de controle e sessões de teste.

  • Estatísticas e histórico da sondagem

  • Status da sessão de controle e teste

  • Geração e recepção de sondagem de sessão de teste, bem como reflexão

  • Relatório de erros somente por meio de mensagens de log do sistema e interceptações SNMP

  • Somente modo não autenticado

O suporte do Junos OS Evolved para TWAMP também inclui alguns recursos que não estão incluídos no Junos OS:

  • A partir do Junos OS Evolved Release 23.4R1, oferecemos suporte ao RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). O RFC 8762 padroniza e expande o modo operacional TWAMP Light, que foi definido no Apêndice I do RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Para obter mais informações, consulte Suporte ao STAMP (Simple Two-Way Active Measurement Protocol).

  • A partir do Junos OS Evolved Release 24.4R1, oferecemos suporte ao rastreamento de rota estático usando TWAMP para os dispositivos que oferecem suporte a esse recurso. Consulte Rastreamento de rota estático para obter mais informações.

Comportamento TWAMP específico da plataforma

Use o Explorador de recursos: protocolo de medição ativa bidirecional para confirmar o suporte à plataforma e à versão para recursos específicos.

Use a tabela a seguir para examinar os comportamentos específicos da plataforma.

Tabela 1: Comportamento TWAMP específico da plataforma
Diferença de plataforma

Série ACX

  • No Junos OS, os roteadores da Série ACX710 e ACX5448 oferecem suporte tanto à reflexão quanto à geração. Outros roteadores da Série ACX que executam o Junos OS oferecem suporte apenas à reflexão, não à geração.

  • No Junos OS Evolved, o TWAMP é compatível com roteadores ACX, tanto para reflexão quanto para geração. Veja as diferenças do Junos OS Evolved no suporte ao TWAMP para notas sobre as diferenças do sistema operacional no suporte ao TWAMP.

  • Para o Junos OS, o TWAMP é configurado no nível de [edit services rpm twamp] hierarquia. Para o Junos OS Evolved, o TWAMP é configurado no nível de [edit services monitoring twamp] hierarquia.

  • O tráfego de conexão de controle TWAMP sempre chega aos roteadores ACX com a porta de escuta definida como 862. Como esse número de porta para sondas de tráfego pode ser modificado, as sondas que chegam com um número de porta diferente não são reconhecidas e processadas pelos roteadores ACX corretamente. Como resultado, o tráfego TWAMP e os pacotes vinculados ao host são descartados nesse cenário.

  • Para inline-timestamping o modo, o cliente e o servidor TWAMP não podem ser configurados no mesmo roteador ACX.

  • Para inline-timestamping o modo, TWAMP sobre VPN de Camada 3 não é suportado.

  • Antes do Junos OS Evolved Release 23.4R1, se o TWAMP e o gerenciamento de falhas de conectividade (CFM) estiverem configurados, o cliente TWAMP descartará as sondas TWAMP. Remova a configuração do CFM para habilitar o TWAMP. A partir do Junos OS Evolved Release 23.4R1, você pode configurar o CFM no mesmo dispositivo que o TWAMP.

Série EX

Tanto o cliente de controle quanto o remetente da sessão (o cliente TWAMP) residem no mesmo roteador da Juniper Networks. No entanto, o cliente TWAMP não exige que o servidor e o refletor de sessão estejam no mesmo sistema. Portanto, o cliente TWAMP da Juniper é capaz de trabalhar com uma implementação de servidor de terceiros.

Série MX

  • Tanto o cliente de controle quanto o remetente da sessão (o cliente TWAMP) residem no mesmo roteador da Juniper Networks. No entanto, o cliente TWAMP não exige que o servidor e o refletor de sessão estejam no mesmo sistema. Portanto, o cliente TWAMP da Juniper é capaz de trabalhar com uma implementação de servidor de terceiros.

  • O TWAMP não é suportado quando você habilita os serviços de próxima geração em um roteador da Série MX.

Série PTX

  • O atributo de interface si-x/y/z de destino, que se destina a habilitar serviços em linha, não é suportado em roteadores da Série PTX para configurações de cliente TWAMP.

  • Para o Junos OS, o TWAMP é configurado no nível de [edit services rpm twamp] hierarquia. Para o Junos OS Evolved, o TWAMP é configurado no nível de [edit services monitoring twamp] hierarquia. Veja as diferenças do Junos OS Evolved no suporte ao TWAMP para notas sobre as diferenças do sistema operacional no suporte ao TWAMP.

Série QFX10000

Tanto o cliente de controle quanto o remetente da sessão (o cliente TWAMP) residem no mesmo roteador da Juniper Networks. No entanto, o cliente TWAMP não exige que o servidor e o refletor de sessão estejam no mesmo sistema. Portanto, o cliente TWAMP da Juniper é capaz de trabalhar com uma implementação de servidor de terceiros.

Série QFX5000 (Junos OS Evolved)

Para o Junos OS Evolved, o TWAMP é configurado no nível de [edit services monitoring twamp] hierarquia. Veja as diferenças do Junos OS Evolved no suporte ao TWAMP para notas sobre as diferenças do sistema operacional no suporte ao TWAMP.

Série SRX (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 e SRX4200 dispositivos e instâncias de Firewall virtual vSRX)

  • TWAMP para IPv6 não é suportado.

  • Não há suporte para o servidor TWAMP e a autenticação do cliente TWAMP.

  • TWAMP Light não é suportado.

Para a Série MX, a tabela abaixo mostra a relação entre o suporte ao cliente e ao servidor RPM, o suporte ao cliente TWAMP (com o componente de controle) e ao servidor TWAMP (com o componente respondente) e o hardware que executa o carimbo de data/hora.

Tabela 2: Suporte e hardware de recursos TWAMP para o Junos OS, Série MX

Suporte ao recurso TWAMP

Carimbo de data e hora do Mecanismo de Roteamento

Carimbo de data/hora do MS-PIC/MS-DPC

Carimbo de data/hora MS-MIC/MS-MPC

Carimbo de data e hora do Mecanismo de Encaminhamento de Pacotes (microkernel)

Mecanismo de Encaminhamento de Pacotes (LU) Carimbo de data/hora (si- interface)

Cliente RPM

Sim

Sim

Sim

Sim

Não

Servidor RPM

Sim

Sim

Sim

Sim

Não

Cliente TWAMP

Não

Não

Não

Sim

Sim

Servidor TWAMP

Não

Sim

Não

Sim (não é necessária configuração de respondente)

Sim
Observação:

O suporte para as interfaces de serviços (sp-, ms- e si- interfaces) são todos ligeiramente diferentes.

A Tabela 3 fornece informações sobre o TWAMP da Série MX e o suporte de carimbo de data/hora relacionado em MPC, MS-MIC/MPC e em linha:

Tabela 3: TWAMP gerenciado e suporte a carimbo de data/hora relacionado, Série MX

Característica

Função

Versão IP

Suporte (S/N)

Carimbo de data/hora em linha

Carimbo de data/hora no MPC (carimbo de data/hora do hardware)

Carimbo de data/hora no MPC (interface si)

Carimbo de data/hora no MS-MIC/MPC (delegado-sondas)

TWAMP

Cliente gerenciado

IPv4

Y

N

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

IPv6

N

N

N

N

N

Servidor gerenciado

IPv4

Y

N

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

IPv6

N

N

N

N

N
Tabela 4: TWAMP Light e suporte de carimbo de data/hora relacionado, Série MX

Característica

Função

Versão IP

Suporte (S/N)

Carimbo de data/hora em linha

Carimbo de data/hora no MPC (carimbo de data/hora do hardware)

Carimbo de data/hora no MPC (interface si)

Carimbo de data/hora no MS-MIC/MPC (delegado-sondas)

TWAMP

Cliente Light

IPv4

Y

Y (μs) (a partir da versão 25.4R1)

1000 sondas máximas

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

IPv6

Y

Y (μs) (a partir da versão 25.4R1)

1000 sondas máximas

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

Servidor Light

IPv4

Y

Y (μs) (a partir da versão 25.4R1)

1000 sondas máximas

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

IPv6

Y

Y (μs) (a partir da versão 25.4R1)

1000 sondas máximas

Y (μs)

1000 sondas máximas

Y (μs)

1000 sondas máximas

N

Documentação relacionada