Las políticas de datos son una herramienta poderosa para que Cisco SD-WAN cumpla sus promesas. Permiten redirigir o dirigir flujos de tráfico específicos de una manera particular dentro o a través de la red superpuesta SD-WAN. Más específicamente, las políticas de datos permiten que la solución haga:
- Cualquier modificación que afecte el reenvío de paquetes en el plano de datos
- Por ejemplo: Marcado de paquetes, reenvio a través de un transporte específico Application Aware Routing (AAR), NAT, redirección de tráfico
Provisionamiento:
Las políticas se pueden aprovisionar de dos formas:
- Centralized
- Enviado desde vManage a vSmart a través de una transacción NETCONF transaction y luego publicado a los los Edge routers por vSmart a través de OMP - afecta a todos los Edges identificados en una lista
- Localized
- Enviado desde vManage directamente a los Edge routers a través de una transacción NETCONF - afecta a dispositivos específicos que requieran una política o configuraciones personalizadas (requiere un feature template que lo referencie)
¿Cuáles son las diferencias?
- Centralized Data policy - sólo puede haber una habilitada por VPN y site ID
- P. ej.: Marcado de paquetes, reenvio a través de un transporte específico Application Aware Routing (AAR), NAT, redirección de tráfico
- La configuración no se mantiene en el vEdge, se recibe a través de OMP y se almacena en la RIB volátil, por lo tanto, es temporal - no persiste luego de un reinicio
- Localized Data Policy
- P. ej.: QoS, ACLs
- La configuración se mantiene en el vEdge, se recibe a través de NETCONF, parecido a introducir los comandos en el CLI del equipo - persiste luego de un reinicio
Estructura de la Política de Datos (Data Policy) en formato CLI
Version en texto:
data-policy <name> vpn-list <name> sequence <n> match app-list <name> destination-data-ipv6-prefix-list <name> destination-data-prefix—list <name> destination-ip <ip-address> destination-ipv6 <ipv6-address> destination-port <port> dnsrequest | response dnsapp-list <name> dscp <dscp> packet-length <length> plp <plp> protocol <protocol> source-data-ipv6-prefix-list <name> source-data-ip-prefix-list <name> source-ip <ip-address> source-ipv6 <ipv6-address> source-port <port> tcp-syn ! ! ! action accept set dscp <dscp> forwarding-class <name> local-tloc <tloc> local-tloc-list <list> next-hop <ip-address> next-hop-ipv6 <ipv6-address> policer <name> service <name> tloc <tloc> tloc-list <name> vpn <vpn-id> cflowd count <counter> drop log loss-protect-fec-always loss-protect-fec-adaptive loss-protect-packet-dup nat-pool <nat-pool> natuse-vpn <vpn-id> redirect dns tcp-optimization ! ! ! ! default-action accept | drop
De manera análoga a los Route Maps en Cisco IOS, la política de datos contiene un conjunto de elementos que se pueden combinar y un conjunto de acciones que se pueden realizar al evaluarlos.
NOTA: tenga en cuenta la acción predeterminada en la parte inferior de la política de datos.
Aplicación de la Política:
Las políticas de datos pueden ser aplicadas en tres modos o formas (tenga en cuenta que la dirección es desde el punto de vista de Edge router
- From-Service (Upstream - hacia WAN desde LAN)
- From-Tunnel (Downstream - hacia LAN desde WAN)
- All (Ambos Upstream y Downstream)
Se pueden utilizar diferentes políticas si se aplican en diferentes direcciones. La dirección más común para aplicar una política es Upstream.
Tipos de Políticas de Datos
Entre las políticas de datos, hay 3 tipos principales de políticas que se pueden configurar para manejar los flujos de tráfico:
- Application Aware Routing (AAR)
- Traffic Data
- Cflowd
Application Aware Routing (AAR)
- En breve: PBR en esteroides
- Permite la evaluación y selección (matching) de muchos valores dentro de los paquetes IP, entre ellos:
- Dirección IP de origen y destino
- Puerto de origen y destino
- Protocolo de transporte de capa 4
- IP DSCP packet markings
- Aplicaciones - usando el motor DPI
- Qosmos DPI engine para vEdge appliances (Viptela OS)
- NBAR2 parar Cisco appliances (SD-WAN based IOS XE image)
- Después de ser seleccionados (matched), los paquetes se pueden reenviar de acuerdo con ciertos criterios.
- P. ej.:. Si el enlace de Internet no funciona, nadie navega a Youtube o Facebook.
- P. ej.:Si el enlace MPLS de un proveedor muestra una gran demora, reenvíe el tráfico a través del enlace MPLS de otro proveedor.
- Transporte específico
- Cumplimiento de SLA específico (según los umbrales (thresholds) de drop, delay y jitter)
Nota: AAR rige cómo se reenvía el tráfico entre los nodos SD-WAN dentro y a través de la red overlay. En otras palabras: solo entre Edge routers. La comparación se lleva a cabo de forma descendente, similar a las conocidas Access Lists y Route Maps de Cisco.
¿Cómo se calculan esos umbrales?
La política de AAR se basa en los resultados de paquetes (probes) BFD enviados a través de los túneles IPsec entre los dispositivos Edge. Los resultados de esos paquetes se almacenan en cubetas (buckets), y cada cubeta tiene una duración / longitud específica. Un cálculo medio promedio de todos los depósitos es el resultado observado por la solución al informar la calidad del enlace. El grupo de umbrales que deben cumplirse (y con los que se compara la calidad de los enlaces) se denomina SLA.
La naturaleza promedio del cálculo de los valores promueve un cierto factor de tolerancia, reduciendo la capacidad de respuesta a expensas de la estabilidad. En otras palabras: para que la solución detecte una caída de tensión (brownout) en un enlace dados los valores predeterminados, se necesitaría llenar al menos una cubeta (10 minutos, por defecto) para que se pueda activar un cambio.
Estos valores predeterminados se pueden personalizar para adaptarse a requisitos de SLA más agresivos / sensibles:
Ejemplo de Política AAR:
policy app-route-policy STANDARD-APP-POLICY vpn-list VPN-1 sequence 1 match dscp 46 !>>>> Matching DSCP values ! action count SLA_PLATINUM_COUNTER backup-sla-preferred-color biz-internet private1 !>>>> Transporte/color preferido y backup sla-class SLA_PLATINUM preferred-color private1 !>>>> SLA a satisfacer ! ! sequence 11 match dscp 34 ! action count SLA_GOLD_COUNTER backup-sla-preferred-color biz-internet private1 !>>>> Transporte/color preferido y backup sla-class SLA_GOLD preferred-color private1 !>>>> SLA a satisfacer ! ! sequence 21 match dscp 24 ! action count SLA_GOLD_COUNTER backup-sla-preferred-color biz-internet private1 !>>>> Transporte/color preferido y backup sla-class SLA_GOLD preferred-color private1 !>>>> SLA a satisfacer ! ! sequence 31 match app-list AL_FILE_TRANSFER !>>>> Matching Application list/family ! action count SLA_BRONZE_COUNTER backup-sla-preferred-color biz-internet private1 !>>>> Transporte/color preferido y backup sla-class SLA_BRONZE preferred-color biz-internet !>>>> SLA a satisfacer ! ! ! ! policy sla-class SLA_BRONZE !>>>> SLA a satisfacer loss 25 latency 500 ! sla-class SLA_GOLD !>>>> SLA a satisfacer loss 2 latency 110 ! sla-class SLA_PLATINUM !>>>> SLA a satisfacer loss 1 latency 100 ! ! ! !Magnitudes y unidades para los valores SLA jitter Jitter, in milliseconds latency Latency, in milliseconds loss Loss percentage
Traffic Data
Traffic Data es la política más flexible entre todas las políticas de datos. Permite al operador definir elementos específicos e implementar el reenvío en base a varios criterios. De manera análoga a los bien conocidos Route Maps y Access Lists en Cisco IOS, entre los elementos a crear y / o referenciar se pueden encontrar los siguientes:
- Next Hops
- TLOC
- TLOC lists
- Data prefixes
- Data prefix lists
- Servicios
- Hacen referencia a un punto de la red con un servicio específico que se ofrecerá: se puede crear y anunciar en la overlay rápidamente sin perturbar ni modificar la infraestructura ya existente.
- El tráfico se dirigirá / redirigirá a un servicio particular en la red overlay solo si una política de datos lo dicta
- Interfaces
- Policers
- Forwarding Classes
- DSCP markings
- Application Family lists
- Números de puertos
Como puede sugerir la variedad de elementos, las posibles combinaciones y el grado de personalización son copiosos, lo que proporciona una herramienta muy flexible para cumplir con requisitos complejos. Las políticas de tráfico de datos permiten dirigir, redirigir, sobrescribir / anular y desviar el tráfico entrante y saliente de la red overlay. A diferencia de la política AAR que tiene lugar entre TLOC que pertenecen solo a los Edges, la política de tráfico de datos puede hacer referencia a elementos dentro y fuera de la red overlay SD-WAN. La misma proporciona la capacidad de manipular, agregar y desagregar los flujos de tráfico en función de una variedad de información incluida en cada paquete reenviado.
Advertencia: se debe tener cuidado al intentar implementar políticas complejas. Las soluciones tienden a ser tan o más complejas que los problemas que buscan solucionar. Un alto grado de flexibilidad también podría conducir a un grado aún mayor de complejidad.
La lógica detrás de las políticas de datos es análoga a las Prefix Lists / Access Lists y Route Maps de Cisco. En otras palabras: las secuencias se evalúan de forma descendente y se detiene tan pronto como se encuentra una coincidencia (match). Además de eso, la acción predeterminada al final de una política es "drop", análoga a una / Access List en la jerga de Cisco.
A continuación se muestran algunos ejemplos de casos de uso:
Direct Internet Access (DIA) usando Data Policy:
- Más granular que una ruta en la VPN de servicio
- Match de prefijos, puertos y otros
- Aquí solo se separando el tráfico web
- Podría hacer match de O365 y otras aplicaciones similares en la nube
- Se puede configurar un transporte específico para usarlo como punto de salida
data-policy DIA vpn-list VPN-10 sequence 1 match destination-data-prefix-list INTERNAL-NETWORKS !>>>> Esta prefix list debió ser creada de antemano ! action accept ! ! sequence 11 match destination-port 80 443 source-ip 0.0.0.0/0 ! action accept nat use-vpn 0 !>>>> Dirigir el tráfico hacia la overlay infra de VPN 0
Direct Internet Access (DIA) con Service Chaining
- Redirigir el tráfico a un servicio configurado localmente
- Aquí un túnel GRE
- Aprovechando elementos externos como Umbrella SIG o zScaler cloud gateway
- Túnel GRE o IPSec configurado en el dispositivo local
policy data-policy Web_Firewall vpn-list vpn_all sequence 10 match protocol 6 match destination-port 80 443 ! action accept set service FW local !>>>> Se puede crear un servicio para hacer referencia a un punto en la red overlay o en el Edge local ! ! ! default-action accept
Cflowd
Cflowd permite al administrador monitorear el tráfico que fluye a través de los Edge routers en la red overlay y exportar la información del flujo a un recopilador configurado. Cflowd envía información periódica sobre el flujo a su recolector. La información exportada contiene datos que identifican los flujos, que están contenidos en los paquetes IP. Viptela OS implementa Cflowd versión 10, también conocido como el protocolo IP Flow Information Export (IPFIX).
Las políticas de Cflowd son sencillas de configurar, los elementos necesarios para que funcione una política de Cflowd son los siguientes:
- Active Flow Timeout
- Inactive Flow Timeout
- Flow Refresh
- Sampling Interval
- VPN ID
- IP address
- Puerto
- Protocolo
- Source Interface
A continuación se muestra un ejemplo de un par de políticas de Cflowd:
policy cflowd-template CFT_CFLOWD_ALL_HUBS flow-active-timeout 60 flow-sampling-interval 32 collector vpn 512 address 10.15.1.20 port 2055 transport transport_udp source-interface mgmt0 collector vpn 512 address 10.15.128.20 port 2055 transport transport_udp source-interface mgmt0 collector vpn 512 address 192.0.2.10 port 9995 transport transport_udp source-interface mgmt0 collector vpn 512 address 192.0.2.254 port 9995 transport transport_udp source-interface mgmt0 ! ! ! cflowd-template CFT_CFLOWD_BRANCHES flow-active-timeout 60 flow-sampling-interval 32 collector vpn 1 address 10.15.1.20 port 2055 transport transport_udp source-interface loopback1 collector vpn 1 address 192.0.2.10 port 9995 transport transport_udp source-interface loopback1 collector vpn 1 address 192.0.2.254 port 9995 transport transport_udp source-interface loopback1 !
Tenga en cuenta que se muestran dos políticas de Cflowd. Cada política se puede aplicar a un conjunto de dispositivos (site list) y se puede personalizar su configuración. Algunos sitios pueden obtener muestras de diferentes VPN e interfaces, y hacia diferentes servidores de destino. Siempre que la site list esté diseñada correctamente (y no haya duplicados entre las site lists), se pueden personalizar sus políticas correspondientes.
Nota: Se admite un número máximo de 4 collectors por política.
Guia paso a paso (vManage GUI) - Creación de una Política de Datos Centralizada
Dada la naturaleza modular de la solución, algunos elementos (listas) deben crearse de antemano para que sean referenciados por la propia política más adelante.
Los elementos mínimos requeridos son:
- Site List (que coincida con varios sites, o simplemente uno solo): dependerá de sus requisitos
- VPN List (que coincida con varias VPNS o simplemente una sola VPN): en general, una lista de VPN por política de datos es la regla general, ya que cada VPN es un espacio virtual aislado
Elementos opcionales (según su política):
- Source Data Prefix List
- Destination Data Prefix List
- Application Family list
- TLOC list
- Policer list
- NATpool interfaces (Configuracion del Edge router)
Walkthrough:
Desde el panel de vManage:
- Acceda al panel izquierdo en la sección de configuración y seleccione "Policies"
- Cree una nueva política o edite una ya existente; tenga en cuenta que las políticas centralizadas contienen políticas de control y de datos para cada VPN y sitio. Este documento se centra en las políticas de datos.
- Al crear una política desde cero, el asistente (wizard) guiará al usuario a través del flujo de trabajo:
- Observe en verde los pasos del flujo de trabajo
- Anote en rojo los grupos de interés (listas)
Una vez que se han creado los grupos de interés, el flujo de trabajo puede avanzar al siguiente paso (Configure Topology and VPN Membership). Si las listas se crearon antes de la política en sí, no es necesario realizar ninguna acción en este paso, se puede omitir.
- De forma predeterminada, en ausencia de una política de topología de VPN creada, los dispositivos Edge intentan establecer túneles de Data Plane (IPsec) desde cada transporte hacia cualquier transporte. En otras palabras: malla completa (full mesh).
- No es necesario crear una política de topología, se puede dejar en blanco, lo que supone una malla completa
- La membresía de VPN (VPN Membership) dicta qué dispositivos pertenecen a una VPN en particular, lo que les impide unirse a otros segmentos de la red (VPN) a los que no han sido autorizados.
Una vez que se ha cubierto el paso de la topología y la membresía de VPN, se pueden crear y aplicar las políticas de datos.
Entre las políticas de datos, hay 3 tipos principales de políticas que se pueden configurar para manejar los flujos de tráfico:
- Application Aware Routing (AAR)
- Traffic Data
- Cflowd
Cada política tiene sus casos de uso y requisitos que deben cumplirse; consulte la información anterior para seleccionar la política que mejor se adapte a sus requisitos. Las políticas que se muestran arriba se muestran en su expresión CLI equivalente. Al crear políticas en vManage, su creación implica el uso de una interfaz gráfica de usuario (GUI).
Application Aware Routing (AAR)
Al crear una política AAR, la pantalla predeterminada que se muestra es la siguiente:
Al seleccionar "+ Sequence Type", se muestran dos opciones a la derecha. Continuemos examinando con la opcion "Sequence Rule":
Las políticas de AAR permitirían la realizar matching de varios elementos, no solo "aplicaciones" como su nombre podría implicar. Una vez seleccionados los criterios a coincidir, las acciones a realizar serán las siguientes:
Un ejemplo de posibles combinaciones se puede encontrar a continuación.
Una vez que se hayan seleccionado los criterios y acciones coincidentes, guarde la política en la parte inferior de la pantalla.
Traffic Data
Para crear una política de datos de tráfico, acceda al botón "Add Policy" en la GUI, en la opción "Traffic Data". Se puede crear una política antes de este paso y luego importarla.
Al crear una política, se ofrecen varias opciones con respecto a la secuencia que se agregará, elija la que mejor se adapte a su caso de uso.
Las opciones más flexibles - y también más complejas - que se ofrecen son las políticas "Custom". A continuación se muestra una captura de posibles combinaciones para los criterios de coincidencia utilizando una política personalizada:
Tenga en cuenta la capacidad de reescribir los valores DSCP y los Forwarding Classes, redirigir el tráfico a un Next Hop específico (fuera de la red overlay), TLOC o conjunto de TLOCs (ambos dentro de la red overlay), usar un NAT Pool o aplicar un Policer.
NOTA: Recuerde siempre la cláusula de "default-action" de una Política de datos. Es por defecto "drop". Los datos que no coincidan con los criterios (podrían ser para NAT o redireccionamiento / dirección) no necesariamente deben descartarse, simplemente podrían omitirse en el proceso. Si no cambia esta configuración, se produciría un outage (experiencia propia) para el tráfico que no coincida. Recuerde cambiar ese valor a "accept" como se muestra a continuación:
Una vez que se hayan seleccionado los criterios y acciones coincidentes, guarde la política en la parte inferior de la pantalla.
Cflowd
Para crear una política de Cflowd, acérquese al botón "Add Policy" debajo de la opción "Cflowd" en la GUI.
A continuación, se muestra la información requerida para que la política sea creada en vManage.
Una vez que se haya introducido la configuración del recopilador y de la muestra, guarde la política en la parte inferior de la pantalla.
Policy application
El último de los pasos en el flujo de trabajo de creación de políticas es aplicar las políticas a una lista específica y definir su dirección (cuando sea necesario). Siendo la lista para obtener la política aplicada site list o VPN list.
Intentemos aplicar una Política de datos de prueba en un site list para observar la información requerida a ingresar para realizar esta operación:
Tenga en cuenta las instrucciones disponibles para la Política de datos: From Service, From Tunnel, All. Además de eso, un site list o VPN list.
Una vez que se hayan seleccionado las listas de direcciones, sitios y VPN deseados, proceda a Guardar la política y envíelo a los controladores vSmart. La política debe enviarse en segundos, y los sitios que coincidan con las listas específicas obtendrán su nueva configuración de vSmart a través de OMP.
¡Espero que esta publicación les sea útil!
David
Version en ingles: https://recurseit.com/2021/01/27/cisco-sd-wan-data-policies/
Resources (Ingles): https://recurseit.com/2020/02/26/resources-for-the-cisco-sd-wan-exam/
1 Comentario
