Entenda o protocolo de medição ativa de duas vias
Saiba mais sobre o uso do Protocolo de Medição Ativa de Duas Vias (TWAMP) para medir o desempenho da rede entre qualquer dois dispositivos em uma rede.
O Protocolo de Gerenciamento Ativo de Duas Vias (TWAMP), descrito na RFC 5357, é uma extensão do Protocolo de Gerenciamento Ativo de Mão Única (OWAMP) que fornece medições de duas vias ou de ida e volta em vez de recursos unidirecionais. Medições de duas vias são úteis porque atrasos de ida e volta não exigem sincronização do relógio de host e o suporte remoto pode ser uma função de eco simples. No entanto, o Protocolo de Mensagem de Controle de Internet (ICMP) Eco Request/Reply (usado por ping) para essa finalidade tem várias deficiências. O TWAMP define um protocolo aberto para medir métricas de duas vias ou ida e volta com maior precisão do que outros métodos usando carimbos de tempo (atrasos no processamento também podem ser contabilizados).
Use o Feature Explorer: Protocolo de medição ativa de duas vias para confirmar o suporte de plataforma e versão para recursos específicos.
Analise a seção de comportamento de TWAMP específica 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 tempos de TWAMP fornecem métricas de ida ou volta com maior precisão do que outros métodos (atrasos no processamento também podem ser contabilizados).
-
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 de duas vias são melhores do que as medições de ida e volta, pois 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.
Recomendamos que você não configure o cliente RPM e um servidor TWAMP no mesmo dispositivo. Isso pode causar alguns problemas nos resultados da sonda RPM.
Entenda o protocolo de medição ativa de duas vias (TWAMP)
Normalmente, o TWAMP opera entre interfaces em dois dispositivos desempenhando funções específicas. O TWAMP é frequentemente usado para verificar a conformidade do Contrato de nível de serviço (SLA), 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.
-
Teste de TWAMP — 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:

Embora quatro dispositivos TWAMP diferentes possam desempenhar as quatro funções lógicas do TWAMP Control-Client, Server, Session-Sender e Session-Reflector, diferentes dispositivos podem desempenhar diferentes funções. 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 Servidor e Session-Reflector no outro dispositivo (conhecido como o responder TWAMP ou servidor TWAMP). Neste caso, cada dispositivo executa tanto o TWAMP-Control (entre o cliente de controle e o servidor) quanto o TWAMP-Test (entre os protocolos Session-Sender e Session-Reflector).
A arquitetura TWAMP cliente-servidor como implementada é assim:
-
Cliente TWAMP
-
O Control-Client configura, inicia e interrompe as sessões de teste do TWAMP.
-
O Session-Sender cria pacotes de teste TWAMP que são enviados ao 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 dessas informações.
-
O servidor gerencia uma ou mais sessões com o cliente TWAMP e ouve mensagens de controle em uma porta TCP.
-
A embalagem desses elementos nos processos de servidor TWAMP e cliente TWAMP é mostrada na Figura 2.

- Suporte de luz TWAMP
- Suporte simples para o protocolo de medição ativa de duas vias (STAMP)
- Rastreamento de rota estático
- Suporte ao roteamento por segmentos para a configuração de caminhos
Suporte de luz TWAMP
TWAMP Light, conforme definido no apêndice I do RFC 5357, é uma versão stateless 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 oferecem suporte, você também pode configurar endereços-alvo IPv6, incluindo endereços-alvo locais de enlace IPv6.
Use o Feature Explorer: Protocolo de medição ativa de duas vias para confirmar o suporte de plataforma e versão para recursos específicos.
Suporte simples para o protocolo de medição ativa de duas vias (STAMP)
Conforme definido no RFC 8762, Simple Two-Way Active Measurement Protocol, o STAMP padroniza e se expande no modo operacional TWAMP Light, que foi definido no apêndice I do RFC 5357, Protocolo de medição ativa de duas vias (TWAMP). Para os dispositivos que oferecem suporte ao STAMP, um refletor compatível com STAMP garante o tamanho da carga simétrica (de acordo com a RFC 6038) e opera em modo stateless ou stateful, dependendo se o número de sequência na carga refletida é copiado do quadro do cliente ou gerado de forma independente. Um refletor stateful pode detectar em que direção ocorreram quedas. Em versões anteriores, oferecemos suporte a cargas simétricas e reflexão stateless. Apoiamos a reflexão stateful, a conformidade total com o padrão STAMP e os valores de queda unidirecionais para os clientes. Oferecemos suporte a valores de queda unidirecionais não apenas para clientes STAMP, mas também para clientes do modo gerenciado TWAMP. Para o Junos OS Evolved, o STAMP está configurado no nível de [edit services monitoring twamp server light]
hierarquia. A reflexão stateful está configurada com a stateful-sequence
declaração. Para servidores, o novo padrão offload-type
agora pfe-timestamp
inline-timestamp
é .
Use o Feature Explorer: Simple Two-Way Active Measurement Protocol (STAMP) para confirmar o suporte de plataforma e versão.
Rastreamento de rota estático
A partir do Junos OS Evolved Release 24.4R1, estendemos o suporte para o rastreamento de rotas estáticas para o Junos OS Evolved e também incluímos suporte a testes de protocolo de medição ativa de duas vias (TWAMP). Você usa sondas TWAMP para detectar o status do link e alterar o estado de rota preferida com base nos resultados da sonda. Rotas estáticas acompanhadas podem ser IPv4 ou IPv6, e cada rota estática acompanhada de IPv4 e IPv6 suporta até 16 saltos seguintes. 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 maneira diferente nos dispositivos Junos OS Evolved; você configura a sla-tracking
declaração no nível de [edit routing-options]
hierarquia. Você também usa um comando show route sla-tracking
diferente para ver informações sobre essas rotas.
Suporte ao roteamento por segmentos para a configuração de caminhos
A partir do Junos OS Evolved Release 24.4R1, para os roteadores PTX que o suportam, adicionamos suporte no Protocolo de Medição Ativa de Duas Vias (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 segmentoS IPv6 (SID).
Você pode especificar a lista de segmentos SR-MPLS ou SRv6 para que uma sonda TWAMP chegue ao refletor. Além disso, você pode especificar as mesmas informações para o caminho de devolução 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 extensões simples de TWAMP (STAMP) para redes de roteamento por segmentos, draft-ietf-ippm-stamp-srpm, ou seja, o caminho de devolução TLV e sua lista de segmentos de devolução sub-TLVs, conforme apropriado, dependendo do tipo de roteamento por segmentos. As sondas TWAMP são temporizados no mecanismo de roteamento ou no mecanismo de encaminhamento de pacotes.
Para configurar esse recurso, inclua a source-routing
declaração no nível de [edit services monitoring twamp client control-connection name test-session session-name
hierarquia.
Diferenças evoluídas do Junos OS no suporte ao TWAMP
O suporte do Junos OS Evolved para TWAMP é limitado ao seguinte:
-
Tráfego IPv4 e IPv6 apenas para sessões de controle e sessões de teste. A partir do Junos OS Evolved Release 21.4R1, endereços de origem e alvo 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 de 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
Carimbos de tempo definidos pelo mecanismo de roteamento ou pelo mecanismo de encaminhamento de pacotes para tráfego IPv4. Para tráfego IPv6, carimbos de tempo definidos apenas pelo Mecanismo de Roteamento. Para tráfego IPv6, a partir do Junos OS Evolved 22.3R1, oferecemos suporte a datas de tempo do Mecanismo de encaminhamento de pacotes. Antes do Junos OS Evolved Release 22.3R1, para tráfego IPv6, a
A partir do Junos OS Evolved Release 23.4R1 para servidores, o padrão para aoffload-type
declaração no nível de[edit services monitoring twamp client control-connection name test-session name]
hierarquia deve ser configurada comonone
. A partir do Junos OS Evolved Release 22.4R1 para dispositivos suportados, você pode configurar a opçãoinline-timestamping
daoffload-type
declaração para permitir que os carimbos de tempo sejam definidos em linha pelo hardware.offload-type
declaração agorapfe-timestamp
inline-timestamp
é .-
Relatórios de erros por meio de mensagens de log do sistema e armadilhas SNMP apenas
-
Modo não autenticado apenas
O suporte evoluído do Junos OS 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 se expande no modo operacional TWAMP Light, que foi definido no Apêndice I do RFC 5357, Protocolo de Medição Ativa de Duas Vias (TWAMP). Para obter mais informações, consulte o suporte para o Simple Two-Way Active Measurement Protocol (STAMP).
-
A partir do Junos OS Evolved Release 24.4R1, oferecemos suporte ao rastreamento de rotas estático usando o TWAMP, para os dispositivos que oferecem suporte a esse recurso. Consulte o rastreamento de rotas estáticas para obter mais informações.
-
A partir do Junos OS Evolved Release 24.4R1, para os roteadores PTX que o suportam, adicionamos suporte no Protocolo de Medição Ativa de Duas Vias (TWAMP) para roteamento por segmentos (SR), conforme definido no RFC 8402. Consulte o suporte ao roteamento por segmentos para configurar caminhos para obter mais informações.
Comportamento de TWAMP específico da plataforma
Use o Feature Explorer: Protocolo de medição ativa de duas vias para confirmar o suporte de plataforma e versão para recursos específicos.
Use a tabela a seguir para revisar comportamentos específicos da plataforma para sua plataforma.
Diferença de plataforma | |
---|---|
Série ACX |
|
Série EX |
Tanto o cliente de controle quanto o remetente de 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 terceirizada. |
Série MX |
|
Série PTX |
|
Série QFX 10000 |
Tanto o cliente de controle quanto o remetente de 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 terceirizada. |
Série QFX5000 (Junos OS Evolved) |
Para o Junos OS Evolved, o TWAMP está configurado no nível de |
Série SRX (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 e dispositivos SRX4200 e instâncias de firewall virtual vSRX) |
|
Para a Série MX, a tabela abaixo mostra a relação entre o suporte de servidor e cliente RPM, o cliente TWAMP (com o componente de controle) e o servidor TWAMP (com o componente respondente) e o hardware que realiza o temporizante.
Suporte a recursos do TWAMP |
Temporização do mecanismo de roteamento |
Data-hora do MS-PIC/MS-DPC |
Data de tempo MS-MIC/MS-MPC |
Data de tempo do mecanismo de encaminhamento de pacotes (microkernel) |
Temporização do mecanismo de encaminhamento de pacotes (LU) ( |
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 (sem necessidade de configuração de responder) |
Sim |
O suporte para as interfaces de serviços (sp-
ms-
e si-
interfaces) são todos um pouco diferentes.
A Tabela 3 fornece informações sobre o TWAMP da Série MX e suporte a datas de tempo relacionados no MPC, MS-MIC/MPC e em linha:
Característica |
Papel |
Versão IP |
Suporte (Y/N) |
Linha de temporidade |
Data de tempo no MPC (temporidade de hardware) |
Data-hora no MPC (si-interface) |
Temporizações no MS-MIC/MPC (delegações-sondas) |
---|---|---|---|---|---|---|---|
TWAMP |
Cliente |
IPv4 |
Y |
N |
Y (μsec) 500 sondagens máximas |
Y (μsec) 500 sondagens máximas |
N |
IPv6 |
N |
N |
N |
N |
N |
||
Servidor
|
IPv4 |
Y |
N |
Y (μsec) 500 sondagens máximas |
Y (μsec) 500 sondagens máximas |
N |
|
IPv6 |
N |
N |
N |
N |
N |