Grabación del webinar sobre medidas de activación del servicio Ethernet (RF2544 y Y.1561) y monitorización (Y.1731 y TWAMP lite) …
La entrada Grabación del webinar sobre medidas en circuitos Ethernet se publicó primero en Blog DAVANTEL.
Mostrando entradas con la etiqueta Twamp Lite. Mostrar todas las entradas
Mostrando entradas con la etiqueta Twamp Lite. Mostrar todas las entradas
jueves, 7 de febrero de 2019
lunes, 19 de marzo de 2018
Webinar Gratuito - Quieres saber cómo medir los SLA en tus enlaces Ethernet o cómo lanzar una RFC2544 sin un costoso equipo de medida?
• Como puedo lanzar una medida RFC2544 para activación del servicio sin equipos de test Ethernet costosos y difíciles de manejar?
• Ha provisionado mi enlace mi provedor de servicios de acuerdo a mis requerimientos?
• Con qué frecuencia estamos experimentando...
• Como puedo lanzar una medida RFC2544 para activación del servicio sin equipos de test Ethernet costosos y difíciles de manejar?
• Ha provisionado mi enlace mi provedor de servicios de acuerdo a mis requerimientos?
• Con qué frecuencia estamos experimentando problemas en la red o qué porcentaje del tiempo la red está simplemente caída?
• Los parámetros de latencia y variación (jitter) de la misma están dentro de los permitidos para mi servicio de telefonía sobre IP?
• Si implantamos un nuevo servicio de video conferencia entre nuestras sedes, como impactará esto en el resto de servicios que corren actualmente sobre la misma red?
• Varía el rendimiento de nuestra red a lo largo del día o del mes o por el contrario permanece inalterado?
Si quieres respuestas a estas preguntas puedes apuntarte a nuestro webinar gratuito donde te explicaremos:
• las diferencias entre las medidas de puesta en servicio RFC2544 e Y.1564
• el funcionamiento de los equipos NetTESTER para realizar medidas 'en servicio' según Y.1731 y TWAMP
También te explicaremos como lanzar una medida RFC2544 desde el equipo NetTESTER contra cualquier otro medidor en bucle y guardar la medida en formato de texto.
• Ha provisionado mi enlace mi provedor de servicios de acuerdo a mis requerimientos?
• Con qué frecuencia estamos experimentando...
• Como puedo lanzar una medida RFC2544 para activación del servicio sin equipos de test Ethernet costosos y difíciles de manejar?
• Ha provisionado mi enlace mi provedor de servicios de acuerdo a mis requerimientos?
• Con qué frecuencia estamos experimentando problemas en la red o qué porcentaje del tiempo la red está simplemente caída?
• Los parámetros de latencia y variación (jitter) de la misma están dentro de los permitidos para mi servicio de telefonía sobre IP?
• Si implantamos un nuevo servicio de video conferencia entre nuestras sedes, como impactará esto en el resto de servicios que corren actualmente sobre la misma red?
• Varía el rendimiento de nuestra red a lo largo del día o del mes o por el contrario permanece inalterado?
Si quieres respuestas a estas preguntas puedes apuntarte a nuestro webinar gratuito donde te explicaremos:
• las diferencias entre las medidas de puesta en servicio RFC2544 e Y.1564
• el funcionamiento de los equipos NetTESTER para realizar medidas 'en servicio' según Y.1731 y TWAMP
También te explicaremos como lanzar una medida RFC2544 desde el equipo NetTESTER contra cualquier otro medidor en bucle y guardar la medida en formato de texto.
Fecha y hora: Miércoles, 21 de Marzo a las 16:00
Duración aprox: 30 min.
Duración aprox: 30 min.
miércoles, 14 de marzo de 2018
Medidas de monitorización de circuitos Ethernet - Y.1731 vs TWAMP
Y.1731 y TWAMP-lite son dos conjuntos de medida que nos permiten monitorizar en tiempo real nuestro servicio Ethernet y compararlo con unos indicadores (KPI) asimilables a nuestro nivel de servicio (SLA) para así detectar su incumplimiento.
Si en el anterior post vimos las medidas de activación del servicio RFC2544 e Y.1564 en el de hoy veremos las medidas de monitorización de dichos circuitos según Y.1731 y TWAMP.
Lo primero que debemos tener claro es que las medidas de activación eran intrusivas ya que inyectaban tráfico o bien a la máxima velocidad del interfaz (RFC2544) o bien a la máxima velocidad comprometida del circuitos (CIR en Y.1564) y por tanto no pueden coexistir con el tráfico de usuario. Sin embargo, las medidas de monitorización NO deben ser intrusivas y deben permitir medir de forma constante en el tiempo la calidad de dicho servicio sin influir en el rendimiento del tráfico de usuario.
Toda medida debe monitorizar unos indicadores (KPIs 0 Key Performance Indicators) en relación a un nivel de servicio acordado (SLA). Para los servicios Ethernet, este SLA se basa en los siguientes indicadores:
El SLA se definirá como el valor máximo permisible para estos indicadores dentro de un período de tiempo (típicamente 24h o incluso días o semanas). En este punto cabe destacar que un problema puntual y muy definido en el tiempo en nuestra red puede hacernos cumplir el SLA una vez promediado en un intervalo grande de tiempo. Por ello, el SLA no será siempre un buen indicador de las anomalías puntuales de la red.
TWAMP define medidas entre dos puntos de la red que se identifican a través de su dirección IP. Un extremo (generador) origina la medida inyectando los paquetes y el otro extremo actúa como reflector, devolviendo los paquetes al origen. Los paquetes TWAMP se envían típicamente 1 por segundo ( 1 pps) y se encapsulan en un puerto UDP (evitando así las retransmisiones y reconocimientos de TCP). El extremo reflector básicamente cambia direcciones origen y destino para retornar el paquete.
Para las medidas de latencia y jitter, los paquetes TWAMP se marcan en tiempo al ser enviados y recibidos tanto en el extremo local (generador) como en extremo remoto (reflector).
El jitter se mide como la diferencia en el RTD entre un paquete y el siguiente. Para algunos tráficos como VoIP es más importante tener un retardo constante aunque alto que no variable, es decir, un jitter elevado.
El packet loss (o FLR) se mide únicamente sobre los paquetes TWAMP y por tanto no representa una medida fiel de la pérdida de paquetes en la red.
A diferencia de TWAMP, las medidas Y.1731 se realizan a nivel 2, es decir, directamente sobre tramas Ethernet y por tanto sólo pueden realizarse en redes de nivel 2 extremo a extremo (no ruteadas).
Y.1731 define una compleja arquitectura para permitir realizar medidas extremo a extremo (end-to-end) con posibilidad de interconexión de diferentes redes y proveedores de servicio.
Los principales elementos de esta arquitectura son:
La normativa Y.1731 define una métrica para FDV y para IFDV pero dos métricas diferentes para FLR. Estas métricas se basan en los siguientes tipos de mensajes/paquetes:
Estos mensajes se usan para mantener una tabla de estado de todos los puntos o MEP de la arquitectura Y.1731 y poder dar un primer nivel de alarma en caso de fallo de alguno de ellos
Los MEP intercambian mensajes CCM Multicast (1 pps típicamente). Si un MEP para de transmitir mensajes CCM los otros MEPs envían una alarma
El mensaje incluye el estado de los puertos locales del MEP facilitando la localización exacta del fallo.
Estos paquetes se usan para medir latencia (FDV) y jitter (IFDV). Un extremo envía un paquete DDM (típicamente 1 pps) con marca de tiempo en tx y rx. El extremo remoto envía un paquete de respuesta DMR que incluye las marcas originales del DDM y le añade las nuevas locales. A través de la resta de estas marcas, se obtiene el RTD igual que en TWAMP.
Puesto que los paquetes se envían entre un extremo y otro son de tipo Unicasts entre dos MEP concretos de la red. En aplicaciones multipunto deberemos definir tantas sesiones MEP - MEP como extremos remotos queramos medir.
Estos paquetes se usan para medir frame loss ration (FLR).
El paquete LMM se marca con el contador de paquetes transmitidos del EVC (Ethernet Virtual Circuit) en transmisión y con el contador de paquetes recibidos en recepción.
La respuesta LMR se marca con los contadores en el sentido inverso. Comparando estas marcas en ambos extremos podemos calcular el FLR (Frame Loss Ratio) sobre TODO EL TRAFICO DEL EVC y no sólo sobre los paquetes LMM/LMR.
Al igual que en el caso anterior, esta medida sólo funciona en conexiones punto a punto ya que debemos medir todos los paquetes de usuario y del protocolo entre ambos extremos.
De forma similar a la medida FLR en TWAMP, estos paquetes se usan para estimar la FLR y se envían a un ritmo de 1 pps.
El paquete SMM se marca con un número de secuencia autoincrementado
La respuesta SMR también se marca con un número de secuencia en el sentido opuesto
Por tanto, la pérdida o salto de un número de secuencia implica FL (pérdida de paquete) en los paquetes SM. A modo de ejemplo, un SM FLR de 0,01% implica un paquete perdido de 10000 = 10000 seg (2,7h). Por tanto los SLA basados en SMM/SMR deben procesarse en períodos de 24h o 30 días para tener validez.
Si en el anterior post vimos las medidas de activación del servicio RFC2544 e Y.1564 en el de hoy veremos las medidas de monitorización de dichos circuitos según Y.1731 y TWAMP.
Lo primero que debemos tener claro es que las medidas de activación eran intrusivas ya que inyectaban tráfico o bien a la máxima velocidad del interfaz (RFC2544) o bien a la máxima velocidad comprometida del circuitos (CIR en Y.1564) y por tanto no pueden coexistir con el tráfico de usuario. Sin embargo, las medidas de monitorización NO deben ser intrusivas y deben permitir medir de forma constante en el tiempo la calidad de dicho servicio sin influir en el rendimiento del tráfico de usuario.
SLA (Service Level Agreement)
Toda medida debe monitorizar unos indicadores (KPIs 0 Key Performance Indicators) en relación a un nivel de servicio acordado (SLA). Para los servicios Ethernet, este SLA se basa en los siguientes indicadores:
- FLR - Frame Loss Ratio (TWAMP packet loss)
- FTD - Frame Transfer Delay (network transfer delay)
- IFDV - Interframe Delay Variation (jitter)
El SLA se definirá como el valor máximo permisible para estos indicadores dentro de un período de tiempo (típicamente 24h o incluso días o semanas). En este punto cabe destacar que un problema puntual y muy definido en el tiempo en nuestra red puede hacernos cumplir el SLA una vez promediado en un intervalo grande de tiempo. Por ello, el SLA no será siempre un buen indicador de las anomalías puntuales de la red.
TWAMP (Two-Way Active Measurement Protocol)
TWAMP define medidas entre dos puntos de la red que se identifican a través de su dirección IP. Un extremo (generador) origina la medida inyectando los paquetes y el otro extremo actúa como reflector, devolviendo los paquetes al origen. Los paquetes TWAMP se envían típicamente 1 por segundo ( 1 pps) y se encapsulan en un puerto UDP (evitando así las retransmisiones y reconocimientos de TCP). El extremo reflector básicamente cambia direcciones origen y destino para retornar el paquete.
Para las medidas de latencia y jitter, los paquetes TWAMP se marcan en tiempo al ser enviados y recibidos tanto en el extremo local (generador) como en extremo remoto (reflector).
Tiempo de proceso del paquete en el reflector = T_tx2 – T_rx1 (se resta del total)
RTD = T_rx2- T_Tx1 - (T_tx2 - T_rx1)
El jitter se mide como la diferencia en el RTD entre un paquete y el siguiente. Para algunos tráficos como VoIP es más importante tener un retardo constante aunque alto que no variable, es decir, un jitter elevado.
El packet loss (o FLR) se mide únicamente sobre los paquetes TWAMP y por tanto no representa una medida fiel de la pérdida de paquetes en la red.
Y.1731
A diferencia de TWAMP, las medidas Y.1731 se realizan a nivel 2, es decir, directamente sobre tramas Ethernet y por tanto sólo pueden realizarse en redes de nivel 2 extremo a extremo (no ruteadas).
Y.1731 define una compleja arquitectura para permitir realizar medidas extremo a extremo (end-to-end) con posibilidad de interconexión de diferentes redes y proveedores de servicio.
Los principales elementos de esta arquitectura son:- MEG - Maintenance Entity Group – Grupo de MEs
- ME - Maintenance Entity – Agrupa los MEPs que terminan las conexiones
- MEP - Maintenance End Point – Dos para punto a punto o varios para punto-mutipunto
La normativa Y.1731 define una métrica para FDV y para IFDV pero dos métricas diferentes para FLR. Estas métricas se basan en los siguientes tipos de mensajes/paquetes:
CCM - Continuity Check Message
Estos mensajes se usan para mantener una tabla de estado de todos los puntos o MEP de la arquitectura Y.1731 y poder dar un primer nivel de alarma en caso de fallo de alguno de ellos
Los MEP intercambian mensajes CCM Multicast (1 pps típicamente). Si un MEP para de transmitir mensajes CCM los otros MEPs envían una alarma
El mensaje incluye el estado de los puertos locales del MEP facilitando la localización exacta del fallo.
DMM/DMR - Delay Measurement Message/Reply
Estos paquetes se usan para medir latencia (FDV) y jitter (IFDV). Un extremo envía un paquete DDM (típicamente 1 pps) con marca de tiempo en tx y rx. El extremo remoto envía un paquete de respuesta DMR que incluye las marcas originales del DDM y le añade las nuevas locales. A través de la resta de estas marcas, se obtiene el RTD igual que en TWAMP.
Puesto que los paquetes se envían entre un extremo y otro son de tipo Unicasts entre dos MEP concretos de la red. En aplicaciones multipunto deberemos definir tantas sesiones MEP - MEP como extremos remotos queramos medir.
LMM/LMR – Loss Measurment Message/Reply
Estos paquetes se usan para medir frame loss ration (FLR).
El paquete LMM se marca con el contador de paquetes transmitidos del EVC (Ethernet Virtual Circuit) en transmisión y con el contador de paquetes recibidos en recepción.
La respuesta LMR se marca con los contadores en el sentido inverso. Comparando estas marcas en ambos extremos podemos calcular el FLR (Frame Loss Ratio) sobre TODO EL TRAFICO DEL EVC y no sólo sobre los paquetes LMM/LMR.
Al igual que en el caso anterior, esta medida sólo funciona en conexiones punto a punto ya que debemos medir todos los paquetes de usuario y del protocolo entre ambos extremos.
SMM/SMR - Synthetic Loss Measurment Message/Reply
De forma similar a la medida FLR en TWAMP, estos paquetes se usan para estimar la FLR y se envían a un ritmo de 1 pps.
El paquete SMM se marca con un número de secuencia autoincrementado
La respuesta SMR también se marca con un número de secuencia en el sentido opuesto
Por tanto, la pérdida o salto de un número de secuencia implica FL (pérdida de paquete) en los paquetes SM. A modo de ejemplo, un SM FLR de 0,01% implica un paquete perdido de 10000 = 10000 seg (2,7h). Por tanto los SLA basados en SMM/SMR deben procesarse en períodos de 24h o 30 días para tener validez.
jueves, 1 de febrero de 2018
Raisecom monitoriza conexiones Premium a 10G en un ISP en Bélgica
Un ISP que provee conexiones Ethernet 10G Premium al sector financiero en Bélgica ha seleccionado el EDD RAX711-C de Raisecom para monitorizar dichas conexiones en términos de latencia, jitter y packet loss.
El punto de demarcación RAX711-C ofrece medidas de activación del servicio (SAT) y de monitorización de enlaces Ethernet a 1G y 10G según Y.1731 y Twamp Lite.
En esta aplicación, este dispositivo se conecta en paralelo a una señal Ethernet 10G óptica a través de un splitter y permite inyectar y recibir tráfico CFM para poder monitorizar el servicio a nivel de latencia, jitter y packet loss.
Dichas medidas pueden consultarse a través de la interfaz gráfica proporcionada por la aplicación web SLA Portal.
Puedes ampliar la información en la web de Raisecom.
El punto de demarcación RAX711-C ofrece medidas de activación del servicio (SAT) y de monitorización de enlaces Ethernet a 1G y 10G según Y.1731 y Twamp Lite.
En esta aplicación, este dispositivo se conecta en paralelo a una señal Ethernet 10G óptica a través de un splitter y permite inyectar y recibir tráfico CFM para poder monitorizar el servicio a nivel de latencia, jitter y packet loss.
Dichas medidas pueden consultarse a través de la interfaz gráfica proporcionada por la aplicación web SLA Portal.
Puedes ampliar la información en la web de Raisecom.
lunes, 29 de enero de 2018
Un completo medidor Gigabit Ethernet por menos de 500,00 EUR
Hoy te queremos presentar el NT1003 que es un equipo de demarcación Ethernet que puede usarse como un medidor sobre cobre o fibra a velocidades Gigabit Ethernet y también como equipo para monitorizar la calidad de tus enlaces Ethernet una vez en servicio.
NT1003 Network Tester
2 ports 10/100/1000BaseT
1 port 100BaseFX/1000BaseX (SFP)
Alimentación AC / DC
Medidas de activación del servicio (SAM o Service Activation Measurements)
El NT1003 permite realizar medidas según las normas RFC2544 o Y.1564 sobre redes de nivel 2 o incluso redes ruteadas de nivel 3. Con él podrás realizar las mediciones necesarias para la activación de tu servicio Ethernet.
Para ello colocaremos un equipo en un extremo como generador de tráfico y otro como reflector en el extremo remoto del enlace a medir, devolviendo el tráfico recibido del generador y pudiendo medir así paquetes perdidos o retardos de la red de transporte.
En el extremo remoto no tendremos que hacer absolutamente nada ya que el equipo viene configurador de fábrica como reflector. En el extremo generador, la configuración y realización de las pruebas puede llevarse a cabo de forma sencilla a través de comandos por consola o Telnet o incluso de forma gráfica e intuitiva a través del servidor web integrado en el equipo. Tras el primer servicio podemos guardar en el equipo todas las configuraciones de las medidas a realizar para recuperarlas, de forma rápida, en las siguientes puestas en servicio.
Asimismo, los resultados de las medidas de activación de servicio pueden presentarse por pantalla o exportarse a un fichero de texto para que puedas adjuntarlas a la documentación de alta del servicio.
Medidas de calidad de la red
El NT1003 también puede usarse como sonda dentro de tu red Ethernet a fin de poder monitorizar la calidad de la misma.
En esta configuración puedes colocar un equipo NT1003 en cada extremo del enlace a monitorizar o bien un equipo NT1005 como generador y hasta 16 equipos NT1003 como reflectores.
Podrás realizar medidas continuas dentro de tu red de acuerdo con las normas Y.1731 (nivel 2) o TWAMP-Lite (nivel 3). Estas medidas incluyen pérdidas de paquetes, retardo y latencia (variación del retardo). Además, podrás configurar un nivel de servicio (SLA o Service Level Agreement) y si las medidas exceden este SLA recibirás una alarma en forma de TRAP SNMP.
Puedes ampliar esta información en nuestra web
Suscribirse a:
Entradas (Atom)