Gazelle S2026i, un switch industrial a precio de comercial

El Gazelle S2026i es un switch industrial con 24 puertos 10/100BaseTX y 4 uplinks Gigabit (2 combo) con rango extendido de temperatura y diseñado para cumplir con los estándares IEC 61850-2, IEEE 1613 y EN 50121 con prestaciones Carrier Ethernet y un precio muy competitivo.

El Gazelle S2026i es un switch de nivel 2 para montaje en rack 19” gestionable y de rango industrial especialmente diseñado para aplicaciones smart grid (IEC 61850-3, IEEE 1613), transporte (EN50121-4), energia y automatización industrial. Soporta hasta 4 upllinks GE (2 combo y 2 SFP) y 24 downlinks FE 10/100BaeTX. Asimismo dispone de protocolos de redundancia LACP y de anillo G.8032 ERPS (tiempo de recuperación <50ms). Existen versiones con alimentación24/48 VDC o 110/220 VDC/VAC.
 
S2026i - Gazelle S2026i, un switch industrial a precio de comercial

Datasheet S2026i

VRRP – Virtual Router Redundancy Protocol – Los Miércoles de Tecnología

VRRP te permite configurar dos o más routers o gateways de salida de tu red en modo redundante. Uno principal y los otros de reserva. La conmutación en caso de fallo se realiza de forma automática y totalmente transparente de cara a todos los equipos de la red.

Toda red Ethernet que deba conectarse a Internet o a otra red en un direccionamiento IP distinto debe hacerlo a través de un router o Gateway de salida. En la mayoría de casos, los nodos de dicha red obtienen la dirección IP de este gateway a través del protocolo DHP o bien configurándolo manualmente. En ambos casos, si el router de salida sufre un fallo y no está disponible ningún nodo de la red puede comunicar con el exterior produciéndose un fallo que afecta a toda la red.

Para evitar esto, se ideó el protocolo VRRP (Virtual Router Redundancy Protocol) que en pocas palabras permite definir dos o más routers en nuestra red en modo redundante, es decir, uno funcionando y el resto en reserva o backup. Cuando un router falla otro toma el control.

Virtual IP y virtual group

Veamos cómo funciona VRRP a través del siguiente ejemplo.

vrrp from cisco - VRRP - Virtual Router Redundancy Protocol - Los Miércoles de TecnologíaImagen cortesía de Cisco

Tenemos tres routers de salida en nuestra red: A, B y C. Para no entrar en conflicto tienen direcciones IP diferentes: 10.0.0.1, 10.0.0.2 y 10.0.0.3 respectivamente. Definimos además la IP virtual del grupo que en nuestro caso es 10.0.0.4 y que será el gateway de salida de nuestra red. Únicamente el router que actúe como master mostrará esta IP virtual hacia la red actuando realmente como gateway de salida de dicha red.

También definiremos otros dos parámetros en todos los routers:

  • Virtual group: nos permite asociar varios routers a un mismo grupo VRRP redundante. Podemos tener varios grupos virtuales en la misma red.
  • Prioridad: valor entre 0 y 255. En igualdad de condiciones, el router con mayor prioridad actuará como master. En caso de empate de prioridades el master se decide a través de una combinación lógica con la dirección MAC de cada router para evitar igualdades.

¿ Cómo funciona VRRP?

Los routers pertenecientes a un mismo grupo virtual se intercambian mensajes del protocolo, típicamente cada segundo. A través de estos mensajes el router master puede notificar al resto que ha perdido la conexión al exterior y por tanto no puede seguir como master o bien los routers en backup pueden determinar que el master ha caído si no reciben respuestas o mensajes de éste y tomar el control.

Una vez se determina la necesidad de conmutación, el router en backup con mayor prioridad tomará el papel de nuevo master. A partir de este momento presentará la IP virtual a la red (10.0.0.4 en nuestro ejemplo).

La gran ventaja de VRRP es que es totalmente transparente a los nodos y equipos de la red. Veamos por qué. Cuando un equipo envíe un paquete a la dirección MAC que tenía antes asociada a la IP de salida en el router A en su tabla de direcciones no obtendrá respuesta. Por tanto, enviará una petición ARP para descubrirla de nuevo y en este momento el router B que supongamos ha tomado el papel de master le devolverá la dirección MAC de su interfaz de conexión a la red local. A partir de este momento. este equipo de red ya cursará todo el tráfico a otras redes a través del nuevo gateway.

¿ Cómo configurar VRRP en los routers de Teltonika?

La familia de routers RUT9XX y RUT2XX de Teltonika soportan el protocolo VRRP.

Simplemente tendremos que activarlo y configurar los siguientes parámetros:

  • IP address: es la dirección virtual IP del grupo VRRP que tendremos que definir como gateway de salida en los equipos de red. Si el router actúa como servidor DHCP y tiene el protocolo VRRP activado ya notificará esta IP como gateway de salida a los diferentes clientes DHCP
  • Virtual ID: identificador del grupo VRRP. Debe ser el mismo en todos los routers del grupo
  • Priority: recordemos que el router con mayor número será el master

Además deberemos configurar la verificación de la conexión a Internet de cara a que un router sin conexión deje de ser maestro o vuelva a tomar el papel de maestro si recupera la conexión. Para ello configuraremos una IP pública a la que hacer ping y el número de reintentos y timeout de respuesta.

vrrp teltonika - VRRP - Virtual Router Redundancy Protocol - Los Miércoles de Tecnología

 

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

Inscripción

NT1003 - NetTESTER

Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

Gama Aquam 81XX (L2) y 86XX (L3) de switches embarcados EN510155 con soporte de las últimas funcionalidades específicas para el sector ferroviario según el estándar IEC61375

Nuestro partner Kyland Technology dispone de una amplia gama de switches industriales para ser insalados a bordo de trenes y otros convoyes.

Hoy te queremos presentar la gama Aquam86XX de nivel 3 o Aquam81XX de nivel 2 en sus versiones de 8+4G, 16+4G y 24+4G puertos

Aquam8612-8112

Aquam8620 8120 300x232 - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

Aquam = Robusto

Protección IP65 con carcasa de aluminido a prueba de humedad y polvo.
Conectores M12 que aseguran la firmeza y sujección ante vibraciones.
Sistema pionero de disipación de calor para evitar sobrecalentamientos aún con la máxima potencia entregada a través de los puertos PoE/PoE+.

EN50155 / EN50121 /EN45545

Alta densidad de puertos

Hasta 24+4G puertos con conectores M12. Puerto de consola, contactos de alarma y alimentación también con conectores M12.

M12 connectors - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

Máxima potencia PoE+ de 240W

Posibilidad PoE y PoE+ en todos los puertos 100M.120W disponibles a través de la fuente de alimentación interna del equipo con rango de entrada 24-120Vdc (booster). Y también 120W adicionales si conectamos una fuente exterior adicional al switch.

poe 1024x559 - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

Gigabit hardware bypass

En una topología lineal como la que tenemos en un tren el fallo de uno de los dispositivos intermedios puede bloquear la comunicación entre sí de los equipos a ambos lados del dispositivo averiado.
Para evitarlo, los switches Aquam disponen de un mecanismo de bypass mecánico que da continuidad a la señal Gigabit Ethernet en caso de fallo de un equipo. De esta forma, sólo los terminales conectados a este equipo se verán afectados.

bypass train - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

TTDT:Train Topology Discovery Protocol

Debido al hecho de que la topología de la red en el tren puede variar en el acoplamiento y desacoplamiento de diferentes vagones. la norma IEC61375 define el protoloc TTDT (Train Topololoy Discovery Protocol) que permite la reconfiguración automática de los equipos de cara a simular siempre la misma topología.

TTDP train - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

R-NAT:Railway-Network Adress Translation

IEC61735 también define esta funcionalidad de cara a mantener una misma configuración en los dispositivos terminales conectados al switch en cada vagón. Con R-NAT los switches realizan una traslación de direcciones entre las IPs duplicadas de los terminales y las IPs únicas de los switches en los diferentes vagones.

R-NAT, Railway-Network Address Translation

Redundancia llevada al extremo

En un entorno tan crítico como el ferroviario, la gama Aquam soporta topo tipo de redundancias incluyendo:
• VRRP (Virtual Router Redundancy Protocol)
• RSTP (Rapid Spanning Tree Protocol)
• DRP (Distributed Redundancy Protocol IEC62439-6) con recuperación < 20ms
• MRP (Media Redundancy Protocol IEC62439-2)
• Link Agreggation (LACP, IEEEE802.3ad)

ring train - Nueva gama de switches embarcados IEC61375 (TTDP, R-NAT y bypass)

Puedes ampliar información en la página web de Kyland.

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.

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.

latency - Medidas de monitorización de circuitos Ethernet - Y.1731 vs TWAMPPara 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.

Y1731 architecture - Medidas de monitorización de circuitos Ethernet - Y.1731 vs TWAMPLos 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.