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

Nota:

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:

Figura 1: Quatro elementos do TWAMP Four Elements of TWAMP

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.

Figura 2: Os elementos do TWAMP implementados como cliente (esquerda) e servidor (direita). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

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-trackingdiferente 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 offload-type declaração no nível de [edit services monitoring twamp client control-connection name test-session name] hierarquia deve ser configurada como none. A partir do Junos OS Evolved Release 22.4R1 para dispositivos suportados, você pode configurar a opção inline-timestamping da offload-type declaração para permitir que os carimbos de tempo sejam definidos em linha pelo hardware.

    A partir do Junos OS Evolved Release 23.4R1 para servidores, o padrão para a offload-type declaração agora pfe-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.

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

Série ACX

  • No Junos OS, os roteadores ACX710 e série ACX5448 suportam reflexão e 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 tem suporte para roteadores ACX, tanto para reflexão quanto para geração. Veja as diferenças evoluídas do Junos OS no suporte de TWAMP para notas sobre as diferenças de SO no suporte ao TWAMP.

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

  • O tráfego de conexão de controle de 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 sondagens que chegam com um número de porta diferente não são reconhecidas e processadas corretamente pelos roteadores ACX. Como resultado, o tráfego TWAMP e os pacotes vinculados ao host são descartados em tal 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, o TWAMP sobre a 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 descarta 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 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

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

  • O TWAMP não é suportado quando você habilita 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, destinado à habilitação de serviços em linha, não é suportado em roteadores da Série PTX para configurações de clientes TWAMP.

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

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 [edit services monitoring twamp] hierarquia. Veja as diferenças evoluídas do Junos OS no suporte de TWAMP para notas sobre as diferenças de SO no suporte ao TWAMP.

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

  • O TWAMP para IPv6 não tem suporte.

  • O servidor TWAMP e a autenticação do cliente TWAMP não são compatíveis.

  • O TWAMP Light não é compatível.

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.

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

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) (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 (sem necessidade de configuração de responder)

Sim
Nota:

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:

Tabela 3: TWAMP e suporte a datas de tempo relacionados, Série MX

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

Documentação relacionada