SD-WAN empresarial para conectar sucursales, nube y centros de datos con políticas por aplicación

¿Qué es SD-WAN?

Es una forma de construir y administrar una red WAN mediante funciones de borde, control centralizado, políticas y una red lógica superpuesta sobre los servicios de conectividad disponibles.

Las siglas SD-WAN significan Software-Defined Wide Area Network, traducido como red de área amplia definida por software. La expresión describe una arquitectura y un conjunto de funciones; no corresponde a un único protocolo, equipo o fabricante.

Una WAN conecta ubicaciones que no forman parte de la misma red local, como oficinas centrales, sucursales, centros de datos, servicios en nube y sitios remotos. SD-WAN añade una capa de administración y políticas que puede utilizar diferentes servicios de transporte para comunicar esas ubicaciones.

En lugar de tomar todas las decisiones únicamente a partir de una dirección de destino y una ruta estática, la plataforma puede considerar la aplicación, el grupo de usuarios, el segmento, la prioridad, la disponibilidad del camino y métricas de desempeño observadas.

El comportamiento concreto depende de la plataforma, los enlaces, las licencias, la topología y las políticas configuradas. Por ello, dos soluciones descritas como SD-WAN pueden ofrecer funciones y alcances diferentes.

¿Cómo funciona una red SD-WAN?

La solución conecta funciones de borde a uno o varios servicios de transporte, establece una red lógica, identifica tráfico, mide caminos y aplica políticas para determinar cómo debe reenviarse cada flujo.

1. Se identifican las ubicaciones. Se registran oficinas, sucursales, centros de datos, nubes, redes locales y recursos que necesitan comunicarse.
2. Se inventarían los enlaces. Se documentan proveedores, capacidades, medios, direcciones, condiciones, rutas, contratos y características de cada servicio.
3. Se definen los objetivos. Se establecen aplicaciones prioritarias, segmentos, destinos, necesidades de seguridad, tolerancia a degradaciones y criterios de continuidad.
4. Se incorporan las funciones de borde. Los equipos o instancias virtuales se conectan con las redes locales y con los servicios WAN disponibles.
5. Se registran en la plataforma. Las funciones de borde reciben identidad, configuración, políticas, certificados o credenciales de acuerdo con la arquitectura.
6. Se establecen caminos lógicos. La solución crea las relaciones necesarias entre ubicaciones sobre uno o varios servicios de transporte.
7. Se intercambia información de rutas. Las redes locales, prefijos, segmentos y destinos se anuncian mediante mecanismos compatibles con el diseño.
8. Se clasifica el tráfico. Los paquetes o sesiones se agrupan como aplicaciones, categorías, usuarios, redes, protocolos o destinos.
9. Se mide cada camino. La solución puede observar disponibilidad, retardo, variación del retardo, pérdida y otras condiciones definidas.
10. Se aplican las políticas. Las reglas determinan la prioridad, los caminos permitidos, los umbrales, la segmentación y los tratamientos correspondientes.
11. Se selecciona una ruta. Cada flujo se reenvía mediante el camino que cumpla los criterios disponibles en ese momento.
12. Se reacciona a cambios. Cuando un enlace falla o supera un umbral, la plataforma puede redirigir tráfico hacia otra ruta permitida.
13. Se recopila telemetría. La plataforma registra eventos, utilización, aplicaciones, rutas y comportamiento observado.
14. Se ajustan políticas. Las reglas pueden modificarse conforme cambian las aplicaciones, ubicaciones, enlaces y prioridades del negocio.

¿Dónde se utiliza SD-WAN?

Puede utilizarse en organizaciones con varias ubicaciones, aplicaciones distribuidas, servicios en nube o diferentes medios de conectividad que necesitan administrarse mediante políticas comunes.

Ventajas específicas de SD-WAN

Una arquitectura correctamente diseñada puede facilitar la administración de redes distribuidas y adaptar el encaminamiento a las necesidades de las aplicaciones.

• Administración centralizada. Las políticas y configuraciones pueden coordinarse desde una plataforma común, según las capacidades disponibles.
• Políticas por aplicación. El tratamiento puede diferenciar voz, video, sistemas empresariales, servicios en nube y otros grupos de tráfico.
• Uso de diferentes transportes. La arquitectura puede integrar enlaces con tecnologías, operadores y características distintas.
• Selección dinámica de caminos. El tráfico puede cambiar hacia una ruta permitida cuando el camino principal falla o supera los umbrales establecidos.
• Respuesta ante degradaciones. Las decisiones pueden considerar pérdida, retardo y variación, además de la disponibilidad básica.
• Mayor visibilidad. La telemetría puede mostrar aplicaciones, enlaces, ubicaciones, eventos y utilización.
• Consistencia entre sucursales. Las plantillas y políticas pueden reducir diferencias producidas por configuraciones manuales independientes.
• Incorporación ordenada de ubicaciones. La orquestación puede facilitar el despliegue de nuevas sucursales mediante configuraciones preparadas.
• Acceso a nube. Las políticas pueden evitar recorridos innecesarios y dirigir tráfico hacia servicios en nube mediante rutas apropiadas.
• Segmentación. La red lógica puede mantener separados diferentes grupos de tráfico de acuerdo con el diseño.
• Flexibilidad comercial. Puede combinar servicios de transporte con costos, capacidades y coberturas diferentes.
• Migración gradual. La organización puede conservar determinados enlaces y añadir nuevos servicios por etapas.
• Priorización de aplicaciones. Las políticas pueden reservar tratamiento preferente para tráfico sensible a retardo o pérdida.
• Información para diagnóstico. Los registros ayudan a distinguir problemas del enlace, la ruta, la aplicación, la política o la ubicación.
• Preparación para automatización. Algunas plataformas ofrecen plantillas, APIs y flujos que pueden reducir tareas repetitivas.
• Integración con seguridad. La arquitectura puede enviar determinados flujos hacia controles locales o servicios de seguridad definidos.
• Mejor aprovechamiento de enlaces secundarios. Un servicio alterno puede transportar tráfico permitido durante la operación normal, en lugar de permanecer completamente inactivo.

Consideraciones antes de implementar SD-WAN

La selección de una plataforma debe partir de aplicaciones, ubicaciones, enlaces, seguridad, operación y objetivos verificables. Las funciones publicitadas deben comprobarse con el diseño y las condiciones reales.

• Objetivo del proyecto. Debe definirse si se busca mejorar administración, disponibilidad, acceso a nube, visibilidad, expansión, seguridad o una combinación específica.
• Inventario de ubicaciones. Es necesario documentar oficinas, sucursales, centros de datos, nubes, sitios temporales y redes remotas.
• Inventario de aplicaciones. Deben identificarse destinos, protocolos, dependencias, usuarios, horarios y sensibilidad a pérdida o retardo.
• Flujos críticos. Conviene establecer qué tráfico debe conservar prioridad durante una degradación o reducción de capacidad.
• Topología actual. Se deben registrar rutas, concentradores, salidas a Internet, VPN, firewalls, centros de datos y conexiones con terceros.
• Plan de direccionamiento. Deben revisarse prefijos, redes superpuestas, traducciones, direcciones públicas, IPv4 e IPv6.
• Servicios DHCP y DNS. La migración debe considerar dónde se encuentran, cómo se alcanzan y qué ocurre durante un cambio de ruta.
• Protocolos de enrutamiento. Debe verificarse la compatibilidad con rutas estáticas, BGP, OSPF u otros mecanismos utilizados.
• Redistribución de rutas. Las reglas deben evitar bucles, anuncios no deseados y pérdida de información de preferencia.
• Rutas predeterminadas. Es necesario definir dónde se origina la salida y cómo cambia entre enlaces, túneles o servicios de seguridad.
• Asimetría. Debe evaluarse si el tráfico de ida y regreso puede atravesar rutas distintas y cómo afecta firewalls, traducciones y aplicaciones.
• Enlaces disponibles. Se deben documentar capacidad, entrega, medio, operador, direccionamiento, equipo terminal y condiciones contractuales.
• Diversidad de operadores. Contratar proveedores diferentes no garantiza rutas físicas completamente independientes.
• Diversidad física. Conviene revisar accesos al inmueble, postes, ductos, registros, centrales, energía y tramos compartidos.
• Última milla. Dos enlaces pueden compartir infraestructura antes de llegar al sitio.
• Conectividad móvil. Cobertura, señal, capacidad, política de uso, NAT, límites de datos y variación deben comprobarse en el lugar.
• Conectividad satelital. El retardo, la visibilidad, las políticas del operador y las condiciones ambientales pueden modificar su uso.
• Capacidad ascendente y descendente. Los enlaces asimétricos deben evaluarse en ambas direcciones.
• Congestión. La utilización debe analizarse por horario, aplicación, ubicación y sentido del tráfico.
• Calidad del underlay. SD-WAN depende del comportamiento real de los servicios de transporte.
• Acuerdos de nivel de servicio. Deben diferenciarse los compromisos del operador de los umbrales internos utilizados por SD-WAN.
• Métricas. Deben definirse retardo, variación, pérdida, disponibilidad y periodos de cálculo relevantes.
• Dirección de las mediciones. Un enlace puede comportarse de forma diferente en cada sentido.
• Frecuencia de medición. Intervalos muy largos pueden reaccionar tarde e intervalos demasiado agresivos pueden provocar cambios inestables.
• Umbrales. Deben relacionarse con las aplicaciones y no copiarse sin validar el entorno.
• Histéresis. La política debe evitar cambios repetitivos cuando una métrica oscila cerca del límite.
• Recuperación del enlace. Debe definirse cuándo y cómo regresa el tráfico al camino preferido.
• Clasificación de aplicaciones. Debe verificarse qué tráfico puede identificarse de manera confiable.
• Tráfico cifrado. El cifrado puede limitar la visibilidad disponible para clasificar aplicaciones.
• Aplicaciones compartidas. Distintos servicios pueden utilizar los mismos dominios, proveedores de nube o redes de distribución.
• Aplicaciones personalizadas. Puede ser necesario definir reglas mediante direcciones, puertos, segmentos u otros identificadores.
• Políticas por negocio. La prioridad técnica debe reflejar la importancia real y no únicamente el nombre de la aplicación.
• Calidad de servicio. Deben revisarse marcado, colas, límites, conformación y tratamiento en cada dominio.
• Mapeo de DSCP. Los valores pueden conservarse, modificarse o ignorarse al atravesar diferentes proveedores.
• Ancho de banda reservado. La prioridad no crea capacidad cuando el enlace está saturado.
• Voz y video. Deben probarse calidad, establecimiento de llamadas, señalización, medios y comportamiento durante cambios de ruta.
• Transferencias grandes. Respaldos, actualizaciones y replicación pueden competir con aplicaciones interactivas.
• MTU. Los túneles añaden encabezados y pueden reducir el tamaño útil de los paquetes.
• Fragmentación. Deben revisarse descubrimiento de MTU, bloqueos de mensajes de control y aplicaciones sensibles.
• NAT. La traducción de direcciones puede modificar el establecimiento de túneles, rutas y continuidad de sesiones.
• Direcciones públicas. Algunos diseños requieren direcciones o comportamientos específicos del operador.
• Equipos del proveedor. Módems, ONT, routers y firewalls existentes pueden necesitar modo puente, rutas o configuraciones coordinadas.
• Capacidad del equipo de borde. Deben revisarse rendimiento, sesiones, túneles, rutas, puertos y usuarios soportados.
• Rendimiento cifrado. La capacidad con cifrado y funciones habilitadas puede diferir de la cifra máxima publicada.
• Servicios simultáneos. Inspección, filtrado, registro y otras funciones pueden consumir recursos.
• Alta disponibilidad del borde. Debe definirse si existirá un equipo, dos equipos, rutas separadas y sincronización de estado.
• Falla del equipo local. Tener dos enlaces no resuelve una falla del único equipo que los conecta.
• Falla de energía. Equipos, módems y terminaciones requieren respaldo compatible con el objetivo de continuidad.
• Plano de control. Debe analizarse qué ocurre si una sucursal pierde comunicación con los controladores.
• Plano de administración. La indisponibilidad del portal no debería confundirse automáticamente con pérdida del tráfico.
• Ubicación de controladores. Debe identificarse si se encuentran en nube, centro de datos, servicio del fabricante o instalación propia.
• Dependencia de Internet. Algunas funciones de incorporación, licenciamiento o control pueden necesitar conectividad externa.
• Seguridad de los túneles. Deben definirse algoritmos, autenticación, gestión de claves y tráfico que requiere cifrado.
• Cifrado no universal. No debe asumirse que todos los caminos o flujos están cifrados sin revisar la política.
• Identidad de los equipos. Certificados, credenciales y procesos de incorporación deben protegerse.
• Acceso administrativo. Deben utilizarse roles, mínimo privilegio, autenticación reforzada y registros.
• Separación de funciones. Conviene distinguir administración, operación, seguridad, auditoría y soporte.
• Salida directa a Internet. Deben definirse controles equivalentes a los riesgos de cada ubicación.
• Firewall. La presencia de funciones básicas de filtrado no equivale automáticamente a una plataforma completa de seguridad.
• Integración SASE o SSE. Deben confirmarse proveedor, puntos de presencia, encaminamiento, licencias y funciones contratadas.
• DNS seguro. La resolución debe coordinarse con las salidas, los segmentos y los servicios de protección.
• Segmentación. Deben definirse zonas, rutas permitidas, excepciones y puntos donde se aplican los controles.
• Tráfico entre segmentos. La separación lógica debe acompañarse de reglas explícitas para las comunicaciones necesarias.
• Integración con redes locales. VLAN, switches, gateways, WiFi y firewalls deben coordinarse con el borde SD-WAN.
• IPv6. Debe comprobarse el soporte en enlaces, túneles, políticas, rutas, seguridad y monitoreo.
• Servicios de nube. Deben definirse regiones, redes virtuales, gateways, costos de transferencia y rutas.
• Instancias virtuales. Deben revisarse recursos, imágenes, disponibilidad, licencias y responsabilidad de actualización.
• Conectividad multinube. Cada proveedor puede utilizar mecanismos, regiones y costos distintos.
• Ubicaciones temporales. Deben considerarse seguridad física, conectividad, inventario y retiro controlado.
• Telemetría. Debe definirse qué se mide, durante cuánto tiempo y quién puede consultarlo.
• Registros. Eventos, cambios, accesos, rutas y alertas requieren sincronización horaria y conservación adecuada.
• Integración con SIEM. Deben confirmarse formatos, APIs, volumen, licencias y responsabilidades.
• Alertas. Cada alerta necesita umbral, destinatario, prioridad y procedimiento de respuesta.
• Paneles. La información visible depende de la telemetría y licencias habilitadas.
• APIs. Deben revisarse autenticación, límites, versiones, permisos y compatibilidad.
• Automatización. Los cambios automáticos necesitan validación, control de versiones y mecanismos de reversión.
• Respaldo de configuración. Debe definirse cómo recuperar políticas, plantillas, certificados y parámetros.
• Actualizaciones. Se deben establecer versiones, ventanas, pruebas, compatibilidad y retorno a una versión anterior.
• Vulnerabilidades. El ciclo de vida debe contemplar avisos, parches, exposición y priorización.
• Fin de soporte. Equipos, software y licencias necesitan una ruta de renovación.
• Modelo de licenciamiento. Deben confirmarse funciones, vigencia, capacidad, ubicaciones, soporte y costos recurrentes.
• Dependencia del fabricante. Debe evaluarse la posibilidad de exportar configuraciones, datos y registros.
• Interoperabilidad. Las funciones entre plataformas diferentes no deben asumirse sin pruebas.
• Prueba piloto. Conviene utilizar ubicaciones y aplicaciones representativas antes de una migración completa.
• Línea base. Deben medirse desempeño, uso y fallas antes de cambiar la arquitectura.
• Criterios de aceptación. El proyecto debe definir rutas, aplicaciones, eventos, rendimiento y resultados esperados.
• Pruebas de degradación. Deben simularse pérdida, retardo, variación y reducción de capacidad.
• Pruebas de falla. Es necesario comprobar enlaces, equipos, energía, túneles, controladores y rutas.
• Pruebas de recuperación. Debe observarse qué ocurre cuando el componente o enlace vuelve a operar.
• Sesiones existentes. Las aplicaciones deben probarse durante cambios de camino.
• Migración por etapas. Conviene definir secuencia, coexistencia, dependencias y sitios de validación.
• Ventana de cambio. Deben establecerse horarios, responsables, comunicación y criterios para detener la migración.
• Plan de reversión. La red anterior debe poder restaurarse cuando no se cumplan los criterios.
• Documentación. Deben entregarse diagramas, inventarios, rutas, plantillas, políticas, licencias y resultados.
• Capacitación. Operadores, mesa de ayuda y seguridad deben conocer el nuevo modelo.
• Responsabilidades. Debe separarse la atención del enlace, equipo, software, nube, seguridad y aplicación.
• Escalamiento. Conviene documentar contactos, horarios, niveles y evidencias requeridas.
• Operación administrada. No debe asumirse que monitoreo, cambios o soporte continuo forman parte de la implementación.
• Cumplimiento. Los registros, rutas, cifrado y ubicación de los servicios deben revisarse conforme a las obligaciones de la organización.
• Privacidad. La telemetría puede contener direcciones, nombres, usuarios, aplicaciones y otros datos operativos.
• Costos totales. Deben incluirse enlaces, equipos, licencias, suscripciones, nube, seguridad, soporte, instalación y renovación.

Relación con otras soluciones de Conectividad empresarial

SD-WAN administra la comunicación entre ubicaciones y caminos WAN. La disponibilidad, el acceso local, el uso de enlaces y la información operativa se complementan con otros subservicios de conectividad.

• Redes de alta disponibilidad: contemplan la eliminación o reducción de puntos únicos de falla en equipos, enlaces, energía, topologías y servicios críticos.
• WiFi empresarial: proporciona el acceso inalámbrico local de usuarios y dispositivos que posteriormente utilizan la red WAN y los servicios de Internet.
• Balanceo de enlaces: distribuye tráfico entre conexiones y puede proporcionar rutas alternativas sin implicar necesariamente una arquitectura SD-WAN multisede.
• Analítica de redes: organiza métricas, eventos y tendencias para comprender utilización, desempeño y comportamiento de la conectividad.

Cobertura y atención de proyectos SD-WAN en México

Solidem contempla la atención de proyectos relacionados con SD-WAN en todo México, de acuerdo con la ubicación de las sedes, infraestructura disponible, operadores, alcance y condiciones de ejecución.

La revisión puede considerar oficinas corporativas, sucursales, hoteles, escuelas, hospitales, tiendas, gasolineras, centros logísticos, plantas, centros de datos, servicios en nube y ubicaciones remotas.

Para delimitar el proyecto resulta útil contar con la lista de ubicaciones, diagramas, enlaces contratados, proveedores, capacidades, direccionamiento, aplicaciones, redes locales, servicios en nube, equipos existentes, necesidades de seguridad y calendario de migración.

La disponibilidad de enlaces, cobertura móvil, rutas físicas, tiempos de instalación, permisos y condiciones comerciales debe confirmarse para cada ubicación.