Monitore a qualidade do serviço de rede usando o RMON

Limites de configuração

Ao definir um limiar crescente e em queda para uma variável monitorada, você pode ser alertado sempre que o valor da variável estiver fora do intervalo operacional permitido. (Veja Figura 1.)

Figura 1: Limites de configuração

Os eventos só são gerados quando o limiar é cruzado pela primeira vez em qualquer direção, em vez de após cada período de amostra. Por exemplo, se um evento de travessia de limiar crescente for levantado, não ocorrerão mais eventos de travessia de limiar até um evento correspondente de queda. Isso reduz consideravelmente a quantidade de alarmes que são produzidos pelo sistema, tornando mais fácil para a equipe de operações reagir quando os alarmes ocorrem.

Para configurar o monitoramento remoto, especifique as seguintes informações:

• A variável a ser monitorada (pelo identificador de objetos SNMP)

• O tempo entre cada inspeção

• Um limite crescente

• Um limiar em queda

• Um evento em ascensão

• Um evento em queda

Antes de configurar com sucesso o monitoramento remoto, você deve identificar quais variáveis precisam ser monitoradas e seu alcance operacional permitido. Isso requer algum período de base para determinar os intervalos operacionais permitidos. Um período de linha de base inicial de pelo menos três meses não é incomum quando se identifica primeiro as faixas operacionais e define limites, mas o monitoramento da linha de base deve continuar ao longo da vida útil de cada variável monitorada.

Interface de linha de comando RMON

O Junos OS fornece dois mecanismos que você usa para controlar o agente de monitoramento remoto no roteador: interface de linha de comando (CLI) e SNMP. Para configurar uma entrada RMON usando a CLI, inclua as seguintes declarações no nível de [edit snmp] hierarquia:

Se você não tiver acesso à CLI, poderá configurar o monitoramento remoto usando o SNMP Manager ou o aplicativo de gerenciamento, assumindo que o acesso SNMP foi concedido. (Veja Tabela 1.) Para configurar o RMON usando O SNMP, realize solicitações de SNMP Set para o evento RMON e tabelas de alarme.

Tabela de eventos da RMON

Configure um evento para cada tipo que você deseja gerar. Por exemplo, você pode ter dois eventos genéricos, subindo e caindo, ou muitos eventos diferentes para cada variável que está sendo monitorada (por exemplo, evento de elevação da temperatura , evento de queda da temperatura , evento de impacto de firewall , evento de utilização de interface e assim por diante). Após a configuração dos eventos, você não precisa atualizá-los.

Tabela de alarme RMON

A tabela de alarme RMON armazena os identificadores de objetos SNMP (incluindo suas instâncias) das variáveis que estão sendo monitoradas, juntamente com quaisquer limiares de aumento e queda e seus índices de eventos correspondentes. Para criar uma solicitação de RMON, especifique os campos mostrados em Tabela 2.

Tanto os alarmStatus campos eventStatus são entryStatus primitivos, como definido na RFC 2579, Convenções textuais para SMIv2.

Solução de problemas RMON

Você soluciona problemas do agente RMON, rmopdque é executado no roteador inspecionando o conteúdo do RMON MIB empresarial da Juniper Networks, jnxRmonque fornece as extensões listadas na Tabela 3 RFC 2819 alarmTable.

O monitoramento das extensões nesta tabela fornece pistas sobre por que alarmes remotos podem não se comportar como esperado.

Pontos de medição

Definir os pontos de medição onde as métricas são medidas é igualmente tão importante quanto definir as próprias métricas. Esta seção descreve pontos de medição dentro do contexto deste capítulo e ajuda a identificar onde as medições podem ser tomadas de uma rede de provedor de serviços. É importante entender exatamente onde está um ponto de medição. Os pontos de medição são vitais para entender a implicação do que a medição real significa.

Uma rede IP consiste em uma coleção de roteadores conectados por links físicos que estão todos executando o Protocolo de Internet. Você pode ver a rede como uma coleção de roteadores com um ponto de entrada (entrada) e um ponto de saída (saída). Veja Figura 2.

• As medições centradas na rede são feitas em pontos de medição que mapeiam mais de perto os pontos de entrada e saída para a própria rede. Por exemplo, para medir o atraso em toda a rede do provedor do Site A ao Site B, os pontos de medição devem ser o ponto de entrada para a rede do provedor no Site A e o ponto de saída no Site B.

• As medições centradas no roteador são tomadas diretamente dos próprios roteadores, mas tenha cuidado para garantir que os subcomponentes corretos do roteador tenham sido identificados com antecedência.

Figura 2: Pontos de entrada de rede

Principais indicadores básicos de desempenho

Por exemplo, você pode monitorar uma rede de provedor de serviços para três indicadores básicos de desempenho chave (KPIs):

• mede a "acessibilidade" de um ponto de medição de outro ponto de medição na camada de rede (por exemplo, usando ping de ICMP). A infraestrutura de roteamento e transporte subjacente da rede do provedor oferecerá suporte às medições de disponibilidade, com falhas destacadas como indisponibilidade.

• mede o número e o tipo de erros que estão ocorrendo na rede do provedor, e pode consistir em medições centradas no roteador e centradas na rede, como falhas de hardware ou perda de pacotes.

• da rede do provedor mede o quão bem ela pode oferecer suporte a serviços IP (por exemplo, em termos de atraso ou utilização).

Configuração das linhas de base

Qual é o desempenho da rede do provedor? Recomendamos um período inicial de monitoramento de três meses para identificar os parâmetros operacionais normais de uma rede. Com essas informações, você pode reconhecer exceções e identificar comportamentos anormais. Você deve continuar o monitoramento da linha de base para a vida útil de cada métrica medida. Com o tempo, você deve ser capaz de reconhecer tendências de desempenho e padrões de crescimento.

No contexto deste capítulo, muitas das métricas identificadas não têm um alcance operacional permitido associado a eles. Na maioria dos casos, você não pode identificar o intervalo operacional permitido até que você tenha determinado uma linha de base para a variável real em uma rede específica.

Definir disponibilidade de rede

A disponibilidade da rede IP de um provedor de serviços pode ser considerada como a acessibilidade entre os pontos de presença regionais (POP), como mostrado em Figura 3.

Figura 3: Pontos de presença regionais

Com o exemplo acima, quando você usa uma malha completa de pontos de medição, onde cada POP mede a disponibilidade a cada outro POP, você pode calcular a disponibilidade total da rede do provedor de serviços. Esse KPI também pode ser usado para ajudar a monitorar o nível de serviço da rede e pode ser usado pelo provedor de serviços e seus clientes para determinar se eles estão operando dentro dos termos de seu contrato de nível de serviço (SLA).

Quando um POP pode consistir em vários roteadores, faça medições para cada roteador conforme mostrado em Figura 4.

Figura 4: Medições para cada roteador

As medições incluem:

• Disponibilidade de caminho — disponibilidade de uma interface B1 de saída, como visto de uma interface de entrada A1.

• Disponibilidade do roteador — Porcentagem da disponibilidade de caminhos de todos os caminhos medidos que terminam no roteador.

• Disponibilidade POP — Porcentagem da disponibilidade do roteador entre quaisquer dois POPs regionais, A e B.

• Disponibilidade de rede — Porcentagem da disponibilidade pop para todos os POPs regionais na rede do provedor de serviços.

Para medir a disponibilidade POP de POP A para POP B Figura 4, você deve medir os seguintes quatro caminhos:

Medir a disponibilidade do POP B ao POP A exigiria mais quatro medições e assim por diante.

Uma malha completa de medições de disponibilidade pode gerar tráfego de gerenciamento significativo. No diagrama da amostra acima:

• Cada POP tem dois roteadores de borda de provedor (PE) co-localizados, cada um com 2 interfaces STM1, para um total de 18 roteadores PE e 36 interfacesSTM1.

• Existem seis roteadores de provedor de núcleo (P), quatro com 2xSTM4 e 3 interfaces STM1 cada, e dois com 3xSTM4 e 3 interfaces STM1 cada.

Isso faz um total de 68 interfaces. Uma malha completa de caminhos entre cada interface é:

[n x (n-l)] / 2 dá [68 x (68-1)] / 2=2278 caminhos

Para reduzir o tráfego de gerenciamento na rede do provedor de serviços, em vez de gerar uma malha completa de testes de disponibilidade de interface (por exemplo, de cada interface para qualquer outra interface), você pode medir a partir do endereço loopback de cada roteador. Isso reduz o número de medições de disponibilidade necessárias para um total de uma para cada roteador, ou:

[n x (n-1)] / 2 dá [24 x (24-1)] / 2=276 medições

Isso mede a disponibilidade de cada roteador para todos os outros roteadores.

Medir a disponibilidade

Existem dois métodos que você pode usar para medir a disponibilidade:

• Proativo — a disponibilidade é automaticamente medida com a maior frequência possível por um sistema de suporte operacional.

• Reativo — A disponibilidade é registrada por um help desk quando uma falha é relatada pela primeira vez por um usuário ou um sistema de monitoramento de falhas.

Esta seção discute o monitoramento de desempenho em tempo real como uma solução de monitoramento proativa.

Meça a classe de serviço

Você pode usar mecanismos de classe de serviço (CoS) para regular como determinadas classes de pacotes são tratadas em sua rede durante os momentos de pico de congestionamento. Normalmente, você deve executar as seguintes etapas ao implementar um mecanismo CoS:

• Identificar o tipo de pacotes que é aplicado a esta classe. Por exemplo, inclua todo o tráfego do cliente a partir de uma interface de borda de entrada específica em uma classe, ou inclua todos os pacotes de um protocolo específico, como voz sobre IP (VoIP).

• Identificar o comportamento determinístico necessário para cada classe. Por exemplo, se o VoIP for importante, dê ao tráfego VoIP a maior prioridade em tempos de congestionamento de rede. Por outro lado, você pode rebaixar a importância do tráfego web durante o congestionamento, pois isso pode não afetar muito os clientes.

Com essas informações, você pode configurar mecanismos na entrada da rede para monitorar, marcar e policiar as aulas de tráfego. O tráfego marcado pode então ser tratado de uma maneira mais determinística nas interfaces de saída, normalmente aplicando diferentes mecanismos de fila para cada classe durante os tempos de congestionamento da rede. Você pode coletar informações da rede para fornecer aos clientes relatórios que mostram como a rede está se comportando em tempos de congestionamento. (Veja Figura 5.)

Figura 5: Comportamento da rede durante o congestionamento

Para gerar esses relatórios, os roteadores devem fornecer as seguintes informações:

• Tráfego enviado — Quantidade de tráfego recebido por classe.

• Tráfego entregue — Quantidade de tráfego transmitido por classe.

• Tráfego em queda — A quantidade de tráfego caiu devido aos limites da CoS.

A seção a seguir descreve como essas informações são fornecidas pelos roteadores da Juniper Networks.

Contadores de filtro de firewall de entrada por classe

Os contadores de filtro de firewall são um mecanismo muito flexível que você pode usar para combinar e contar tráfego de entrada por classe, por interface. Por exemplo:

Por exemplo, Tabela 8 mostra filtros adicionais usados para combinar com as outras classes.

Qualquer pacote com um ponto de código CoS DiffServ (DSCP) em conformidade com o RFC 2474 pode ser contado dessa forma. O MIB do filtro de firewall específico para empresas da Juniper Networks apresenta as informações contrárias nas variáveis mostradas em Tabela 9.

Essas informações podem ser coletadas por qualquer aplicativo de gerenciamento SNMP que ofereça suporte ao SNMPv2. Produtos de fornecedores como Concord Communications, Inc., e InfoVista, Inc., fornecem suporte para o Juniper Networks Firewall MIB com seus drivers de dispositivos nativos da Juniper Networks.

Monitore bytes de saída por fila

Você pode usar o ATM CoS MIB empresarial da Juniper Networks para monitorar o tráfego de saída, por classe de encaminhamento de circuito virtual, por interface. (Veja Tabela 10.)

Os contadores de interface não-ATM são fornecidos pelo CoS MIB específico para empresas da Juniper Networks, que fornece informações mostradas em Tabela 11.

Calcule a queda de tráfego

Você pode calcular a quantidade de tráfego perdido subtraindo o tráfego de saída do tráfego de entrada:

Você também pode selecionar contadores do CoS MIB, conforme mostrado em Tabela 12.