Cómo configurar Geofeed en Registro.br
En el artículo anterior hablamos sobre geofeed, RFC 8805, RFC 9632, RDAP y por qué es importante para los proveedores. Ahora pasemos a la práctica. La idea es crear un ejemplo sencillo de publicación de un geofeed utilizando Registro.br, con un archivo CSV publicado en HTTPS y validación a través de WHOIS y RDAP. Para no utilizar ningún bloque real, los ejemplos que figuran a continuación utilizan bloques reservados para pruebas y documentación. En entorno de producción, como es lógico, deberá sustituirlos por los bloques reales de la ASN. Ejemplo de escenario Imaginemos que el proveedor dispone de un bloque de direcciones IPv4 /22 y utiliza cada una de las direcciones /24 en una ciudad diferente. Para el ejemplo de IPv4, utilizaremos: Este bloque forma parte de un espacio reservado para pruebas y evaluaciones comparativas. No debe utilizarse en entornos de producción en Internet. En este caso, solo sirve para que el ejemplo parezca una operación real, sin mostrar el prefijo. La división operativa sería la siguiente: En IPv6, utilizaremos el bloque de documentación: Y dividirlo en /40: Este enfoque se ajusta más a la realidad: un bloque más amplio registrado y, dentro de él, divisiones por ciudad o región. Un archivo por bloque Por el momento, Registro.br mantiene una política más restrictiva en cuanto a la publicación de geofeeds. En la práctica, lo más seguro es trabajar con un archivo por bloque registrado, que contenga únicamente el propio bloque o sus subbloques. Entonces, si el bloque registrado es: Tiene sentido disponer de un único archivo para este /22, que contenga los /24 internos: Contenido: Fíjese en lo más importante: todas las líneas se encuentran dentro del bloque « 198.18.0.0/22 ». Esto es diferente a mezclar bloques independientes en el mismo archivo. Por ejemplo, si tuviera dos bloques diferentes registrados en Registro.br, como: No sería una buena idea incluirlo todo en el mismo archivo CSV en este momento. Lo más seguro sería crear un archivo para cada bloque. Archivo IPv6 En el caso de IPv6, siguiendo la misma lógica, el bloque registrado sería: El archivo podría llamarse: Contenido: Aquí también se aplica la misma regla: los archivos « /40 » se encuentran dentro de la carpeta « /32 ». En un proveedor real, el nivel de detalle puede variar. Puede utilizar /40, /44, /48 u otro tamaño, dependiendo de cómo se haya planificado el IPv6. Lo importante es que el geofeed refleje el funcionamiento de forma coherente y no intente ser más preciso de lo que la red realmente permite. Formato correcto del archivo CSV La RFC 8805 define el formato básico del geofeed [1]: Sin embargo, en el archivo publicado, normalmente no se incluye encabezado. Entonces, no lo haga así: Haga lo siguiente: Algunos detalles importantes: El archivo debe estar en UTF-8. El prefijo debe estar en formato CIDR. El país de Brasil es BR. El estado debe cumplir con la norma ISO 3166-2. Paraná es BR-PR, São Paulo es BR-SP y Rio Grande do Sul es BR-RS. El nombre de la ciudad no debe contener ninguna coma. El campo del código postal debe quedar en blanco, pero debe mantenerse la coma final. Dónde consultar los códigos de los estados En el campo «región», utilice la norma ISO 3166-2. Algunos ejemplos: La fuente oficial es la Plataforma de consulta en línea de la ISO [4]. Para una consulta rápida, la página ISO 3166-2:BR también recoge los códigos de los estados brasileños [5]. Publicación del archivo Puede publicar el archivo CSV en la propia página web del proveedor, en un servidor web, en un bucket público o mediante GitHub Pages. Lo más importante es que la URL debe descargar el archivo directamente. Ejemplo para IPv4: Ejemplo para IPv6: O bien, utilizando GitHub Pages: Tenga cuidado con enlaces del tipo: Este enlace abre una página HTML de GitHub, no el archivo directamente. Para Registro.br, la URL debe proporcionar el archivo CSV directamente. Ejemplo con GitHub Pages Una opción sencilla para laboratorios o pequeños proveedores es utilizar GitHub Pages. El flujo es: El archivo IPv4 quedaría así: La URL final podría quedar así: Si, al abrir esa URL, el navegador descarga o muestra únicamente el contenido CSV, va por buen camino. Si al abrir una página de GitHub aparece con diseño, botones, menú y vista previa, es un error. Tipo de contenido Registro.br puede verificar el tipo de contenido publicado. Lo ideal es que el servidor responda con: o: La RFC 9877 define el tipo « application/geofeed+csv » para los archivos geofeed [3]. Para validar: Ejemplo de respuesta esperada: o: Validación de la sintaxis Antes de registrarse en Registro.br, conviene comprobar el archivo con un validador. Una opción práctica es: Ayuda a detectar errores tontos, como: Ejemplo incorrecto: Problemas: Correcto: Configuración en Registro.br Una vez que haya publicado y validado el archivo, acceda al portal de Registro.br. El proceso general es el siguiente: 3. Seleccione el bloque y abra la opción «Configurar Geofeed»; 4. Indique la URL HTTPS del archivo; Ejemplo de IPv4: Ejemplo de IPv6: Le recordamos una vez más: estos bloques son solo ejemplos con fines de documentación. En entorno de producción, utilizaría los bloques reales. Comprobación en WHOIS Una vez configurado, compruebe si el geofeed aparece en WHOIS. Ejemplo de IPv4: Resultado esperado: Ejemplo de IPv6: Resultado esperado: En entorno de producción, sustitúyalos por las direcciones IP reales de los bloques configurados. Validación en el RDAP También se puede validar a través de RDAP. IPv4: Resultado esperado: IPv6: Resultado esperado: El RDAP es importante porque constituye la vía más estructurada para que los sistemas automatizados detecten el geofeed. La RFC 9877 se creó precisamente para estandarizar este enlace de geofeed en las respuestas RDAP [3]. Comprobando si ha quedado al descubierto Además de WHOIS y RDAP, una herramienta útil es GeolocateMuch: En un entorno real, utilice el prefijo o la dirección IP. Esta herramienta permite comprobar si el geofeed está siendo detectado a partir de datos públicos. Lista de comprobación final Antes de darlo por terminado, revíselo: Errores
Pruebas de rendimiento de CGN/BNG en la plataforma Huawei NE8000
Aprenda de la mano de Luiz Puppin, especialista en Huawei, cómo realizar un análisis técnico de las pruebas de rendimiento (Forwarding Performance) llevadas a cabo en un entorno de laboratorio con la plataforma Huawei NE8000, con el fin de validar la capacidad del equipo para funcionar como BNG+CGN integrado bajo una carga elevada. Las pruebas tenían por objeto comprobar: Objetivo de las pruebas de rendimiento El objetivo era demostrar que la solución de Huawei es capaz de soportar: Estas características son fundamentales para las operaciones de los proveedores de servicios de Internet (ISP) y los operadores con una elevada concentración de abonados detrás de un CGN. Arquitectura utilizada La topología utilizada conecta: Metodología 5. Evidencias y resultados A continuación se incluyen las pruebas extraídas directamente del archivo de prueba. 5.1. Suscriptores autenticados correctamente El informe confirma la autenticación simultánea de miles de abonados PPPoE: El total validado fue de: 5.2. Creación de 32 millones de sesiones NAT El DUT ha alcanzado el límite de escalabilidad previsto por el fabricante: Es decir, el equipo soportó 32 millones de flujos simultáneos sin que se apreciara ninguna pérdida de calidad. 5.3. Tráfico sostenido a 50 Gbps – Sin pérdida de paquetes Es decir: 5.4. Tráfico bidireccional de 50 Gbps (25G + 25G) El laboratorio ha validado el funcionamiento simultáneo de las fases de pretratamiento y postratamiento: Una vez más, sin pérdida alguna de paquetes: 5.5. Estabilidad de la CPU La CPU se mantiene en niveles estables, sin alcanzar los límites críticos. 5.6. Conclusión de las pruebas de rendimiento A la luz de las pruebas, cabe concluir que: Por lo tanto, la plataforma demuestra una capacidad real para gestionar redes CGN/BNG en entornos a gran escala, con un elevado volumen de tráfico y una gran densidad de abonados. Este artículo se ha elaborado en colaboración con el equipo de responsables de productos IP para ISP de Huawei Brasil, con un agradecimiento especial a Thiago Sério y a Natan Fernandes. ¿Necesita ayuda para configurar sus equipos Huawei? ¡Podemos ayudarle! Quiero saber más
