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.
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.
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
La importancia de que un proveedor tenga su propio DNS
Un proveedor siempre busca brindar la mejor calidad de internet para sus clientes, y un factor muy importante para que podamos navegar en internet es tener configurado un servidor DNS recursivo, el porque de esto y como funciona ya lo entendemos, pero ¿Cómo tener un servidor dentro de su red mejorará aún más la navegación de sus clientes?
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!
Instalación de PFSense como Gateway de su red.
Al final del Asistente, ¡tendremos nuestro PFSense listo para usar! En próximas entradas. Te enseñaremos a crear una VPN usando PFSense, para que tengas acceso a tu Red Interna, a través de tu casa. Gracias y nos vemos en los próximos Posts. Adriano Elias de SouzaConsultor de TIMade4it
Interconexión de dos sistemas virtuales (VS) en la plataforma NE de Huawei (interconexión de 2 routers virtuales en la plataforma NE de Huawei)
La otra forma de conectar… Interconexión de dos VS mediante VPN VPWS CCC # Admin-VS ¡! Lado L2 Admin-VS interfaz Virtual-Ethernet0/2/100 ve-grupo 100 l2-terminar interfaz Virtual-Ethernet0/2/100.100 vlan-type dot1q 100 ¡! Lado L2 VS1 interfaz Virtual-Ethernet0/2/200 ve-grupo 200 l2-terminar interfaz Virtual-Ethernet0/2/200.100 vlan-type dot1q 100 ! Interconexión MPLS CCC VPWSccc prueba interfaz Virtual-Ethernet0/2/100.100 etiquetada salida interfaz Virtual-Ethernet0/2/200.100 etiquetada # Admin-VS ¡! Lado L3 Admin-VS interfaz Virtual-Ethernet0/2/101 dirección-mac c4b8-b434-ab45 ve-group 100 l3-access interfaz Virtual-Ethernet0/2/101.100 vlan-type dot1q 100 dirección ip 10.1.1.1 255.255.255.252 ¡! Lado L3 VS1 interfaz Virtual-Ethernet0/2/201 ve-group 200 l3-access interfaz Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 # Admin-VSadmin virtual-system vs1 pvmb slot 3 port-mode port assign interface Virtual-Ethernet0/2/201.100 # VS1 ! Lado L3 VS1interface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 ip address 10.1.1.2 255.255.255.252 Consideraciones sobre el escenario Validaciones <HUAWEI>display vll ccctotal ccc vc : 1local ccc vc : 1, 1 activoremote ccc vc : 0, 0 activo nombre: prueba, tipo: local, estado: activo,intf1: Virtual-Ethernet0/2/100.100 (activo), puerto de acceso: falso intf2: Virtual-Ethernet0/2/200.100 (activo), puerto de acceso: falso Última hora de actividad del VC: 17/02/2020 14:40:58Tiempo total de actividad del VC: 0 días, 0 horas, 16 minutos, 37 segundos Admin-VS:<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 bytes de datos; pulse CTRL_C para interrumpir Respuesta de 10.1.1.2: bytes=56, secuencia=1, TTL=255, tiempo=1 ms Respuesta de 10.1.1.2: bytes=56, secuencia=2, TTL=255, tiempo=1 ms Respuesta de 10.1.1.2: bytes=56 Secuencia=3 TTL=255 tiempo=1 msd Respuesta desde 10.1.1.2: bytes=56 Secuencia=4 TTL=255 tiempo=1 ms Respuesta desde 10.1.1.2: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms — Estadísticas de ping de 10.1.1.2 — 5 paquetes transmitidos 5 paquetes recibidos 0,00 % de pérdida de paquetes tiempo de ida y vuelta mín./med./máx. = 1/1/1 ms VS1:<HUAWEI-vs1>ping 10.1.1.1 PING 10.1.1.1: 56 bytes de datos, pulse CTRL_C para interrumpir Respuesta de 10.1.1.1: bytes=56 Secuencia=1 ttl=255 tiempo=1 ms Respuesta desde 10.1.1.1: bytes=56 Secuencia=2 ttl=255 tiempo=1 ms Respuesta de 10.1.1.1: bytes=56 Secuencia=3 ttl=255 tiempo=1 ms Respuesta de 10.1.1.1: bytes=56 Secuencia=4 ttl=255 tiempo=1 ms Respuesta de 10.1.1.1: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms — 10.1.1.1 estadísticas ping — 5 paquete(s) transmitido(s) 5 paquete(s) recibido(s) 0,00% de pérdida de paquetes ida y vuelta min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 bytes de datos, pulse CTRL_C para interrumpir Respuesta de 10.1.1.2: bytes=56 Secuencia=1 ttl=255 tiempo=1 ms Respuesta de 10.1.1.2: bytes=56 Secuencia=2 ttl=255 tiempo=1 ms Respuesta de 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Respuesta de 10.1.1.2: bytes=56 Secuencia=4 ttl=255 tiempo=1 ms Respuesta de 10.1.1.2: bytes=56 Secuencia=5 ttl=255 tiempo=1 ms — 10.1.1.2 estadísticas ping — 5 paquete(s) transmitido(s) 5 paquete(s) recibido(s) 0,00% de pérdida de paquetes ida y vuelta min/avg/max = 1/1/1 ms <HUAWEI>displ bgp peer ID del enrutador BGP local: 192.168.88.100 Número AS local: 11111 Número total de pares: 1 Pares en estado establecido: 1 Par V AS Mensajes recibidos Mensajes enviados Cola de salida Activo/Inactivo Estado PrefRcv 10.1.1.2 4 22222 25 25 0 00:19:38 Establecido 0<HUAWEI>displ ospf peer brief (M) Indica vecino MADJ Proceso OSPF 1 con ID de enrutador 10.0.0.1 Información estadística de paresNúmero total de pares: 1 Pares en estado completo: 1—————————————————————————– Área ID Interfaz ID del vecino Estado 0.0.0.0 VE0/2/101.100 10.0.0.2 Completo<HUAWEI> displ ospfv3 peer Proceso OSPFv3 (1) Área OSPFv3 (0.0.0.0) ID de vecino Pri Estado Tiempo de inactividad Interfaz ID de instancia 10.0.0.1 1 Full/DR 00:00:38 VE0/2/201.100 0 Finalmente esto es todo amigos, no sabemos el rendimiento o impacto en la caja, sin embargo los servicios básicos funcionaron con normalidad. Si lo pruebas con tráfico, ¡háznoslo saber! Comparta sus resultados con nosotros. Si necesita ayuda , póngase en contacto con nosotros. Abrazos, Rafael Ganascim, Gabriel Henrique y Kevin Walters Equipo de consultoría TI – Made4it
