Operación de red
Al implementar CSO como una implementación local, es útil saber cómo funciona la red y qué protocolos están en uso. Cuando se trabaja con una implementación alojada en la nube, los conceptos son todos iguales, pero los detalles y el control son invisibles para los suscriptores; son responsabilidad del equipo que instala CSO en la nube.
Al igual que con la mayoría de las redes, la solución SD-WAN de Contrail generalmente opera en dos planos:
Plano de control: OAM y tráfico de enrutamiento
Plano de datos (de reenvío): tráfico de usuarios
Control Plane Operation
El plano de control para la solución Contrail SD-WAN se centra en la plataforma CSO. Más concretamente:
La capa Network Service Controller (NSC) de CSO implementa el plano de control mediante vRR.
Todos los sitios de todos los inquilinos establecen emparejamientos MP-IBGP con el vRR.
CSO usa un único número de AS privado para todos los inquilinos, con destinos de ruta para la separación de inquilinos.
La separación de rutas del inquilino la proporcionan tanto el vRR como los dispositivos de concentrador de varios inquilinos que utilizan comunidades extendidas BGP.
Diseño vRR
Todas las implementaciones de CSO incluyen una o más instancias de vRR, que proporcionan funcionalidad de plano de control para el entorno SD-WAN. En la figura 1 se muestra un ejemplo general en el que los dispositivos locales de cada sitio se emparejan con el vRR.
de vRR único
La figura 2 muestra un ejemplo de la salida de la CLI del vRR.
Resistencia del plano de control
CSO versión 3.3 y posteriores admiten la instalación de varios vRR para proporcionar redundancia y escala. CSO separa los vRR en dos grupos de redundancia (RG) y hace que una única dirección IP virtual sea visible para la red. Como parte de la configuración de un sitio, CSO establece sesiones de emparejamiento BGP entre el dispositivo y un vRR en cada RG. Si se produce un error en el vRR principal o se pierde la conectividad, el segundo vRR continúa recibiendo y anunciando rutas LAN para los sitios conectados, lo que proporciona redundancia. Este diseño se ilustra en la figura 3.
multi-vRR
Distribución y separación de rutas
La solución SD-WAN de Contrail utiliza instancias de enrutamiento y reenvío virtual (VRF) de Junos OS y destinos de ruta MP-BGP para proporcionar separación de rutas de inquilinos y habilitar multiinquilino.
Estos conceptos se pueden ilustrar bien utilizando un entorno VPN MPLS como ejemplo. Como se muestra en la figura 4, a cada cliente se le asigna un valor de destino de ruta único, y todos los sitios de la VPN de cliente usan ese valor de destino de ruta. Cuando un enrutador anuncia la información de enrutamiento de un cliente, adjunta el valor de destino de ruta adecuado en función del VRF del cliente que originó los anuncios. El enrutador receptor utiliza el valor de destino de ruta adjunto para identificar el VRF del cliente en el que se debe colocar la información de enrutamiento recibida.
: VPN MPLS
Un entorno radial de VPN MPLS utiliza los destinos de ruta de manera diferente, como se muestra en la figura 5. Para cada cliente, cada VRF radial asigna el mismo valor de destino de ruta al enviar información de enrutamiento. El enrutador receptor acepta rutas con el mismo valor de destino de ruta y las instala en el concentrador VRF. Por el contrario, el VRF del concentrador asigna un valor de destino de ruta diferente al enviar información de enrutamiento, y los enrutadores receptores aceptan e instalan rutas con ese mismo valor de destino de ruta en VRF radiales.
Con esta configuración, solo el VRF del concentrador acepta rutas del VRF radial y solo los VRF radiales aceptan rutas del VRF del concentrador. Con este método, los sitios radiales necesitan muy poca información de enrutamiento (tal vez solo una ruta predeterminada), ya que solo necesitan accesibilidad al sitio central, lo que mantiene las tablas de enrutamiento pequeñas y sin abandono.
MPLS radial
El ejemplo radial anterior sirve como una buena base, ya que la solución SD-WAN de Contrail implementa la distribución y separación de rutas de la misma manera cuando se reenvía tráfico de un sitio a otro, o cuando se divide el tráfico a Internet local.
La figura 6 muestra un ejemplo de sitio radial donde el dispositivo radial está configurado con dos túneles superpuestos y una ruptura local, con todo el tráfico fluyendo por la misma interfaz. Cada ruta de tráfico tiene su propio VRF, y los destinos de ruta se asignan adecuadamente en los sitios de radio y concentrador para garantizar una separación adecuada de la ruta del inquilino.
radial de SD-WAN
Gestión de APBR y SLA: plano de control
El enrutamiento avanzado basado en políticas (APBR) permite definir el comportamiento del enrutamiento y la selección de rutas por aplicación (grupo). El mecanismo APBR clasifica las sesiones en función de aplicaciones conocidas y firmas de aplicaciones definidas por el usuario, y utiliza intenciones de políticas para identificar la mejor ruta posible para la aplicación. El enrutamiento dinámico basado en aplicaciones permite definir políticas que cambiarán los vínculos WAN sobre la marcha en función de los parámetros de SLA definidos por la aplicación.
Real-Time Optimized - AppQoE
A partir de la versión 3.3.1, CSO admite la calidad de experiencia de la aplicación (AppQoE), un mecanismo de nivel de plano de datos que proporciona una mejor escalabilidad y una toma de decisiones más rápida. Trabajando en conjunto con APBR, AppQoE funciona a nivel de dispositivo; es decir, los propios dispositivos realizan mediciones de SLA en los vínculos WAN disponibles y, a continuación, asignan dinámicamente el tráfico de la aplicación a la ruta que mejor sirve para el requisito de SLA de la aplicación. Todo esto se hace sin la necesidad de que el controlador CSO distribuya rutas específicas de SLA.
Con AppQoE, cuando se produce una infracción de SLA, solo el tráfico correspondiente a la aplicación que informó de la infracción de SLA se mueve a un vínculo alternativo; Cualquier otro tráfico que utilice el enlace no se verá afectado.
Con la administración de SLA optimizada en tiempo real, solo se requiere el VRF predeterminado, como se muestra en la Figura 7. El VRF predeterminado utiliza ECMP en todos los vínculos. La siguiente selección de salto por SLA ocurre en la ruta de datos (descrita en la sección del plano de datos).
En este caso, la etiqueta MPLS solo se usa para identificar al inquilino.
AppQoE se habilita cuando el modo SD-WAN para el inquilino se establece en Real-time Optimized. Este es el modo predeterminado para las implementaciones de SD-WAN.
Tenga en cuenta lo siguiente acerca de AppQoE:
Solo se admite en dispositivos SRX y vSRX.
Ambos extremos deben utilizar la misma versión de Junos OS y la misma configuración.
Se admite la multiconexión.
Operación del plano de datos
En esta sección se describe cómo se reenvía un paquete en una topología radial.
Cuando un usuario de un sitio radial envía tráfico a través del dispositivo CPE local y el paquete no se conmuta localmente ni se envía directamente a Internet, se envía a través de un túnel al dispositivo concentrador. Este paquete de la LAN del cliente se encapsula primero dentro de un encabezado MPLSoGRE con el destino GRE como uno de los vínculos WAN del dispositivo concentrador. La etiqueta MPLS del encabezado MPLSoGRE identifica el VRF que se utilizará para reenviar el paquete en el sitio del concentrador. El encabezado de paquete resultante se muestra en la figura 8.
Si el túnel entre el sitio radial y el concentrador está configurado para usar IPsec, el paquete MPLSoGRE se cifra y encapsula en un encabezado IPsec que usa el modo de túnel. El encabezado del paquete resultante se muestra en la figura 9.
En el concentrador, primero se descifra el encabezado IPsec. El encabezado MPLSoGRE del paquete resultante se utiliza para terminar el túnel GRE y realizar una búsqueda en el VRF apropiado, como se identifica mediante la etiqueta MPLS. Según la búsqueda de ruta en el VRF, el paquete se reenvía hacia otro sitio radial o fuera del entorno SD-WAN. Si se reenvía a otro radio, el dispositivo concentrador encapsula el paquete como se describe anteriormente.
Design Options
La figura 10 ilustra cómo se implementan normalmente los túneles mediante los encabezados de paquete descritos anteriormente. Los túneles GREoIPSec se utilizan generalmente a través de la ruta de Internet, dada la necesidad de un transporte de paquetes seguro a través de la red pública. Los túneles GRE generalmente se usan sobre rutas MPLS, aunque la opción GREoIPSec también se puede usar según corresponda.
de diseño de túneles
APBR and SLA Management - Data Plane
Como se señaló anteriormente, los inquilinos pueden elegir un modo de SD-WAN de administración de SLA para el tráfico de aplicaciones:
Optimizado en tiempo real: administración de SLA a nivel de dispositivo, usando AppQoE
AppQoE es un mecanismo de nivel plano de datos que proporciona una mejor escalabilidad y una toma de decisiones más rápida. Con AppQoE, la conmutación de vínculos se produce a nivel de aplicación en la ruta de datos de los dispositivos; los propios dispositivos realizan mediciones de SLA en los vínculos WAN disponibles, sin necesidad del controlador CSO.
La supervisión de vínculos se realiza mediante dos tipos de sondeos en línea:
Sondas pasivas
Sondeos en línea que viajan junto con el tráfico de aplicaciones
Imitar la ráfaga de los flujos de aplicaciones
Habilite el monitoreo de RTT, jitter, pérdida de paquetes para la sesión de la aplicación
Se utiliza para supervisar la ruta utilizada actualmente para el cumplimiento de los SLA, detectar infracciones de SLA
Sondas activas
Sondeos periódicos (basados en la configuración) que recopilan datos de SLA en todas las rutas potenciales
Se utiliza para determinar la mejor ruta original para el tráfico
Se utiliza para supervisar rutas alternativas
AppQoE se habilita cuando el modo SD-WAN para el inquilino se establece en Real-time Optimized.
Tunnel Liveliness
Para evitar el tráfico de agujeros negros, se aplican las comprobaciones de vida adecuadas en la red superpuesta. La solución SD-WAN de Contrail utiliza dos mecanismos para garantizar la vitalidad:
Detección de pares muertos (DPD) IPsec, donde se usa
GRE keepalives
Etiquetas de malla y VPN de malla dinámica
Como se mencionó en la discusión de los modelos de implementación, la malla dinámica es la implementación de Juniper que ahorra recursos de VPN de malla completa dentro de CSO. En esta sección se describe el funcionamiento de las etiquetas de malla y las VPN de malla dinámica que permiten.
Mesh Tags
Las etiquetas de malla son etiquetas basadas en texto que se aplican a las interfaces WAN de los dispositivos de concentrador y CPE durante el proceso de incorporación en CSO. CSO se envía con dos etiquetas de malla predeterminadas: Internet y MPLS. Puede crear sus propias etiquetas de malla mediante el Portal de administración de CSO. Las VPN bajo demanda o dinámicas solo se pueden formar entre interfaces WAN que compartan la misma etiqueta de malla.
En la siguiente explicación se explica cómo funcionan las etiquetas de malla y algunos de los casos de uso a los que se aplican.
Como se mencionó anteriormente, se aplica una etiqueta de malla a cada interfaz WAN del dispositivo CPE en cada sitio. En dispositivos radiales, como NFX150 y NFX250, y en la mayoría de los dispositivos SRX, solo se puede aplicar una etiqueta de malla a cada interfaz WAN. En los dispositivos de concentrador de proveedor y concentrador empresarial, como los dispositivos de la serie SRX4x00, se pueden aplicar varias etiquetas de malla a cada interfaz debido a las mayores capacidades de VPN de los dispositivos.
La siguiente lista ayuda a ilustrar los diversos casos de uso en los que entran en juego las etiquetas de malla y las VPN de malla dinámica.
Connecting Different Underlay Links
Site-to-Site Tunnels Based on Capacity
Geo-Based Meshing
With Dual CPE
Dynamic Mesh Load Balancing
Redundant Link
Dynamic Mesh VPNs
La figura 11 muestra una topología VPN de malla dinámica entre tres sitios radiales y describe cómo se muestra la VPN de sitio a sitio.
de malla dinámica
|
1
—
Sitios y túneles a sitios de Hub aprovisionados mediante ZTP. El tráfico de sitio a sitio pasa por los túneles de datos de sitio a concentrador.
|
4
—
CSO configura túneles de sitio a sitio bajo demanda entre los pares de sitios.
|
|
2
—
CSO recibe mensajes syslog de los dispositivos que contienen detalles sobre las tasas de tráfico.
|
5
—
El tráfico de sitio a sitio ahora cambia a los túneles de sitio a sitio recién formados.
|
|
3
—
CSO reconoce que el tráfico entre Phoenix Site 1 y Houston Site 2 supera los umbrales de KPI.
|
CSO también controla y automatiza la eliminación de túneles mediante umbrales de tráfico y mensajes syslog.
Ruptura de Internet
Mientras que el tráfico destinado a Internet se puede enviar a través de los túneles superpuestos y a través de un sitio central, los túneles suelen estar destinados a admitir el tráfico de sitio a sitio. Para destinos que no son SD-WAN, la división local ofrece la opción de enviar el tráfico del dispositivo local local directamente a Internet. La ruptura local permite al inquilino usar su ancho de banda de red de manera óptima en cada sitio y evitar incurrir en el costo de transportar todo el tráfico al sitio central.
La ruptura local es una característica importante en los despliegues de SD-WAN, ya que muchas empresas hoy en día utilizan servicios SaaS que están alojados fuera de la red corporativa. Dado que la mayoría de estas aplicaciones SaaS usan SSL como transporte y también admiten el inicio de sesión único con los sistemas AAA empresariales, los problemas de seguridad se abordan a pesar de enviar tráfico directamente a través de Internet.
WAN Interface Options
Las interfaces WAN (MPLS e Internet) de un dispositivo local pueden admitir tráfico de interrupción local y tunelizado en cualquier combinación:
Solo tráfico tunelizado
Tráfico de ruptura local y tunelizado
Solo tráfico de ruptura local
Design Options
Hay varias maneras de implementar la ruptura local, dependiendo de los requisitos de diseño.
Breakout at Spoke
La ruptura local en sitios radiales permite a los usuarios acceder a Internet directamente sin tener que enviar tráfico a través de la red superpuesta hacia el concentrador, lo que ayuda a conservar el ancho de banda del túnel. Esta opción se puede implementar en los vínculos WAN de Internet o MPLS. La figura 12 ilustra este concepto.
Cuando se utiliza la ruptura local, puede especificar NAT basada en interfaz o en grupo.
Breakout at Provider Hub (Central Breakout)
La ruptura central en un sitio de concentrador de proveedor permite despliegues radiales en los que los sitios radiales reenvían el tráfico destinado a Internet a través de la red superpuesta al dispositivo concentrador del proveedor, que luego reenvía el tráfico a Internet, como se muestra en la figura 13.
La conexión central en el sitio central se habilita de manera diferente que en un sitio radial. Se puede configurar manualmente en CSO a través de plantillas de etapa 2.
También se puede proporcionar un grupo central a sitios radiales a través de un sitio de Enterprise Hub. En este escenario, el concentrador empresarial puede realizar una ruptura local mediante una red subyacente para el reenvío o puede recibir la ruta predeterminada del departamento del centro de datos y propagarla a los radios.
Cuando se ofrece una división central tanto en el concentrador del proveedor como en el concentrador empresarial mediante el método de ruta predeterminado, se prefiere la ruta predeterminada del concentrador empresarial mediante la preferencia local del BGP.
Cloud Breakout
Otra opción de ruptura para el tráfico destinado a Internet, Cloud Breakout, está disponible para sitios radiales y centros empresariales. Cuando la ruptura de nube está habilitada, el sitio radial o el sitio del centro empresarial reenvía el tráfico destinado a Internet a Zscaler para su posterior procesamiento relacionado con la seguridad antes de enviarlo a Internet. La cuenta de Zscaler debe estar activa y accesible antes de enviar tráfico a través de la ruptura.
Usage Notes for Cloud Breakout
Los túneles de encapsulación de enrutamiento genérico (GRE) que utilizan direcciones IP públicas para los vínculos WAN son compatibles con la ruptura de la nube.
Cuando se utilizan túneles GRE, los dispositivos CPE no pueden estar detrás de NAT.
Al configurar las opciones de desglose de nube, puede especificar los parámetros de fase 1 de IPsec, los parámetros de fase 2 y el nombre de dominio.
Puede especificar la validación de la dirección IP o del nombre de host para los nodos de ruptura de la nube.
CSO rellena automáticamente el FQDN, las claves previamente compartidas y la información del vínculo WAN, y ofrece la opción de cambiar los valores rellenados automáticamente.
CSO admite la alta disponibilidad entre los vínculos WAN de un sitio radial de SD-WAN y el nodo de ruptura de nube.
Los nodos de vínculo WAN se pueden configurar como activos/pasivos o activos/activos.
Se puede definir un máximo de dos vínculos WAN entre el sitio radial de SD-WAN y el nodo de ruptura de nube.
Order of Preference for Scenarios with Multiple Breakout Options
Si el CPE dispone de varias opciones de desglose en el sitio radial y no se especifica una política de desglose, el orden de preferencia para el desglose es:
Departamento de centro de datos/centro empresarial
Ruptura local/Sesión en la nube
Centro de proveedores (central)
Si hay varias opciones de desglose disponibles para un sitio de concentrador corporativo, el orden de preferencia para el tráfico de desglose es:
Sin política de SD-WAN:
Departamento de centros de datos
Hub
Con la política de SD-WAN:
Ruptura local/Sesión en la nube
Departamento de centros de datos
Centro de proveedores (central)
Use Cases for Local Breakout
A continuación se describen algunos casos de uso para la ruptura local.
Service Provider Data Center
En este caso de uso, el cliente Enterprise utiliza el servicio SD-WAN del proveedor de servicios para la interconectividad de sitio a sitio. El cliente también utiliza servicios de valor añadido alojados fuera del centro de datos del proveedor de servicios.
En el sitio radial, la interfaz WAN orientada a MPLS del dispositivo local está configurada para admitir tráfico de interrupción local y de túnel. Como se muestra en la figura 14, el tráfico fluye a través de la red de la siguiente manera:
El tráfico entre sitios (SD-WAN) viaja a través de la red MPLS utilizando el túnel superpuesto.
El tráfico destinado a DC utiliza la ruptura local y viaja directamente a través de la red MPLS subyacente.
Como variación de este escenario, el centro de datos podría estar ubicado en otro lugar de la red MPLS, tal vez en un POP, como se muestra en la figura 16. En este caso, los flujos de tráfico siguen siendo generalmente los mismos que los anteriores.
Como otra variación de este escenario, el tráfico destinado a DC podría usar el túnel de superposición, la ruptura en el dispositivo del concentrador y volver al DC, como se muestra en la figura 16.
Esta opción tiene algunos inconvenientes:
Utiliza más ancho de banda de túnel.
Puede aumentar la latencia a medida que el dispositivo local en el sitio radial procesa y encapsula más tráfico.
Aumenta la carga en el dispositivo concentrador.
Crea una ruta subóptima, lo que hace que el tráfico fluya a través de los túneles hacia el dispositivo concentrador, solo para tener que volver a doblar para llegar al DC.
Sin embargo, también tiene algunas ventajas:
Mediante el uso de los túneles superpuestos, el tráfico destinado a DC puede aprovechar los servicios de SLA y elegir la mejor ruta de forma dinámica, mejorando así el rendimiento de la red para esas aplicaciones.
Se pueden ofrecer funciones de seguridad adicionales de forma centralizada.
Migration to SD-WAN
En este caso de uso, el cliente empresarial tiene varias ubicaciones grandes y usa el servicio MPLS existente del proveedor de servicios para proporcionar una malla completa entre sitios. El cliente desea migrar a SD-WAN y es probable que la implementación sea incremental. Sin embargo, es fundamental mantener la conectividad entre los sitios en todo momento.
La figura 17 ilustra un escenario en el que la migración está en marcha. La funcionalidad de SD-WAN se ha agregado al sitio 3 y al sitio 4, mientras que los demás sitios aún no se han migrado. En cada sitio habilitado para SD-WAN, la interfaz WAN orientada a MPLS del dispositivo local está configurada para admitir tráfico de interrupción local y de túnel. El tráfico fluye a través de la red de la siguiente manera:
El tráfico entre los sitios habilitados para SD-WAN puede usar el túnel superpuesto.
El tráfico entre un sitio habilitado para SD-WAN y un sitio heredado utiliza la ruptura local y viaja directamente a través de la red MPLS subyacente.
En este caso, la ruptura local es la clave para mantener la conectividad entre los sitios migrados y los sitios heredados.
Local breakout and NAT
Cuando el tráfico fluye desde un VRF de inquilino a Internet, normalmente se debe usar NAT para traducir desde el espacio de red privada del inquilino al espacio de red de Internet (público).
En los sitios radiales, los dispositivos locales pueden usar Auto-NAT para realizar automáticamente NAT de origen en todo el tráfico de ruptura local. En los sitios de concentrador, Auto-NAT no está disponible; sin embargo, la interfaz de usuario de CSO admite la creación manual de reglas NAT para estos dispositivos locales.
Local Breakout and DNS
La configuración de un dispositivo local como servidor DHCP para segmentos LAN permite especificar información del servidor DNS para los hosts finales. Para un sitio con la ruptura local habilitada, generalmente se recomienda especificar más de un servidor de nombres: un servidor interno para la resolución de nombres de dominio corporativos y un servidor público o ISP para el tráfico de ruptura local destinado a Internet.
Seguridad de red
Una de las consideraciones de seguridad importantes para las arquitecturas SD-WAN es proporcionar seguridad para los datos no solo en reposo, sino también en movimiento. La seguridad de los datos se ha mejorado para permitir el uso de PKI multinivel para los túneles de datos y OAM. Esto permite a CSO recibir certificados de CA de varios niveles de un servidor de CA, enviar varios certificados de CA a dispositivos de CPE, renovar y revocar varios certificados de CA en dispositivos de CPE.
CSO admite el protocolo simple de inscripción de certificados (SCEP), a partir de la versión 4.1 de CSO. Esto permite a CSO:
Actuar como servidor SCEP
Actuar como cllient de SCEP
Revocación de certificados
Renovación automática del certificado
Implementar certificados en un sitio o CPE
Administrar certificados en CPE (sitio)
Proporcionar compatibilidad con la interfaz gráfica de usuario para la información de CA Server
Renovaciones de certificados de sitio/CPE
Compatibilidad con Microsoft CA/NDES
Certificados de intermediario para cada sitio/CPE
Se proporciona una API back-end para el acceso mediante programación a las características de PKI.
Data Plane
Las conexiones de plano de datos se pueden configurar para usar IPsec con autenticación basada en PKI. Cuando se usa, el dispositivo local en las instalaciones cifra el tráfico antes de transmitirlo a través de la red al sitio remoto y la autenticación se controla con pares de claves pública y privada.
Management and Control Plane
CSO se conecta y configura dispositivos locales mediante SSH para conexiones de consola y NETCONF. A partir de CSO versión 4.0, los túneles de superposición OAM dedicados ayudan a mejorar las comunicaciones seguras e integrales entre los dispositivos locales y CSO. Los túneles OAM cifrados con IPsec y autenticados por PKI, que se muestran en la figura 18, permiten que los dispositivos radiales locales envíen tráfico de administración, enrutamiento y registro de forma segura a través de la red a un concentrador de proveedores. A continuación, el hub reenvía el tráfico a CSO.
OAM segura
Para obtener más detalles, consulte la sección Red OAM segura y redundante anteriormente en esta guía.