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

Geofeed: por qué tus IP aparecen en la ciudad equivocada y cómo empezar a solucionarlo

Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja: «Mi cliente está en Paraná, pero el sitio web cree que está en São Paulo».«El streaming está diciendo que estoy en otro país».«El banco bloqueó el acceso porque pensó que la ubicación IP era extraña».«Google está mostrando una previsión meteorológica para otra ciudad». Es una situación un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP está bien, DNS responde, traceroute pasa, la latencia es aceptable. Pero para el usuario final, la constatación es sencilla: algo va mal en su Internet. Y a menudo lo es. No en la conectividad, sino en la forma en que esa dirección IP está siendo geolocalizada por terceros. La IP no tiene ninguna ciudad registrada en su interior Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro. No existe tal campo en el protocolo IP: o: La geolocalización de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de búsqueda, los servicios de streaming y las bases comerciales intentan averiguar dónde se está utilizando probablemente esa IP. Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tráfico, mediciones, historial, información de usuarios, bases comerciales, DNS, BGP, entre otras cosas. En la mayoría de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia. Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicación. Sólo que las bases externas pueden tardar en aprenderlo. Y entonces empiezan las llamadas. Dónde entra el geofeed El geofeed es una forma normalizada de que el operador de red diga: «Estos prefijos IP se están utilizando en estos lugares». No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesión ascendente. No es más que un archivo CSV publicado a través de HTTPS, siguiendo un formato definido en el RFC 8805 [1]. Un ejemplo sencillo: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Cada línea asocia un prefijo a una ubicación aproximada. El formato es: En la práctica: Es decir: La coma del final es importante. Representa el último campo, postal_code, que está vacío. Qué significa cada campo El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR. Ejemplos: El segundo campo es el país, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR. El tercer campo es la región, utilizando la norma ISO 3166-2. En el caso de los estados brasileños: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia rápida, también existe la página ISO 3166-2:BR, que enumera los códigos de los estados brasileños [5]. El cuarto campo es la ciudad. El quinto campo es el código postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precaución, porque puede dar demasiada granularidad [1]. Para el ISP, en la mayoría de los casos, el país, el estado y la ciudad son suficientes. La geolocalización es aproximación, no GPS Este punto es más importante de lo que parece. Cuando hablamos de geolocalización, es fácil caer en la tentación de intentar ser demasiado precisos. Pero la geolocalización IP no es un GPS. En NANOG 96, Sid Mathur presentó una charla titulada Geolocalización IP de alta calidad mediante asistentes de codificación de IA y MCP. Uno de los mensajes más útiles de la presentación es precisamente éste: la geolocalización IP es estadística e inexacta. Lo ideal es pensar en regiones geográficas, no en un punto exacto del mapa [6]. Tiene razón: más precisión no siempre significa más calidad. Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad: Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado: Esto evita resolver el problema de un cliente y crear un problema a otro. En la misma presentación, también comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona está en otro país, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo está fuera de la capa de conectividad [6]. Cualquiera que viva en una operación sabe que esto ocurre. ¿El geofeed lo soluciona todo? No. Y aquí es importante ser honesto. Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa información. La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1]. Aun así, publicar correctamente mejora mucho tu posición. Antes, tenías que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente pública, normalizada y descubrible automáticamente. No es una garantía de corrección instantánea, pero es una práctica operativa mucho mejor. ¿Cómo se enteran los demás de tu geofeed? Publicar el archivo en una URL es sólo una parte de la historia. Tienes que indicar dónde está este archivo en los registros del bloque IP. Ahí es donde entra la RFC 9632 [2]. Define cómo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum y inet6num. Hay dos formas principales. La forma más novedosa es utilizar el atributo propio: La forma compatible con entornos que aún no admiten el atributo específico es utilizar remarks: Lo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a él. ¿Qué pasa con el RDAP? RDAP es la forma más moderna de

Made4Flow 2.11.1: exportación de NetFlow para la mitigación de ataques DDoS, nuevas alertas y mucho más

Descubra las novedades de Made4Flow 2.11.1: exporte NetFlow V5, V9 y sFlow a plataformas de mitigación de DDoS, configure alertas por router e integre el sistema con sistemas externos a través de la API REST. Quien gestiona una red de tamaño mediano o grande sabe que la visibilidad del tráfico no es una ventaja competitiva, sino una cuestión de supervivencia. Detectar un ataque DDoS en curso, saber de qué país procede el tráfico anómalo o integrar el analizador de NetFlow con la plataforma de mitigación del operador sin necesidad de reconfigurar los routers: estos son los verdaderos retos a los que se enfrentan a diario los equipos de NOC y de seguridad. La versión 2.11.1 de Made4Flow, disponible a partir del 27 de febrero de 2026, responde precisamente a estas necesidades. En este artículo, detallamos cada novedad y lo que aporta en la práctica. ¿Qué es Made4Flow y a quién va dirigida esta actualización? Made4Flow es un analizador de NetFlow y sFlow desarrollado por Made4it para proveedores de Internet, operadores y equipos de NOC que necesitan una visibilidad detallada del tráfico de red. Recopila los flujos exportados por los routers (NetFlow V5, V9, sFlow, IPFIX), aplica análisis inteligente a dichos datos y ofrece gráficos, alertas y análisis en tiempo real. Esta actualización es especialmente relevante para quienes: Cómo exportar NetFlow a una plataforma de mitigación de DDoS — sin necesidad de intervenir en los routers Esta es la novedad más esperada de la versión 2.11.1 por parte de los equipos que gestionan plataformas de mitigación de ataques DDoS. La situación anterior era la siguiente: para enviar flujos a una solución de mitigación de terceros, era necesario configurar el router para que exportara simultáneamente a dos destinos: el colector de Made4Flow y el colector de la plataforma de mitigación. En muchos entornos, esto no es sencillo, resulta arriesgado o, sencillamente, inviable. Con el nuevo replicador de flujos de Made4Flow, el enrutador sigue exportando con normalidad a Made4Flow. A partir de ahí, la propia plataforma replica y reenvía los flujos a cualquier destino externo, en los siguientes formatos: La configuración se realiza directamente en la interfaz de Made4Flow: sin tiempo de inactividad, sin ventana de mantenimiento en los routers y sin riesgo operativo. Para los proveedores que utilizan soluciones como Wanguard, NSFOCUS, Arbor o cualquier otra plataforma que utilice NetFlow o sFlow, esta funcionalidad elimina una dependencia compleja y agiliza la integración. Integre su plataforma de mitigación de DDoS con Made4Flow y replique NetFlow V5, V9, IPFIX o sFlow con una sola configuración. Análisis de amenazas: nueva visualización para identificar ataques internos La página de Análisis de amenazas de Made4Flow se ha rediseñado por completo en la versión 2.11.1. El nuevo diseño reúne en una única pantalla las principales métricas de seguridad: el total de amenazas detectadas, las direcciones IP sospechosas, el volumen de tráfico malicioso, la distribución temporal de los incidentes y los principales objetivos. La visión geográfica de las amenazas también se ha mejorado, lo que facilita la correlación entre el origen del ataque y el impacto en la red. Para los equipos de seguridad que necesitan responder rápidamente ante incidentes, esto supone menos clics y más información contextual disponible en el momento crítico. Descubra quién está provocando ataques dentro de su red interna con UN SOLO CLIC. Alertas relacionadas con la frecuencia de muestreo y el enrutador: deje de analizar datos distorsionados Uno de los problemas más ocultos en la monitorización con NetFlow es la incompatibilidad de la frecuencia de muestreo. Cuando el valor configurado en la herramienta de análisis difiere del que el router está aplicando realmente, todos los gráficos de tráfico se distorsionan, y el equipo puede tomar decisiones basadas en datos erróneos sin darse cuenta. La versión 2.11.1 incorpora dos tipos de alertas específicas para este escenario: Aviso de incompatibilidad de la frecuencia de muestreo Le avisa automáticamente cuando el valor de muestreo configurado en Made4Flow difiere del que está indicando el router. Esto resulta especialmente útil en entornos con varios routers de distintos fabricantes (Cisco, Huawei, MikroTik, Juniper), en los que el patrón de muestreo puede variar. Alertas explícitas por router Cada router registrado en Made4Flow puede ahora tener sus propias alertas activas, visibles directamente en la lista de equipos y en la página de edición. Esto facilita la gestión en entornos con decenas o cientos de routers supervisados. Reciba una alerta antes de que el problema afecte a sus datos: configúrelo en cuestión de minutos. Tráfico por país y aplicación por prefijo: visibilidad geográfica en tiempo real Para los proveedores de Internet y los operadores, saber de dónde procede el tráfico es tan importante como saber cuál es su volumen. Un pico procedente de un país concreto puede indicar que se está produciendo un ataque volumétrico; un prefijo específico que consuma ancho de banda por encima de lo habitual puede indicar que un cliente ha sido víctima de un ataque. La versión 2.11.1 incorpora una nueva pantalla de visualización con gráficos de tráfico desglosados por: Esta información ya estaba disponible en los datos sin procesar, pero ahora se presenta en un formato visual nativo, sin necesidad de exportar datos, cruzar hojas de cálculo ni utilizar herramientas externas. Compruebe en cuestión de segundos qué país o prefijo está generando tráfico anómalo, y actúe antes de que el ataque se intensifique. Agregación por indicadores TCP y países: detecte con precisión los patrones de ataques DDoS Los ataques DDoS modernos suelen camuflarse entre un volumen de tráfico aparentemente normal. El análisis de los indicadores TCP —como las inundaciones de SYN, ACK o RST— es una de las formas más eficaces de identificar el tráfico malicioso antes de que afecte a los servicios. La versión 2.11.1 incorpora nuevas pestañas de agregación en los datos brutos de Made4Flow: Para los equipos de seguridad que investigan incidentes, la combinación del análisis por indicadores y por origen geográfico resulta especialmente eficaz a la hora de establecer una correlación entre la técnica de ataque y su origen. Detecte los ataques basándose

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

MC-LAG en routers Huawei

Cómo configurar MC-LAG en Huawei: E-Trunk, Eth-Trunk, LACP y BFD paso a paso. Aprende MC-LAG en Huawei, hoy te mostramos por qué E-Trunk (multichasis), cuándo utilizar Eth-Trunk (agregación), cómo ajustar LACP para puertos activos/de reserva y cómo BFD acorta el MTTR. Hemos incluido recomendaciones para el hashing en escenarios MPLS y un script de prueba para validar el comportamiento ante fallos. La agregación de enlaces (LAG), llamada Trunk en Huawei(Eth-Trunk cuando es Ethernet), es una tecnología que combina varias interfaces físicas en una única interfaz lógica. Con la agregación de enlaces ganamos: El LAG tradicional es siempre entre dos dispositivos, punto a punto: Tipos de LAG para Huawei En pocas palabras, en Huawei tenemos tres formas principales de utilizar Eth-Trunk: En el contexto de MC-LAG, lo que nos importa es básicamente: Hagámoslo sencillo: Manual LACP estático Cómo equilibra Trunk el tráfico Eth-Trunk no «añade puertos» como una puerta gigante. El equipo decide a través de qué miembro enviar cada flujo mediante algoritmos de equilibrado. Esto define dos comportamientos principales: Equilibrio de carga basado en hash Es estándar en la mayoría de los routers/conmutadores. Funciona así El hash puede utilizar varios criterios, por ejemplo: Con hash, el modo por defecto es por flujo: El hash tiene una consecuencia importante: No siempre distribuye uniformemente el ancho de banda.Según la distribución de los flujos (hash), un miembro puede estar en el cuello de botella mientras que otro casi no tiene tráfico. Esto es normal. Equilibrio dinámico de la carga Algunos dispositivos admiten el modo dinámico, que supervisa la carga instantánea de cada miembro y reasigna los flujos entre los enlaces infrautilizados o sobrecargados. Un dispositivo que utiliza este tipo de equilibrado son los conmutadores Datacom. ¿Y qué pueden utilizar los chips para el hashing? Casi nadie habla de este punto, pero es crucial. Dependiendo del ASIC, el router puede tener un aspecto: En el caso de MPLS: Eso importa porque Ejemplos prácticos: En resumen: Cuanto mayor sea la profundidad MPLS que vea el ASIC, mejor será la distribución de los flujos MPLS en el LAG. Qué hace LACP LACP (Protocolo de Control de Agregación de Enlaces, IEEE 802.3ad) es el que: En Huawei, cuando Eth-Trunk está en LACP estático, las interfaces miembro: El lado con mayor prioridad del sistema (valor numérico más bajo) se convierte en el Actor. A partir de ahí Qué tiene que estar «bien» para que el GAL suba correctamente Para que un Eth-Trunk con LACP funcione como se espera, es necesario que ciertos puntos estén alineados entre ambos lados: Lo que hace LACP es utilizar la prioridad del sistema + ID del sistema + prioridad de la interfaz + número de interfaz para: Entrar en MC-LAG Hasta ahora hemos hablado de LAG «normal», es decir, sólo entre dos dispositivos. MC-LAG (Multi-Chassis LAG) entra cuando lo deseas: La idea es sencilla: Objetivo principal del MC-LAG: Básicamente es llevar la idea de redundancia del nivel de puerto/enlace al nivel de dispositivo. Activo/activo vs activo/reserva En muchos vendedores puedes encontrar MC-LAG de dos sabores: En Huawei, para este escenario concreto con E-Trunk/mLACP, el comportamiento es activo/respaldo: MC-LAG en Huawei: E-Trunk vs mLACP En Huawei, hay dos formas principales de implantar MC-LAG: La diferencia radica en el mecanismo de control entre los PE: En este artículo nos centraremos en el E-Trunk, que es la forma«clásica»de MC-LAG en muchos escenarios PE-CE. Cómo funciona E-Trunk No confundas E-Trunk (la tecnología de sincronización entre chasis) con Eth-Trunk (la propia agregación de enlaces). Considera el siguiente escenario: Los EP entonces: Con esto: Cuando se produce un fallo: Opcionalmente, puedes Conectividad CE ↔ PEs con E-Trunk Algunos puntos importantes del diseño: Casos prácticos En la topología siguiente, cubriremos dos casos de uso de MC-LAG (hay muchos otros). 1) MC-LAG que protege VPLS (capa 2) En la parte superior del dibujo, CE1 está en multihoming con PE1 y PE2 mediante MC-LAG, todos en la misma instancia VPLS-1.En el lado de la red, PE1/PE2 cierran el VPLS con PE3, que presta el mismo servicio a CE2. Se trata de una protección L2 de extremo a extremo para el VPLS, con redundancia de equipos y POP. 2) MC-LAG que protege /30 L3 (capa 3) En la parte inferior del dibujo, CE3 recibe un /30 L3 a través de MC-LAG, dual-homed en PE2 y PE3. Configurar el entorno Ahora que ya conoce todos los conceptos que subyacen al MC-LAG, pasemos al laboratorio. Utilizaremos el entorno virtual PNETLAB, con la imagen Huawei NE40 V22. Los puertos físicos y las conexiones entre dispositivos se describen en la topología siguiente. La configuración de los CE es sencilla: un mikrotik (ROS 7.6) que utiliza interfaces bonding, con LACP rápido (en 1s). CE3 es simplemente una interfaz física con una VLAN. CE1 CE2 CE3 La configuración de los PE incluye las interfaces punto a punto, activas con OSPF, MPLS. En las interfaces de acceso, las configuraciones LAG y de sincronización e-trunk. Y en la capa de servicio, el VPLS (VSI) y la pasarela L3 (con la dirección mac y la misma IP). PE1 – Capa central Servicio MLAG y E-trunk Aquí es donde el MLAG cobra todo su sentido. Primero creamos un Eth-Trunk ordinario, y luego lo asociamos a una configuración e-trunk, que hace que se produzca la magia MLAG. Una vez creado el LAG, ahora debemos configurar el e-trunk. Para configurarlo, necesitamos: En nuestro laboratorio, vamos a cerrar el loopback entre PE1 y PE2, que forman parte del MLAG desde la perspectiva de CE1. La prioridad maestra será PE2, con prioridad 5. Los temporizadores configurados son 9 para hello y 30 para hold-timer. Por último, es hora de asociar la interfaz LAG con e-trunk, creando así un MLAG desde la perspectiva de CE1. Servicios VPLS PE2 – Capa central Las configuraciones CORE y VPLS del PE2 son similares a las del PE1 Servicio MLAG y E-trunk Servicios de pasarela redundantes Para el servicio de pasarela redundante para CE3, lo haremos: PE3 – Capa central Las configuraciones CORE del PE3 son similares a las del PE1.

Cómo Pontonet salió del caos de servidores y redujo costes con Proxmox

Descubre cómo Made4it transformó un escenario de fracaso total en una infraestructura moderna, resistente y más barata. 16/09/2025 – Por Made4it La escena es familiar para cualquier responsable informático: final de mes, facturas por emitir, sistema en marcha… hasta que todo se cae. Esto es exactamente lo que le ocurrió a Pontonet, cuando un fallo simultáneo en un servidor físico puso en peligro toda la empresa. Párate a pensar: si todos tus discos fallaran hoy, ¿cuánto costaría recuperar la información de todo un año? Fue entonces cuando Made4it intervino para convertir el desastre en oportunidad. El problema: fallo simultáneo y sin copia de seguridad Este es el tipo de riesgo que muchas empresas ignoran hasta que es demasiado tarde. Soluciones sobre la mesa: ¿mantener VMware o migrar? Ante el desastre, evaluamos dos alternativas: Continuar con VMware Migrar a Proxmox ¿Por qué Proxmox? Proxmox es más que una alternativa gratuita. Te ofrece: En comparación con VMware, Proxmox demostró ser más ágil, económico y seguro. El papel de Made4it en este giro Pontonet ya era cliente de las redes y servidores de Made4it. Cuando se produjo el fallo, tomamos las siguientes medidas: Este proceso demostró nuestro dominio técnico y nuestra capacidad para convertir las crisis en oportunidades de innovación. Resultados: seguridad y ahorro Después de la migración: Proxmox y Made4it: la combinación ganadora Esta historia demuestra que la tecnología y la estrategia van de la mano. No tiene sentido invertir en licencias caras si el proyecto no incluye redundancia y copias de seguridad; del mismo modo, una solución de código abierto requiere conocimientos especializados para aplicarse con seguridad. Made4it ofrece ambas cosas: conocimientos profundos y soluciones asequibles. ¿Conoces a alguien que siga confiando en un servidor antiguo sin copia de seguridad? ¡Envíale este artículo! Y si no quieres llevarte una sorpresa al descubrir que tu empresa es vulnerable, habla con nuestros expertos.

IPv6 para proveedores de servicios de Internet: seguridad, rendimiento y escalabilidad

IPv6: la clave para el futuro de la conectividad en los proveedores de Internet Internet a nivel mundial está atravesando una transición inevitable. Con la proliferación de dispositivos conectados —desde teléfonos inteligentes y el Internet de las cosas (IoT) hasta las aplicaciones 5G—, el agotamiento de las direcciones IPv4 ha dejado de ser una previsión lejana para convertirse en un verdadero cuello de botella. Desde 2011, la IANA ya venía advirtiendo sobre el agotamiento de los bloques de direcciones IPv4 y, en Brasil, desde 2020, ya no hay direcciones disponibles para su asignación. Ante esta situación, muchos proveedores de servicios de Internet (ISP) han recurrido al CGNAT como solución provisional. Funciona a corto plazo, pero tiene un alto coste: pérdida de conectividad de extremo a extremo, repercusiones en aplicaciones sensibles y graves problemas de trazabilidad y seguridad. En este contexto, el IPv6 deja de ser una mera alternativa tecnológica. Se convierte en la única vía viable para garantizar la escalabilidad, la estabilidad y la competitividad en la nueva generación de redes. ¿Por qué es más que necesario el IPv6? ¡Es fundamental para su proveedor! La adopción de IPv6 va mucho más allá de una simple actualización técnica: se trata de una decisión estratégica que repercute directamente en el presente y el futuro de su empresa. Al eliminar las limitaciones del IPv4, el IPv6 abre nuevas perspectivas en materia de conectividad, con un mayor número de direcciones, mayor seguridad, menor latencia y un rendimiento superior. Todo ello con un mayor control y escalabilidad de la red. Los proveedores que ya han migrado están obteniendo resultados: operaciones más eficientes, menor dependencia de soluciones provisionales como el CGNAT y una mayor preparación para tecnologías como el 5G, el IoT, la automatización y las aplicaciones en tiempo real. El cliente final también nota la diferencia gracias a una navegación más rápida, conexiones más estables y una experiencia optimizada para juegos, llamadas, streaming y acceso remoto. IPv6 no es solo el futuro. Es una ventaja competitiva ya en la actualidad. Cómo implementar el IPv6 de forma segura y eficiente La migración a IPv6 no tiene por qué ser compleja. Con una planificación adecuada, se lleva a cabo de forma gradual, segura y sin que ello afecte a sus clientes. El secreto está en comprender las ventajas reales, preparar a su equipo y seguir una estructura bien definida. Descubra cómo el IPv6 aporta un valor inmediato a su proveedor —y al usuario final—. ¿Cuáles son los beneficios reales para su proveedor? ¿Y para sus clientes? Una experiencia de primer nivel. Cómo ponerlo en práctica: guía paso a paso simplificada Errores habituales que pueden poner en peligro su transición La transición ya ha comenzado y quien esté a la cabeza ahora, tomará la delantera La migración a IPv6 ya no es una posibilidad futura. Es una realidad en curso y quienes la adopten ahora obtendrán las ventajas antes que sus competidores. Más rendimiento. Más seguridad. Más escalabilidad. Menos costes operativos. Los proveedores que lideran este cambio aportan más valor a sus clientes, evitan los cuellos de botella técnicos y se posicionan con firmeza ante las exigencias de un mercado cada vez más conectado, automatizado y exigente. Con el apoyo adecuado, una planificación técnica y una ejecución estructurada, su empresa podrá llevar a cabo esta transición de forma segura, gradual y eficiente, sin comprometer la calidad del servicio. Made4it puede acompañarle en este proceso.Póngase en contacto con nuestro equipo y descubra cómo podemos acelerar su transición hacia una infraestructura preparada para el futuro.

RU y MRU en Wi-Fi 7: eficiencia, latencia y potencia para los proveedores de servicios de Internet

La revolución del Wi-Fi 7: cómo el RU y el MRU están reinventando la comunicación inalámbrica El caos del tráfico de datos y la necesidad de nuevas «autopistas» La analogía entre las redes informáticas y las grandes autopistas urbanas nunca ha sido tan acertada. Los entornos densos, con cientos de dispositivos conectados, convierten los canales de frecuencia en avenidas congestionadas. El Wi-Fi 7 surge como respuesta técnica a esta limitación, con dos avances fundamentales: RU (Resource Unit) y MRU (Multi-Resource Unit). Estos nuevos mecanismos funcionan como auténticos ingenieros del tráfico digital, optimizando la asignación del espectro, reduciendo la latencia y garantizando una mayor eficiencia espectral. OFDMA y RU: Compartir la carretera de forma inteligente Desde el Wi-Fi 4 (802.11n), la multiplexación por división ortogonal de frecuencia (OFDM) ya se utilizaba para transmitir datos en múltiples subportadoras de forma simultánea. Con el Wi-Fi 6, la OFDMA introdujo el concepto de RU —divisiones más pequeñas de la subportadora— que permiten que varios dispositivos transmitan datos simultáneamente dentro del mismo canal, asignando diferentes tamaños de RU según sea necesario. Sin embargo, existía una limitación: cada dispositivo solo podía utilizar una RU por transmisión. Esto generaba latencia en las aplicaciones más exigentes, incluso con espectro ocioso. MRU: La combinación inteligente de recursos El Wi-Fi 7 supera esta limitación gracias al concepto de MRU. Ahora es posible agrupar varias RU contiguas o no contiguas para formar un bloque lógico más grande. Esto permite que los dispositivos con grandes volúmenes de datos transmitan con una latencia mínima y un mayor rendimiento, utilizando el espectro de forma mucho más eficiente. Esta flexibilidad resulta fundamental en entornos como las industrias, los hospitales y las ciudades inteligentes. Perforación: cómo evitar las interferencias sin sacrificar el canal Otro avance del Wi-Fi 7 es la técnica de «puncturing». A diferencia del Wi-Fi 6, en el que las subportadoras afectadas por interferencias quedaban inutilizadas, el Wi-Fi 7 permite aislar esas bandas afectadas y mantener el funcionamiento normal del resto. Esto aumenta drásticamente la resistencia a las interferencias. ¿Qué mejora el MRU en la práctica? Especificaciones Wi-Fi 6 Wi-Fi 7 Ancho del canal Hasta 160 MHz Hasta 320 MHz Modulación 1024-QAM 4096-QAM Velocidad máxima 9,6 Gbps 46 Gbps MRU + Perforación No disponible Implementado Eficiencia con MRU Limitada Hasta un 40 % de beneficio Fuente: Broadcom, Intel, Qualcomm Aplicaciones avanzadas con MRU Eficiencia, flexibilidad e inteligencia RU y MRU no solo aumentan la velocidad, sino que redefinen la arquitectura de las comunicaciones inalámbricas. El Wi-Fi 7 supone un cambio estructural, basado en la asignación dinámica e inteligente del espectro. El futuro de la conectividad pasa por soluciones flexibles y escalables. Y en esta nueva realidad, RU y MRU son los pilares que permitirán crear redes adaptativas, resilientes y verdaderamente optimizadas. Si su empresa está estudiando cómo migrar a una arquitectura Wi-Fi 7 o cómo aprovechar las ventajas de RU y MRU, nuestro equipo puede ayudarle. Botón central Póngase en contacto con nosotros

Cómo la IA transforma el NOC: de la detección a la solución en cuestión de segundos

El uso de la inteligencia artificial para agilizar los procesos de gestión de incidencias ¿Su equipo de TI ya ha pasado horas intentando averiguar por qué se ha caído la red?Mientras tanto, el servicio de atención al cliente se satura, los clientes se quejan y la presión no hace más que aumentar. ¿Y si, en lugar de buscar la causa manualmente, recibiera en cuestión de segundos un diagnóstico preciso, las medidas recomendadas y cómo evitar que esto vuelva a ocurrir?Eso es precisamente lo que hace la Inteligencia Artificial de Made4NOC. El reto: 600 incidentes al día En Made4NOC, supervisamos redes críticas de proveedores de servicios de Internet (ISP), empresas e instituciones.Se trata de unos 600 incidentes diarios que requieren atención y una respuesta inmediata. Para los técnicos con experiencia, identificar la causa raíz es más rápido.Sin embargo, para quienes están empezando, el proceso puede llevar horas y cada minuto cuenta cuando hay clientes afectados. Por ello, hemos identificado en la IA una oportunidad para optimizar nuestros procesos y facilitar el trabajo tanto de los principiantes como de los técnicos con experiencia. ¿Cómo funciona la IA en Made4NOC? Con la llegada de Zabbix 7.0, la comunidad ha incorporado nuevas funciones de inteligencia artificial.Nosotros hemos ido más allá: hemos adaptado estas funciones a la monitorización en tiempo real y al nivel de exigencia que requiere Made4NOC. Cada vez que se activa una alerta y aparece en el panel de control de Made4NOC, nuestros analistas comienzan a gestionarla marcando la alerta como «reconocida». El proceso es sencillo y eficaz: Este registro no es solo un trámite burocrático. Constituye una valiosa base de conocimientos, lista para agilizar la resolución de futuras incidencias. Personalización Made4NOC Partimos de una base creada por la comunidad de Zabbix y la hemos adaptado a nuestra realidad.Hemos desarrollado un script que: El regreso de la IA se presenta con fuerza: Velocidad y precisión El resultado aparece en la interfaz de gestión de incidencias con solo dos clics.El analista obtiene: Así es como la IA de Made4NOC transforma un incidente crítico en una resolución casi inmediata, manteniendo la red estable, el SLA intacto y al cliente satisfecho. Conclusión La IA en Made4NOC es solo el principio.Lo que hoy en día agiliza los diagnósticos y aumenta la precisión de las respuestas transformará por completo, en breve, la forma en que supervisamos las redes. Combinamos lo mejor de la comunidad Zabbix con personalizaciones adaptadas a cada caso concreto.¿El resultado? Mayor agilidad, mayor calidad y atención a los clientes en el momento oportuno. Y esto es solo el principio.El siguiente paso es ampliar el uso de la IA para predecir fallos incluso antes de que se produzcan, y eso ya está en nuestro punto de mira. Si desea ver cómo funciona esta tecnología en su empresa, no espere más. Póngase en contacto con nosotros: Botones centralizados Póngase en contacto con nosotros Más información

Tendencias en tecnologías de la información para 2025: ¿Qué debe hacer su empresa ahora?

Las principales tendencias en TI y telecomunicaciones para 2025 El documento recoge las opiniones de líderes del mercado que presentan las tendencias globales y sus aplicaciones en el contexto brasileño: La inteligencia artificial será el gran pilar de la transformación digital, impulsando la automatización, la personalización y la eficiencia. El uso de datos para la toma de decisiones estratégicas será imprescindible. La necesidad de un procesamiento descentralizado y de respuestas rápidas situará al «Edge Computing» en el centro de la innovación, junto con el crecimiento de las soluciones en la nube. La infraestructura 5G desempeñará un papel decisivo, al permitir el funcionamiento de redes más rápidas y el desarrollo de soluciones avanzadas, como las ciudades inteligentes y la automatización industrial. La TI verde y las prácticas ESG cobrarán protagonismo, gracias a la optimización del consumo energético y a la adopción de soluciones sostenibles en los centros de datos. La calidad del servicio y la reducción de la tasa de abandono serán factores diferenciadores competitivos. Las empresas que se centren en la excelencia y en la adopción de herramientas de gestión destacarán. La visión de Made4it – Guilherme Ganascim En el contexto de estas tendencias, Guilherme Ganascim, director comercial de Made4it, ha aportado valiosas reflexiones en la página 54 del informe. Reitera que el gran reto para 2025 será mantener la cartera de clientes en un mercado saturado, y destaca tres estrategias fundamentales: Como destaca Guilherme: «La banda ancha ya no se reduce únicamente a velocidades y precios, sino que se trata de ofrecer una mejor calidad de experiencia». Made4it, gracias a su experiencia en soluciones tecnológicas innovadoras, se posiciona como un socio imprescindible para las empresas que buscan la excelencia en la atención al cliente y la innovación en sus operaciones. Otros aspectos destacados del informe El informe «IPV7 Predictions» también contó con las aportaciones de directivos de otras empresas que comparten una visión en consonancia con las principales tendencias para 2025: Vero Internet – Fabiano Ferreira, director ejecutivo, prevé que el 5G, junto con la inteligencia artificial, constituirá la base para la personalización y la optimización de los servicios, y que irá más allá de la conectividad para ofrecer soluciones integradas. Zadara – Robson Andrade, director nacional, destaca la consolidación del «Edge Computing», esencial para hacer frente al aumento de datos y a las demandas en tiempo real impulsadas por el IoT. Elea Digital Data Centers: Wesley Barbosa, director comercial, destaca el potencial de Brasil para convertirse en un centro mundial de inteligencia artificial, gracias a su matriz energética limpia y a su capacidad de expansión en materia de infraestructura digital. Estas empresas, al igual que Made4it, se encuentran a la vanguardia de la innovación, con estrategias claras para afrontar los retos y aprovechar las oportunidades en 2025. Conclusión: Preparándose para un futuro de innovación y calidad El informe «IPV7 Predictions 2025» es una guía imprescindible para los líderes que desean anticiparse a los cambios y liderar el mercado. Tendencias como la inteligencia artificial, la computación en el borde, el 5G y los criterios ESG apuntan hacia un futuro en el que la innovación y la calidad de la experiencia del cliente serán factores determinantes. Made4it, gracias a la contribución de Guilherme Ganascim, reitera su compromiso de ofrecer soluciones sólidas y personalizadas, ayudando a las empresas de TI y telecomunicaciones a posicionarse con excelencia en el mercado. DESCARGUE EL LIBRO ELECTRÓNICO IPV7. Previsiones para 2025.pdf