Resumen

  • Un artículo técnico publicado por LINX el 10 de noviembre de 2020 acredita de forma conjunta a los ingenieros sénior de red Mo Shivji y Jan Kayser y al ingeniero de fiabilidad de sistemas Ariel Smutkochorn. Su relato enlaza las limitaciones de Quagga, una looking glass interna y los Cisco 7200 con la adopción de Alice LG y Birdwatcher, una prueba agregada que reveló más demanda de memoria y el traslado de casi todos los colectores a servidores de sitio basados en BIRD.
  • La evidencia permite describir a Kayser como uno de los autores y participantes nombrados en ese registro colectivo, no como dueño exclusivo de las decisiones. Documentos de NetUK3 fechados en julio de 2026 lo identifican con LINX, lo listan como Senior Network Engineer y le atribuyen la presentación «LON2 Network Refresh»; no prueban que él eligiera al proveedor ni que dirigiera por sí solo la renovación institucional de 17 emplazamientos.

El valor de un expediente técnico limitado

La información pública sobre Jan Kayser no sostiene una biografía total. No ofrece una cronología completa de puestos, una descripción de su vida privada ni una distribución individual de todas las tareas realizadas en LINX. Lo que sí ofrece es más útil para entender una infraestructura compartida: un informe fechado, firmado junto con dos colegas y suficientemente detallado para reconstruir por qué cambió un sistema de observabilidad.

LINX publicó «New LINX Route-Server Looking-Glass» el 10 de noviembre de 2020. Al final del texto atribuye la autoría a Mo Shivji, Jan Kayser y Ariel Smutkochorn. Los dos primeros aparecen como Senior Network Engineers y el tercero como Systems Reliability Engineer. Esa línea acredita a Kayser de manera directa, pero también impide presentar el trabajo como una iniciativa solitaria.

El informe no reparte entre los tres la selección de software, las pruebas, la configuración o las decisiones de hardware. Utiliza una voz colectiva y describe una intervención que atravesó varias disciplinas: BGP, servidores de rutas, colectores, automatización, capacidad de memoria, interfaces para miembros y mantenimiento de sistemas. La atribución rigurosa debe conservar esa estructura. Kayser está dentro del relato porque la fuente lo nombra; las acciones siguen perteneciendo al equipo y a LINX porque la fuente no las individualiza.

Este límite no convierte el perfil en una nota superficial. Al contrario, permite observar una forma de responsabilidad profesional frecuente en la infraestructura de Internet. Un ingeniero puede responder públicamente por una explicación técnica sin ser la única causa de un resultado distribuido. La calidad del expediente reside en hacer visibles las restricciones, las pruebas que no bastaron y las excepciones que sobrevivieron al cambio.

La observabilidad era una función operativa, no una página decorativa

Una looking glass permite examinar información de rutas desde otro sistema autónomo sin conceder acceso administrativo completo al router que la produce. Para investigar una anomalía de alcance o comparar lo que ve un punto remoto, un operador necesita consultar el estado BGP con un nivel de acceso controlado. LINX había proporcionado históricamente esa posibilidad mediante acceso Telnet de solo lectura a colectores y mediante interfaces web para colectores y servidores de rutas.

En ese contexto, la interfaz no era un añadido visual. Formaba parte de la capacidad de diagnóstico. Debía representar datos obtenidos del software de encaminamiento, distinguir funciones diferentes y mantenerse al ritmo de los cambios de protocolo. Una looking glass que sigue cargando pero ya no puede incorporar las funciones relevantes puede dar una impresión de continuidad que el sistema real no comparte.

El informe de 2020 presenta dos caminos heredados. En los servidores de rutas basados en Quagga, LINX utilizaba una looking glass desarrollada internamente en 2003. Con el tiempo, quedaban menos ingenieros familiarizados con ese código y las mejoras resultaban más difíciles. En los colectores Cisco, la interfaz mlrg ya no estaba en desarrollo activo. Un sistema sufría una concentración de conocimiento interno; el otro dependía de un proyecto externo detenido.

Ninguna de esas afirmaciones equivale a un incidente. LINX no comunica una brecha, una interrupción ni un daño a usuarios. El problema era de continuidad técnica: si el entorno de rutas cambia y la capa de observación no puede seguirlo, la herramienta pierde capacidad antes de desaparecer. La migración respondió a esa divergencia entre el estado de los instrumentos y las necesidades del servicio.

La mantenibilidad apareció como una variable de red

En infraestructura, la mantenibilidad suele tratarse como un asunto posterior al diseño. El caso de LINX muestra que puede determinar el diseño mismo. La looking glass interna había cumplido una función durante muchos años, pero la reducción del grupo capaz de modificarla convertía cada nueva necesidad en una dependencia más concentrada. mlrg, por su parte, no ofrecía una trayectoria activa de evolución.

La dificultad no se medía solo por la edad del código. Importaba la distancia entre ese código y las capacidades que LINX necesitaba observar: mejoras modernas de BGP, información vinculada a RPKI, acceso programático y una interfaz utilizable. Cuanto mayor fuera esa distancia, más trabajo exigiría mantener una representación fiable del sistema en marcha.

Esto permite leer la deuda técnica de una manera concreta. No es una etiqueta genérica para software antiguo. Es el coste creciente de cambiar, verificar y operar una pieza cuando el conocimiento, el soporte o las interfaces disponibles ya no acompañan al servicio. El expediente no cuantifica horas ni personal, por lo que no cabe inventar un ahorro. Sí deja claro que la capacidad de mantenimiento formó parte de la decisión de reemplazo.

El aprendizaje es especialmente relevante para herramientas de observación. El forwarding puede seguir funcionando mientras la capacidad de interpretar lo que ocurre se deteriora. Por eso la continuidad de una looking glass depende tanto de personas y proyectos mantenidos como de CPU, memoria o conectividad.

Definir la necesidad antes de escoger el sustituto

LINX estableció un conjunto visible de condiciones para la nueva solución. Debía ofrecer una interfaz gráfica sencilla, admitir mejoras actuales de BGP y RPKI, proporcionar una API y contar con mantenimiento activo. Cada condición atacaba una debilidad distinta del entorno heredado.

La interfaz gráfica atendía al operador humano. La compatibilidad de encaminamiento evitaba que la vista quedara por detrás de los servidores. La API permitía consultar los datos de forma estructurada y no solo mediante navegación manual. El mantenimiento activo reducía el riesgo de repetir la dependencia de un código interno conocido por pocos o de un proyecto sin evolución.

Solo después aparecen Alice LG y Birdwatcher. La combinación fue seleccionada porque el equipo consideró que respondía a esos requisitos. Birdwatcher proporcionaba la capa de acceso a los datos que Alice LG presentaría. El informe no atribuye la evaluación o la decisión a Kayser de manera individual, y tampoco afirma que la combinación sea la respuesta adecuada para cualquier IXP.

El orden protege la lógica de la decisión. Si en el futuro cambian las necesidades, LINX puede volver a examinar si las herramientas siguen cumpliéndolas. Si solo quedara el nombre del producto, sería imposible distinguir una elección fundada de una preferencia. El registro conserva el problema y los criterios junto con el resultado.

La diversidad entre Quagga y BIRD dejó de ser sostenible

Antes de completar la migración, LINX había usado Quagga como base de sus servidores de rutas y más tarde había trasladado la mitad a BIRD. La convivencia tenía un objetivo razonable: reducir el impacto potencial de un fallo específico de una implementación. Si dos códigos diferentes procesan una función similar, un defecto exclusivo de uno no necesariamente se reproduce en el otro.

Esa protección exige, sin embargo, que ambas implementaciones puedan satisfacer los cambios necesarios. El informe indica que adaptar Quagga a RPKI y a otras mejoras BGP se volvió progresivamente más difícil. LINX terminó migrando todos los servidores de rutas a BIRD. La decisión redujo la diversidad de implementaciones, pero también eliminó una variante que ya no seguía el ritmo requerido.

No hay una victoria abstracta de la estandarización sobre la diversidad. Ambas tienen costes y beneficios. La diversidad puede contener determinados fallos; la estandarización puede simplificar configuración, automatización y soporte. El equilibrio cambia cuando una de las opciones deja de ser operativamente viable. En este caso, el soporte de funciones y la mantenibilidad desplazaron el punto de equilibrio.

La convergencia en BIRD produjo además un activo reutilizable. LINX había invertido en automatizar su configuración para servidores de rutas. Cuando llegó el momento de retirar los colectores Cisco, esa automatización ofrecía una base conocida. Compartir implementación no borró la diferencia funcional entre un servidor de rutas y un colector, pero redujo el número de mecanismos distintos que el equipo debía sostener.

Dos décadas de colectores y una fecha de fin de servicio

Los Cisco 7200 utilizados como colectores representaban otra clase de límite. LINX afirma que habían desempeñado ese papel durante unos veinte años y que estaban fuera de servicio del fabricante desde 2015. Su retirada no se presenta como reacción a una avería súbita. El fin del ciclo de soporte bastó para concluir que no debían convertirse en una excepción permanente.

Un equipo puede seguir encendido después de esa fecha. La continuidad inmediata no elimina la dificultad de sostener hardware, software e integración indefinidamente. Las fuentes no enumeran escasez de repuestos, vulnerabilidades o fallos concretos, de modo que ninguna de esas hipótesis debe atribuirse a LINX. El hecho documentado es más contenido: la edad y el estado de servicio hicieron necesaria la sustitución según el equipo.

La interfaz mlrg envejecía al mismo tiempo que la plataforma. Cambiar solo la presentación habría dejado los 7200; cambiar solo el hardware habría conservado una vía de observación sin desarrollo activo. La solución debía tratar el proceso BGP, la máquina que lo alojaba, la automatización y la forma de exponer los datos como partes de un problema conectado.

La adopción previa de BIRD hizo que trasladar allí la función de los colectores fuera una opción coherente con la arquitectura de LINX. Esa coherencia es local. No demuestra que todo colector deba compartir software con los servidores de rutas, sino que una inversión existente puede modificar el coste y la viabilidad de la siguiente decisión.

Febrero de 2020: una primera prueba útil pero incompleta

El trabajo con Alice LG comenzó en febrero de 2020, después de que LINX habilitara RPKI y actualizara Ubuntu en los servidores de rutas. El primer entorno colocó una máquina virtual en uno de esos servidores y utilizó Birdwatcher para emular LON1 RS1. En ese montaje acotado, el sistema funcionó.

La prueba resolvía una pregunta de integración. Confirmaba que los componentes podían intercambiar datos y ofrecer una vista en un escenario representativo de una sola instancia emulada. No medía la demanda total de la looking glass cuando recibiera información de todos los servidores previstos.

Es fácil convertir un éxito temprano en una autorización demasiado amplia. El expediente evita esa simplificación porque registra la siguiente prueba. Al conectar todos los servidores de rutas de LINX en un entorno de ensayo, el equipo observó que hacía falta más memoria. La prueba inicial no era incorrecta; simplemente tenía un alcance menor que la decisión final.

Las fuentes no publican cuántas rutas se cargaron, cuántas consultas se realizaron o cuánta memoria consumió cada componente. Por ello, el caso no ofrece una fórmula universal de capacidad. Ofrece una lección de método: el resultado debe interpretarse dentro de la escala realmente probada.

La prueba agregada cambió el soporte físico

Ante la mayor demanda de memoria, LINX eligió un dispositivo físico con más capacidad. El artículo señala que Alice parecía funcionar mejor allí. La formulación importa porque describe una observación situada, no una condena general de las máquinas virtuales.

El equipo no partió de una preferencia pública por el hardware dedicado. Primero probó el sistema en una máquina virtual, amplió la conexión a todos los servidores y encontró un límite. Solo entonces cambió el soporte. La arquitectura siguió al comportamiento del software con la carga prevista.

Esta secuencia convierte la observabilidad en una carga que debe presupuestarse de verdad. Aunque la looking glass no reenvíe el tráfico de los miembros, necesita procesar suficiente estado de rutas para responder a preguntas operativas. Una herramienta que solo funciona a escala reducida no proporciona la visibilidad para la que fue desplegada.

Tampoco puede concluirse que el nuevo equipo garantizara seguridad, disponibilidad o ausencia de incidentes. No hay métricas públicas que permitan afirmarlo. El resultado verificable es que el ensayo agregado mostró una necesidad de memoria, y que LINX adaptó el despliegue en lugar de mantener la forma inicial por inercia.

La primacía del sistema en ejecución se ve aquí con claridad. Los diagramas y las expectativas sirvieron para construir la prueba; la respuesta real de los componentes decidió qué plataforma era suficiente.

Reutilizar servidores de sitio sin ocultar el coste

La retirada de los colectores Cisco abrió una segunda decisión de capacidad. En el otoño de 2020, LINX empezó a trasladar su función a «captain servers». Había uno de estos servidores en cada sitio y se utilizaban habitualmente para monitorización y resolución de problemas. Colocar allí los procesos de colector evitaba instalar otra máquina física en cada LAN o adquirir licencias adicionales de virtualización.

La proximidad funcional hacía atractiva la reutilización. Los captain servers ya formaban parte del entorno operativo de cada sitio, y BIRD podía configurarse con la automatización utilizada en los servidores de rutas. La función de colección permanecía distribuida en máquinas asociadas a los sitios sin introducir una familia completamente nueva de equipos.

Pero LINX no presenta la reutilización como capacidad gratuita. Antes de añadir los colectores, aumentó la memoria de los captain servers. La decisión reconoce que compartir un equipo suma cargas y que una consolidación responsable debe dimensionar la plataforma común.

Las fuentes no permiten calcular cuánto se ahorró en hardware, licencias o trabajo, ni si la nueva disposición alteró algún dominio de fallo. Esas preguntas quedan abiertas. Lo que sí muestran es el intercambio observable: menos máquinas o licencias dedicadas a cambio de más memoria en equipos existentes y de una nueva función compartida.

Una arquitectura mayoritaria con una excepción explícita

Después de la migración, todos los colectores salvo el de LON1 estaban colocados en captain servers. LON1 continuaba en un servidor dedicado. El informe no explica por qué, y cualquier motivo añadido sería especulativo.

Mantener esa excepción en el relato es una señal de buena documentación. Las descripciones resumidas suelen convertir una solución mayoritaria en una regla total. En operaciones, esa simplificación puede ocultar la parte más relevante para una futura modificación. Una arquitectura que reconoce dónde no es uniforme es más útil que otra que parece limpia solo porque ha eliminado los casos incómodos del texto.

La excepción también ayuda a separar conceptos. La estandarización en BIRD y en automatización no exigía un soporte físico idéntico. La colocalización en servidores de sitio no implicaba centralizar toda la colección en un único lugar. LINX combinó un patrón común, una distribución geográfica y un caso dedicado.

No sabemos si LON1 respondía a capacidad, topología, historia o alguna otra razón. Esa ausencia debe conservarse. La transparencia consiste tanto en registrar lo que ocurrió como en no fingir conocimiento sobre lo que la fuente calla.

Dos looking glasses para no confundir dos papeles

LINX mantuvo instancias distintas de Alice LG para servidores de rutas y colectores. La configuración del lado de los colectores se parecía a la del otro entorno, pero omitía funciones de RPKI y filtrado que los colectores no implementaban. Esta diferencia impide que una interfaz común cree una equivalencia falsa.

Ambos tipos de proceso podían usar BIRD y ambos podían alimentar Alice LG. Eso no los convertía en el mismo servicio. Un servidor de rutas participa en la distribución de rutas del intercambio; un colector observa sin aplicar necesariamente la misma lógica de política. La vista debía reflejar la función ejecutada, no solo el software compartido.

Para un operador, la procedencia de la observación condiciona su interpretación. Si una vista de colector mostrara controles propios del servidor de rutas, podría sugerir una validación o un filtrado que no existe allí. Separar las instancias preserva la semántica de los datos y permite reutilizar componentes sin borrar las fronteras.

Los enlaces públicos incluidos por LINX también dirigían a vistas diferenciadas. El objetivo no era ofrecer rutas en una sola página, sino mantener dos puntos de observación coherentes con los sistemas que representaban. Esa decisión pertenece tanto al diseño de información como al de red.

RPKI es una entrada operativa, no un sustituto del encaminamiento

El informe menciona RPKI en varios niveles: como una de las funciones que Quagga tenía dificultades para seguir, como requisito para la nueva looking glass y como capacidad no idéntica entre servidores de rutas y colectores. Esta distribución de referencias evita presentar RPKI como una propiedad homogénea de todo el despliegue.

Un registro puede aportar información de autorización y seguridad al proceso de encaminamiento. No mueve paquetes por sí mismo. Para producir un efecto, el dato debe ser consumido por software, incorporado a una política y reflejado en un estado operativo. La observabilidad debe mostrar ese estado sin confundir la existencia del registro con una decisión ya aplicada en todas partes.

El caso de LINX enlaza esas capas. La información RPKI importaba, pero también importaba que la implementación pudiera manejarla, que la configuración fuera mantenible y que la interfaz distinguiera dónde se aplicaban funciones relacionadas. Los registros actúan como libros de referencia operativa; el sistema en marcha determina el comportamiento efectivo.

Esta lectura mantiene una capa de realidad. No convierte una política declarada en autoridad absoluta ni reduce el valor de datos únicos y exactos. Sitúa cada pieza en su función: los registros describen y respaldan decisiones; el código, la configuración y los operadores las llevan al plano operativo.

La firma conjunta limita y fortalece el perfil de Kayser

Mo Shivji, Jan Kayser y Ariel Smutkochorn aparecen juntos en el crédito de 2020. No sabemos cuál de ellos propuso Alice LG, ejecutó una prueba concreta, detectó el consumo de memoria, preparó un captain server o redactó cada párrafo. El informe no ofrece ese reparto.

Sí sabemos que los tres pusieron sus nombres en una explicación que conecta restricciones, decisiones y resultados. Kayser puede ser descrito como uno de los ingenieros que documentaron por qué las herramientas anteriores no bastaban, por qué BIRD se convirtió en la base común, por qué los 7200 debían retirarse y por qué la prueba agregada obligó a revisar la capacidad.

Ser autor no significa necesariamente ser la única persona que implementó el proyecto. Es posible que otros profesionales de LINX contribuyeran, pero la fuente no proporciona un registro completo de participantes. La formulación segura reconoce lo que está explícito y no excluye lo que no puede comprobarse.

Esta precisión es parte de la exactitud técnica. Las infraestructuras compartidas rara vez responden a una causalidad individual simple. Hardware, software, automatización, política y operación se combinan. Atribuir todos esos elementos a una sola persona deformaría la arquitectura humana tanto como confundir colectores y servidores de rutas deformaría la arquitectura de red.

NetUK3 aporta una referencia fechada de 2026

La lista de asistentes a NetUK3, celebrado los días 6 y 7 de julio de 2026, registra a Jan Kayser con LINX y el cargo «Senior Network Engineer». El directorio de ponentes y la página de la sesión lo nombran como presentador de «LON2 Network Refresh». Esas páginas constituyen evidencia profesional directa dentro del marco temporal del evento.

La forma correcta de usarla es igualmente temporal. Puede decirse que NetUK3 lo listó de ese modo en julio de 2026. No puede transformarse automáticamente en una afirmación sin fecha sobre su empleo actual. Tampoco permite asignarle todo el diseño o la ejecución de LON2. La autoría de una presentación no es un acta de propiedad de cada decisión institucional.

El resumen visible de la sesión sitúa LON2 dentro de una arquitectura londinense de doble LAN orientada a evitar un punto crítico único y a sostener redundancia, diversidad y resiliencia. Los materiales conservados no incluyen las palabras completas de la ponencia. Por tanto, no deben ponerse en boca de Kayser detalles técnicos no observados.

Esta referencia posterior confirma una continuidad pública en torno a la ingeniería de redes de LINX. No amplía retroactivamente su crédito en el proyecto de 2020, cuya autoría sigue siendo conjunta.

El resultado de LON2 pertenece al registro institucional

Dos publicaciones de LINX describen la renovación completada de LON2. Una presenta un proyecto en 17 sitios, impulsado por equipos al final de su vida útil y por una selección con pruebas de concepto. Los requisitos incluían los servicios de interconexión de LINX, EVPN, opciones de puerto desde 10GE hasta 800GE y diversidad respecto a LON1.

La otra publicación informa de la implantación de equipos Nokia IXR con SR Linux, de la continuidad de una arquitectura EVPN sobre VXLAN y de la conservación de diferencias de hardware y software respecto a LON1. Son datos sobre una decisión y un resultado de LINX.

Los criterios de proveedor se atribuyen en el material de la organización al CTO Richard Petrie, no a Kayser. Ninguna de las páginas afirma que Kayser eligiera Nokia, definiera por sí solo la plataforma o fuera responsable único de los 17 sitios. Su vínculo sustentado es que NetUK3 lo presentó como ponente del tema.

Mantener separados estos niveles evita una inferencia habitual: usar la asociación de una persona con una presentación para adjudicarle toda la causalidad del proyecto descrito. La continuidad temática es relevante, pero la atribución debe permanecer en la escala de cada fuente.

Lo que une 2020 y 2026 son las restricciones visibles

La migración de observabilidad de 2020 y la renovación de LON2 no son el mismo trabajo. Tampoco hay base para afirmar que siguieran una única dirección personal. Pueden compararse porque ambas narraciones de LINX exponen límites de ciclo de vida, requisitos técnicos y decisiones condicionadas por continuidad.

En la primera aparecen un software de routing difícil de adaptar, interfaces antiguas, hardware fuera de servicio, memoria insuficiente y reutilización de sistemas de sitio. En la segunda, equipos al final de vida, EVPN, una gama de velocidades amplia y diversidad frente a otro LAN. En ambos casos, la sustitución debía preservar funciones en ejecución mientras cambiaba la plataforma.

Kayser ocupa posiciones documentadas distintas: coautor de la explicación técnica de 2020 y ponente nombrado en 2026. Esa relación permite un perfil enfocado en cómo se comunican los cambios operativos. No autoriza una narración continua en la que cada decisión entre ambas fechas se convierta en obra suya.

El artículo mantiene por ello la migración de la looking glass como eje principal. LON2 sirve como corroboración fechada y como contraste institucional, no como una ampliación ilimitada de la identidad del candidato.

Los silencios de las fuentes también delimitan la conclusión

El expediente de 2020 es rico en secuencia, pero no en cifras. No publica la memoria exacta, el número de rutas, el volumen de consultas, el modelo del nuevo dispositivo o una medida de mejora. No cuantifica ahorro de licencias, horas de ingeniería, fiabilidad o disponibilidad. No comunica un incidente ni una consecuencia para clientes.

Tampoco explica la excepción de LON1, reparte tareas entre los autores o enumera a todos los participantes internos. Los documentos de 2026 no proporcionan la presentación completa de Kayser ni lo hacen responsable de la selección de Nokia. Cada una de estas ausencias descarta una clase de afirmación tentadora.

La conclusión defendible se apoya en lo que sí está cerrado. LINX identificó necesidades de mantenimiento y funciones de routing; seleccionó Alice LG y Birdwatcher; probó primero a pequeña escala; detectó más consumo de memoria al conectar todos los servidores; pasó a hardware físico; reforzó captain servers; llevó allí casi todos los colectores; mantuvo LON1 separado y publicó vistas distintas para roles distintos.

Kayser tiene relevancia pública porque figura en la autoría de esa explicación. El retrato no necesita llenar los huecos con motivaciones, jerarquías o resultados no medidos. Su solidez depende precisamente de dejarlos abiertos.

Documentar el cambio es una forma de responsabilidad

La migración no se presenta como una sucesión impecable. El primer entorno funcionó, pero no representó toda la carga. La consolidación reutilizó equipos existentes, pero exigió memoria adicional. La estandarización se extendió ampliamente, pero no eliminó la excepción de LON1. Las vistas compartieron herramientas, pero no fingieron funciones iguales.

Esos matices convierten el informe en algo más que un anuncio de producto. Permiten a otros operadores entender qué observó el equipo, qué cambió y dónde dejó de aplicar el patrón común. También permiten evaluar la decisión años después sin depender de una memoria informal.

La posición de Kayser se entiende mejor en ese marco. Su nombre acompaña un documento que deja que los límites técnicos sean visibles. La importancia no procede de atribuirle autoridad total, sino de asociarlo con una explicación pública que conserva el contexto y la incertidumbre.

En sistemas donde la responsabilidad se distribuye entre personas y componentes, esa calidad documental tiene consecuencias operativas. Facilita que el siguiente equipo reconozca qué hipótesis fueron probadas, qué recursos debieron ampliarse y qué diferencias deben seguir apareciendo en la interfaz.