Funcionalidades: \u00bfqu\u00e9 puede hacer una tecnolog\u00eda que otra no puede? \u00bfY es realmente tan importante?<\/li>\n<\/ul>\n<\/p>\n
\u00bfCu\u00e1les son las diferencias arquitect\u00f3nicas y son realmente importantes?<\/h3>\n \nEn cada una de las tecnolog\u00edas mencionadas hay m\u00faltiples \u00abpartes m\u00f3viles\u00bb, que no solo tienen diferentes roles, sino tambi\u00e9n principios de interacci\u00f3n entre s\u00ed. La escalabilidad, la resistencia a fallos y la eficacia general de la soluci\u00f3n dependen directamente de cu\u00e1n bien pensados est\u00e1n estos principios y la mec\u00e1nica general de la soluci\u00f3n. <\/p>\n
Analicemos diversos aspectos de la arquitectura con m\u00e1s detalle:<\/p>\n
Data-plane<\/b> es la parte de la soluci\u00f3n responsable de la transmisi\u00f3n del tr\u00e1fico de usuario entre el origen y el receptor. En DMVPN y SD-WAN se implementa de manera bastante similar en los enrutadores basados en t\u00faneles GRE Multipoint. La diferencia radica en c\u00f3mo se forma el conjunto necesario de par\u00e1metros de estos t\u00faneles:<\/p>\n\nen DMVPN\/PfR<\/b> es \u00fanicamente una jerarqu\u00eda de nodos de dos niveles con una topolog\u00eda tipo \u00abEstrella\u00bb o Hub-n-Spoke. Se requiere una configuraci\u00f3n est\u00e1tica del Hub y un enlace est\u00e1tico del Spoke al Hub, as\u00ed como la interacci\u00f3n a trav\u00e9s del protocolo NHRP para formar la conectividad del data-plane. Como resultado, cambios en el Hub<\/b>resultan significativamente dif\u00edciles, relacionados, por ejemplo, con la modificaci\u00f3n\/conexi\u00f3n de nuevos canales WAN o el cambio de par\u00e1metros de los existentes.<\/li>\nen SD-WAN<\/b> es un modelo completamente din\u00e1mico de detecci\u00f3n de par\u00e1metros de t\u00faneles establecidos basado en control-plane (protocolo OMP) y orchestration-plane (interacci\u00f3n con el controlador vBond para la detecci\u00f3n de controladores y NAT traversal). En este caso, se pueden tener cualquier tipo de topolog\u00edas superpuestas, incluidas las jer\u00e1rquicas. Dentro de la topolog\u00eda superpuesta establecida de los t\u00faneles, es posible una configuraci\u00f3n flexible de la topolog\u00eda l\u00f3gica en cada VPN (VRF) individual.<\/li>\n<\/ul>\n Control-plane<\/b> son funciones de intercambio, filtrado y modificaci\u00f3n de informaci\u00f3n de rutas y otros datos entre los componentes de la soluci\u00f3n. <\/p>\n\nen DMVPN\/PfR<\/b> solo se lleva a cabo entre los enrutadores Hub y Spoke. El intercambio directo de informaci\u00f3n de rutas entre Spoke no es posible. Como resultado, sin un Hub operativo, no puede funcionar ni el control-plane ni el data-plane.<\/b>, lo que impone a Hub requisitos adicionales de alta disponibilidad que no siempre pueden cumplirse.<\/li>\nen SD-WAN<\/b> \u2013 el plano de control nunca se establece directamente entre los enrutadores; la interacci\u00f3n se basa en el protocolo OMP y debe realizarse a trav\u00e9s de un tipo especializado de controlador vSmart, lo que permite la carga equilibrada, la georreserva y la gesti\u00f3n centralizada de la carga de se\u00f1alizaci\u00f3n. Otra caracter\u00edstica del protocolo OMP es su significativa resistencia a la p\u00e9rdida y su independencia de la velocidad del canal de comunicaci\u00f3n con los controladores (dentro de l\u00edmites razonables, por supuesto). Esto permite colocar controladores SD-WAN en nubes p\u00fablicas o privadas con acceso a trav\u00e9s de Internet.<\/li>\n<\/ul>\n Pol\u00edtica de plano<\/b> \u2013 la parte de la soluci\u00f3n encargada de definir, distribuir y aplicar pol\u00edticas de gesti\u00f3n del tr\u00e1fico en la red distribuida.<\/p>\n\nDMVPN <\/b>\u2013 est\u00e1 efectivamente limitada por las pol\u00edticas de calidad de servicio (QoS), configuradas individualmente en cada enrutador a trav\u00e9s de CLI o plantillas de Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 las pol\u00edticas PfR se generan en el enrutador centralizado Master Controller (MC) a trav\u00e9s de CLI y luego se distribuyen autom\u00e1ticamente a los MC de las sucursales. Se utilizan las mismas v\u00edas de transferencia de pol\u00edticas que para el plano de datos. No hay forma de disociar el intercambio de pol\u00edticas, informaci\u00f3n de rutas y datos de usuarios. La distribuci\u00f3n de pol\u00edticas implica la necesidad de conectividad IP entre Hub y Spoke. En este contexto, la funci\u00f3n del MC puede combinarse, si es necesario, con el enrutador DMVPN. Es posible (pero no obligatorio) usar plantillas de Prime Infrastructure para la creaci\u00f3n centralizada de pol\u00edticas. Una caracter\u00edstica importante es que la pol\u00edtica se forma globalmente de la misma manera en toda la red \u2013 no se admiten pol\u00edticas individuales para segmentos espec\u00edficos.<\/b>.<\/li>\nSD-WAN<\/b> Las pol\u00edticas de gesti\u00f3n del tr\u00e1fico y calidad del servicio se definen de forma centralizada a trav\u00e9s de la interfaz gr\u00e1fica de Cisco vManage, accesible tambi\u00e9n a trav\u00e9s de Internet (si es necesario). Se distribuyen mediante canales de se\u00f1alizaci\u00f3n directamente o indirectamente a trav\u00e9s de controladores vSmart (depende del tipo de pol\u00edtica). No dependen de la conectividad de data-plane entre los enrutadores, ya que utilizan todos los caminos disponibles para el tr\u00e1fico entre el controlador y el enrutador.\n Para diferentes segmentos de la red, es posible una formaci\u00f3n flexible de diversas pol\u00edticas: el \u00e1mbito de aplicaci\u00f3n de la pol\u00edtica se determina por una serie de identificadores \u00fanicos previstos en la soluci\u00f3n, como el n\u00famero de sucursal, tipo de aplicaci\u00f3n, direcci\u00f3n del tr\u00e1fico, etc.\n<\/li>\n<\/ul>\n
Plano de orquestaci\u00f3n<\/b> mecanismos que permiten que los componentes se descubran entre s\u00ed de forma din\u00e1mica, configuren y coordinen la posterior interacci\u00f3n.<\/p>\n\nen DMVPN\/PfR<\/b> El descubrimiento mutuo entre los enrutadores se basa en la configuraci\u00f3n est\u00e1tica de los dispositivos Hub y la configuraci\u00f3n correspondiente de los dispositivos Spoke. El descubrimiento din\u00e1mico ocurre solo para Spoke, que reporta sus par\u00e1metros de conexi\u00f3n al dispositivo Hub, que a su vez ha sido previamente ingresado en la configuraci\u00f3n de Spoke. Sin conectividad IP entre Spoke y al menos un Hub, no es posible formar ni data-plane ni control-plane.<\/b><\/li>\nen SD-WAN<\/b> La orquestaci\u00f3n de los componentes de la soluci\u00f3n se realiza utilizando el controlador vBond, con el que cada componente (enrutadores y controladores vManage\/vSmart) debe establecer preliminarmente conectividad IP.\n Inicialmente, los componentes no conocen los par\u00e1metros de conexi\u00f3n entre s\u00ed: para esto necesitan al intermediario-orquestador vBond. El principio general es el siguiente: cada componente en la fase inicial solo conoce (autom\u00e1ticamente o est\u00e1ticamente) los par\u00e1metros de conexi\u00f3n a vBond; luego, vBond informa al enrutador sobre los controladores vManage y vSmart (detectados previamente), lo que permite el establecimiento autom\u00e1tico de todas las conexiones de se\u00f1alizaci\u00f3n necesarias. <\/p>\n
El siguiente paso es que el nuevo enrutador obtenga informaci\u00f3n sobre los dem\u00e1s enrutadores en la red a trav\u00e9s del intercambio OMP con el controlador vSmart. De este modo, el enrutador, sin conocer inicialmente nada sobre los par\u00e1metros de la red, puede descubrir y conectarse autom\u00e1ticamente a los controladores, y luego tambi\u00e9n descubrir y formar la conectividad con los dem\u00e1s enrutadores. En este proceso, los par\u00e1metros de conexi\u00f3n de todos los componentes son inicialmente desconocidos y pueden cambiar durante la operaci\u00f3n.\n<\/li>\n<\/ul>\n
Plano de gesti\u00f3n<\/b> \u2013 la parte de la soluci\u00f3n que proporciona gesti\u00f3n y monitoreo centralizados.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 no se contempla una soluci\u00f3n de plano de gesti\u00f3n especializada. Para la automatizaci\u00f3n b\u00e1sica y el monitoreo, se pueden utilizar productos como Cisco Prime Infrastructure. Cada enrutador tiene la capacidad de ser administrado a trav\u00e9s de la interfaz de l\u00ednea de comandos CLI. No se contempla la integraci\u00f3n con sistemas externos a trav\u00e9s de API.<\/b><\/li>\nSD-WAN<\/b> \u2013 toda la interacci\u00f3n y el monitoreo se realizan de manera centralizada a trav\u00e9s de la interfaz gr\u00e1fica del controlador vManage. Todas las funcionalidades de la soluci\u00f3n est\u00e1n disponibles para configuraci\u00f3n a trav\u00e9s de vManage, as\u00ed como a trav\u00e9s de una biblioteca de API REST completamente documentada.\n Todas las configuraciones de la red SD-WAN en vManage se reducen a dos constructos principales: la creaci\u00f3n de plantillas de dispositivos (Device Template) y la creaci\u00f3n de pol\u00edticas que definen la l\u00f3gica de operaci\u00f3n de la red y el tratamiento del tr\u00e1fico. As\u00ed, al transmitir la pol\u00edtica formulada por el administrador, vManage selecciona autom\u00e1ticamente qu\u00e9 cambios y en qu\u00e9 dispositivos\/controladores individuales deben realizarse, lo que aumenta significativamente la eficiencia y escalabilidad de la soluci\u00f3n.<\/p>\n
A trav\u00e9s de la interfaz vManage, se puede no solo configurar la soluci\u00f3n Cisco SD-WAN, sino tambi\u00e9n realizar un monitoreo completo del estado de todos los componentes de la soluci\u00f3n, incluyendo el estado actual de las m\u00e9tricas de t\u00faneles individuales y estad\u00edsticas de uso de diversas aplicaciones basadas en el an\u00e1lisis DPI.<\/p>\n
A pesar de la centralizaci\u00f3n de la interacci\u00f3n, todos los componentes (controladores y enrutadores) tambi\u00e9n cuentan con una interfaz de l\u00ednea de comandos (CLI) completamente funcional, que es necesaria en la fase de implementaci\u00f3n o en caso de situaciones an\u00f3malas para el diagn\u00f3stico local. En modo est\u00e1ndar (con un canal de se\u00f1al entre los componentes), la l\u00ednea de comandos en los enrutadores est\u00e1 disponible solo para diagn\u00f3stico y no para realizar cambios locales, lo que garantiza tanto la seguridad local como una \u00fanica fuente de cambios en dicha red: vManage.<\/li>\n<\/ul>\n
\nSeguridad integrada<\/b> \u2013 aqu\u00ed se debe hablar no solo de la protecci\u00f3n de los datos del usuario durante la transmisi\u00f3n por canales abiertos, sino tambi\u00e9n de la seguridad general de la red WAN basada en la tecnolog\u00eda elegida.<\/p>\n\nen DMVPN\/PfR<\/b> se prev\u00e9 la posibilidad de cifrado de datos del usuario y protocolos de se\u00f1alizaci\u00f3n. Al utilizar ciertos modelos de enrutadores, tambi\u00e9n est\u00e1n disponibles las funciones de cortafuegos con inspecci\u00f3n de tr\u00e1fico, IPS\/IDS. Se puede segmentar redes de sucursales utilizando VRF. Existe la posibilidad de autenticaci\u00f3n (de un solo factor) de los protocolos de control.\n El enrutador remoto se considera, por defecto, un elemento confiable de la red; es decir, no se suponen ni se consideran casos de compromiso f\u00edsico de dispositivos individuales ni la posibilidad de acceso no autorizado a ellos, y no hay autenticaci\u00f3n de dos factores para los componentes de la soluci\u00f3n, lo que, en el caso de una red geogr\u00e1ficamente distribuida, puede conllevar graves riesgos adicionales.<\/b> <\/li>\nen SD-WAN<\/b> De manera similar a DMVPN, se prev\u00e9 la posibilidad de cifrado de datos del usuario, pero con funciones de seguridad de red y segmentaci\u00f3n L3\/VRF significativamente ampliadas (MSS, IPS\/IDS, filtrado de URL, filtrado de DNS, AMP\/TG, SASE, proxy TLS\/SSL, etc.). A su vez, el intercambio de claves de cifrado se realiza de manera m\u00e1s eficiente a trav\u00e9s de controladores vSmart (y no directamente), a trav\u00e9s de canales de se\u00f1al previamente establecidos, protegidos por cifrado DTLS\/TLS basado en certificados de seguridad. Esto, a su vez, garantiza la seguridad de dicho intercambio y proporciona una mejor escalabilidad de la soluci\u00f3n, incluso hasta decenas de miles de dispositivos en una sola red.\n Todas las conexiones de se\u00f1al (controlador-controlador, controlador-rutina) tambi\u00e9n est\u00e1n protegidas mediante DTLS\/TLS. Los enrutadores son equipados con certificados de seguridad al momento de su fabricaci\u00f3n, con la posibilidad de ser reemplazados o renovados. La autenticaci\u00f3n de dos factores se logra mediante el cumplimiento obligatorio y simult\u00e1neo de dos condiciones para que el enrutador\/controlador funcione en la red SD-WAN:<\/p>\n
\nCertificado de seguridad vigente<\/li>\n Incorporaci\u00f3n expl\u00edcita y consciente por parte del administrador de cada componente en la lista blanca de dispositivos permitidos.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Diferencias funcionales entre SD-WAN y DMVPN\/PfR<\/h2>\n \nAl pasar a discutir las diferencias funcionales, es importante se\u00f1alar que muchas de ellas son una continuaci\u00f3n de las arquitect\u00f3nicas; no es un secreto que al formar la arquitectura de la soluci\u00f3n, los desarrolladores se basan en las capacidades que desean obtener como resultado. Examinemos las diferencias m\u00e1s significativas entre las dos tecnolog\u00edas.<\/p>\n
AppQ (Calidad de Aplicaci\u00f3n): funciones para asegurar la calidad de transmisi\u00f3n del tr\u00e1fico de aplicaciones empresariales<\/h3>\n \nLas funciones clave de las tecnolog\u00edas consideradas est\u00e1n destinadas a mejorar en la medida de lo posible la experiencia del usuario al usar aplicaciones cr\u00edticas para el negocio en una red distribuida. Esto es especialmente importante en situaciones en las que parte de la infraestructura no es controlada por IT o incluso no garantiza una transmisi\u00f3n exitosa de datos.<\/p>\n
DMVPN no proporciona tales mecanismos por s\u00ed mismo. Lo mejor que se puede hacer en una red DMVPN cl\u00e1sica es clasificar el tr\u00e1fico saliente por aplicaciones y priorizarlo al momento de transmitirlo hacia el canal WAN. La selecci\u00f3n del t\u00fanel DMVPN se basa en su disponibilidad y en el resultado del funcionamiento de los protocolos de enrutamiento, sin tener en cuenta el estado del camino\/t\u00fanel ni su posible degradaci\u00f3n parcial en t\u00e9rminos de m\u00e9tricas clave relevantes para las aplicaciones de red: latencia, variaci\u00f3n de latencia (jitter) y p\u00e9rdidas (%). Por lo tanto, comparar DMVPN cl\u00e1sico con SD-WAN en t\u00e9rminos de resolver tareas de AppQ carece de sentido: DMVPN no puede abordar esta tarea. Sin embargo, al incorporar la tecnolog\u00eda de Cisco Performance Routing (PfR) a este contexto, la situaci\u00f3n cambia y la comparaci\u00f3n con Cisco SD-WAN se vuelve m\u00e1s razonable. <\/p>\n
Antes de pasar a discutir las diferencias, hablemos brevemente sobre en qu\u00e9 se parecen las tecnolog\u00edas. As\u00ed que ambas tecnolog\u00edas:<\/p>\n
\ntienen un mecanismo que permite evaluar din\u00e1micamente el estado de cada t\u00fanel instalado en funci\u00f3n de ciertas m\u00e9tricas: al menos, latencia, variaci\u00f3n de latencia y p\u00e9rdida de paquetes (%)<\/li>\n utilizan un conjunto espec\u00edfico de herramientas para formar, difundir y aplicar las reglas (pol\u00edticas) de gesti\u00f3n del tr\u00e1fico teniendo en cuenta los resultados de la medici\u00f3n del estado de las m\u00e9tricas clave de los t\u00faneles.<\/li>\n clasifican el tr\u00e1fico de aplicaciones en los niveles L3-L4 (DSCP) del modelo OSI o por las firmas de aplicaciones en L7 basadas en mecanismos DPI incorporados en el enrutador.<\/li>\n permiten a aplicaciones significativas definir valores umbrales aceptables de m\u00e9tricas, reglas de transmisi\u00f3n de tr\u00e1fico por defecto y reglas de reenv\u00edo de tr\u00e1fico al superar los valores umbrales.<\/li>\n al encapsular el tr\u00e1fico en GRE\/IPSec, utilizan un mecanismo establecido en la industria para transferir la marca de DSCP interna al encabezado del paquete GRE\/IPSec externo, lo que permite sincronizar las pol\u00edticas de QoS de la organizaci\u00f3n y el proveedor de servicios (si existe un SLA correspondiente).<\/li>\n<\/ul>\n\n
\u00bfC\u00f3mo difieren los mecanismos de evaluaci\u00f3n de m\u00e9tricas de extremo a extremo entre SD-WAN y DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nPara evaluar las m\u00e9tricas est\u00e1ndar del estado del t\u00fanel, se utilizan tanto sensores de software activos como pasivos (Probes). Los activos se basan en el tr\u00e1fico del usuario, los pasivos emulan dicho tr\u00e1fico (en su ausencia). <\/li>\n No hay un ajuste fino de los temporizadores y las condiciones de detecci\u00f3n de degradaci\u00f3n, el algoritmo es fijo.<\/li>\n Adem\u00e1s, se puede medir el ancho de banda utilizado en la direcci\u00f3n de salida. Lo que agrega a DMVPN\/PfR flexibilidad adicional en la gesti\u00f3n del tr\u00e1fico.<\/li>\n Algunos mecanismos de PfR, al superar las m\u00e9tricas, dependen de la retroalimentaci\u00f3n en forma de mensajes TCA (Threshold Crossing Alert) especiales, que deben provenir del receptor del tr\u00e1fico hacia la fuente, lo que a su vez implica que el estado de los canales medidos debe ser al menos suficiente para transmitir tales mensajes TCA. Lo que en la mayor\u00eda de los casos no es un problema, pero evidentemente no puede ser garantizado. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nPara la evaluaci\u00f3n continua de las m\u00e9tricas est\u00e1ndar del estado del t\u00fanel se utiliza el protocolo BFD en modo eco. En este caso, no se requiere retroalimentaci\u00f3n especial en forma de TCA o mensajes similares, garantizando el aislamiento de los dominios de falla. Tampoco se necesita tr\u00e1fico de usuario para evaluar el estado del t\u00fanel.<\/li>\n Hay una opci\u00f3n de ajuste fino de los temporizadores BFD para regular la velocidad de activaci\u00f3n y la sensibilidad del algoritmo a las degradaciones del canal de comunicaci\u00f3n de unos pocos segundos a minutos.\n
En el momento de redactar este art\u00edculo, en cada uno de los t\u00faneles hay prevista solo una sesi\u00f3n BFD. Esto potencialmente crea una granularidad menor al analizar el estado del t\u00fanel. En la pr\u00e1ctica, esto puede convertirse en una limitaci\u00f3n solo en caso de usar una conexi\u00f3n WAN basada en MPLS L2\/L3 VPN con un SLA de QoS acordado; si la marcaci\u00f3n DSCP del tr\u00e1fico BFD (despu\u00e9s de la encapsulaci\u00f3n en IPSec\/GRE) coincide con la cola de alta prioridad en la red del operador de telecomunicaciones, esto podr\u00eda afectar la precisi\u00f3n y velocidad de detecci\u00f3n de la degradaci\u00f3n para el tr\u00e1fico de baja prioridad. No obstante, existe la posibilidad de cambiar la marcaci\u00f3n BFD por defecto para reducir el riesgo de que ocurran tales situaciones. Se espera que en las pr\u00f3ximas versiones del software Cisco SD-WAN se introduzcan configuraciones m\u00e1s finas para BFD, as\u00ed como la capacidad de iniciar varias sesiones BFD dentro de un mismo t\u00fanel con valores DSCP individuales (para diferentes aplicaciones).<\/li>\n BFD tambi\u00e9n permite evaluar el tama\u00f1o m\u00e1ximo del paquete que se puede transmitir a trav\u00e9s de un t\u00fanel sin fragmentaci\u00f3n. Esto permite que SD-WAN ajuste din\u00e1micamente par\u00e1metros como MTU y TCP MSS Adjust, para utilizar de manera \u00f3ptima el ancho de banda disponible en cada canal.<\/li>\n En SD-WAN tambi\u00e9n est\u00e1 disponible la opci\u00f3n de sincronizar QoS con los operadores de telecomunicaciones no solo bas\u00e1ndose en el campo L3 DSCP, sino tambi\u00e9n en valores L2 CoS, que pueden ser generados autom\u00e1ticamente en la red de sucursales por dispositivos especializados, como tel\u00e9fonos IP.<\/li>\n<\/ul>\n<\/p>\n
\u00bfCu\u00e1les son las diferencias en las capacidades, m\u00e9todos de determinaci\u00f3n y aplicaci\u00f3n de las pol\u00edticas AppQ?<\/h3>\n <\/p>\n
Pol\u00edticas DMVPN\/PfR:<\/h4>\n <\/p>\n
\nSe definen en el (los) enrutador(-es) del centro de la sucursal (CF) a trav\u00e9s de la l\u00ednea de comandos CLI o plantillas de configuraci\u00f3n CLI. La creaci\u00f3n de plantillas CLI requiere preparaci\u00f3n y conocimiento de la sintaxis de las pol\u00edticas.\n
Se definen globalmente sin posibilidad de personalizaci\u00f3n\/cambio seg\u00fan los requisitos de segmentos individuales de la red.<\/b><\/li>\nNo se prev\u00e9 la formaci\u00f3n interactiva de pol\u00edticas en la interfaz gr\u00e1fica.<\/li>\n No se contempla el seguimiento de cambios, la herencia, ni la creaci\u00f3n de m\u00faltiples versiones de pol\u00edticas para un r\u00e1pido cambio.<\/li>\n Se distribuyen autom\u00e1ticamente a los enrutadores de sucursales remotas. Para ello, se utilizan los mismos canales de comunicaci\u00f3n que para la transmisi\u00f3n de datos de usuario. En caso de no haber un canal de comunicaci\u00f3n entre la sede central y la sucursal remota, la distribuci\u00f3n\/cambio de las pol\u00edticas es imposible.<\/li>\n Se aplican en cada enrutador y modifican el resultado de los protocolos de enrutamiento est\u00e1ndar seg\u00fan sea necesario, teniendo mayor prioridad. <\/li>\n En casos donde todos los canales WAN de la sucursal experimentan p\u00e9rdidas significativas de tr\u00e1fico, no se prev\u00e9n mecanismos de compensaci\u00f3n<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Pol\u00edticas SD-WAN:<\/h4>\n <\/p>\n
\nSe definen en la interfaz gr\u00e1fica de vManage a trav\u00e9s de un asistente interactivo de plantillas.<\/li>\n Soportan la creaci\u00f3n de m\u00faltiples pol\u00edticas, copia, herencia y cambio entre pol\u00edticas en tiempo real.<\/li>\n Soportan la personalizaci\u00f3n de pol\u00edticas para diferentes segmentos (sucursales) de la red.<\/li>\n Se distribuyen utilizando cualquier canal de se\u00f1alizaci\u00f3n disponible entre el controlador y el enrutador y\/o vSmart; no dependen directamente de la conectividad del data-plane entre los enrutadores. Sin embargo, se requiere conectividad IP entre el propio enrutador y los controladores.\n
En casos donde todos los canales disponibles de la sucursal sufren p\u00e9rdidas significativas de datos que superan los umbrales permitidos para aplicaciones cr\u00edticas, es posible utilizar mecanismos adicionales que aumentan la fiabilidad de la transmisi\u00f3n:\n\nFEC (Correcci\u00f3n de Errores Adelantada)<\/b> utiliza un algoritmo especial de codificaci\u00f3n redundante. Al transmitir tr\u00e1fico cr\u00edtico a trav\u00e9s de canales con un porcentaje significativo de p\u00e9rdidas, el FEC puede activarse autom\u00e1ticamente y permite recuperar la parte de los datos perdida si es necesario. Esto aumenta ligeramente el ancho de banda utilizado, pero mejora significativamente la fiabilidad.\n
Duplicaci\u00f3n de flujos de datos<\/b> Adem\u00e1s, la pol\u00edtica de FEC puede prever la duplicaci\u00f3n autom\u00e1tica del tr\u00e1fico de las aplicaciones seleccionadas en caso de p\u00e9rdidas a\u00fan m\u00e1s graves que no pueden ser compensadas mediante FEC. En este caso, los datos seleccionados se transmitir\u00e1n a trav\u00e9s de todos los t\u00faneles hacia la filial receptora con posterior desduplicaci\u00f3n (eliminaci\u00f3n de copias de paquetes innecesarias). Este mecanismo aumenta notablemente la utilizaci\u00f3n de los canales, pero tambi\u00e9n mejora significativamente la fiabilidad de la transmisi\u00f3n.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Las capacidades de Cisco SD-WAN, sin an\u00e1logos directos en DMVPN\/PfR<\/h3>\n \nLa arquitectura de la soluci\u00f3n Cisco SD-WAN en algunos casos permite obtener capacidades cuya implementaci\u00f3n en el marco de DMVPN\/PfR es extremadamente dif\u00edcil, poco adecuada debido al esfuerzo necesario, o incluso imposible. Consideremos las m\u00e1s interesantes de ellas:<\/p>\n
Ingenier\u00eda de Tr\u00e1fico (TE)<\/h4>\n \nTE incluye mecanismos que permiten desviar el tr\u00e1fico de la ruta est\u00e1ndar formada por los protocolos de enrutamiento. TE se utiliza a menudo para garantizar alta disponibilidad de los servicios de red, gracias a su capacidad para trasladar r\u00e1pidamente y\/o anticipadamente tr\u00e1fico importante a una ruta alternativa (no coincidente), con el fin de garantizar una mejor calidad del servicio o velocidad de recuperaci\u00f3n en caso de fallo en la ruta principal. <\/p>\n
La complejidad de implementar TE radica en la necesidad de calcular y reservar (verificar) previamente una ruta alternativa. En las redes MPLS de los operadores de telecomunicaciones, esta tarea se aborda utilizando tecnolog\u00edas como MPLS Traffic-Engineering junto con extensiones de protocolos IGP y el protocolo RSVP. Tambi\u00e9n, recientemente, la tecnolog\u00eda de Segment Routing ha ganado popularidad, ya que est\u00e1 m\u00e1s optimizada para la configuraci\u00f3n y orquestaci\u00f3n centralizadas. En las redes WAN cl\u00e1sicas, estas tecnolog\u00edas generalmente no est\u00e1n presentes o se reducen al uso de mecanismos hop-by-hop como Policy-Based Routing (PBR), que pueden desviar el tr\u00e1fico, pero lo implementan en cada router por separado, sin tener en cuenta el estado general de la red o el resultado de PBR en pasos anteriores o posteriores. El resultado de aplicar estas opciones de TE es desalentador: el MPLS TE, debido a la complejidad de configuraci\u00f3n y operaci\u00f3n, generalmente se utiliza solo en la parte m\u00e1s cr\u00edtica de la red (n\u00facleo), y el PBR se utiliza en routers individuales sin la posibilidad de formar una pol\u00edtica PBR unificada en toda la red. Esto tambi\u00e9n se aplica a las redes basadas en DMVPN.<\/p>\n
Service-chaining (Cadenas de servicios) <\/h4>\n \nLa formaci\u00f3n de cadenas de servicios es una tarea a\u00fan m\u00e1s laboriosa en el enrutamiento cl\u00e1sico que el mecanismo de Ingenier\u00eda de Tr\u00e1fico ya descrito. En este caso, no solo es necesario crear una ruta especial para una aplicaci\u00f3n de red espec\u00edfica, sino tambi\u00e9n garantizar la posibilidad de redirigir el tr\u00e1fico de la red en ciertos (o en todos) nodos de la red SD-WAN para su procesamiento por una aplicaci\u00f3n o servicio espec\u00edfico (MCF, Balanceo, Cach\u00e9, Inspecci\u00f3n de tr\u00e1fico, etc.). Es necesario tener la capacidad de controlar el estado de estos servicios externos para evitar situaciones de black-holing, as\u00ed como contar con mecanismos que permitan ubicar dichos servicios externos homog\u00e9neos en diversas geo-localizaciones, con la capacidad de que la red elija autom\u00e1ticamente el nodo de servicio m\u00e1s \u00f3ptimo para el procesamiento del tr\u00e1fico de cada sucursal. En el caso de Cisco SD-WAN, esto se puede lograr f\u00e1cilmente al crear una pol\u00edtica centralizada correspondiente que<\/p>\n
\u00bfCu\u00e1l es el resultado?<\/h2>\n \nEs evidente que tanto DMVPN (con o sin Performance Routing) como Cisco SD-WAN abordan en \u00faltima instancia tareas muy similares<\/b> en relaci\u00f3n con la red WAN distribuida de la organizaci\u00f3n. A su vez, las diferencias arquitect\u00f3nicas y funcionales significativas de la tecnolog\u00eda Cisco SD-WAN llevan el proceso de resoluci\u00f3n de estas tareas a un nivel de calidad diferente<\/b>. En resumen, se pueden se\u00f1alar las siguientes diferencias significativas entre las tecnolog\u00edas SD-WAN y DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR utilizan en general tecnolog\u00edas probadas para la construcci\u00f3n de redes VPN superpuestas y, en cuanto a la data-plane, son similares a la tecnolog\u00eda m\u00e1s moderna SD-WAN; sin embargo, existen varias limitaciones como la necesidad de una configuraci\u00f3n est\u00e1tica obligatoria de los enrutadores y la elecci\u00f3n de topolog\u00edas est\u00e1 restringida a Hub-n-Spoke. Por otro lado, DMVPN\/PfR cuenta con algunas funcionalidades que a\u00fan no est\u00e1n disponibles dentro de SD-WAN (se refiere a per-application BFD).<\/li>\n En cuanto a la tecnolog\u00eda de control-plane, se diferencian fundamentalmente. Considerando el procesamiento centralizado de protocolos de se\u00f1alizaci\u00f3n, SD-WAN permite, en particular, reducir significativamente los dominios de fallos y \"desvincular\" el proceso de transmisi\u00f3n del tr\u00e1fico de usuario de la interacci\u00f3n de se\u00f1alizaci\u00f3n; la moment\u00e1nea indisponibilidad de los controladores no afecta la capacidad de transmitir tr\u00e1fico de usuario. Al mismo tiempo, la moment\u00e1nea indisponibilidad de alguna sucursal (incluida la central) no afecta de ninguna manera la capacidad de las dem\u00e1s sucursales para interactuar entre s\u00ed y con los controladores.<\/li>\n La arquitectura para la formaci\u00f3n y aplicaci\u00f3n de pol\u00edticas de gesti\u00f3n del tr\u00e1fico en el caso de SD-WAN tambi\u00e9n supera a la de DMVPN\/PfR; el geo-reservimiento est\u00e1 significativamente mejor implementado, no hay vinculaci\u00f3n a Hub, hay m\u00e1s posibilidades para una configuraci\u00f3n detallada de pol\u00edticas y la lista de escenarios de gesti\u00f3n del tr\u00e1fico implementados tambi\u00e9n es significativamente mayor.<\/li>\n El proceso de orquestaci\u00f3n de la soluci\u00f3n tambi\u00e9n difiere considerablemente. DMVPN asume que hay par\u00e1metros conocidos de antemano que deben de alguna manera reflejarse en la configuraci\u00f3n, lo que limita un poco la flexibilidad de la soluci\u00f3n y la capacidad de realizar cambios din\u00e1micos. Por su parte, SD-WAN parte de la paradigma de que en el momento inicial de conexi\u00f3n el enrutador \"no sabe nada\" sobre sus controladores, pero sabe \"a qui\u00e9n preguntar\"; esto es suficiente no solo para el establecimiento autom\u00e1tico de conexi\u00f3n con los controladores, sino tambi\u00e9n para la formaci\u00f3n autom\u00e1tica de una topolog\u00eda de data-plane completamente conectada, que luego se puede ajustar\/cambiar de manera flexible mediante pol\u00edticas.<\/li>\n En t\u00e9rminos de gesti\u00f3n centralizada, automatizaci\u00f3n y monitoreo, SD-WAN supera notablemente las capacidades de DMVPN\/PfR, que son el resultado de la evoluci\u00f3n de tecnolog\u00edas cl\u00e1sicas y se basan en gran medida en la l\u00ednea de comandos CLI y en el uso de sistemas NMS basados en plantillas. <\/li>\n En SD-WAN, en comparaci\u00f3n con DMVPN, los requisitos de seguridad han alcanzado un nuevo nivel cualitativo. Los principios clave son: confianza cero, escalabilidad y autenticaci\u00f3n de dos factores.<\/li>\n<\/ul>\n\nDe estas observaciones simples puede surgir la impresi\u00f3n err\u00f3nea de que crear una red basada en DMVPN\/PfR ha perdido toda relevancia hoy en d\u00eda. Esto, por supuesto, no es del todo cierto. Por ejemplo, en casos donde se utilizan muchos equipos obsoletos en la red y no hay posibilidad de reemplazarlos, DMVPN puede permitir combinar dispositivos \"viejos\" y \"nuevos\" en una \u00fanica red geo-distribuida con muchas de las ventajas descritas anteriormente.<\/p>\n
Por otro lado, es importante recordar que todos los enrutadores corporativos actuales de Cisco basados en IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) hoy en d\u00eda soportan cualquier modo de operaci\u00f3n, tanto el enrutamiento cl\u00e1sico como DMVPN y SD-WAN. La elecci\u00f3n depende de las necesidades actuales y de la comprensi\u00f3n de que en cualquier momento se puede comenzar a avanzar hacia una tecnolog\u00eda m\u00e1s avanzada en el mismo equipo.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t