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
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.
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.
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. Baixar e-bookFalar no WhatsApp
Cómo configurar vlans en dispositivos Ufispace
Este artículo te mostrará cómo configurar vlans en dispositivos Ufispace en modo troncal, híbrido y de acceso. En primer lugar, aquí tienes una guía paso a paso sobre cómo crear una VLAN: Accede al modo privilegiado: Accede al modo de configuración: Crea un Puente y configura el protocolo RSTP (requisito de OcNos). Crear VLAN y asociarla al bridge creado: Salir del modo «vlan database» Comprobar las configuraciones pendientes: Resultado esperado del comando anterior: Si necesitas deshacer los ajustes, puedes utilizar el comando Si los ajustes son correctos, se pueden aplicar con el comando Para comprobar la configuración de la VLAN: Una vez creada la Vlan, hay que asignarla a una interfaz, en modo TAG o UNTAGGGED (en acceso). Cómo configurar la VLAN en modo Trunk: Interfaz de acceso: Configura en modo Layer2 y asigna una Bridge (creado previamente): Configura el modo de interfaz en Troncal: Configura la vlan en TAG en la interfaz: Comprueba la configuración y aplícala: Cómo configurar la VLAN en modo Acceso Crear VLAN y asociarla al bridge creado: Interfaz de acceso: Configura en modo Layer2 y asigna un Puente: Configura el modo de interfaz en Troncal: Establece vlan como UNTAGGGED en la interfaz: Comprueba la configuración y aplícala: Cómo configurar la VLAN en modo Hybrid Interfaz de acceso: Configura en modo Layer2 y asigna un Puente: Establece el modo de interfaz en Hybrid: Establece vlan como UNTAGGGED en la interfaz: Configura vlan en TAGGED en la interfaz: Comprueba la configuración y aplícala: Resumen de todos los ajustes aplicados: Una vez completadas todas estas configuraciones detalladas, estará en condiciones de gestionar las VLAN de forma eficiente en los equipos de Ufispace, lo que garantizará una red organizada y segura. Siga los pasos con atención y, en caso de dudas, no dude en consultar la documentación oficial o ponerse en contacto con el servicio de asistencia técnica especializada. ¿Le gustaría hablar con uno de nuestros especialistas en UfiSpace e IPInfusion? En Made4it somos especialistas en estas tecnologías y ofrecemos servicios completos de configuración y asistencia técnica. Póngase en contacto con nuestros asesores para obtener más información y optimizar su red con soluciones profesionales: https://made4it.com.br/
SRv6: ¿un sucesor del MPLS?
En Made4it nos apasiona la evolución, y el SRv6 ha sido motivo de gran entusiasmo y debate entre nuestros equipos y la comunidad. Un protocolo que intente competir directamente con el MPLS sin duda debe analizarse con mucho detenimiento. Vamos a conocerlo un poco mejor en una serie de artículos sobre el tema. En los últimos años, la evolución de las redes se ha visto impulsada por unas demandas cada vez mayores de escalabilidad, flexibilidad y eficiencia. En este escenario dinámico, tecnologías como el MPLS (Multiprotocol Label Switching) han surgido como soluciones predominantes para satisfacer las complejas necesidades de enrutamiento y gestión del tráfico. Sin embargo, con el avance de las aplicaciones y los servicios digitales, han surgido retos que el MPLS tradicional no lograba resolver de manera eficiente. Las necesidades constantes de las redes, junto con nuevas tecnologías como el 5G, el IoT, los vehículos autónomos y todo un ecosistema en crecimiento exponencial, EXIGEN que las redes de comunicación se adapten a las nuevas demandas y necesidades. Es aquí donde el Segment Routing sobre IPv6 (SRv6) entra en escena como una alternativa innovadora que satisface estos requisitos con sencillez y elegancia. MPLS: la tecnología heredada El MPLS se introdujo a finales de la década de 1990 y ganó popularidad rápidamente gracias a su capacidad para proporcionar un enrutamiento de paquetes basado en etiquetas (las famosas «labels»), lo que permite un mayor control sobre el flujo de tráfico y una mejor calidad de servicio (QoS). En la década de 2000, el MPLS se convirtió en la opción preferida de los proveedores de servicios y las empresas que buscaban soluciones robustas para redes a gran escala, centros de datos e interconexiones entre redes. Para los proveedores de servicios, la escalabilidad y la facilidad que ofrecía el MPLS hicieron que su implementación en sus redes resultara inevitable. Esto permitió a los proveedores de servicios desarrollar y comercializar nuevos productos, lo que culminó en que las empresas conectaran sus sedes centrales y sucursales de forma transparente, que los operadores de telefonía móvil lograran expandir sus redes de forma masiva, entre otras muchas innovaciones que se produjeron con el tiempo, a medida que Internet dejaba de ser propiedad de las grandes corporaciones para pasar a ser de las personas. Necesidades y limitaciones del MPLS: Toda tecnología tiene aspectos positivos y negativos, y se diseña y desarrolla para satisfacer una o varias necesidades en un momento determinado. A medida que pasa el tiempo, las redes crecen y siguen evolucionando, lo que implica que surgen constantemente nuevas necesidades que quizá no puedan satisfacerse con dichas tecnologías. En el caso del MPLS no ha sido diferente: a medida que las redes han continuado creciendo y evolucionando, algunas limitaciones del MPLS han comenzado a hacerse muy evidentes. Complejidad operativa: La gestión y la configuración de las redes MPLS, en función de su tamaño y de las «funcionalidades» que requiera la red, pueden resultar complejas y exigir conocimientos altamente especializados. Escalabilidad: A medida que las redes crecen, resulta complicado ampliar las infraestructuras MPLS sin aumentar significativamente los costes y la complejidad de la red. Existen técnicas y buenas prácticas para este tipo de implementaciones, pero, al igual que cualquier otra tecnología, el MPLS también tiene sus limitaciones en cuanto a escalabilidad. En muchos casos, el precio de la escalabilidad de una red MPLS es un uso cada vez mayor de recursos de procesamiento en los equipos de red, tablas de enrutamiento cada vez más extensas y entornos de red cada vez más delicados. Esto aumenta inevitablemente los gastos de capital (CAPEX) y los gastos operativos (OPEX) de la operación, llegando a puntos en los que resulta completamente inviable mantener dicha tecnología en funcionamiento en la red y obliga a buscar arquitecturas de red alternativas para mantener el entorno operativo. Flexibilidad limitada: MPLS se diseñó para escenarios específicos y puede que no se adapte fácilmente a las nuevas demandas de tráfico y a los servicios emergentes. Con la aparición de nuevas tecnologías como el 5G y las nuevas necesidades que plantean el IoT y las innovaciones tecnológicas en el ámbito de los vehículos autónomos y la telemedicina, resulta necesario disponer de alternativas para la segregación de la red a nivel de topología (Slicing), además de la segmentación del tráfico según prioridades tales como rutas de baja latencia y alto tráfico, baja latencia y bajo tráfico, alto tráfico sin tener en cuenta la latencia, y así sucesivamente. En la actualidad, el MPLS no es capaz de satisfacer estas nuevas demandas con sus mecanismos heredados. SRv6: La innovación en el enrutamiento por segmentos El Segment Routing sobre IPv6 (SRv6) es una tecnología de nueva generación que combina el Segment Routing (SR) y el IPv6, aprovechando los mecanismos de enrutamiento ya existentes en el IPv6. Mediante el uso de una extensión de la cabecera IPv6 como medio para la identificación y el enrutamiento de la información dentro de una red, el SRv6 aporta ventajas tanto en el plano de control como en el plano de datos de los equipos de red, con un menor coste y un mayor rendimiento. El SRv6 se diseñó desde el principio teniendo en cuenta las necesidades actuales y futuras, por lo que es altamente programable y totalmente flexible para adaptar tanto las redes heredadas como los nuevos entornos de red. Con el concepto de «programabilidad» ya consolidado, el SRv6 ofrece a la red la capacidad de codificar instrucciones individuales para los paquetes directamente en su encabezado. En el «SR-MPLS» (Segment Routing MPLS), estas instrucciones se transportan en etiquetas (labels) MPLS; en SRv6, dichas instrucciones se transportan de forma nativa en la cabecera IPv6 mediante la incorporación de una extensión denominada SRH, o Segment Routing Header. Características y ventajas de SRv6. Comparación con tecnologías heredadas Al comparar el SRv6 con tecnologías heredadas como el MPLS, resulta evidente que el SRv6 ofrece un enfoque más sencillo, flexible y adaptable a las necesidades actuales de las redes de comunicación. Si bien el MPLS sigue siendo una solución viable para muchos
Opción 43 de DHCP para la configuración automática de ACS
Hoy vamos a analizar la famosa opción 43 de DHCP, que se utiliza principalmente en la autoconfiguración de dispositivos como puntos de acceso, conmutadores, teléfonos IP, CPE, dispositivos IoT y otros a través del protocolo TR-069. Asimismo, le mostraremos un ejemplo de configuración utilizando el servidor DHCP de un router Mikrotik, que proporciona parámetros a través de la opción 43 de DHCP y permite la autoconfiguración de servicios durante el proceso de asignación de la dirección IP al dispositivo. Esto nos permite, por ejemplo, detectar automáticamente un controlador externo al dispositivo, incluso si el equipo ha sido restablecido a los valores de fábrica. El documento RFC 2132 «DHCP Options and BOOTP Vendor Extensions» [1] aborda diversos tipos de información que pueden enviarse a través del protocolo DHCP, como, por ejemplo, el DNS, la máscara de subred, la dirección de la puerta de enlace (enrutador), los atributos específicos del proveedor y muchos otros. La Opción 43 se define en este RFC como «Vendor Specific Information» y se utiliza para que los clientes y los servidores DHCP intercambien información específica entre sí. El RFC no especifica qué valores se pueden enviar, ni de qué tipo de información se trata, y mucho menos el tipo de datos. Se limita a describir la estructura, que debe ser la siguiente: Código Len Información específica del proveedor 43 n i1 i2 … Código 1 Len 1 Fecha 1 Código 2 Len 2 Fecha 2 Código n Len n Fecha n T1 n1 d1 T2 n2 T2 … … … Con esta estructura, cada fabricante u organización puede estructurar los datos de la forma que le resulte más conveniente para su uso. Por ejemplo, para que los puntos de acceso puedan configurarse con las direcciones IP de los controladores Wi-Fi, lo que permite su «incorporación» al controlador centralizado; para que los teléfonos IP dispongan de la dirección IP o la URL del servidor de telefonía; y para que los routers compatibles con TR-069 puedan configurarse con la URL del ACS. ¡Y todo ello de forma automática! El objetivo de este artículo es mostrar el uso de la opción 43 junto con TR-069, enviando la URL del servidor ACS al CPE a través del servidor DHCP. Esto nos permite que el router, incluso si se ha reiniciado y carece de una «plantilla» de configuración, obtenga a través de DHCP la URL del servidor ACS, junto con el nombre de usuario y la contraseña, datos necesarios para integrarse en el ACS y permitir que el TR-069 aplique automáticamente las configuraciones en el CPE. Pero antes de continuar, voy a dejar algunos enlaces a otros ejemplos de casos de uso de la opción 43. Configure la opción 43 de DHCP para los puntos de acceso ligeros: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html Detección de ID de VLAN a través de DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Utilice la opción 43 de DHCP para la configuración de los puntos de acceso Unifi:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ ¿Cómo llegó el DHCP al TR-069? Si no sabe qué es el ACS, consulte nuestro otro artículo. El DHCP se ha incorporado como una de las formas de incorporación del ACS. La incorporación es el proceso mediante el cual se configura el CPE o el router con un servidor ACS.Existen tres formas de llevar a cabo el proceso de incorporación de los CPE a un servidor ACS, según la especificación TR-069 del Broadband Forum [2]: El objetivo final de cualquiera de los tres es el mismo: tener la URL del servidor ACS configurada en el CPE, para que este pueda gestionarse a través del protocolo TR-069. Proceso de solicitud de la opción 43 de DHCP El BroadBand Forum establece una serie de pasos para que el CPE pueda obtener la URL del ACS a través de DHCP. La siguiente imagen muestra los pasos, y a continuación vamos a comentar cada uno de ellos. Pasos a seguir en la comunicación: En la especificación del TR-069 también se definen otros campos o protocolos que pueden utilizarse con el mismo fin: la opción 125 de DHCPv4 y la opción 17 de DHCPv6. Asimismo, se mencionan diversas reglas de detección tras un reinicio y cómo abordar los problemas de conectividad con el ACS. Sin embargo, quedan fuera del alcance de este artículo. Ejemplo de una transacción DHCP con la opción 43: capturas de paquetes Ejemplo de configuración en Mikrotik En este artículo, veremos cómo configurar un router Mikrotik para que, a través del servidor DHCP, proporcione parámetros de autoconfiguración a los «clientes» mediante la opción 43. La configuración se basará en la topología que se muestra a continuación, similar a la utilizada en nuestras pruebas con un CPE de Nokia. En primer lugar, es necesario configurar el servidor DHCP y, a continuación, vincular los ajustes de la opción DHCP 43. Utilizamos la red 192.168.2.0/24 y la VLAN 881, tal y como se muestra en nuestro ejemplo: Seguramente se estará preguntando: ¿de dónde ha salido ese valor de la opción 43? Efectivamente, existe una regla que hay que crear, y en el siguiente artículo podrá consultar cómo generarla para su servidor ACS. Conclusión En este artículo, explicamos cómo utilizar el atributo «Option43» de DHCP para la autoconfiguración de un servidor ACS en CPE y diversos dispositivos. Analizamos su funcionamiento y cómo puede utilizarse para automatizar el envío de configuraciones específicas a los dispositivos mediante un protocolo tan habitual como el DHCP. Conocer las capacidades, características y opciones que admiten el fabricante y el modelo del equipo nos ayuda a automatizar diversas configuraciones, entre las que se incluye, entre otras, la gestión de un CPE de Nokia a través del protocolo TR-069. Referencias:[1] RFC 2132, Opciones DHCP y extensiones de fabricante de BOOTP, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, Protocolo de gestión de CPE en WAN, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
Creación de VPN usando PFSense y OpenVPN
Básicamente, VPN significa Red Privada Virtual (o Red Privada Virtual), y sirve como un túnel entre dos puntos de conexión. Al establecer una VPN entre un ordenador de su domicilio y un PFSense de su empresa, por ejemplo, el túnel creado hace que su ordenador pueda actuar como si estuviera «dentro» de la red local de su empresa, lo que le permite acceder a servidores y equipos, siempre y cuando se pueda acceder al PFSense desde su ordenador doméstico. Ahora que entendemos de qué se trata VPN, aprendamos cómo configurar usando PFSense para establecer la conexión entre sus diferentes redes. Configuración de la VPN Vamos a utilizar el «asistente» del propio PFSense para esta configuración. Para ello, accedemos al menú VPN > OpenVPN. A continuación, haga clic en la pestaña Asistentes: Bueno, eso es todo, amigos: esta ha sido nuestra guía de configuración de OpenVPN con PFSense y de cómo conectarse a ella mediante el cliente OpenVPN, utilizando los archivos proporcionados por el propio PFSense.Si necesita ayuda o asistencia para el mantenimiento de PFSense, póngase en contacto con nosotros; ¡estaremos encantados de ayudarle!¡Gracias y hasta la próxima!
