El circuito estaba bien y la videollamada se cayó igual

La sucursal llamó a las once y cuarenta: la videollamada con el cliente se había cortado tres veces esa mañana. Abriste incidencia. Dos días después te la cerraron con la frase de siempre, que el circuito ha permanecido dentro de los parámetros contratados. Y tienes delante la gráfica de tu SD-WAN, con tres picos de pérdida clavados en esa franja. Nadie está mintiendo. Tu operador y tú estáis midiendo cosas distintas, y las diferencias están escritas en las normas que hay debajo de tu contrato.

Entre qué dos puntos

Las métricas de rendimiento de una red IP no son propiedades de «la red»: están definidas entre dos puntos de medida. El retardo de un solo sentido (RFC 7679) y la pérdida de un solo sentido (RFC 7680) se definen de un origen a un destino concretos. Cambia los dos puntos y cambia el número, sin que nadie haya falseado nada. En el plano Ethernet pasa lo mismo con Y.1731: el operador manda tramas de medida entre dos MEP que él configura —DMM para el retardo, LMM o SLM para la pérdida— y el resultado describe el tramo entre esas dos bocas.

Los puntos del operador son los bordes de su red: normalmente su equipo de acceso y la interfaz de entrega en tu sede. Lo que queda fuera de ese par —tu LAN, tu cortafuegos, el tránsito a internet más allá de la entrega, el SaaS del otro extremo— no está en el número y nunca pretendió estarlo. Tu SD-WAN mide otra cosa, igual de legítima: el túnel completo, del equipo de la sede al nodo de salida, incluyendo tramos que el operador no te vendió y no puede garantizar.

Durante cuánto tiempo

La recomendación ITU-T Y.1541 es la que fija objetivos de calidad para servicios sobre IP. Su clase 0, la exigente, la que corresponde a voz y vídeo en tiempo real, pide un retardo medio (IPTD) por debajo de 100 ms, una variación de retardo (IPDV) por debajo de 50 ms y una tasa de pérdida (IPLR) por debajo de 1·10⁻³, es decir un 0,1%. Sugiere un intervalo de evaluación de un minuto, exige que el intervalo quede registrado junto al valor observado y añade una frase que merece la pena leer despacio: cualquier minuto observado debería cumplir esos objetivos. Cualquiera. No la media de los del mes.

El IPDV, además, está definido como la cota superior del cuantil 1−10⁻³ del IPTD menos el IPTD mínimo. Traducido: un paquete de cada mil puede salirse y el objetivo se sigue cumpliendo, por definición. Es la forma correcta de describir estadísticamente una red, y aun así basta para que un técnico mire un informe conforme mientras tú oías la llamada cortarse.

Ahora mira tu contrato. En todos los de acceso que nos han pasado para revisar, lo que se compromete es un porcentaje de disponibilidad mensual. La clase medida por minuto se queda fuera. Son dos productos distintos y el segundo es mucho más barato de cumplir, porque un promedio de un mes absorbe episodios que un minuto no absorbe. La cuenta cabe en una tabla. Un mes de treinta días tiene 2.592.000 segundos:

Mira la fila del 99,9%, que es la más habitual en los contratos de acceso para empresa. Un corte de veinte segundos consume el 0,00077% del mes. Dentro de ese 99,9% caben 129 de esos cortes: más de cuatro al día, todos los días del mes. Si caen en horario de oficina y encima de las llamadas, la sucursal ha tenido un mes infernal, el informe mensual sale en verde y las dos cosas son verdad a la vez. El porcentaje está midiendo otra cosa.

A eso se le suelen añadir dos filtros más, y esto lo decimos como lectura de los contratos que nos pasan, no como estadística del sector: una duración mínima por debajo de la cual un evento no cuenta, y un reloj que arranca cuando tú abres el ticket y no cuando empieza el problema. Ve a tu contrato y busca esas dos cláusulas. Están casi siempre, y entre las dos se comen la mayoría de los episodios que de verdad molestan a la gente.

En qué cola viaja la sonda

Para medir de forma continua, muchos operadores usan TWAMP, el protocolo de medida activa de dos sentidos descrito en el RFC 5357. En TWAMP una sesión de prueba lleva un DSCP, y el RFC usa un MUST: el reflector tiene que emplear ese mismo DSCP en los paquetes que devuelve. La medida es, por diseño, por clase de tráfico. Y eso está bien, porque es exactamente lo que hace falta para verificar una clase de servicio contratada.

El problema empieza cuando la clase de la sonda y la clase de tu tráfico no coinciden. En la entrega, el remarcado de DSCP es rutina: lo que salió de tu equipo marcado como EF puede entrar en la red del operador como mejor esfuerzo si el mapeo no se acordó por escrito. La sonda informa entonces, con toda la verdad del mundo, de una cola vacía, mientras tu vídeo espera en otra que está llena. Nadie ha hecho trampa; se está leyendo una medida de una clase como si fuera una afirmación sobre todo lo que pasa por el cable.

Queda el muestreo. Una sonda activa no mira de forma continua: manda ráfagas de paquetes con una cadencia que se configura, y entre ráfaga y ráfaga no está mirando nada. Nuestra propia instalación de SmokePing, por poner el número que sí podemos poner, va por defecto a veinte pings cada cinco minutos. Con esa cadencia, una cola que se llena durante ochocientos milisegundos puede no coincidir con ninguna muestra. A nadie le han engañado: no había nadie mirando en ese instante. Antes de citar una sonda en una reclamación, averigua cada cuánto mide.

La prueba de alta certifica el día del alta

Cuando se dio de alta el circuito te mandaron un PDF con gráficas y un sello de «conforme». Lo más probable es que fuera una prueba Y.1564, la metodología de activación de servicios Ethernet de la ITU-T. Son dos fases. La primera verifica la configuración subiendo el tráfico por escalones al 25, 50, 75 y 100% del caudal comprometido, luego al caudal en exceso y luego por encima, para comprobar que el limitador se comporta como dice el contrato. La segunda mantiene el 100% del caudal comprometido y mide pérdida, retardo, variación y disponibilidad. Los tres periodos que la norma obliga a soportar son quince minutos, dos horas y veinticuatro horas: quince minutos para un servicio metropolitano sobre red que ya lleva tráfico, dos horas para larga distancia de un solo operador, veinticuatro para un servicio internacional que cruza varias redes.

Es una buena prueba y hace exactamente lo que promete: certificar el servicio en el momento de la activación. Pero fíjate en la escala. El caso más común, el metropolitano, se certifica con quince minutos de tráfico, y ese circuito lo vas a tener puesto cinco años. El PDF dice la verdad sobre aquel cuarto de hora. No dice nada del martes pasado a las once y cuarenta, y nunca pretendió decirlo. Sacarlo en una reclamación —en cualquiera de las dos direcciones, porque también lo sacamos nosotros cuando nos conviene— es pedirle a un documento algo que no contiene.

Tu SD-WAN tampoco tiene la verdad entera

Esta parte la escribimos siendo nosotros los que montamos SD-WAN, y la escribimos igual. Un argumento que solo se sostiene cuando lo defiende quien vende la caja vale poco. La telemetría de tu orquestador también es una sonda, con su cadencia, su tamaño de paquete y su clase, y tiene tres sesgos propios que conviene conocer antes de llevarla a una reunión.

• Mide el camino entero, no el circuito. Incluye la encapsulación del túnel y un tramo intermedio de internet que nadie te vendió con compromiso. Que ese camino esté mal no implica que el acceso esté mal, y si lo presentas como si lo implicara, el operador tiene razón al devolvértelo.
• Al actuar, modifica lo que estaba midiendo. En cuanto el equipo desvía el tráfico del camino que iba mal, ese camino deja de llevar carga y deja de parecer malo. La gráfica de después demuestra que el desvío funcionó, no que el circuito se haya curado. Son dos conclusiones distintas y es muy fácil cobrar la segunda sin haberla ganado.
• La prueba caduca antes que la reclamación. Comprueba cuánto tiempo guarda tu orquestador la serie a resolución de segundos antes de compactarla en medias. Si tu ventana de reclamación es de treinta días y el detalle muere a los siete, tu prueba se evaporó antes que la discusión. No te lo va a avisar nadie: está en la configuración de retención y hay que ir a mirarla.

Nada de esto quita valor a una SD-WAN bien puesta; dice para qué sirve y para qué no. Ya escribimos en julio cuándo compensa y cuándo sobra, y aquello sigue en pie: resuelve un problema concreto y sin ese problema es una capa más que mantener. Lo que añadimos hoy es que su telemetría, que es una de sus mejores razones de compra, necesita contexto para convertirse en prueba.

Siete líneas de anexo antes de firmar

Siete frases para escribir en el anexo técnico del contrato, o para preguntar por correo antes de firmar guardándose la respuesta. Cada una cierra una de las ambigüedades de arriba. Si el comercial no puede contestar seis de las siete, ya sabes algo útil.

• Entre qué dos puntos se mide, nombrados con la interfaz concreta y no con «la red del cliente». Si el punto de tu lado es el equipo del operador en tu sede, dilo así por escrito.
• Qué parámetro y contra qué norma: retardo, variación y pérdida con los valores exactos, citando Y.1541 o Y.1731 si es lo que aplica. Un «calidad garantizada» sin parámetro es decorativo.
• El intervalo de evaluación y si la cifra es media o percentil, y en el segundo caso cuál. La diferencia entre una media de cinco minutos y un percentil 95 de un minuto es la diferencia entre ver el episodio y no verlo.
• En qué clase viaja la sonda y qué marcado recibe tu tráfico en la entrega. Si vas a mandar vídeo marcado como EF, que esté escrito qué hace el operador con esa marca en su frontera.
• Qué cuenta como evento: duración mínima, y si el reloj arranca en la detección del operador o en la apertura de tu ticket. De todas las de esta lista, es la línea que más veces hemos visto decidir cómo acaba la discusión.
• Quién aporta prueba, en qué formato y cuánto tiempo la guarda cada parte. Si ellos conservan noventa días y tú siete, en la práctica la prueba la pone uno solo.
• Cuál es la compensación y qué no cubre. En los contratos que hemos revisado siempre ha sido un porcentaje de la cuota del mes. Está bien que exista y conviene decir en voz alta lo que ya sabes: no paga la reunión perdida. Si el servicio es crítico, el dinero se gasta mejor en un segundo camino que en negociar la penalización.

Desde los dos lados del teléfono

Nosotros estamos en una posición rara que aquí viene bien: somos operador con red propia —BGP, tránsito, peering y un looking glass público en lg.everywan.com— y a la vez llevamos servicios gestionados para empresas cuyos circuitos ha vendido otro. Hemos escrito la reclamación y hemos escrito la respuesta. Con el sesgo por delante: nos conviene que contrates servicios gestionados, así que dalo por supuesto. Lo que sigue funciona exactamente igual si lo montas tú.

De todo esto salen dos costumbres que nos han ahorrado discusiones. La primera: guardar la dispersión y no solo la media. Usamos SmokePing precisamente porque conserva el reparto de cada ronda de sondas, así que un episodio de veinte segundos deja una marca visible que una media mensual borra sin dejar rastro; y Zabbix para los umbrales y para la alerta que de verdad despierta a alguien, que es un oficio aparte del que ya hemos hablado. La segunda: que el circuito tenga nombre. Mantenemos NetBox como fuente de verdad con su referencia, su interfaz de entrega y su responsable, porque una buena parte de las reclamaciones que se mueren se mueren en el primer correo, discutiendo de qué circuito estamos hablando.

Y una tercera, menos cómoda: hay averías que ningún anexo arregla, porque lo que decide el resultado es dónde se puede actuar. Lo contamos cuando hablamos de por qué un blackhole local no salva tu enlace de acceso: si el enlace ya está lleno cuando el tráfico llega a tu puerta, lo que hagas en tu puerta llega tarde. Saber de quién es cada tramo sirve para dos cosas, y reclamar es la menos importante; la otra es saber a quién hay que pedirle que actúe.

Lo que se compra de verdad

Un SLA de disponibilidad funciona como un seguro: devuelve parte de la cuota cuando el servicio falla mucho rato seguido. Tiene valor, está bien que exista y no hay nada turbio en él. Lo que no hace es describir cómo se comporta tu red el martes a las once y cuarenta, porque para eso haría falta medir otra cosa, en otro sitio y con otra ventana, y eso es precisamente lo que no se ha contratado.

Nos encontramos el mismo mecanismo en agosto con una incidencia de Microsoft 365: el buscador llevaba días roto y, leído contra las definiciones de Downtime del propio SLA, aquello no computaba como caída. Allí lo que mandaba era la definición de servicio; aquí mandan el punto y la ventana de medida. El fondo es el mismo: lo que un contrato considera un fallo lo decide el contrato, no el usuario al que se le ha cortado la llamada.

Nuestro eje de siempre dice que el fallo es inevitable y la avería es una decisión de diseño. La discusión con el operador, en cambio, no es inevitable en absoluto: es la consecuencia de que nadie escribiera, antes de firmar, qué quiere decir que esto funciona. Siete líneas, media página, y se escriben una sola vez.

Si estás montando o renegociando una WAN multisede, ese anexo vale más que una comparativa de precios: es lo que decide quién tiene razón dentro de ocho meses. Es el punto por donde empezamos cuando diseñamos una SD-WAN o cuando nos hacemos cargo de las redes y comunicaciones de una empresa, antes de tocar ninguna caja. Si quieres que le echemos un ojo a tu contrato actual y te digamos cuál de las siete líneas te falta, escríbenos.