Supervisión de la calidad del servicio de red mediante RMON

Configuración de umbrales

Al establecer un umbral ascendente y descendente para una variable supervisada, se le puede alertar cada vez que el valor de la variable caiga fuera del rango operativo permitido. (Consulte Figura 1.)

Figura 1: Configuración de umbrales

Los eventos solo se generan cuando el umbral se cruza por primera vez en una dirección en lugar de después de cada período de muestreo. Por ejemplo, si se eleva un evento de cruce de umbral ascendente, no se producirán más eventos de cruce de umbral hasta un evento de caída correspondiente. Esto reduce considerablemente la cantidad de alarmas que produce el sistema, lo que facilita que el personal de operaciones reaccione cuando se producen alarmas.

Para configurar la supervisión remota, especifique los siguientes datos:

• La variable que se va a supervisar (por su identificador de objeto SNMP)

• El tiempo transcurrido entre cada inspección

• Un umbral ascendente

• Un umbral descendente

• Un evento en alza

• Un evento de caída

Antes de poder configurar correctamente la supervisión remota, debe identificar qué variables deben supervisarse y su rango operativo permitido. Esto requiere un período de referencia para determinar los rangos operativos permitidos. Un período inicial de referencia de al menos tres meses no es inusual cuando se identifican por primera vez los rangos operativos y se definen los umbrales, pero el monitoreo de línea de base debe continuar durante la vida útil de cada variable monitoreada.

Interfaz de línea de comandos RMON

Junos OS proporciona dos mecanismos que se utilizan para controlar el agente de supervisión remota en el enrutador: interfaz de línea de comandos (CLI) y SNMP. Para configurar una entrada de RMON mediante la CLI, incluya las siguientes instrucciones en el nivel de [edit snmp] jerarquía:

Si no tiene acceso a la CLI, puede configurar la supervisión remota mediante SNMP Manager o la aplicación de administración, suponiendo que se haya concedido acceso SNMP. (Véase Tabla 1.) Para configurar RMON mediante SNMP, realice solicitudes SNMP Set a las tablas de eventos y alarmas de RMON.

Tabla de eventos RMON

Configure un evento para cada tipo que desee generar. Por ejemplo, podría tener dos eventos genéricos, subida y bajada, o muchos eventos diferentes para cada variable que se está supervisando (por ejemplo, evento de aumento de temperatura , evento de caída de temperatura , evento de golpe de firewall , evento de utilización de interfaz , etc.). Una vez configurados los eventos, no es necesario actualizarlos.

Tabla de alarma RMON

La tabla de alarmas RMON almacena los identificadores de objeto SNMP (incluidas sus instancias) de las variables que se supervisan, junto con los umbrales ascendentes y descendentes y sus índices de eventos correspondientes. Para crear una solicitud RMON, especifique los campos que se muestran en Tabla 2.

Tanto los campos como los son primitivos, como se define en RFC 2579, Convenciones textuales para SMIv2.entryStatusalarmStatuseventStatus

Solución de problemas de RMON

Para solucionar los problemas del agente RMON, rmopd, que se ejecuta en el enrutador, inspeccione el contenido de la MIB de RMON empresarial de Juniper Networks, jnxRmon, que proporciona las extensiones enumeradas en Tabla 3 el RFC 2819 alarmTable.

La supervisión de las extensiones de esta tabla proporciona pistas sobre por qué las alarmas remotas pueden no comportarse como se esperaba.

Puntos de medición

Definir los puntos de medición donde se miden las métricas es tan importante como definir las métricas en sí. En esta sección se describen los puntos de medición en el contexto de este capítulo y se ayuda a identificar dónde se pueden realizar mediciones desde una red de proveedores de servicios. Es importante entender exactamente dónde está un punto de medición. Los puntos de medición son vitales para comprender la implicación de lo que significa la medición real.

Una red IP consiste en una colección de enrutadores conectados por vínculos físicos que ejecutan el protocolo de Internet. Puede ver la red como una colección de enrutadores con un punto de entrada y un punto de salida. Consulte Figura 2.

• Las mediciones centradas en la red se toman en los puntos de medición que se corresponden más estrechamente con los puntos de entrada y salida de la propia red. Por ejemplo, para medir el retraso en toda la red del proveedor desde el sitio A hasta el sitio B, los puntos de medición deben ser el punto de entrada a la red del proveedor en el sitio A y el punto de salida en el sitio B.

• Las mediciones centradas en el enrutador se toman directamente de los propios enrutadores, pero tenga cuidado de asegurarse de que los subcomponentes correctos del enrutador se hayan identificado de antemano.

Figura 2: Puntos de entrada a la red

Indicadores clave básicos de rendimiento

Por ejemplo, podría supervisar una red de proveedores de servicios en busca de tres indicadores clave de rendimiento (KPI) básicos:

• mide la "accesibilidad" de un punto de medición desde otro punto de medición en la capa de red (por ejemplo, utilizando ping ICMP). La infraestructura subyacente de enrutamiento y transporte de la red de proveedores admitirá las mediciones de disponibilidad, y las fallas se destacarán como indisponibilidad.

• Mide el número y el tipo de errores que se producen en la red del proveedor, y puede consistir en mediciones centradas tanto en el enrutador como en la red, como fallas de hardware o pérdida de paquetes.

• de la red de proveedores mide en qué medida puede soportar los servicios de IP (por ejemplo, en términos de retraso o utilización).

Configuración de líneas base

¿Qué tan bien está funcionando la red de proveedores? Recomendamos un período inicial de monitoreo de tres meses para identificar los parámetros operativos normales de una red. Con esta información, puede reconocer excepciones e identificar comportamientos anormales. Debe continuar con el monitoreo de línea base durante la vida útil de cada métrica medida. Con el tiempo, debe ser capaz de reconocer las tendencias de rendimiento y los patrones de crecimiento.

En el contexto de este capítulo, muchas de las métricas identificadas no tienen un rango operativo permitido asociado. En la mayoría de los casos, no se puede identificar el rango operativo permitido hasta que se haya determinado una línea base para la variable real en una red específica.

Definir la disponibilidad de la red

La disponibilidad de la red IP de un proveedor de servicios puede considerarse como la accesibilidad entre los puntos de presencia regionales (POP), como se muestra en Figura 3.

Figura 3: Puntos de presencia regionales

Con el ejemplo anterior, cuando se utiliza una malla completa de puntos de medición, donde cada POP mide la disponibilidad de cada otro POP, se puede calcular la disponibilidad total de la red del proveedor de servicios. Este KPI también se puede usar para ayudar a monitorear el nivel de servicio de la red, y puede ser utilizado por el proveedor de servicios y sus clientes para determinar si están operando dentro de los términos de su acuerdo de nivel de servicio (SLA).

Cuando un POP pueda constar de varios enrutadores, tome medidas en cada enrutador como se muestra en Figura 4.

Figura 4: Mediciones a cada enrutador

Las mediciones incluyen:

• Disponibilidad de ruta: disponibilidad de una interfaz de salida B1 vista desde una interfaz de entrada A1.

• Disponibilidad del enrutador: porcentaje de disponibilidad de rutas de todas las rutas medidas que terminan en el enrutador.

• Disponibilidad de COP: porcentaje de disponibilidad del enrutador entre dos POP regionales, A y B.

• Disponibilidad de red: porcentaje de disponibilidad de POP para todos los POP regionales de la red del proveedor de servicios.

Para medir la disponibilidad de POP de POP A a POP B en Figura 4, debe medir las cuatro rutas siguientes:

La medición de la disponibilidad de COP B a COP A requeriría otras cuatro mediciones, y así sucesivamente.

Una malla completa de mediciones de disponibilidad puede generar un tráfico de administración significativo. Del diagrama de ejemplo anterior:

• Cada POP tiene dos enrutadores perimetrales de proveedor (PE) coubicados, cada uno con interfaces 2xSTM1, para un total de 18 enrutadores PE y 36xSTM1 interfaces.

• Hay seis enrutadores de proveedor principal (P), cuatro con interfaces 2xSTM4 y 3xSTM1 cada uno, y dos con interfaces 3xSTM4 y 3xSTM1 cada uno.

Esto hace un total de 68 interfaces. Una malla completa de rutas entre cada interfaz es:

[n x (n–l)] / 2 da [68 x (68–1)] / 2=2278 rutas

Para reducir el tráfico de administración en la red del proveedor de servicios, en lugar de generar una malla completa de pruebas de disponibilidad de interfaz (por ejemplo, de cada interfaz a cualquier otra interfaz), puede medir a partir de la dirección de circuito cerrado de cada enrutador. Esto reduce el número de mediciones de disponibilidad necesarias a un total de una para cada enrutador o:

n[ x (n–1)] / 2 da [24 x (24–1)] / 2=276 mediciones

Esto mide la disponibilidad de cada enrutador a todos los demás.

Mida la disponibilidad

Hay dos métodos que puede utilizar para medir la disponibilidad:

• Proactivo: la disponibilidad se mide automáticamente con la mayor frecuencia posible mediante un sistema de soporte operativo.

• Reactivo: la disponibilidad es registrada por un servicio de asistencia cuando un usuario o un sistema de monitoreo de fallas reportan por primera vez una falla.

En esta sección se describe la supervisión del rendimiento en tiempo real como una solución de supervisión proactiva.

Medir la clase de servicio

Puede usar mecanismos de clase de servicio (CoS) para regular cómo se manejan ciertas clases de paquetes dentro de su red durante los momentos de máxima congestión. Normalmente, debe realizar los pasos siguientes al implementar un mecanismo de CoS:

• Identifique el tipo de paquetes que se aplica a esta clase. Por ejemplo, incluya todo el tráfico del cliente desde una interfaz de borde de entrada específica dentro de una clase, o incluya todos los paquetes de un protocolo determinado, como voz sobre IP (VoIP).

• Identificar el comportamiento determinista requerido para cada clase. Por ejemplo, si VoIP es importante, otorgue al tráfico VoIP la máxima prioridad durante los momentos de congestión de la red. Por el contrario, puede degradar la importancia del tráfico web durante la congestión, ya que puede no afectar demasiado a los clientes.

Con esta información, puede configurar mecanismos en la entrada de red para supervisar, marcar y controlar las clases de tráfico. El tráfico marcado se puede manejar de una manera más determinista en las interfaces de salida, normalmente aplicando diferentes mecanismos de cola para cada clase durante los momentos de congestión de la red. Puede recopilar información de la red para proporcionar a los clientes informes que muestren cómo se comporta la red en tiempos de congestión. (Consulte Figura 5.)

Figura 5: Comportamiento de la red durante la congestión

Para generar estos informes, los enrutadores deben proporcionar la siguiente información:

• Tráfico enviado: cantidad de tráfico recibido por clase.

• Tráfico entregado: cantidad de tráfico transmitido por clase.

• Tráfico perdido: cantidad de tráfico eliminado debido a los límites de CoS.

La siguiente sección describe cómo los enrutadores de Juniper Networks proporcionan esta información.

Contadores de filtro de firewall entrantes por clase

Los contadores de filtros de firewall son un mecanismo muy flexible que puede usar para hacer coincidir y contar el tráfico entrante por clase e interfaz. Por ejemplo:

Por ejemplo, Tabla 8 muestra los filtros adicionales utilizados para que coincidan con las otras clases.

Cualquier paquete con un punto de código CoS DiffServ (DSCP) conforme a RFC 2474 se puede contar de esta manera. La MIB del filtro de firewall específico para empresa de Juniper Networks presenta la información del contador en las variables que se muestran en Tabla 9.

Esta información puede ser recopilada por cualquier aplicación de administración SNMP que admita SNMPv2. Los productos de proveedores como Concord Communications, Inc. e InfoVista, Inc., proporcionan compatibilidad con la MIB del firewall de Juniper Networks con sus controladores de dispositivo nativos de Juniper Networks.

Supervisar bytes de salida por cola

Puede usar la MIB CoS ATM empresarial de Juniper Networks para supervisar el tráfico saliente, por clase de reenvío de circuito virtual, por interfaz. (Consulte Tabla 10.)

Los contadores de interfaz que no son ATM son proporcionados por la MIB de CoS específica para la empresa de Juniper Networks, que proporciona la información que se muestra en Tabla 11.

Calcular el tráfico perdido

Puede calcular la cantidad de tráfico perdido restando el tráfico saliente del tráfico entrante:

También puede seleccionar contadores de la MIB de CoS, como se muestra en Tabla 12.