Este artículo está pensado para arquitectos de red que quieran diseñar redes de área extensa definidas por software (SD-WAN) para conectar las instalaciones locales entre sí y con Azure. En él se describe una arquitectura que permite a los clientes de Azure usar sus inversiones existentes en la plataforma, mediante la creación de superposiciones eficaces y globales de SD-WAN sobre la red troncal de Microsoft.
Situaciones aplicables
Las recomendaciones de este artículo son independientes del proveedor y se aplican a cualquier tecnología sd-WAN que no sea de Microsoft que cumpla dos requisitos previos básicos:
- Dependencia de los protocolos de tunelización que usan el Protocolo de control de transmisión (TCP) o el Protocolo de datagramas de usuario (UDP) como transporte subyacente, como ser IPSec en modo túnel ESP con NAT-Traversal.
- Compatibilidad con el Protocolo de puerta de enlace de borde (BGP) v4 para el intercambio de rutas con entidades externas. No se realiza ninguna suposición en el protocolo de enrutamiento utilizado por los dispositivos que no son de Microsoft SD-WAN para intercambiar información de enrutamiento entre sí.
Los clientes que se adhieren a estas recomendaciones pueden usar la tecnología SD-WAN que prefieran para lograr los siguientes objetivos:
- Integrar los productos SD-WAN en una red hub-and-spoke de Azure existente mediante la automatización del intercambio de rutas entre Azure Virtual Network y los dispositivos SD-WAN.
- Optimizar la conectividad (tanto en Azure como en los centros de datos locales) para las ramas con los saltos de Internet locales. El alcance de la red troncal de Microsoft, combinado con su capacidad, resistencia y directiva de enrutamiento de "patata fría" sugiere que se puede usar como una subyacente de alto rendimiento para SD-WAN globales.
- Usar la red troncal de Microsoft para todo el tráfico de Azure a Azure (entre regiones y geografías).
- Usar redes existentes de conmutación de etiquetas multiprotocolo (MPLS) como subyacentes de alto rendimiento. También se puede usar para reemplazar una red MPLS existente en un enfoque por fases que minimice el efecto en la empresa.
En las secciones siguientes se supone que el lector está familiarizado con los conceptos básicos del paradigma SD-WAN y con la arquitectura de la red troncal de Microsoft. La red troncal de Microsoft interconecta las regiones de Azure entre sí y con la red pública de Internet.
Architecture
Las organizaciones con presencia global y una superficie de Azure de varias regiones suelen usar una combinación de servicios de conectividad para implementar sus redes corporativas y conectarse a la red troncal de Microsoft:
- Los servicios de conectividad dedicados, como redes privadas virtuales del protocolo de Internet (IPVPN) MPLS, se pueden usar en los sitios más grandes, como centros de datos o sedes centrales.
- Los sitios grandes pueden incluir conectividad dedicada a la red troncal de Microsoft a través de circuitos ExpressRoute, mediante uno de los modelos de conectividad admitidos. Más concretamente, un sitio puede usar circuitos de punto a punto dedicados para conectarse a la ubicación de emparejamiento de ExpressRoute más cercana. O bien, puede aplicar su IPVPN de MPLS para acceder a circuitos ExpressRoute proporcionados por el operador de MPLS.
- Las sucursales que solo tienen conectividad a Internet pueden usar VPN ipSec para conectarse al centro de datos local más cercano y usar la conexión ExpressRoute del centro de datos para acceder a los recursos de Azure. O bien, pueden usar VPN de IPSec para conectarse directamente a redes de hub-and-spoke de Azure.
Los proyectos de SD-WAN pueden tener ámbitos diferentes en cuanto a los servicios de red tradicionales que pretenden reemplazar. Es posible que algunas organizaciones quieran seguir los vínculos dedicados o MPLS para instalaciones grandes e implementar una SD-WAN solo para reemplazar las VPN IPSec heredadas basadas en Internet en sitios pequeños. Es posible que otras organizaciones quieran ampliar sus sitios conectados a SD-WAN a MPLS y usar la red MPLS existente como una subyacente de alto rendimiento. Por último, es posible que algunas organizaciones quieran descartar sus IPVPN de MPLS o cualquier servicio de conectividad dedicado, para adoptar el paradigma SD-WAN. De este modo, pueden crear toda su red corporativa como una superposición lógica en subyacentes públicas o compartidas (la red troncal pública de Internet y la red troncal de Microsoft).
La arquitectura que se describe en este artículo admite todos los ámbitos enumerados anteriormente y se basa en los siguientes principios:
- Los dispositivos SD-WAN se implementan como aplicaciones virtuales de red (NVA) en la red hub-and-spoke de cada región de Azure y se configuran como concentradores SD-WAN que finalizan los túneles de sitios locales.
- Los dispositivos SD-WAN de Azure están configurados para establecer túneles entre sí, lo que crea una superposición de concentrador a concentrador totalmente en malla que puede transportar eficazmente el tráfico entre regiones de Azure y retransmitir el tráfico entre sitios locales geográficamente distantes, sobre la red troncal de Microsoft.
- Los dispositivos SD-WAN se implementan en todos los sitios locales cubiertos por la solución SD-WAN y están configurados para establecer túneles a las NVA SD-WAN en las regiones de Azure más cercanas. Diferentes sitios pueden usar diferentes servicios de transporte como una subyacente para los túneles, como Internet público, conectividad de ExpressRoute, etc.
- El tráfico de un sitio a cualquier destino, ya sea en Azure o en otro sitio local, se enruta a las NVA SD-WAN en la región de Azure más cercana. A continuación, se enruta a través de la superposición de concentrador a concentrador.
Los productos SD-WAN pueden usar protocolos y características propietarios para detectar, una vez establecidos dinámicamente, túneles directos entre dos sitios que pueden proporcionar un mejor rendimiento que retransmitir el tráfico a través de NVA SD-WAN en Azure.
La arquitectura de alto nivel de una SD-WAN global que usa la red troncal de Microsoft, la red troncal pública de Internet y las conexiones ER dedicadas como subyacentes se muestra en la siguiente imagen.
Figura 1: Arquitectura de alto nivel de una SD-WAN global que usa la red troncal de Microsoft, la red pública de Internet y las conexiones ER dedicadas como subyacentes. La línea discontinua negra muestra cómo se puede enrutar el tráfico entre dos sitios locales a través de NVA SD-WAN implementadas en regiones de Azure geográficamente cercanas a los sitios. La red troncal de Microsoft, debido a su alcance, capacidad y directiva de enrutamiento de "patata fría" puede dar lugar a un rendimiento considerablemente mejor o predecible que la red pública de Internet, especialmente para las conexiones de larga distancia.
Productos SD-WAN en redes hub-and-spoke de Azure
En esta sección se proporcionan recomendaciones para implementar dispositivos CPE que no son de Microsoft SD-WAN como NVA en una red de Azure hub-and-spoke existente.
NVA de SD-WAN en la red virtual del concentrador
Hub-and-spoke es la topología que Microsoft recomienda para crear redes escalables en una región de Azure mediante redes virtuales administradas por el cliente. La red virtual del concentrador hospeda componentes compartidos, como NVA que no son de Microsoft y servicios nativos que proporcionan funciones de red, como firewall, equilibrio de carga y conectividad a sitios locales a través de VPN de sitio a sitio o ExpressRoute. La red virtual del concentrador es la ubicación natural de las NVA SD-WAN que, en última instancia, son puertas de enlace no de Microsoft que proporcionan acceso a redes remotas.
Las NVA SD-WAN deben implementarse en redes virtuales de concentrador de la siguiente manera:
- Se usa un único controlador de interfaz de red (NIC) para todo el tráfico SD-WAN. Otras NIC, como una NIC de administración, se pueden agregar para cumplir los requisitos de seguridad y cumplimiento o para cumplir las directrices del proveedor para las implementaciones de Azure.
- La NIC que se usa para el tráfico SD-WAN debe estar conectada a una subred dedicada. El tamaño de la subred debe definirse en función del número de NVA SD-WAN implementadas para satisfacer los requisitos de alta disponibilidad y escalado o rendimiento, que se describen más adelante en este artículo.
- Los grupos de seguridad de red (NSG) deben estar asociados a la NIC de tráfico SD-WAN, ya sea directamente o en el nivel de subred. Esta asociación permite conexiones desde sitios locales remotos a través de los puertos TCP/UDP utilizados por la solución SD-WAN.
- El reenvío de IP debe estar habilitado en la NIC que se usa para el tráfico SD-WAN.
Azure Route Server en la red virtual del concentrador
Azure Route Server automatiza el intercambio de rutas entre NVA SD-WAN y la pila de redes definidas por software (SDN) de Azure. Route Server admite BGP como protocolo de enrutamiento dinámico. Al establecer las adyacencias BGP entre Route Server y las NVA de SD-WAN:
- Las rutas para todos los sitios locales conectados a la SD-WAN se inyectan en las tablas de rutas de la red virtual y todas las máquinas virtuales de Azure las aprenden.
- Las rutas de todos los prefijos IP incluidos en el espacio de direcciones de las redes virtuales se propagan a todos los sitios conectados a SD-WAN.
Route Server debe configurarse de la manera siguiente.
- Debe implementarse en una subred dedicada de la red virtual del concentrador según Creación y configuración de Route Server mediante Azure Portal.
- Para habilitar el intercambio de rutas automatizado para todas las redes virtuales de radio, se debe configurar el emparejamiento de redes virtuales para permitir que las redes virtuales de radio usen la puerta de enlace de la red virtual del concentrador y Route Server. Detalles disponibles en las Preguntas más frecuentes sobre Azure Route Server.
- A medida que Route Server y las NVA SD-WAN se conectan a diferentes subredes, las sesiones BGP entre Route Server y las NVA SD-WAN deben configurarse con compatibilidad con salto múltiple de eBGP. Se puede establecer cualquier número de saltos entre 2 y el máximo admitido por la NVA SD-WAN. Los detalles sobre cómo configurar las adyacencias BGP para Route Server están disponibles en Creación y configuración de Route Server mediante Azure Portal.
- Se deben configurar dos rutas estáticas
/32en la NVA SD-WAN para los puntos de conexión de BGP expuestos por Route Server. Esta configuración garantiza que la tabla de rutas de la NVA siempre contenga rutas para sus nodos del mismo nivel de BGP de salto múltiple (no conectados directamente).
Route Server no está en la ruta de acceso de datos. Es una entidad del plano de control. Propaga las rutas entre la NVA SD-WAN y la pila de SDN de red virtual, pero el reenvío real del tráfico entre la NVA SD-WAN y las máquinas virtuales de la red virtual se realiza mediante la pila de SDN de Azure, como se muestra en la ilustración siguiente. Para obtener este comportamiento de enrutamiento, Route Server inyecta todas las rutas que aprende de las NVA SD-WAN con el próximo salto establecido en la propia dirección de la NVA.
Por el momento, Route Server no admite IPv6. Esta arquitectura solo es para IPv4.
Figura 2. Route Server admite la propagación de rutas entre SD-WAN CPE y la pila de SDN de red virtual, pero no reenvía el tráfico entre SD-WAN CPE y las máquinas virtuales de la red virtual.
Alta disponibilidad para NVA SD-WAN con Route Server
Route Server tiene alta disponibilidad integrada. Dos nodos de proceso devuelven una sola instancia de Route Server. Se implementan en diferentes zonas de disponibilidad, para las regiones que tienen compatibilidad con zonas de disponibilidad o en el mismo conjunto de disponibilidad. Exponen dos puntos de conexión BGP. La alta disponibilidad de las NVA SD-WAN se logra implementando varias instancias en diferentes zonas de disponibilidad, para las regiones que las admiten, o en el mismo conjunto de disponibilidad. Cada NVA SD-WAN establece dos sesiones BGP con ambos puntos de conexión expuestos por Route Server.
La arquitectura que se describe en este artículo no se basa en Azure Load Balancers. Más concretamente:
Ningún equilibrador de carga público expone puntos de conexión de túnel SD-WAN. Cada NVA SD-WAN expone su propio punto de conexión de túnel. Los nodos del mismo nivel remoto establecen varios túneles, uno para cada NVA SD-WAN en Azure.
Ningún equilibrador de carga interno distribuye el tráfico originado por las máquinas virtuales de Azure a las NVA SD-WAN. Route Server y la pila de Azure SDN admiten el enrutamiento de múltiples rutas de igual costo (ECMP). Si varias NVA configuran adyacencias de BGP con Route Server y anuncian rutas para los mismos destinos (como en redes remotas y sitios conectados a SD-WAN) mediante el mismo grado de preferencia, Route Server:
- Inyecta varias rutas para esos destinos en la tabla de rutas de la red virtual.
- Establece cada ruta para usar una aplicación virtual de red diferente como próximo salto.
A continuación, la pila de SDN distribuye el tráfico a esos destinos en todos los próximo saltos disponibles.
La arquitectura de alta disponibilidad resultante se muestra en la ilustración siguiente:
Figura 3. Route Server admite el enrutamiento de múltiples rutas de igual costo (ECMP). Los equilibradores de carga de Azure no son necesarios cuando se usan varias NVA SD-WAN con fines de disponibilidad o escalabilidad.
N-activo frente a alta disponibilidad en espera activa
Cuando se usan varias NVA SD-WAN y se emparejan con Route Server, BGP controla la conmutación por error. Si una NVA SD-WAN se queda sin conexión, deja de anunciar rutas a Route Server. Las rutas aprendidas del dispositivo con errores se retiran de la tabla de rutas de la red virtual. Por lo tanto, si una NVA SD-WAN ya no proporciona conectividad a sitios remotos de SD-WAN debido a un error, en el propio dispositivo o en la capa subyacente, ya no aparece como un próximo salto posible hacia los sitios remotos en la tabla de rutas de la red virtual. Todo el tráfico va a los dispositivos correctos restantes. Para obtener más información sobre la propagación de rutas entre las NVA SD-WAN y Route Server, consulte Rutas anunciadas por un nodo del mismo nivel de BGP a Route Server.
Figura 4. Conmutación por error controlada por BGP. Si una NVA SD-WAN n.º 0 se queda sin conexión, sus sesiones BGP con Route Server se cierran. La NVA SD-WAN n.º 0 se quita de la tabla de rutas de la red virtual como posible próximo salto para el tráfico que va de Azure al sitio local.
La conmutación por error controlada por BGP y el enrutamiento ECMP habilitan naturalmente arquitecturas de alta disponibilidad N-activas con dispositivos N que procesan simultáneamente el tráfico. Pero también puede usar BGP para implementar arquitecturas de alta disponibilidad activas y pasivas: configure el dispositivo pasivo para anunciar a Route Server las rutas con un grado de preferencia inferior al del nodo del mismo nivel activo. Route Server descarta las rutas recibidas del dispositivo pasivo si recibe del dispositivo activo cualquier ruta para los mismos destinos con un mayor grado de preferencia. Y solo establece las últimas rutas en la tabla de rutas de la red virtual.
Si se produce un error en el dispositivo activo o retira algunas de sus rutas, Route Server:
- Selecciona las rutas correspondientes anunciadas por el dispositivo pasivo.
- Establece las rutas de la tabla de rutas de la red virtual.
Los únicos atributos BGP que las NVA SD-WAN pueden usar para expresar un grado de preferencia para las rutas que anuncian a Route Server es Ruta de acceso de AS.
Se recomiendan arquitecturas de alta disponibilidad N-activas porque permiten un uso óptimo de los recursos (no hay NVA SD-WAN) y escalabilidad horizontal. Para aumentar el rendimiento, varias NVA se pueden ejecutar en paralelo, hasta el número máximo de nodos del mismo nivel de BGP admitidos por Route Server. Para más información, consulte Nodos del mismo nivel de BGP. Pero el modelo de alta disponibilidad N-activo requiere que las NVA SD-WAN actúen como enrutadores de capa 3 sin estado. Cuando existen varios túneles a un sitio, las conexiones TCP se pueden enrutar de forma asimétrica. Es decir, los flujos ORIGINAL y REPLY de la misma conexión TCP se pueden enrutar a través de túneles diferentes y diferentes NVA. En la ilustración siguiente se muestra un ejemplo de una conexión TCP enrutada asimétricamente. Estas asimetrías de enrutamiento son posibles para las conexiones TCP iniciadas en la red virtual o en el sitio local.
Figura 5. Enrutamiento asimétrico en arquitecturas activas o de alta disponibilidad activas. La NVA SD-WAN n.º 0 y la NVA SD-WAN n.º 1 anuncian la misma ruta para el destino 192.168.1.0/24 (sitio remoto SD-WAN) con la misma longitud de ruta de acceso AS a Route Server. El flujo ORIGINAL (desde el sitio remoto SD-WAN a Azure, la ruta de acceso roja) se enruta a través del túnel terminado, en el lado de Azure, mediante la NVA SD-WAN n.º 1. La SD-WAN CPE local selecciona este túnel. La pila de SDN de Azure enruta el flujo REPLY (de Azure al sitio remoto de SD-WAN, la ruta verde) a la NVA SD-WAN n.º 0, que es uno de los posibles próximo saltos para 192.168.1.0/24, según la tabla de rutas de la red virtual. No es posible garantizar que el próximo salto elegido por la pila de SDN de Azure siempre sea la misma SD-WAN CPE que recibió el flujo ORIGINAL.
Las arquitecturas de alta disponibilidad activas y pasivas solo se deben tener en cuenta cuando las NVA SD-WAN de Azure realizan otras funciones de red que requieren simetría de enrutamiento, como el firewall con estado. No se recomienda este enfoque debido a sus implicaciones en la escalabilidad. La ejecución de más funciones de red en NVA SD-WAN aumenta el consumo de recursos. Al mismo tiempo, la arquitectura de alta disponibilidad activa y pasiva permite tener un solo tráfico de procesamiento de NVA en cualquier momento. Es decir, toda la capa SD-WAN solo se puede escalar verticalmente hasta el tamaño máximo de máquina virtual de Azure que admite, no se escala horizontalmente. Ejecute funciones de red con estado que requieran la simetría de enrutamiento en clústeres de NVA independientes que dependen de Standard Load Balancer para alta disponibilidad n-activa.
Consideraciones de conectividad de ExpressRoute
La arquitectura que se describe en este artículo permite a los clientes adoptar completamente el paradigma SD-WAN y crear su red corporativa como una superposición lógica sobre la red pública de Internet y la red troncal de Microsoft. También admite el uso de circuitos Expressroute dedicados para abordar escenarios específicos, que se describen más adelante.
Escenario 1: coexistencia de ExpressRoute y SD-WAN
Las soluciones SD-WAN pueden coexistir con la conectividad de ExpressRoute cuando los dispositivos SD-WAN solo se implementan en un subconjunto de sitios. Por ejemplo, algunas organizaciones podrían implementar soluciones SD-WAN como reemplazo de las VPN de IPSec tradicionales en sitios con conectividad a Internet únicamente. A continuación, usan servicios MPLS y circuitos ExpressRoute para sitios y centros de datos de gran tamaño, como se muestra en la ilustración siguiente.
Figura 6. Las soluciones SD-WAN pueden coexistir con la conectividad de ExpressRoute cuando los dispositivos SD-WAN CPE solo se implementan en un subconjunto de sitios.
Este escenario de coexistencia requiere que las NVA SD-WAN implementadas en Azure puedan enrutar el tráfico entre sitios conectados a SD-WAN y sitios conectados a circuitos ExpressRoute. Route Server se puede configurar para propagar rutas entre puertas de enlace de red virtual de ExpressRoute y NVA SD-WAN en Azure habilitando la función AllowBranchToBranch, tal como se documenta aquí. La propagación de rutas entre la puerta de enlace de red virtual de ExpressRoute y las NVA SD-WAN se produce a través de BGP. Route Server establece sesiones BGP con ambas y propaga a cada nodo del mismo nivel las rutas aprendidas de la otra. La plataforma administra las sesiones BGP entre Route Server y la puerta de enlace de red virtual de ExpressRoute. Los usuarios no necesitan configurarlas explícitamente, sino solo para habilitar la marca AllowBranchToBranch al implementar Route Server.
Figura 7. La propagación de rutas entre la puerta de enlace de red virtual de ExpressRoute y las NVA SD-WAN se produce a través de BGP. Route Server establece sesiones BGP con ambas y propaga rutas en ambas direcciones cuando se configura con "AllowBranchToBranch=TRUE". Route Server actúa como un reflector de ruta, es decir, no forma parte de la ruta de acceso de datos.
Este escenario de coexistencia de SD-WAN y ExpressRoute permite migraciones de redes MPLS a SD-WAN. Ofrece una ruta de acceso entre sitios MPLS heredados y los sitios SD-WAN recién migrados, lo que elimina la necesidad de enrutar el tráfico a través de centros de datos locales. Este patrón se puede usar no solo durante las migraciones, sino también en escenarios derivados de fusiones y adquisiciones de la empresa, lo que proporciona una interconexión sin problemas de redes dispares.
Escenario 2: Expressroute como una capa subyacente SD-WAN
Si los sitios locales tienen conectividad de ExpressRoute, puede configurar dispositivos SD-WAN para configurar túneles en las NVA del concentrador de SD-WAN que se ejecutan en Azure sobre el circuito o circuitos ExpressRoute. La conectividad de ExpressRoute se puede realizar a través de circuitos de punto a punto o una red MPLS. Puede usar el emparejamiento privado de ExpressRoute y el emparejamiento de Microsoft.
Emparejamiento privado
Cuando se usa el emparejamiento privado de ExpressRoute como capa subyacente, todos los sitios SD-WAN locales establecen túneles a las NVA del concentrador de SD-WAN en Azure. No se necesita propagación de rutas entre las NVA SD-WAN y la puerta de enlace de red virtual de ExpressRoute en este escenario (es decir, Route Server debe configurarse con la marca "AllowBranchToBranch" establecida en false).
Este enfoque requiere una configuración de BGP adecuada en los enrutadores del lado cliente o del proveedor que terminan la conexión de ExpressRoute. De hecho, los enrutadores de Microsoft Enterprise Edge (MSEE) anuncian todas las rutas de las redes virtuales conectadas al circuito (ya sea directamente o a través del emparejamiento de redes virtuales). Pero para reenviar el tráfico destinado a las redes virtuales a través de un túnel SD-WAN, el sitio local debe aprender esas rutas desde el dispositivo SD-WAN, no el circuito ER.
Por lo tanto, los enrutadores del lado cliente o del lado proveedor que terminan la conexión de ExpressRoute deben filtrar las rutas recibidas de Azure. Las únicas rutas configuradas en la capa subyacente deben ser las que permiten que los dispositivos SD-WAN locales lleguen a las NVA del concentrador SD-WAN en Azure. Los clientes que quieran usar el emparejamiento privado de ExpressRoute como una capa subyacente SD-WAN deben comprobar que pueden configurar sus dispositivos de enrutamiento en consecuencia. Esto es especialmente relevante para los clientes que no tienen control directo sobre sus dispositivos perimetrales para ExpressRoute. Un ejemplo es cuando un operador de MPLS proporciona el circuito ExpressRoute sobre un servicio IPVPN.
Figura 8. Emparejamiento privado de ExpressRoute como una capa subyacente de SD-WAN. En este escenario, los enrutadores del lado de cliente y proveedor reciben las rutas de la red virtual que finalizan la conexión de ExpressRoute, en las sesiones BGP de emparejamiento privado de ER y la SD-WAN CPE. Solo la SD-WAN CPE debe propagar las rutas de Azure a la LAN del sitio.
Emparejamiento de Microsoft
También puede usar el emparejamiento de Microsoft de ExpressRoute como una capa subyacente para túneles SD-WAN. En este escenario, las NVA del concentrador de SD-WAN en Azure solo exponen puntos de conexión de túnel públicos, que se usan tanto en las SD-WAN CPE en sitios conectados a Internet, si los hay, como en las SD-WAN CPE en sitios conectados a Expressroute. Aunque el emparejamiento de Microsoft de ExpressRoute tiene requisitos previos más complejos que el emparejamiento privado, se recomienda usar esta opción como capa subyacente debido a estas dos ventajas:
No requiere puertas de enlace de red virtual de Expressroute en la red virtual del concentrador. Quita la complejidad, reduce el costo y permite que la solución SD-WAN se escale más allá de los límites de ancho de banda de la propia puerta de enlace cuando no se usa FastPath de ExpressRoute.
Proporciona una separación limpia entre las rutas superpuestas y subyacentes. Los MSEE solo anuncian los prefijos públicos de la red de Microsoft al perímetro del cliente o proveedor. Puede administrar esas rutas en una VRF independiente y propagarlas solo a un segmento DMZ de la LAN del sitio. Los dispositivos SD-WAN propagan las rutas de la red corporativa del cliente en la superposición, incluidas las rutas de las redes virtuales. Los clientes que consideran este enfoque deben comprobar que pueden configurar sus dispositivos de enrutamiento en consecuencia o solicitar el servicio adecuado a su operador de MPLS.
Consideraciones de MPLS
La migración de redes corporativas MPLS tradicionales a arquitecturas de red más modernas basadas en el paradigma SD-WAN requiere un esfuerzo significativo y una cantidad considerable de tiempo. La arquitectura que se describe en este artículo habilita las migraciones por fases de SD-WAN. Más adelante se describen dos escenarios de migración típicos.
Retirada por fases de MPLS
Los clientes que quieran crear una SD-WAN sobre la red pública de Internet y la red troncal de Microsoft, y retirar completamente IPVPN de MPLS u otros servicios de conectividad dedicados, pueden usar el escenario de coexistencia de ExpressRoute y SD-WAN descrito en la sección anterior durante la migración. Permite que los sitios conectados a SD-WAN lleguen a los sitios aún conectados a los MPLS heredados. En cuanto se migre un sitio a SD-WAN y se implementen los dispositivos CPE, se puede retirar su vínculo MPLS. El sitio puede acceder a toda la red corporativa a través de sus túneles SD-WAN a las regiones de Azure más cercanas.
Figura 9. El escenario de "coexistencia de ExpressRoute y SD-WAN" permite la retirada por fases de MPLS.
Cuando se migran todos los sitios, el IPVPN de MPLS se puede retirar, junto con los circuitos ExpressRoute que lo conectan a la red troncal de Microsoft. Las puertas de enlace de red virtual de ExpressRoute ya no son necesarias y se pueden desaprovisionar. Las NVA del concentrador SD-WAN de cada región se convierten en el único punto de entrada en la red hub-and-spoke de esa región.
Integración de MPLS
Las organizaciones que no confían en redes públicas y compartidas para proporcionar el rendimiento y la confiabilidad deseados pueden decidir usar una red MPLS existente como una red subyacente de clase empresarial. Hay dos opciones:
- Subconjunto de sitios como centros de datos o sucursales grandes.
- Subconjunto de conexiones, normalmente sensibles a la latencia o de tráfico crítico.
El escenario de Expressroute como SD-WAN subyacente descrita anteriormente habilita la integración de SD-WAN y MPLS. El emparejamiento de Microsoft de ExpressRoute debe preferirse al emparejamiento privado por las razones expuestas anteriormente. Además, cuando se usa el emparejamiento de Microsoft, la red MPLS y la red pública de Internet se convierten en subyacentes funcionalmente equivalentes. Proporcionan acceso a todos los puntos de conexión del túnel SD-WAN expuestos por la NVA del concentrador de SD-WAN en Azure. Una SD-WAN CPE implementada en un sitio con conectividad a Internet y MPLS puede establecer varios túneles a los concentradores SD-WAN de Azure en ambas capas subyacentes. Después, pueden enrutar diferentes conexiones a través de diferentes túneles, en función de las directivas de nivel de aplicación administradas por el plano de control SD-WAN.
Figura 10. El escenario de "ExpressRoute como SD-WAN subyacente" permite la integración de SD-WAN y MPLS.
Preferencia de enrutamiento de Route Server
En ambos escenarios de MPLS descritos en las dos secciones anteriores, algunos sitios de sucursal se pueden conectar tanto a IPVPN de MPLS como a SD-WAN. Como resultado, las instancias de Route Server implementadas en las redes virtuales del concentrador pueden aprender las mismas rutas de las puertas de enlace de ExpressRoute y las NVA SD-WAN. La preferencia de enrutamiento de Route Server permite controlar qué ruta de acceso se debe preferir y establecer en las tablas de rutas de las redes virtuales. La preferencia de enrutamiento es útil cuando no se puede usar la anteposición de ruta de acceso de AS. Un ejemplo son los servicios IPVPN de MPLS, que no admiten configuraciones BGP personalizadas en los PE que finalizan las conexiones de ExpressRoute.
Consideraciones de diseño y límites de Route Server
Route Server es la piedra angular de la arquitectura que se describe en este artículo. Propaga las rutas entre las NVA SD-WAN implementadas en redes virtuales y la pila de SDN de Azure SDN subyacente. Proporciona un enfoque basado en BGP para ejecutar varias NVA SD-WAN para lograr alta disponibilidad y escalabilidad horizontal. Al diseñar grandes SD-WAN en función de esta arquitectura, se deben tener en cuenta los límites de escalabilidad de Route Server.
En las secciones siguientes se proporcionan instrucciones sobre los máximos de escalabilidad y cómo tratar cada límite.
Rutas anunciadas por un nodo del mismo nivel BGP a Route Server
Route Server no define un límite explícito para el número de rutas que se pueden anunciar en puertas de enlace de red virtual de ExpressRoute cuando se establece la marca AllowBranchToBranch. Sin embargo, las puertas de enlace de ExpressRoute propagan aún más las rutas que aprenden de Route Server a los circuitos ExpressRoute a los que están conectados.
Hay un límite para el número de rutas que las puertas de enlace de ExpressRoute pueden anunciar a circuitos ExpressRoute a través del emparejamiento privado, que se explica en Límites, cuotas y restricciones de suscripción y servicio de Azure. Al diseñar soluciones SD-WAN basadas en las directrices de este artículo, es fundamental asegurarse de que las rutas SD-WAN no superen este límite. Si se supera, se quitan las sesiones BGP entre las puertas de enlace de ExpressRoute y los circuitos ExpressRoute, y se pierde la conectividad entre redes virtuales y redes remotas conectadas a través de ExpressRoute.
El número total de rutas anunciadas a circuitos por las puertas de enlace de ExpressRoute es la suma de las rutas aprendidas de Route Server y el número de prefijos que componen el espacio de direcciones de la red hub-and-spoke de Azure. Para evitar interrupciones debido a sesiones BGP eliminadas, se recomienda implementar las siguientes mitigaciones:
- Use las características nativas de los dispositivos SD-WAN para limitar el número de rutas anunciadas a Route Server, si la característica está disponible.
- Use alertas de Azure Monitor para detectar de forma proactiva picos en el número de rutas anunciadas por las puertas de enlace de ExpressRoute. La métrica que se va a supervisar se denomina Recuento de rutas anunciadas al nodo del mismo nivel, tal como se documenta en Supervisión de ExpressRoute.
Pares BGP
Route Server puede establecer sesiones BGP con un número máximo de nodos del mismo nivel BGP. Este límite determina el número máximo de NVA SD-WAN que pueden establecer adyacencias BGP con Route Server y, por tanto, el rendimiento agregado máximo que se puede admitir en todos los túneles SD-WAN. Solo se espera que las SD-WAN grandes alcancen este límite. No existen soluciones alternativas para solucionarlo, más allá de crear varias redes hub-and-spoke, cada una con sus propias puertas de enlace y servidores de rutas.
Máquinas virtuales participantes
Las puertas de enlace de red virtual y Route Server configuran las rutas que aprenden de sus nodos del mismo nivel remotos para todas las máquinas virtuales de su propia red virtual y en redes virtuales emparejadas directamente. Para proteger Route Server del consumo excesivo de recursos debido a las actualizaciones de enrutamiento a las máquinas virtuales, Azure define un límite en cuanto al número de máquinas virtuales que pueden existir en una sola red hub-and-spoke. No existen soluciones alternativas para abordar este límite, más allá de la creación de varias redes hub-and-spoke, cada una con sus propias puertas de enlace y servidores de rutas, en la misma región.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Federico Guerrini | Arquitecto sénior de soluciones en la nube
- Khush Kaviraj | Arquitecto de soluciones en la nube
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.