Resumen

  • Los puntos de acceso de JANOG58 detectaron 1.925 direcciones MAC durante el primer día; unas 1.580, cerca del 82 %, eran aleatorias. La asistencia fue de 2.578 personas.
  • En la fase de preparación exclusiva del NOC, unos 60 usuarios activos y cerca de 120 terminales estimados dejaron 275 direcciones en el historial, unas 2,3 veces la estimación de equipos.
  • Los conmutadores conservaron un amplio margen de tabla MAC. El primer problema apareció en la identidad, la política y la telemetría, no en la capacidad de reenvío.
  • El NOC también activó una prueba VESPA sobre EVPN/VXLAN, aunque no publicó métricas antes/después que demuestren una mejora o una necesidad a esa escala.

JANOG58 se preparó para que se llenara una tabla. Lo que se desbordó antes fue el supuesto de que una dirección identifica de forma estable a un dispositivo.

El informe de campo publicado tras la reunión del Japan Network Operators' Group en Matsuyama registra 1.925 direcciones MAC vistas por los puntos de acceso en el primer día y unas 2.000 vistas por los conmutadores. Aproximadamente 1.580 de las direcciones detectadas por los AP —alrededor del 82 %— eran direcciones privadas aleatorias.

La cifra de 2.578 asistentes sirve para situar el tamaño del encuentro, pero no debe dividirse directamente por el número de direcciones. No todos tuvieron que conectarse al Wi-Fi, algunos llevaban varios equipos y un mismo terminal podía aparecer con más de una dirección.

La holgura del hardware ocultaba el coste

El cálculo de diseño partía de 50 puntos de acceso y 100 clientes por AP: unas 5.000 direcciones. Frente a esa necesidad, la capacidad declarada era amplia. El 7050SX3 utilizado como puerta de enlace de capa 3 admitía 160.000 entradas MAC; el 720XP, 64.000; y el 710P, 32.000.

Ese margen hizo viable una red plana de capa 2. El propio equipo afirma que no llegó a desbordar las tablas. Tampoco atribuye a la aleatorización una caída, pérdida de paquetes o congestión.

La ausencia de saturación es una conclusión, no una falta de noticia. Comprar un conmutador mayor solo resuelve cuántas entradas caben. No resuelve si una entrada sigue representando al mismo equipo, si una regla de acceso conserva continuidad o si el identificador de ayer ayuda a reconstruir el incidente de hoy.

El hardware seguía cómodo mientras la unidad de medición se volvía inestable.

Una dirección ya no equivale a un dispositivo

La fase de preparación del NOC ofrece una señal más limpia. Unos 60 usuarios activos equivalían, según la hipótesis de dos dispositivos por persona, a cerca de 120 terminales. Sin embargo, el historial de los AP acumuló 275 direcciones, de las cuales 245 eran aleatorias. El estado histórico fue unas 2,3 veces mayor que el parque estimado.

Los autores plantean que el paso por distintas redes —la del NOC, la de invitados y OpenRoaming— pudo influir. Es una explicación posible, no un reparto causal medido. El número de terminales también es una estimación. Aun así, el dato demuestra que el estado de direcciones puede crecer más deprisa que el número de clientes físicos.

Ese desfase tiene costes concretos. La autenticación, las ACL o las políticas basadas en MAC pierden continuidad. Los alquileres DHCP y las asociaciones ARP pueden multiplicarse. La analítica puede contar identificadores en vez de equipos. Y durante una avería, el operador debe relacionar la queja de una persona, el registro del AP y la tabla del conmutador aunque el dispositivo haya dejado varias identidades efímeras.

La aleatorización protege contra el seguimiento entre redes inalámbricas, una finalidad legítima. El reto no consiste en eliminar esa privacidad, sino en dejar de usar una dirección deliberadamente volátil como clave permanente de identidad.

VESPA cambia dónde reside el estado

El NOC no se limitó a contar. Activó un camino inalámbrico experimental con dos puertas de enlace VESPA, una VPN de capa 2 sobre EVPN/VXLAN y puntos de acceso Wi-Fi 6, 6E y 7.

La presentación técnica define VESPA, «Virtual Ethernet Segment with Proxy ARP», como una implementación de Arista que extiende el multihoming de EVPN a segmentos Ethernet conectados por túneles. Los puntos de acceso actúan como proxies de capa 2, y las puertas de enlace mantienen el estado de los clientes mediante una identidad de conjunto compartida y un punto de terminación virtual.

La base protocolaria sí está normalizada. RFC 7432 define los segmentos Ethernet y la movilidad MAC de EVPN. RFC 9161 explica cómo Proxy ARP/ND puede distribuir asociaciones IP-MAC y reducir la inundación de resolución en grandes dominios de difusión.

VESPA, sin embargo, no es un estándar del IETF. Tampoco puede presentarse esta prueba como evidencia de que JANOG58 lo necesitaba para evitar una saturación. Las cifras muestran que sobraba capacidad. La prueba exploró dónde alojar un estado cliente cada vez más volátil; no comparó de forma neutral todas las arquitecturas disponibles.

Faltan medidas antes/después de latencia, pérdida, carga del plano de control, estado ARP o DHCP y tiempo de diagnóstico. Sin ellas, sabemos que la arquitectura funcionó, pero no cuánto mejoró la operación.

La siguiente prueba debe medir la rotación

Un próximo informe debería separar clientes simultáneos de direcciones históricas, medir cuántos identificadores genera cada terminal, registrar alquileres DHCP, entradas ARP, CPU y tráfico de difusión, y comparar esos indicadores antes y después del proxy.

La compra de equipos necesita el mismo cambio de perspectiva. El máximo de entradas MAC sigue siendo importante, pero debe acompañarse de políticas de retención, integración con identidades superiores a la capa 2, visibilidad del comportamiento por SSID y un modo de fallo claro cuando el estado del proxy queda obsoleto.

JANOG58 no documentó el colapso esperado. Documentó algo más útil: una red puede tener capacidad de sobra y, aun así, perder precisión sobre quién o qué representa cada dirección. Ahí empieza el nuevo problema operativo.

Fuentes