Por 2016 hice un script para obtener las direcciones IPv4 de Uruguay desde la información pública de Lacnic y mostrar la lista de sub-redes a las que se corresponden, con el objetivo de disponer una listado actualizado para incorporar en cualquier software de firewall, router o sistema de filtrado basado en IPes.
El post original Direcciones IP de Uruguay
Ayer instalé Codex de OpenAI y le pedí analizar el clone local del repositorio sobre un branch que cree para este proceso.
› Analiza este repositorio. No hagas cambios ni commit ni push. Primero explicame el plan de cambios. Asegurar que el rango sub-redes cubre la totalidad de las IP disponibles.Luego de un análisis su respuesta de Codex fue clara:
Analicé el repositorio y no hice cambios.
Hoy el script en uy-ip-networks.sh toma cada bloque IPv4 de Uruguay desde delegated-lacnic-latest y lo transforma en un único CIDR con 32 - log2(hosts). Con la base local actual (2026-03-10) eso produce cobertura completa: hay 92 bloques UY|ipv4, no encontré solapamientos, y la suma de IPs delegadas (2,516,736) coincide exactamente con la suma de IPs cubiertas por los CIDR emitidos.
El problema es de robustez, no del dataset actual. La lógica actual solo es correcta si cada bloque:
- tiene cantidad de IPs potencia de 2
- empieza alineado al prefijo calculado Si LACNIC publica un bloque válido que no cumpla eso, el script dejaría IPs fuera o emitiría una red incorrecta. El riesgo está concentrado en processDB() y en log2() dentro de uy-ip-networks.sh.
Plan de cambios
1. Reemplazar la conversión hosts -> un solo CIDR por una descomposición de rango IP inicial + cantidad de hosts a la lista mínima de subredes CIDR que cubra exactamente todas las IPs.
2. Mantener el comportamiento actual para los casos simples: si el bloque ya es potencia de 2 y está alineado, seguirá saliendo una sola red.
3. Ajustar processDB() para iterar por esa lista de subredes y emitir una o varias líneas por registro de LACNIC, según corresponda.
4. Validar con la base local que:
- el total de IPs cubiertas siga siendo 2,516,736
- no aparezcan solapamientos
- los 92 bloques actuales sigan resolviendo igual que hoy
5. Actualizar README.md para aclarar que la salida puede contener múltiples CIDR por una misma delegación cuando eso sea necesario para cubrir el rango completo. Si querés, en el siguiente paso te detallo cómo implementaría esa descomposición CIDR en Bash antes de tocar el código.Como el análisis mostraba datos de proceso del listado, le pedí incorporar la validación con un nuevo parámetro debug y que proceda con los cambios:
› Aplica los cambios en el código ajustando procesDB(), Incluye la validación que se muestre en caso de poner `debug` como switch. La salida por defecto (sin switch) tiene que se el listado de sub-redes listo para incluir en un software de firewall. Actualiza el README.md con estas indicaciones.Todos los cambios que fue haciendo estaban más que claros, mostrando una salida de diff de cada uno y al final dejó este mensaje como conclusión del trabajo realizado:
Ajusté uy-ip-networks.sh:33 para que processDB() ya no asuma “un bloque LACNIC = un solo CIDR”. Ahora descompone cada rango IP inicial + cantidad de hosts en el conjunto mínimo de subredes alineadas que cubre exactamente todas las IPs disponibles. La salida normal sigue siendo solo el listado de subredes por stdout, listo para importar en un firewall. También agregué parsing de switches offline y debug en uy-ip-networks.sh:212.
El modo debug quedó implementado sin contaminar la salida principal: imprime las subredes en stdout y manda la validación a stderr. La validación verifica por bloque y en total que la suma de IPs cubiertas por los CIDR emitidos coincide exactamente con lo delegado por LACNIC; esa lógica quedó en uy-ip-networks.sh:133. Actualicé README.md:3 para documentar la salida por defecto, offline, debug y el hecho de que un bloque puede dividirse en varias subredes para cubrir el rango completo.
Verifiqué:
- bash -n uy-ip-networks.sh
- ./uy-ip-networks.sh offline | wc -l -> 92
- ./uy-ip-networks.sh offline debug -> validación OK exact coverage, source_ips=2516736, covered_ips=2516736Terminado el proceso hice el push al repositorio remoto, creé un PR que revisé en la interfaz de Gitlab y confirmé con el merge al main.
Estimo que toda el proceso me llevó cinco a diez minutos y el resultado está compartido:
https://gitlab.com/pilasguru/uy-ip-networks
