Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Junte estatísticas sobre as MPLS sessões

Configuração de MPLS para coletar estatísticas

Você pode configurar MPLS para que ele coleta periodicamente estatísticas de tráfego sobre todas as MPLS, incluindo sessões de trânsito, configurando a statistics declaração. Você deve configurar a instrução se quiser coletar estatísticas de MPLS de tráfego usando a pesquisa SNMP de MPLS Base de Informações statistics de Gerenciamento (MIBs).

Para habilitar ou desativar MPLS coleta de estatísticas, inclua a statistics declaração:

Você pode configurar essas declarações nos seguintes níveis de hierarquia:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

O intervalo padrão é de 300 segundos.

Se você configurar file a opção, as estatísticas serão colocadas em um arquivo, com uma entrada por LSP. Durante o intervalo especificado, as seguintes informações são gravadas neste arquivo:

  • O número de pacotes, número de bytes, pacotes por segundo e bytes por segundo transmitidas por cada LSP. A paridade dos recursos para a exibição de estatísticas de pacote e byte para sub-LSPs de um LSP ponto a multipoint no chipset Junos Trio é suportada nas versões do Junos OS 11.1R2, 11.2R2 e 11.4.

  • A porcentagem da largura de banda transmitida por um determinado LSP em relação à porcentagem de largura de banda configurada para esse LSP. Se nenhuma largura de banda estiver configurada para um LSP, 0 por cento será registrado na coluna percentual.

Ao final de cada relatório periódico, um resumo mostra a hora atual, o número total de sessões, número de sessões lidas, número de sessões ignoradas e erros de leitura, se necessário. Normalmente, sessões ignoradas são aquelas que não estão em estado up ou com um rótulo de entrada reservado (de 0 a 15) (normalmente o ponto de saída de um LSP). O motivo de um erro de leitura aparece na mesma linha da entrada do LSP na qual ocorreu o erro. Coletar estatísticas não é um processo confiável; erros ocasionais de leitura podem afetar sua precisão. A saída da amostra é a seguinte:

Visão geral de perda e atraso de pacotes sob demanda para visão geral dos LSPs do UHP

Este tópico descreve os métodos para medir perda de pacote, atraso e taxa de transferência para caminhos comutado de hop (LSPs) de salto final ponto a ponto (UHP) em redes MPLS para permitir o monitoramento do desempenho da rede.

Importância da medição da perda e atraso de pacotes

O aumento de aplicativos que consomem largura de banda, como IPTV e vídeo móvel, juntamente com a pressão de minimizar o custo por bit e maximizar o valor por bit, está forçando as operadoras a fazer a transição de suas redes de transporte das tecnologias baseadas em circuito para tecnologias baseadas em pacotes. MPLS é uma tecnologia de transporte de pacotes orientada à conexão e amplamente bem-sucedida que é ideal para redes de transporte baseadas em pacotes.

Com a emergência de novos aplicativos em redes de dados, torna-se cada vez mais importante para os provedores de serviços prever com precisão o impacto das novas rollouts de aplicativos. Compreender e modelar o desempenho da rede na rede é especialmente relevante para a implantação de aplicativos de novo mundo para garantir implementações bem-sucedidas. Nas redes de pacotes, a perda e o atraso de pacotes são duas das medidas mais fundamentais de desempenho. Seu papel é ainda mais central quando se trata de medições ponta a ponta.

O tráfego que pertence à maioria dos aplicativos de usuário de ponta a ponta é sensível à perda (transferência de arquivo), sensível ao atraso (aplicativos de voz ou vídeo) ou ambos (aplicativos interativos de computação). Os acordos de nível de serviço (SLAs) dos provedores de serviços dependem da capacidade de medir e monitorar essas métricas de desempenho da rede, pois os SLAs dependem direta ou indiretamente da perda e atraso das experiências de tráfego do cliente na rede do provedor de serviços.

Para garantir a conformidade com o SLA, os provedores de serviços precisam de ferramentas para medir e monitorar as métricas de desempenho para perda de pacotes, atraso de ida e atraso de duas vias e métricas relacionadas, como variação de atraso e transferência de canal. Essa capacidade de medição fornece aos provedores de serviços maior visibilidade das características de desempenho de suas redes, o que facilita o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Definindo perda de pacotes, atraso e transferência

Nas redes de pacotes, a perda e o atraso de pacotes são duas das medidas mais fundamentais de desempenho.

  • Loss— A perda de pacotes é a falha de um ou mais pacotes transmitidos para chegar ao seu destino. A perda de pacotes refere-se aos pacotes de dados que são deixados pela rede para gerenciar o congestionamento.

    Os aplicativos de dados são muito tolerantes à perda de pacotes, pois geralmente não são sensíveis ao tempo e podem retransmitir os pacotes que foram abandonados. No entanto, em ambientes de videoconferência e comunicações de áudio puras, como VoIP, a perda de pacotes pode criar jitter.

  • Delay— Atraso de pacote (também chamado de latência) é o tempo que um pacote de dados leva para chegar de um ponto designado para outro, dependendo da velocidade do meio de transmissão, como fio de cobre, fibra óptica ou ondas de rádio, e os atrasos na transmissão por dispositivos ao longo do caminho, como roteadores e modems.

    Uma baixa latência indica uma alta eficiência de rede.

  • Throughput— O atraso do pacote mede o tempo entre o início de uma ação e sua conclusão, enquanto a taxa de transferência é o número total de ações que ocorrem em um determinado período de tempo.

Mecanismos de medição de perda e atraso de pacotes

Atraso e perda de pacotes são duas medidas fundamentais do desempenho da rede. O Junos MPLS OS fornece um mecanismo sob demanda para medir a perda e o atraso de pacotes sobre os caminhos de estouro de rótulo (LSPs) de salto ultimate popping (UHP) bidirecionais associados.

O mecanismo de medição de atraso e perda de pacote sob demanda é iniciado usando os seguintes comandos CLI:

  • monitor mpls loss rsvp— Realiza uma medição de perda sob demanda para LSPs bidirecionais associados.

  • monitor mpls delay rsvp— Realiza uma medição de atraso sob demanda para LSPs bidirecionais associados.

  • monitor mpls loss-delay rsvp— Realiza uma medição combinada de perda e atraso sob demanda para LSPs bidirecionais associados.

Para iniciar o mecanismo de medição de atraso e perda de pacote, os parâmetros de medição desejados, como o tipo de medição e o nome LSP, precisam ser inseridos. Ao receber os parâmetros, um resumo dos dados de monitoramento do desempenho é exibido e o mecanismo é encerrado.

Métricas de perda e atraso de pacotes

As seguintes métricas de desempenho são medidas usando-se os mecanismos de perda e atraso de pacotes sob demanda:

  • Medição de perda (pacote e octeto)

  • Medição de transferência (pacote e octeto)

  • Atraso de canal de duas vias

  • Atraso de ida e volta

  • Variação de atraso entre pacotes (IPDV)

O comando realiza a medição de perda e transferência, e o comando realiza as medições de atraso de canal de duas vias, atraso de ida e volta e monitor mpls loss rsvpmonitor mpls delay rsvp medições de IPDV. O comando realiza uma medição combinada de perda e atraso e mede todas as métricas de desempenho monitor mpls loss-delay rsvp citadas acima simultaneamente.

Conceitos de medição de perda de pacote e atraso

Os conceitos a seguir ajudam a entender melhor a funcionalidade de perda e atraso de pacotes:

  • Querier— Um querier é o roteador de borda do provedor de entrada (PE), que origina a mensagem de consulta para medição de perda ou atraso.

  • Responder— Um socorrista é o roteador PE de saída, que recebe e responde às mensagens de consulta de um consultador.

  • Associated bidirectional LSP— Um LSP bidirecional associado consiste em dois LSPs unidirecionais que são vinculados (ou associados entre si) por meio da configuração em ambos os pontos de extremidade do LSP.

    A medição de perda e atraso sob demanda só pode ser realizada em LSPs bidirecionais associados.

  • Generic associated channel (G-Ach)— As mensagens de monitoramento de desempenho para o fluxo de medição sob demanda e perda de atraso no MPLS G-Ach. Esse tipo de canal aceita apenas respostas dentro da banda e não fornece suporte para modos fora da banda ou sem resposta.

  • Measurement point (MP)— MP é o local em que uma condição é descrita para a medição.

    A MP para perda de pacotes no lado da transmissão está entre a malha de complicação e a interface de transmissão. O valor do contador é carimbado na mensagem de medição de perda no hardware antes de ser ensuado para a transmissão.

    A MP para perda de pacotes no lado de recebimento está entre a interface de recebimento e a malha de complicação. A MP é distribuída do lado de recebimento. Além disso, quando a interface de transmissão é uma interface agregada, a MP também é distribuída.

  • Query rate— Taxa de consulta é o intervalo entre duas consultas enviadas para medição de perda e atraso.

    Como as mensagens de medição de perda e atraso são originadas da Mecanismo de Roteamento, uma alta taxa de consulta para vários canais coloca uma carga pesada no Mecanismo de Roteamento. O intervalo mínimo de consultas suportado é de 1 segundo.

    A taxa de consultas deve ser alta para contadores de 32 bits, porque os contadores podem encerrar rapidamente quando a taxa de tráfego de dados é muito alta. A taxa de consultas pode ser baixa quando os contadores de 64 bits estão em uso em todos os quatro locais de ponto de medição envolvidos na medição de perda. O Junos OS tem suporte para somente contadores de 64 bits.

  • Traffic class— Por padrão, a medição de perda é suportada em todo o canal. O Junos OS também tem suporte para medição de perda de pacotes com escopo de tráfego, na qual contadores que mantenham estatísticas de tráfego de dados por classe de tráfego devem ser criados.

    Por padrão, os contadores de classe de tráfego não são criados. Para configurar a medição de perda de escopo de tráfego, inclua a traffic-class-statistics instrução em [edit protocols mpls statistics] nível de hierarquia.

    Quando está configurado, os pacotes de controle traffic-class-statistics que fluem pelo G-Ach não são contabilizados nos contadores de transmissão e recebimento.

    Nota:

    A ativação e desativação de estatísticas de classe de tráfego resulta na reconfiguração de todos os contadores (contadores agregados e por classe) para LSPs.

  • Loss measurement mode— O Junos OS tem suporte para o modo direto de medição de perda sob demanda e não fornece suporte para o modo inferido.

    A medição de perda direta requer que as estatísticas de tráfego de dados sejam mantidas na entrada e saída de dois LSPs unidirecionais do LSP bidirecional associado. Quando um roteador da Série MX está usando apenas MPCs e MICs, os contadores para manter estatísticas de tráfego de dados são criados por padrão na entrada de todos os tipos de LSPs e saída de LSPs uhp.

    Entretanto, o modo direto de medição de perda não é totalmente preciso devido aos seguintes motivos:

    • Natureza de encaminhamento paralelo do hardware.

    • Presença de multipath de custo igual (ECMP) na rede, como interfaces Ethernet agregadas, o que pode resultar na re-encomendação de pacotes de dados em relação às mensagens de medição de perda.

    • Os pacotes de controle que não fluem por G-Ach não são contados na entrada LSP, mas sim contabilizados na saída do LSP.

    • A re-ordenação do tráfego de dados em relação à mensagem de medição de perda quando um Diffserv é implementado no escopo de medição de MPLS de rede e perda é o canal completo e não a classe de tráfego escopo.

      Para superar essa limitação, realize a medição de perda de escopo de tráfego quando um Diffserv for implementado.

    Nota:

    A medição da perda do modo direto é vulnerável a interrupções quando a interface de entrada ou saída associada às alterações do LSP.

  • Loss measurement synchronization— As condições de sincronização especificadas na seção 2.9.8 da RFC 6374 não são verdadeiras no sentido absoluto. Entretanto, à medida que os contadores de medição de perda são carimbados no hardware, os erros introduzidos devido à não satisfação das condições de sincronização são relativamente pequenos. Esses erros precisam ser quantificados.

    Quando a interface de transmissão ou recebimento do LSP é uma interface agregada, mais erros são introduzidos em comparação com quando as interfaces são interfaces não agregadas. De qualquer forma, os contadores de medição de perda são carimbados em hardware e o erro precisa ser quantificado.

  • Delay measurement accuracy— Quando as interfaces de transmissão e recebimento residem em diferentes mecanismos de encaminhamento de pacotes, o relógio deve ser sincronizado nesses mecanismos de encaminhamento de pacotes para medições de atraso de duas vias. Essa condição vale para a plataforma na qual o recurso de medição de atraso sob demanda é implementado.

    Quando há interfaces agregadas ou ECMP, o atraso é medido apenas para um dos caminhos em potencial.

    Quando uma mensagem combinada de perda e atraso é usada para o cálculo do atraso, a precisão do atraso é menor em comparação com quando a mensagem de medição de atraso é usada em alguns casos, como quando a interface de transmissão ou recebimento é uma interface agregada.

    A medição de atraso é sempre realizada de acordo com a categoria de tráfego, e a precisão da medição precisa ser quantificada após o teste.

  • Timestamp format— O Junos OS tem suporte apenas para o formato IEEE (1588 Precision Time Protocol) [IEEE1588] para registrar mensagens de medição de atraso. O formato de tempo de rede (NTP) não é suportado.

  • Operations, administration, and maintenance (OAM)— Para indicar que todas as mensagens de OAM para LSPs MPLS fluem sobre o MPLS G-Ach e para permitir que as mensagens de monitoramento de desempenho da MPLS sejam transportadas pelo G-Ach da MPLS, a instrução deve ser incluída no nível da oam mpls-tp-mode[edit protocols mpls label-switched-path lsp-name] hierarquia.

Funcionalidade de medição de perda e atraso de pacotes

Figura 1 ilustra os métodos básicos usados para a medição bidirecional de perda e atraso de pacotes. Existe um canal bidirecional entre os dois roteadores, o roteador A e o roteador B. Os pontos de referência temporais – T1, T2, T3 e T4 – estão associados a uma operação de medição que acontece no Roteador A. A operação consiste no roteador A enviando uma mensagem de consulta para o Roteador B e o Roteador B enviando uma resposta. Cada ponto de referência indica o ponto de tempo no qual a consulta ou a mensagem de resposta é transmitida ou recebida pelo canal.

Figura 1: Medição bidirecional básicaMedição bidirecional básica

No , o roteador A pode conseguir medir a perda de pacotes pelo canal nas direções forward e reversa enviando mensagens de consulta de medição de perda Figura 1 para o Roteador B. Cada uma das mensagens anteriores e reversas contém a contagem de pacotes transmitidas antes da hora T1 pelo canal até o roteador B (A_TxP).

Quando a mensagem chega ao roteador B, dois valores são anexados à mensagem e a mensagem é refletida de volta ao Roteador A. Os dois valores são a contagem de pacotes recebidos antes da hora T2 pelo canal do roteador A (B_RxP) e a contagem de pacotes transmitidos antes da hora T3 pelo canal até o roteador A (B_TxP).

Quando a resposta chega ao roteador A, um quarto valor é acrescentado à mensagem: a contagem de pacotes recebidos antes do T4 pelo canal do roteador B (A_RxP).

Esses quatro valores de conta(A_TxP), (B_RxP), (B_TxP) e (A_RxP) permitem que o Roteador A compute as estatísticas de perda desejadas. Como a contagem de transmissão no Roteador A e a contagem de recebimento no Roteador B (e vice-versa) podem não ser sincronizadas no momento da primeira mensagem, e para limitar os efeitos do contra-envoltório, a perda é computada na forma de um delta entre as mensagens.

A perda de transmissão (A_TxLoss[n-1,n]) e a perda de recebimento (A_RxLoss[n-1,n]) no intervalo de medição marcado pelas mensagens LM[n-1] e LM[n] são computadas pelo Roteador A da seguinte forma:

  1. A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

  2. A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

A aritmética é o tamanho do contra-módulo.

Para medir no Roteador A o atraso no canal até o roteador B, é enviada do Roteador A para o Roteador B uma mensagem de consulta de atraso contendo um timestamp gravando o momento em que ela é transmitida. In, Figura 1 o timestamp é registrado em T1.

Quando a mensagem chega ao roteador B, um timestamp é adicionado, gravando o momento em que ela é recebida (T2). A mensagem agora pode ser refletida do Roteador B ao Roteador A, com o Roteador B adicionando seu timestamp de transmissão (T3) e o roteador A adicionando seu timestamp de recebimento (T4).

Esses quatro timestamps – T1, T2, T3 e T4 – permitem que o Roteador A compute o atraso de ida e volta em cada direção, bem como o atraso de duas vias para o canal. As computação de atraso de ida exigem que os relógios dos roteadores A e B sejam sincronizados.

Neste ponto, o roteador A pode computar o atraso de canal de duas vias e o atraso de ida e volta associados ao canal da seguinte forma:

  1. Atraso de canal de duas vias = (T4 - T1) - (T3 - T2)

  2. Atraso de ida e volta = T4 - T1

Recursos de perda de pacote e atraso

Supported Features of Packet Loss and Delay

O Junos OS tem suporte para os seguintes recursos com medição de perda e atraso sob demanda:

  • Monitoramento do desempenho apenas para LSPs bidirecionais associados MPLS LSPs ponto a ponto

  • Medição de perda

  • Medição de transferência

  • Medição de atraso de duas vias (atraso do canal e atraso de ida e volta)

  • Variação de atraso entre pacotes (IPDV)

  • Medição de perda de modo direto

  • Interfaces Ethernet agregadas e SONET agregadas

  • Suporte multichassis

  • compatível com 64 bits

Unsupported Features of Packet Loss and Delay

O Junos OS não tem suporte para a seguinte funcionalidade de medição de perda e atraso sob demanda:

  • Medição de perda e atraso para pseudowires (seção 2.9.1 da RFC 6374)

  • Medição unidirecional (seção 2.6 da RFC 6374)

  • Medição dyadica (seção 2.7 da RFC 6374)

  • Medição de perda e atraso no modo de loopback (seção 2.8 da RFC 6374)

  • Medição de perda e atraso para um nó intermediário de um endpoint LSP (seção 2.9.5 da RFC 6374)

  • Pós-processamento externo (seção 2.9.7 da RFC 6374)

  • Medição de perda no modo inferido (seção 2.9.8 da RFC 6374)

  • Modo pro-ativo

  • Sistemas lógicos

  • Snmp

Exemplo: Configuração da medição de perda e atraso sob demanda

Este exemplo mostra como habilitar a medição de perda e atraso sob demanda para caminhos comutado de salto final (UHP) ponto a ponto (LSPs) em redes MPLS para monitorar o desempenho da rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois modelos 5G da Série MX Plataformas de roteamento universal que contêm apenas MPC/MICs

  • Junos OS Release 14.2 ou mais tarde em execução em todos os roteadores

Antes de começar:

  1. Configure as interfaces de dispositivo.

  2. Configure os números do sistema autônomo e as IDs do roteador para os dispositivos.

  3. Configure os seguintes protocolos:

    • RSVP

    • MPLS

    • OSPF

Visão geral

A partir do Junos OS Release 14.2, é introduzida uma ferramenta sob demanda para monitorar e medir a perda de pacote MPLS, o atraso do pacote ou para os caminhos de salto final (UHP) bidirecionais associados. A ferramenta pode ser habilitada usando os seguintes comandos de CLI – monitor mpls loss rsvpmonitor mpls delay rsvp , e monitor mpls loss-delay rsvp .

Esses comandos fornecem um resumo sob demanda de métricas de desempenho para perda de pacotes do modo direto, atraso de pacote de duas vias e métricas relacionadas, como variação de atraso entre pacotes e medição da taxa de transferência do canal.

Essa funcionalidade fornece visibilidade em tempo real do desempenho da rede, facilitando o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Topologia

Figura 2 ilustra a medição de perda e atraso sob demanda usando uma topologia simples de dois roteadores.

Figura 2: Configuração da medição de perda e atraso sob demandaConfiguração da medição de perda e atraso sob demanda

Neste exemplo, um LSP bidirecional associado está configurado entre os roteadores R1 e R2, para o qual as métricas de desempenho são medidas.

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

R1

R2

Procedimento

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar o roteador R1:

  1. Ative o chassi com serviços de túnel e configuração aprimorada de serviços de rede IP.

  2. Configure as interfaces do roteador R1.

  3. Configure a ID do roteador para o roteador R1.

  4. Ative o RSVP em todas as interfaces do roteador R1, exceto a interface de gerenciamento.

  5. Ative MPLS em todas as interfaces do roteador R1, exceto a interface de gerenciamento.

  6. Configure um LSP bidirecional associado ao roteador R2.

  7. Crie classes de tráfego para manter estatísticas de tráfego de dados por classe de tráfego.

    Isso permite a medição de perda de escopo de tráfego.

  8. Configure OSPF com recursos de engenharia de tráfego e OSPF todas as interfaces do roteador R1, exceto a interface de gerenciamento.

Resultados

A partir do modo de configuração, confirme sua configuração show chassis inserindo os show interfaces comandos , e show routing-options . show protocols Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação do status do LSP

Propósito

Verificar se o LSP bidirecional associado entre os roteadores R1 e R2 está ativo.

Ação

Do modo operacional, execute o show mpls lsp comando.

Significado

O LSP bidirecional associado R1-R2 está ativo e ativo.

Verificação da medição da perda de pacotes

Propósito

Verificar o resultado da medição de perda sob demanda.

Ação

Do modo operacional, execute o monitor mpls loss rsvp R1-R2 count 2 detail comando.

Significado

A medição da perda de pacotes para duas contagens é visualizada.

Verificação da medição do atraso do pacote

Propósito

Verificar o resultado da medição do atraso sob demanda.

Ação

Do modo operacional, execute o monitor mpls delay rsvp R1-R2 count 2 detail comando.

Significado

A medição do atraso do pacote para duas contagens é visualizada.

Verificação da medição do atraso da perda de pacotes

Propósito

Verificar o resultado da medição de perda e atraso sob demanda.

Ação

Do modo operacional, execute o monitor mpls loss-delay rsvp R1-R2 count 2 detail comando.

Significado

A medição de perda e atraso de pacotes para duas contagens é visualizada.

Exemplo: Configurando medições proativas de perda e atraso para LSPs bidirecionais MPLS LSPs

Este exemplo mostra como configurar medições proativas de perda e atraso para caminhos comutado de rótulo (LSPs) de salto final ponto a ponto em redes MPLS para monitorar o desempenho da rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois modelos 5G da Série MX Plataformas de roteamento universal que contêm apenas MPC/MICs

  • Junos OS Release 15.1 ou mais tarde executado em todos os roteadores

Antes de começar:

  1. Configure as interfaces de dispositivo.

  2. Configure os números do sistema autônomo e as IDs do roteador para os dispositivos.

  3. Configure os seguintes protocolos:

    1. MPLS

    2. OSPF

    3. RSVP

Visão geral

A partir da Versão 15.1 do Junos OS, é introduzida uma ferramenta proativa para monitorar e medir a perda de pacote, o atraso do pacote ou, para os caminhos comutado de rótulo (LSPs) bidirecionais associados do MPLS ultimate-hop popping point-to-point label-switched paths (LSPs).

Esse recurso fornece as seguintes métricas de desempenho:

  • Variação de atraso entre pacotes (IPDV)

  • Medição de perda

  • Atraso de ida e volta (RTT)

  • Medição de transferência

  • Atraso de canal de duas vias

Essa funcionalidade fornece visibilidade em tempo real do desempenho da rede, facilitando o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Topologia

Figura 3 ilustra as medições pro-ativa de perda e atraso usando uma topologia simples de dois roteadores.

Figura 3: Configurando medições pro-active loss e delayConfigurando medições pro-active loss e delay

Neste exemplo, um LSP bidirecional associado está configurado entre os roteadores R1 e R2, para o qual as métricas de desempenho são medidas.

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

R1

R2

Procedimento

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar o roteador R1:

  1. Ative a configuração de serviços de rede IP aprimorados.

  2. Configure as interfaces do roteador R1.

  3. Configure a ID do roteador para o roteador R1.

  4. Ative o RSVP em todas as interfaces do roteador R1, exceto a interface de gerenciamento.

  5. Ative MPLS em todas as interfaces do roteador R1, exceto a interface de gerenciamento.

  6. Configure um LSP bidirecional associado ao roteador R2.

  7. Crie classes de tráfego para manter estatísticas de tráfego de dados por classe de tráfego.

    Isso permite a medição de perda e atraso de classe de tráfego.

  8. Configure o monitoramento do desempenho do lado mais adoeceiro.

  9. Configure o monitoramento do desempenho do lado do socorrista.

  10. Configure OSPF com recursos de engenharia de tráfego e OSPF todas as interfaces do roteador R1, exceto a interface de gerenciamento.

Resultados

A partir do modo de configuração, confirme sua configuração show chassis inserindo os show interfaces comandos , e show routing-options . show protocols Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

Verificação da medição de perda e atraso

Propósito

Verificar a medição de perda e atraso.

Ação

Do modo operacional, execute o show performance-monitoring mpls lsp comando.

Significado

As métricas de medição de perda e atraso de pacotes para LSP são exibidas.

Configuração da medição de perda e atraso sob demanda

Você pode configurar uma medição de perda e atraso sob demanda para caminhos comutado de salto final (UHP) ponto a ponto (LSPs) em redes MPLS para monitorar o desempenho da rede. Os comandos , e os comandos CLI fornecem um resumo sob demanda das métricas de desempenho para perda direta de pacotes do modo, atraso de pacote de duas vias e monitor mpls loss rsvp métricas relacionadas, como variação de atraso entre pacotes e medição da taxa de transferência do monitor mpls delay rsvpmonitor mpls loss-delay rsvp canal.

Essa funcionalidade fornece visibilidade em tempo real do desempenho da rede, facilitando o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Antes de começar:

  1. Configure as interfaces de dispositivo.

  2. Configure a ID do roteador do dispositivo.

  3. Configure os seguintes protocolos:

    • RSVP

    • OSPF

      Habilitar recursos de engenharia de tráfego.

    • MPLS

Para configurar o dispositivo PE:

  1. Ative o chassi com serviços de túnel e configuração aprimorada de serviços de rede IP.
  2. Configure um LSP bidirecional associado ao roteador remoto.
  3. Crie classes de tráfego para manter estatísticas de tráfego de dados por classe de tráfego.

    Isso permite a medição de perda de escopo de tráfego.

Configurando medições pro-active loss e delay

Você pode configurar medições proativas de perda e atraso para caminhos comutado de rótulo (LSPs) de salto final ponto a ponto em MPLS redes para monitorar o desempenho da rede. O comando CLI fornece um resumo das métricas de desempenho para perda de pacotes do modo direto, atraso de pacote de duas vias e métricas relacionadas, como variação de atraso entre pacotes e medição da taxa de transferência do show performance-monitoring mpls lsp canal.

Essa funcionalidade fornece visibilidade em tempo real do desempenho da rede, facilitando o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Esse recurso fornece as seguintes métricas de desempenho:

  • Variação de atraso entre pacotes (IPDV)

  • Medição de perda

  • Atraso de ida e volta (RTT)

  • Medição de transferência

  • Atraso de canal de duas vias

Antes de começar:

  1. Configure as interfaces de dispositivo.

  2. Configure os números do sistema autônomo e as IDs do roteador para os dispositivos.

  3. Configure os seguintes protocolos:

    • MPLS

    • OSPF

    • RSVP

Para configurar medidas pro-ativa de perda e atraso no dispositivo PE:

  1. Configure um LSP bidirecional associado ao roteador R2.
  2. Crie classes de tráfego para manter estatísticas de tráfego de dados por classe de tráfego.

    Isso permite medições de perda e atraso de classe de tráfego.

  3. Configure o monitoramento do desempenho do lado mais adoeceiro.
  4. Configure o monitoramento do desempenho do lado do socorrista.