Circuitos Dinámicos - Parte 1

Cuando terminamos de eliminar la penalización por recarga, desbloqueamos muchas opciones de desarrollo — muchas de ellas son funciones que la gente ha querido durante mucho tiempo. La más reciente son los circuitos dinámicos.

Anteriormente, cuando LibreQoS detectaba tráfico desde una dirección IP que no aparecía en ShapedDevices.csv, la listaba como una “IP Desconocida (Unknown IP)” — y realmente no permitía hacer mucho con ella. Dependía de ti averiguar qué era y qué estaba haciendo. Sí estaba sujeta al control de tráfico, pero se colocaba en un gran grupo de “desconocidos”, regulado de forma colectiva. A lo largo de los años hemos ofrecido algunas soluciones alternativas que pueden ayudar, pero no son exactamente lo que la gente quiere. Por ejemplo, declarar “subredes fallback” con un grupo compartido de ancho de banda “desconocido” puede ser útil. Sin embargo, esto también ha llevado a diseños poco eficientes — si sabes que un WiFi público puede ocupar 254 direcciones IP pero cada una necesita regulación individual, podrías haber creado 254 circuitos — los necesitaras o no.

Así que me propuse solucionarlo.

Mapeo de Rangos Dinámicos

La primera decisión fue permitir a los usuarios mapear rangos dinámicos en su configuración. Esto incluye un “catch-all” de “0.0.0.0” para todo — pero también puedes mapear fácilmente tu WiFi de eventos a un rango CIDR (o múltiples rangos) y especificar el plan que deseas que reciban los clientes por defecto.

Una vez que la interfaz de usuario y la configuración estuvieron definidas y funcionando, el siguiente paso fue utilizarlas.

Capa de Superposición de Circuitos

Internamente, LibreQoS combina cálculos de topología y mantiene una lista interna de ShapedDevices.csv. A lo largo de los años, el acceso a esto se había vuelto bastante disperso — ya era un punto crítico de mantenimiento, así que tenía sentido refactorizarlo correctamente. Lo primero que hicimos fue refactorizar todo el código de manejo de circuitos en un único actor — y proporcionar una API limpia para acceder a él.

Esto abrió la posibilidad de crear una capa “dinámica” y asegurar que las consultas pudieran devolver circuitos dinámicos. Y — como por arte de magia (aunque en realidad fue planificación) — la interfaz de usuario simplemente funcionó para la visualización de circuitos. Las listas Top X, la búsqueda y otras páginas enlazan a circuitos dinámicos.

Función Bakery

El siguiente paso fue realmente crear los circuitos dinámicos. Afortunadamente, ya teníamos gran parte de esto; la función Bakery ya rastrea la existencia de direcciones IP y el tiempo de vida (TTL) para la creación de circuitos dinámicos. Así que la lógica de “veo una IP” se extendió ligeramente para realizar una verificación de coincidencia de prefijo más largo (longest-prefix-match) en direcciones IP desconocidas. Si coincidían con un manejador definido para rangos de IP desconocidas — la función Bakery crea el circuito y se agrega al rastreador de circuitos dinámicos.

Entonces, ¿qué podemos hacer con esto?

Esta es la primera de varias mejoras, pero inmediatamente desbloquea muchos escenarios:

• Si ofreces WiFi público (de forma permanente o para un evento), puedes definir un rango para ese WiFi y automáticamente cada dispositivo se beneficiará de CAKE. Define un nodo padre y podrás limitar el ancho de banda total del evento.
• Si tienes IPs desconocidas — y seamos honestos, es muy fácil olvidar agregar cosas a tu CRM — puedes asignarles un plan por defecto y usar las herramientas de monitoreo para descubrir quiénes son.
• Para una oficina pequeña, puedes definir fácilmente una red pequeña con un rango dinámico amplio — y automáticamente modelar el tráfico de cada dispositivo que aparezca. A medida que creces, defines dispositivos conocidos — y los visitantes siguen siendo gestionados correctamente.

Y hay mucho más. Las futuras actualizaciones añadirán esto a la API, y estamos explorando formas de integrarlo con DHCP dinámico y RADIUS.